Here are some attempts to compare Proof of History (PoH), as used by the Solana blockchain, with Proof of Work (PoW). Comparisons to real-world activities, such as dice rolling or outer-space rubber-stamp throwing are also included.
More on blockchain in the simple, humorous, yet thorough article «Hitchhiker’s Guide to the Blockchain». I also wrote a shorter Solana/Proof of History explanation in German 🇩🇪.
Please note: This post represents my understanding of how PoH works; I have not been able to get positive/negative feedback about it; I’m still looking forward to confirmations or corrections.
[Added 2022-03-20] Before we look at PoH, let’s revisit some of the PoW analogies, parallel dice rolling and rubber-stamp throwing. Then, the differences between the PoW analogies and their PoH equivalents, serialized dice rolling and rubber-stamp throwing. Plus, you will find a micro-blockchain analogy as well.
Proof of Work
Technical description
You may already be aware of the technical description of Proof of Work, as made popular by Bitcoin: A seemingly infinite army of processors tuned to perform SHA-256 calculations, repeatedly hashes the header of a candidate block, until a “small enough” value results.
“Small enough” is defined by the current difficulty, which is regularly adjusted (about every two weeks) such that the average time to mine a block remains at 10 minutes.
SHA-256 hashing (as every other cryptographic hash function) is a deterministic operation, so calculating the hash over the same block results multiple times will result in the same values. Therefore, the Bitcoin block header contains a Nonce field, which will be changed before every hash operation.
This operation can be fully parallelized, i.e., any number of hash processors can perform their calculations in parallel, without a need to coordinate.
Dice rolling analogy
At the current difficulty, about 120 x 10²¹ hash operations are required before a hash results meets the difficulty requirement (120 trilliard in the long scale; or 120 sextillion in the short scale). This is equivalent of rolling a dice with 120 trilliard sides.
As this is hard to imagine: If we divide the earth’s surface (510 million km²) by 120 x 10²¹, we get 42 cm². Thus, the earth could serve as an appropriate die, if each die side was 6 cm by 7 cm big.
(Ok, all right, it is still hard to imagine. But now, it is somewhat clearer that this is really an unbelievably humongous number.)
Outer space rubber stamp throwing
Another “useful” analogy might be to throw rubber stamps from space until they hit a randomly placed document’s 6 by 7 cm² stamp area (again, a chance of 1 in 120 trilliard per throw). This can be completely parallelized, given enough stamps and hands to throw them.
Proof of History
PoW combines consensus and progress into essentially a single mechanism. Solana, however, splits this into two:
- PoH is used to make and record progress at each node individually, while
- PBFT (Practical Byzantine Fault Tolerance) is used to reach consensus, merging the partial histories.
Technical description
Proof of History aims to avoid the energy waste associated with Proof of Work. Hash computations can no longer be parallelized, therefore, there is no incentive to have more than one processor per node performing the calculations.
The hash operations are strictly serialized, i.e., it is impossible to begin the calculations necessary for the next hash before the calculations for the previous hash have ended.
Also, there is no shortcut. Let’s look at a counter-example: If each operation were a linear operation, e.g., an addition with a constant C or a multiplication with a fixed factor F, several steps could be combined. I.e., hundred steps could be performed at the same time by just adding 100*C or multiplying by 100*F. By their very design, cryptographic hash functions need to be non-linear, therefore, these shortcuts are impossible.
While creation is strictly linear and serial, verification, however, can be parallelized: Someone who has received a large number of these PoH fragments between two well-defined locations, can verify the accuracy of each of those fragments in parallel to all other fragments. (The verification of a single fragment would still require to go through the hashes strictly in sequence, though.)
Dice rolling analogy
Probably the least helpful (and entertaining) of these PoH analogies is dice rolling: You can roll the next die only after the previous was rolled.
Outer space rubber stamp throwing
More fun (if still somewhat outlandish, even literally) is it to have our space-faring blockchain enthusiasts throw auto-homing rubber stamps:
The way the rubber of the stamp is carved determines the aerodynamics of the falling stamp. Imagine, for a second, that the carving would affect the trajectory in the atmosphere in such a way, that the same carving results in the same landing destination, independent of where the stamp was thrown from and how fast it was thrown. Because our fairy tale rubber stamp aerodynamics are so complicated, nobody can determine the landing location without actually throwing the stamp and waiting for it to land.
Now, the PoH rule is to throw the next stamp only after the first one has landed, carving the previous stamp’s exact location into the new stamp’s rubber. This results in a pre-determined pattern of landing locations to be recorded by the stamps. Even though it is pre-determined, it cannot be calculated without actually throwing the stamps and waiting for each of them to land.
Micro-Blockchain analogy
A third analogy would be to look at what each mining node produces as a blockchain, with slightly changed rules:
- There is no endless dice rolling to create a new block, i.e., every “micro-block” is valid (otherwise said, you always roll a winning one, or “every block counts”)
- Only micro-blocks that have any transactions in them will be output, together with information about the number of skipped empty blocks. (This is all the information that is required to reconstruct those blocks that were skipped.)
This can be seen in the image on the right: The hash chain (H) makes continuous progress. If any transaction T arrives, it is included in the hash calculation and the result R output and recorded, ready for inclusion into the next actual blockchain block (which we could also call “macro-block”).
