Enforcing concestency makes it resiliant to attacks and they do this by requiring that the last observed output of the sequence be included in their next input. A malicious Proof of History generator could produce a hidden sequence with the events in reverse order but this would mean that the most recent output they consider to be valid, is not the same one as with all other generators. Through this, the consumers of the sequence know that it is an invalid sequence due to it's invalid referencing. 

Consistency in Proof of History

4000 hashes per second would generate an additional 160 kilobytes of data
and would require access to a GPU with 4000 cores and roughly 0.25-0.75
milliseconds of time to verify

Proof of History Overhead

If you pair different proof of history generators together and use their hash outputs as hash inputs for other generators, it becomes easy to track and validate each one much faster as they are dependent on each other. If you have generators A, B, and C, we know A and B share hashes and B and C share hashes which then creates a transitive property between the three where we can infer dependency between A and C despite them not being synchronized directly. 

Solana Horizontal Scaling

The sequence can be verified correct by a multicore computer in much less time than it took to generate it because the verifier can split up the sequence of hashes and their indexes to verify them in parallel. To generate the hashes, they had to be computed sequentially as they build off of each other but the verification process can simply cross-reference data in parallel and take only as long as the equation (total number of hashes)/(Hashes per second per core * Number of cores available to verify). Considering modern GPUs have hundreds or thousands of cores, the time consumption becomes increasingly small to verify.

Verification in Proof of History

This system can also be used to generate timestamps based around events. The hash output can simply be a unique hash of arbitrary event data in combination with the hash input, thus giving a hash output that's uniqueness is generated from the appendment of the data associated with the event. This then represents, through the hash output, when these hashes were computed as you can see when the event data was appended.

Timestamp for Events in Proof of History

The system is designed such that a computer runs a cryptographic hash function, whose output cannot be predicted without running the function. What the computer does it uses the output of the first hash as an input of the second hash and so forth until you reach the nth hash. HashN represents the actual output. The computer only needs to publish a subset of the hashes and indices and, if each is correct, they only could have been computed by computing all other hashes before it, thus represproving that the work had been done.

Proof of History Description

- Description 
- Timestamp for Events
- Verification
- Horizontal Scaling
- Consistency
- Overhead
- Attacks

Learn Before

Related

Learn After