Technology of proof of anteriority via blockchain
Introduction
In order to create proof of anteriority from information (hereinafter "data", i.e., for example, a song, a text, an image, etc.), it is necessary to link this information to an immutable timestamp.
​
Due to their transparent and resilient nature, public blockchains are not only relevant but also highly efficient infrastructures for time-stamping information.
​
Different approaches are also possible for time-stamping information/data on a blockchain:
​
-
1a) to record the entire data on the blockchain, or
​
-
1b) to record only the digital fingerprint (timestamp) of the data concerned.
​
-
Approach 1a) is not only more costly than approach 1b), but also significantly slows down the operation of a blockchain. What's more, both approaches are unable to time-stamp large amounts of data (proof of anteriority), although they are certainly transparent and easy to verify.
​
-
2) to anchor the root node of a Merkle tree, where each leaf (of the Merkle tree) contains the hash representation of the data concerned. A single transaction is thus created for a given period, regardless of the quantity of information to be time-stamped.
​
In addition, on blockchains compatible with the Ethereum Virtual Machine (EVM), it is possible to write the data, its digital fingerprint or the root node of a Merkle tree, into smart contracts instead of including them in the transaction. This approach makes it possible to interact with smart contracts using the data or its digital fingerprint.
The anchoring mechanism
0) First, a genesis hash is created as the basis of a Merkle tree (see "0x34c3aa" below).
​
Then, 1) another hash (see below "0x34c3aa") is created from the first information/data (cf. "Doc 1") and added to the metadata of the aforementioned Doc 1, which then contains information such as file author(s), file name, file duration (if applicable) and so on.
​
The next step, 2) consists of combining this last hash with the last node of the Merkle tree in order to create the next level node (hash "0x3eed44") until a single root hash is finally obtained ("0x6590ab") as a combination of all the previous hashes of the other information/data, such as, in our example below, "Doc 2", "Doc 3" and "Doc 4".
​
Thus, the sequence of points 1) and 2) applies equally to Doc 2, Doc 3 and Doc 4. This root hash ("0x6590ab") consequently represents the entire content of the Merkle tree and is incorporated at regular intervals into a new blockchain transaction.
Figure 1
Figure 2
In the end, a certificate ("json" file included in a pdf) is delivered to the user, containing the document's metadata as well as the information needed to prove the document's anteriority (in the event, for example, of a third party contesting this anteriority), that is, a hash of the transaction and the path to the root of the anchorage.
​
Consequently, the verification process consists of recreating the document hash (and its metadata) from the original file (or an exact duplicate of it), and then recreating the root hash from the root path contained in the certificate, in order to prove the anteriority of the file concerned beyond any doubt.