Among the dozens of consensus algorithms used by the blockchains of different projects, there is also Proof of History, a solution developed by the team of Project Solana in order to eliminate definitively the problems related to the truthfulness of timestamps in a distributed network.
Decentralised networks have partially solved this problem by using reliable but centralised third-party timestamping solutions. For example, Google’s Spanner relies on several atomic clocks that are synchronised with each other and with the various data centres.
This problem, however, must be solved differently with blockchains, as they are trustless systems. Nodes in the network cannot trust an external source or a timestamp that appears in a message.
Solutions like Hashgraph, for example, solve this problem with an average timestamp. Each message displayed by the network is signed and marked by a higher-level entity. This results in an average synchronisation timestamp based on all signed and certified messages.
However, this is not an efficient solution, as all messages must be collected from the network and signed. Then the average timestamp must be calculated and redistributed over the network. A system that is too slow.
This is where the Proof of History consensus algorithm comes in.
Proof of History: the blockchain algorithm for time synchronisation
Instead of using the classic concept of timestamps, it is possible to prove that a message/event occurred at a certain time after one event but before another.
For example, when taking a photo of the cover of the New York Times it creates proof that the photo was taken after the publication of the newspaper. With Proof of History, it is possible to create a record that shows that a certain event occurred at a specific time, before or after other events, all without using timestamps or third-party synchronisation systems.
Proof of History is a high-frequency Delay Verifiable Function. This means that the function requires a number of sequential steps to evaluate and produce a unique and reliable result which is then made public.
In the case of the implementation carried out in Solana, a function is used that employs a sequential hashing system resistant to pre-images (pre-prepared images of hashes).
To do this, the output of the operation becomes the input of the next operation. Then, the current count, status and output are periodically recorded.
In the case of the SHA256 hashing function, this process is impossible to parallelise without a Brute Force attack using 2¹²⁸ cores.
Input
The data can be inserted in the sequence by adding the hash of the data to the previously generated status. Subsequently are published the status, the input data and the count.
When adding the input, all future outputs will change unpredictably. It is therefore still impossible to parallelise the function, and as long as the SHA256 is immune to pre-images and collisions, it is practically impossible to create an input that generates the desired hash or to create an alternative history with the same hashes.
This proves that a certain amount of time has passed between two operations. It is possible to prove that the data was created before the inclusion.
Back reference
Proof of History inputs may have references to previous Proof of History events. The backreference can be inserted as part of a message signed with the user’s signature, which means that it cannot be modified without the user’s private key.
With reference to the example of the newspaper, it would be equivalent to the user taking a picture with the newspaper in hand.
Since the message contains the hash 0xdeadc0de, it is known that it was generated after the creation of the count 510144806912. The message is then inserted back into the sequential function. So, returning to the example, it is as if once the photo with the newspaper in hand has been taken, the next day the newspaper will publish the photo of the user holding the newspaper.
