Understanding Proof of History

Proof of History is NOT a consensus mechanism, it is a way for leaders to know when to start mining or producing blocks, and for validators, it is a way to verify that the leaders are taking the turns correctly.

Each slot has a duration which is counted in ‘Ticks’, If you are validator #34, you need to wait for 2 slots, and have to count 20 ‘Ticks’

The ticks are counted in form of ‘running a hashing function’, so lets say for example, to count 1 tick, you need to run the hash function for 5 times,

1 Tick = 5 times of ‘running a hash function’
1 slot = 10 ticks
2 slot = 20 ticks
20 Ticks = 20 * 5 = 100 times of ‘running a hash function’

This means that you need to run the hash function 100 times, before producing a block

How Do You Run The Hash Function?

You can start with any random input, and create its Hash (for example, using the SHA-256 hashing)

The hash you get the first time, you use that and use that as an input the next time, and so on. This takes some time.

After generating the 100 hashes, you know its your turn to produce the new block.

When you generate the new block, you send these record of 100 hashes and send them to the valuators for them to verify. Once they check all the hashes, if they are correct, and the number of hashes is 100, etc, only then, will the validators accept your new block. Otherwise, it’s rejected.

This can be any random input, here, we are taking ‘Solana’ for example

The idea is that generating these hashes, takes some time, and generating 100 hashes (just for example) takes about the duration of 2 slots, which is about 800 milliseconds in our time.

And since you generated 100 hashes correctly, its confirmed that you waited the right amount of time, before producing a block

How Does It Make Sure Of No Fraud?

Lets say there are three leaders, with different time slots (obviously). If leader 3 is malicious and wants to produce a block before leader 2, he will needs to be extremely fast and the leader 2 will have to have a bad network - only then this will be possible - which makes it very hard for any misconduct.

Also, leaders can use only single core of the CPU, to generate these hashes, and having a lot of CPUs will not allow the leader to run the hash function faster.

Even if you had more number of CPUs, since the input for generating the next hash has to be the output of the previous one, each CPU will be waiting until it gets the previous hash - which makes it useless to use multiple of them.

Validation on the other hand, can be done by multiple GPU cores at the same time, as we already have the hashes, we just ned to cross-verify that they are correct.

So, for example, you can validate the hundred hashes a lot faster by splitting them up on four cores.

This system, helps leaders take turns at the right time and faster, without slowing down the network.

Other Use Of Proof Of History:

POH, is also used in Time-stamping and ordering transactions.

When a leader is producing a block, he gets the hash of the previous block before him, adds a transaction to it and produces a hash as an output. This outputted hash is then used as an input in generating the next hash, where he adds another transaction to get a new hash and so on.

The validators can be 100% sure that , for example, that transaction 2, happened before hash 80, since in order to generate hash 80, you need to have the transaction 2 ’s hash, this means it existed before hash 80 was even generated. This takes care of the ordering of the transactions.

Also, the transaction itself when it was sent to the leader, included the last block hash seen by the wallet on the network, so we can be 100% certain that the transaction happened after that hash was generated.

If the same hash was used in generating in generating hash 98, we can be certain that this hash (#98) was generated after transaction 2 happened, and so on. This way we can order the transactions correctly before sending it to the validators, where validators also cross-verify the timings of the transactions.

Summary of how POH mechanism works.

The validators are constantly running the hash-function to count the ticks, to know when its their turn to become the leaders and start producing blocks.

Once a validator becomes a leader, he starts getting transactions, out of which the leader removes the fraudulent transactions and verifies the correct ones, and updates its version of the ledger.

Then the leader starts ordering the transactions by including them in the hashing function, like explained earlier.

After the leader finishes with some transactions, he sends them to the validators with the ordering hashes and the empty hashes (the ones that were used to count-down during waiting for his turn)

The leader does NOT wait to finish a full block, before sending to the validators, like on other blockchains such as bitcoin.

Instead, the leader sends the finished transactions to get verified, as its working on rest of the transactions, which helps the SOLANA network, achieve these fast confirmation times.

When validators receives the finished transactions from the leader, they FIRST verify the empty hashes to make sure it is the leaders turn, then they start verifying the transactions and updating their versions of the ledger.

After the leader finishes the whole block, the validators send their votes on the block if they accept it, then the block is finalise.

One point to note here is, the next leaders takes his turn and start building on this block, before it gets voted on by the validators.

This is done to avoid slowing down of the network by waiting for votes.

Let’s say, if the previous block is rejected by the validators, and the next leader has already begun working on the previous block, then both the blocks get discarded and the previous leader is penalised.