Concepts
An of the terms used in version 2 of the protocol
Data Structure:
This are the basics to get you started but for a thorough understanding one done with the sections below have a look at references section to get a thorough understanding for example what is a witness, wtness network and how are witness hash created.
The aqua chain structure can be broken into a the following components :
Revision
A revision is the smallest portable entity within the AQP. Multiple revisions form a single portable hash chain which is serialized in JSON format. They have existed before in unsecured systems where multiple revisions form a file which can be displayed as a page. The AQP adds the cryptographic harness to secure it. With presenting a portable hash chain, it is possible to track all incremental changes stored in each revision to understand the history of a page and how it came to be. This allows us to have version control on digital assets being able to restore earlier states and to relate to them. This allows us to have historical evidence of digital assets.
Every revision is represented by a merkle-root hash representing a list of alphabetically ordered key-value pairs which are hashed (implementation example SHA3-512). This allows us to dynamically change the data structure without the need to introduce breaking protocol changes.
- The input data MUST NOT have dublicated keys as this would lead to non-deterministic ordering.
Aqua-Chain: Is a portable hash-chain. This provides immutability for the history of the file, once signed and/or witnessed with the respective security guarantees. Aqua-revisions form a portable Aqua-Chain.
There are 4 Types of Revisions:
- Content Revision: Contains the data object(the data/file encoded to base 64).This is used to secure the data integrity and reference the data object for provenance purposes.
- Signature Revision: Is used to cryptographically sign, we are currently supporting Ethereum signatures.
- Witness Revision: Used to witness the Hash to prove its existence. We are supporting Ethereum by default.
- Metadata Revision: used to ensure content revision is valid.
Page
A page is a visible representation of a file containing multiple or a single revision attributed to a shared origin. A page view could also be used to create a new revision by a used service which interfaces with the file for manipulation. In AQP all revisions share a global URI hash to attribute them together called a genesis hash.
Witness
We define witnessing as the process of observing an event. A witness is judged by their capability to recollect and share an observed event. In other words, witnessing is the process of storing input data for later playback to provide data symmetry around an event.
Witness Network
The digital service in a distributed ledger or similar infrastructure which provides transaction security and data symmetry for shared data within the network. An example of a witness network would be Ethereum.
E.g. Ethereum can be used to store a digital fingerprint of a domain snapshot of a data vault. A domain snapshot is the Merklized state of all witnessed hash chains being present in the data vault. It is required to pay the witness network for its service. In the case of Ethereum, this is done using 'Ether'. This in return allows the account owner to create an 'undeniable' proof that a specific revision and the previous revisions within a hash chain has existed.
Signature
A signature in AQP is a cryptographic signature generated by public-private key pair. The protocol should be abstract, where it will support ‘Method’ in later iterations. This will allow us to use different types of implementations such as: PGP signatures, Ethereum, or Bitcoin wallet ’s signatures.
In this specification, we use the AQP reference implementation’s signing method, which is via an Ethereum wallet.
1signature_hash = calculate_hash_sum(2 signature + public_key3)The signature is generated by a wallet signing the following message:
I sign the following page verification_hash:" +[0x0x9dab72<revision_verification_hash>]
Wallet
A wallet is a software for protecting and managing private cryptographic keys (of private-public key pairs) which are used to govern digital assets. This is done by authorization of transactions via digital signatures or by initiating decryption processes to access data.
Account
We are following Ethereum's account definition:
In general, there are two types of accounts. Externally owned accounts, controlled by private keys. And contract accounts, controlled by their contract code -- Ethereum Whitepaper
In general, we can't prove if an account owner is a person or a machine. With advancements in AI, it will become increasingly difficult to prove that a human is a human. Attempts are being made to increase trustworthiness of accounts which fall short in questions of privacy and security as they make public claims. Traditional know your customer (KYC) combined with the AQP and Aqua Identity Protocol (AIP) identification processes can provide similar "proof of being human" which can be attested to an account. This allows us to outsource the problem of identification, where we only focus on unique accounts which are sufficient for data accounting independent of humans or machines. Identity claims issued via the AIP will help to provide the context required to meaningfully interact between accounts.
For more on this topic, please read the Aqua Identity Protocol.
Domain
A domain is a unique namespace attributed to an account. It allows us to manage services and files within that namespace creating a domain of data governance After granted permissions, additional accounts can be added to share control over a domain or singular assets. To enforce boundaries of a domain, additional software like the Guardian is required.
E.g. by setting up the a data vault with your account it becomes your domain of data governance.
Transaction Security
Transaction security is an economic measure of the level of integrity assurance for a transaction. It is defined as the cost required to forge a transaction. The transaction security can be increased by cryptographic security and by strong replication of transactions. Public distributed ledger systems are highly suitable for providing very high level of transaction security at the cost of privacy and immutability (data can't be changed or deleted). Today, public distributed ledgers such as Bitcoin and Ethereum provide the highest level of transaction security.
Data Asset
Data turns into a valuable asset if it is accounted for. In an accounted form it can be easily priced, exchanged or traded.
Data Vault
Software used to store and manage data with an account. The software must apply a secure architecture and measures for keeping data assets safe. This is achieved through encryption, strong authentication and restrictive access to keep data private by default.
See Design Principles / Separation of Account and Service
Metadata
metadata_hash = calculate_hash_sum(
domain_id + time_stamp + previous_verification_hash
)
Description:
- metadata_hash: The check sum for all metadata data fields. It simplifies the hash construction and the ability to identify data corrupton in this part of the verification structure.
- domain_id: 10 digits hexadecimal randomly generated to identify the host system that runs the AQP service.
- time_stamp: time-stamp of the current revision (decimal numbers YYYYMMDDHHMMSS e.g. 20211128092608).
- previous_verification_hash: previous_revision_verification_hash if present
Witness
Witnessing allows one to undeniably prove the existence of a dataset (represented as a portable hash chain). To complete the witnessing process, a Domain Snapshot is created. This is a collection of all revision hashes within one domain. A Merkle tree is used to unify all hashes of the latest revisions of all portable hash chains within a domain into a single hash value.
The witness_event_verification_hash is written to the Witness
Network. The
witness_event_verification_hash is then generated by using the
domain_snapshot_genesis_hash and the merkle_root hash together. This
allows the page snapshot itself to also be witnessed.
A single revision which has been witnessed, will not store the whole Merkle tree, but only its relevant path to the Merkle root. Performing a Merkle proof means that its revision is included in the Merkle tree.
witness_hash = calculate_hash_sum(
domain_snapshot_genesis_hash + merkle_root +
witness_network + witness_event_transaction_hash
)
Witness network
We are using the Ethereum Network as an optional Witness Network for cryptographic time-stamping.
Encryption
according to wikipedia
In cryptography, encryption (more specifically, encoding) is the process of transforming information in a way that, ideally, only authorized parties can decode. This process converts the original representation of the information, known as plaintext, into an alternative form known as ciphertext. Despite its goal, encryption does not itself prevent interference but denies the intelligible content to a would-be interceptor.
Hash
according to investopedia
A hash is a mathematical function that converts an input of arbitrary length into an encrypted output of a fixed length. Thus, regardless of the original amount of data or file size involved, its unique hash will always be the same size. Moreover, secure hashes cannot be "reverse-engineered" to get the input from the hashed output, at least with current technology.
If you use a specific function on the same data, its hash will be identical, so you can validate that the data is the same (i.e., unaltered) if you already know its hash. A different function would deliver a different hash.
Verification Process
The verification process is a redo of the verification data generation process, and additionally a comparison of their results.
Verification of Content
All hashes are recalculated in a separate client implementation, and compared with the ones sent via the API. If the data was not altered or corrupted; nor was there a difference in the process to calculate the hash, they will match. This will create a high level of assurance that the integrity and history of the portable hash chain in question has not been altered.
Verification of Account
We cryptographically verify that the revision signature is indeed generated by the account specified in the verification data.
Verification of Time
To verify that the witness event included in a revision is correct, a
lookup and comparison of the witness_event_verification_hash on-chain is
performed and compared with the recalculated event.