diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 3bbeb230ce..b3d9cd48a9 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -10,8 +10,6 @@ - [A Solana Cluster](cluster.md) - [Synchronization](synchronization.md) - - [Introduction to VDFs](vdf.md) - - [Proof of History](poh.md) - [Ledger Replication](storage.md) - [Leader Rotation](leader-scheduler.md) diff --git a/book/src/poh.md b/book/src/poh.md deleted file mode 100644 index b76776fd4c..0000000000 --- a/book/src/poh.md +++ /dev/null @@ -1,43 +0,0 @@ -# Proof of History - -[Proof of History overview](https://medium.com/solana-labs/proof-of-history-a-clock-for-blockchain-cf47a61a9274) - -## Relationship to consensus mechanisms - -Most confusingly, a Proof of History (PoH) is more similar to a Verifiable -Delay Function (VDF) than a Proof of Work or Proof of Stake consensus -mechanism. The name unfortunately requires some historical context to -understand. Proof of History was developed by Anatoly Yakovenko in November of -2017, roughly 6 months before we saw a [paper using the term -VDF](https://eprint.iacr.org/2018/601.pdf). At that time, it was commonplace to -publish new proofs of some desirable property used to build most any blockchain -component. Some time shortly after, the crypto community began charting out all -the different consensus mechanisms and because most of them started with "Proof -of", the prefix became synonymous with a "consensus" suffix. Proof of History -is not a consensus mechanism, but it is used to improve the performance of -Solana's Proof of Stake consensus. It is also used to improve the performance -of the replication and storage protocols. To minimize confusion, Solana may -rebrand PoH to some flavor of the term VDF. - - -## Relationship to VDFs - -A desirable property of a VDF is that verification time is very fast. Solana's -approach to verifying its delay function is proportional to the time it took to -create it. Split over a 4000 core GPU, it is sufficiently fast for Solana's -needs, but if you asked the authors the paper cited above, they might tell you -(and have) that Solana's approach is algorithmically slow it shouldn't be -called a VDF. We argue the term VDF should represent the category of verifiable -delay functions and not just the subset with certain performance -characteristics. Until that's resolved, Solana will likely continue using the -term PoH for its application-specific VDF. - -Another difference between PoH and VDFs used only for tracking duration, is -that PoH's hash chain includes hashes of any data the application observed. -That data is a double-edged sword. On one side, the data "proves history" - -that the data most certainly existed before hashes after it. On the side, it -means the application can manipulate the hash chain by changing *when* the data -is hashed. The PoH chain therefore does not serve as a good source of -randomness whereas a VDF without that data could. Solana's leader selection -algorithm (TODO: add link), for example, is derived only from the VDF *height* -and not its hash at that height. diff --git a/book/src/synchronization.md b/book/src/synchronization.md index f568d4845a..a0e75870ae 100644 --- a/book/src/synchronization.md +++ b/book/src/synchronization.md @@ -35,4 +35,65 @@ blockchain! > [\[L.Lamport > (1984)\]](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.71.1078) +## Verifiable Delay Functions + +A Verifiable Delay Function is conceptually a water clock where its water marks +can be recorded and later verified that the water most certainly passed +through. Anatoly describes the water clock analogy in detail here: + +[water clock analogy](https://medium.com/solana-labs/proof-of-history-explained-by-a-water-clock-e682183417b8) + +The same technique has been used in Bitcoin since day one. The Bitcoin feature +is called nLocktime and it can be used to postdate transactions using block +height instead of a timestamp. As a Bitcoin client, you'd use block height +instead of a timestamp if you don't trust the network. Block height turns out +to be an instance of what's being called a Verifiable Delay Function in +cryptography circles. It's a cryptographically secure way to say time has +passed. In Solana, we use a far more granular verifiable delay function, a SHA +256 hash chain, to checkpoint the ledger and coordinate consensus. With it, we +implement Optimistic Concurrency Control and are now well en route towards that +theoretical limit of 710,000 transactions per second. + +## Proof of History + +[Proof of History overview](https://medium.com/solana-labs/proof-of-history-a-clock-for-blockchain-cf47a61a9274) + +### Relationship to consensus mechanisms + +Most confusingly, a Proof of History (PoH) is more similar to a Verifiable +Delay Function (VDF) than a Proof of Work or Proof of Stake consensus +mechanism. The name unfortunately requires some historical context to +understand. Proof of History was developed by Anatoly Yakovenko in November of +2017, roughly 6 months before we saw a [paper using the term +VDF](https://eprint.iacr.org/2018/601.pdf). At that time, it was commonplace to +publish new proofs of some desirable property used to build most any blockchain +component. Some time shortly after, the crypto community began charting out all +the different consensus mechanisms and because most of them started with "Proof +of", the prefix became synonymous with a "consensus" suffix. Proof of History +is not a consensus mechanism, but it is used to improve the performance of +Solana's Proof of Stake consensus. It is also used to improve the performance +of the replication and storage protocols. To minimize confusion, Solana may +rebrand PoH to some flavor of the term VDF. + +### Relationship to VDFs + +A desirable property of a VDF is that verification time is very fast. Solana's +approach to verifying its delay function is proportional to the time it took to +create it. Split over a 4000 core GPU, it is sufficiently fast for Solana's +needs, but if you asked the authors the paper cited above, they might tell you +(and have) that Solana's approach is algorithmically slow it shouldn't be +called a VDF. We argue the term VDF should represent the category of verifiable +delay functions and not just the subset with certain performance +characteristics. Until that's resolved, Solana will likely continue using the +term PoH for its application-specific VDF. + +Another difference between PoH and VDFs used only for tracking duration, is +that PoH's hash chain includes hashes of any data the application observed. +That data is a double-edged sword. On one side, the data "proves history" - +that the data most certainly existed before hashes after it. On the side, it +means the application can manipulate the hash chain by changing *when* the data +is hashed. The PoH chain therefore does not serve as a good source of +randomness whereas a VDF without that data could. Solana's leader selection +algorithm (TODO: add link), for example, is derived only from the VDF *height* +and not its hash at that height. diff --git a/book/src/vdf.md b/book/src/vdf.md deleted file mode 100644 index 414148d27d..0000000000 --- a/book/src/vdf.md +++ /dev/null @@ -1,18 +0,0 @@ -# Verifiable Delay Functions - -A Verifiable Delay Function is conceptually a water clock where its water marks -can be recorded and later verified that the water most certainly passed -through. Anatoly describes the water clock analogy in detail here: - -[water clock analogy](https://medium.com/solana-labs/proof-of-history-explained-by-a-water-clock-e682183417b8) - -The same technique has been used in Bitcoin since day one. The Bitcoin feature -is called nLocktime and it can be used to postdate transactions using block -height instead of a timestamp. As a Bitcoin client, you'd use block height -instead of a timestamp if you don't trust the network. Block height turns out -to be an instance of what's being called a Verifiable Delay Function in -cryptography circles. It's a cryptographically secure way to say time has -passed. In Solana, we use a far more granular verifiable delay function, a SHA -256 hash chain, to checkpoint the ledger and coordinate consensus. With it, we -implement Optimistic Concurrency Control and are now well en route towards that -theoretical limit of 710,000 transactions per second.