Merged synchronization, PoH and VDF sections
This commit is contained in:
parent
c242467fdf
commit
acee1f7c6c
|
@ -10,8 +10,6 @@
|
||||||
|
|
||||||
- [A Solana Cluster](cluster.md)
|
- [A Solana Cluster](cluster.md)
|
||||||
- [Synchronization](synchronization.md)
|
- [Synchronization](synchronization.md)
|
||||||
- [Introduction to VDFs](vdf.md)
|
|
||||||
- [Proof of History](poh.md)
|
|
||||||
- [Ledger Replication](storage.md)
|
- [Ledger Replication](storage.md)
|
||||||
- [Leader Rotation](leader-scheduler.md)
|
- [Leader Rotation](leader-scheduler.md)
|
||||||
|
|
||||||
|
|
|
@ -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.
|
|
|
@ -35,4 +35,65 @@ blockchain!
|
||||||
> [\[L.Lamport
|
> [\[L.Lamport
|
||||||
> (1984)\]](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.71.1078)
|
> (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.
|
||||||
|
|
||||||
|
|
|
@ -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.
|
|
Loading…
Reference in New Issue