From 209040e80e8403c16ffd5ac115873a0503920983 Mon Sep 17 00:00:00 2001 From: Greg Fitzgerald Date: Tue, 4 Dec 2018 20:52:38 -0700 Subject: [PATCH] Free up term "finality" to imply "economic finality" (#2002) * leader finality -> confirmation Free up term "finality" to imply "economic finality." * Reorder chapters --- book/src/SUMMARY.md | 2 +- book/src/cluster.md | 35 ++++++++++++++++++----------------- book/src/leader-rotation.md | 4 ++-- book/src/terminology.md | 2 +- rfcs/0007-staking-rewards.md | 2 +- 5 files changed, 23 insertions(+), 22 deletions(-) diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 224b39b58..00f16d31c 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -10,8 +10,8 @@ - [A Solana Cluster](cluster.md) - [Synchronization](synchronization.md) - - [Ledger Replication](storage.md) - [Leader Rotation](leader-rotation.md) + - [Ledger Replication](storage.md) - [Anatomy of a Fullnode](fullnode.md) - [TPU](tpu.md) diff --git a/book/src/cluster.md b/book/src/cluster.md index 797e9ec48..a97dd3ff0 100644 --- a/book/src/cluster.md +++ b/book/src/cluster.md @@ -33,10 +33,10 @@ its *control plane*. The control plane is implemented using a *gossip* protocol, meaning that a node may register with any existing node, and expect its registration to propagate to all nodes in the cluster. The time it takes for all nodes to synchronize is proportional to the square of the number of -nodes participating in the cluster. Algorithmically, that's considered very slow, -but in exchange for that time, a node is assured that it eventually has all the -same information as every other node, and that that information cannot be -censored by any one node. +nodes participating in the cluster. Algorithmically, that's considered very +slow, but in exchange for that time, a node is assured that it eventually has +all the same information as every other node, and that that information cannot +be censored by any one node. ## Sending Transactions to a Cluster @@ -48,28 +48,29 @@ cluster's *data plane*. Once on the data plane, the transactions are validated by validator nodes and replicated by replicator nodes, effectively appending them to the ledger. -## Finalizing Transactions +## Confirming Transactions -A Solana cluster is capable of subsecond *leader finality* for up to 150 nodes +A Solana cluster is capable of subsecond *confirmation* for up to 150 nodes with plans to scale up to hundreds of thousands of nodes. Once fully -implemented, finality times are expected to increase only with the logarithm of -the number of validators, where the logarithm's base is very high. If the base -is one thousand, for example, it means that for the first thousand nodes, -finality will be the duration of three network hops plus the time it takes the -slowest validator of a supermajority to vote. For the next million nodes, -finality increases by only one network hop. +implemented, confirmation times are expected to increase only with the +logarithm of the number of validators, where the logarithm's base is very high. +If the base is one thousand, for example, it means that for the first thousand +nodes, confirmation will be the duration of three network hops plus the time it +takes the slowest validator of a supermajority to vote. For the next million +nodes, confirmation increases by only one network hop. -Solana defines leader finality as the duration of time from when the leader +Solana defines confirmation as the duration of time from when the leader timestamps a new entry to the moment when it recognizes a supermajority of ledger votes. -A gossip network is much too slow to achieve subsecond finality once the +A gossip network is much too slow to achieve subsecond confirmation once the network grows beyond a certain size. The time it takes to send messages to all nodes is proportional to the square of the number of nodes. If a blockchain -wants to achieve low finality and attempts to do it using a gossip network, it -will be forced to centralize to just a handful of nodes. +wants to achieve low confirmation and attempts to do it using a gossip network, +it will be forced to centralize to just a handful of nodes. -Scalable finality can be achieved using the follow combination of techniques: +Scalable confirmation can be achieved using the follow combination of +techniques: 1. Timestamp transactions with a VDF sample and sign the timestamp. 2. Split the transactions into batches, send each to separate nodes and have diff --git a/book/src/leader-rotation.md b/book/src/leader-rotation.md index 4294d72a0..1365782af 100644 --- a/book/src/leader-rotation.md +++ b/book/src/leader-rotation.md @@ -77,9 +77,9 @@ slot. normal 3. `M` cycles through the ranks until one of them is leader, generating ticks for slots where the leader is in `K`. -4. `M` validators observe 10% of the vote pool, finality is not reached. +4. `M` validators observe 10% of the vote pool, confirmation is not reached. 5. `M` and `K` reconnect. -6. `M` validators cancel their votes on `M`, which has not reached finality, and +6. `M` validators cancel their votes on `M`, which has not reached confirmation, and re-cast on `K` (after their vote lockout on `M`). ### Leader Timeout diff --git a/book/src/terminology.md b/book/src/terminology.md index eabac94be..859086be2 100644 --- a/book/src/terminology.md +++ b/book/src/terminology.md @@ -40,7 +40,7 @@ consensus. An entry on the [ledger](#ledger) either a [tick](#tick) or a [transactions entry](#transactions-entry). -#### leader finality +#### confirmation The wallclock duration between a [leader](#leader) creating a [tick entry](#tick) and recognizing a supermajority of [ledger votes](#ledger-vote) diff --git a/rfcs/0007-staking-rewards.md b/rfcs/0007-staking-rewards.md index f042c2d75..dd03cdb09 100644 --- a/rfcs/0007-staking-rewards.md +++ b/rfcs/0007-staking-rewards.md @@ -16,7 +16,7 @@ To become a Solana validator, a network node must deposit/lock-up some amount of - *Validation period*: a minimum duration for which the deposited SOL will be inaccessible, at risk of slashing (see slashing rules below) and earning network rewards for the validator participation. Likely duration of months to a year. - *Cool-down period*: a duration of time following the submission of a 'withdrawal' transaction. During this period validation responsibilities have been removed and the funds continue to be inaccessible. Accumulated rewards should be delivered at the end of this period, along with the return of the initial deposit. -Solana's trustless sense of time and ordering provided by its PoH data structure, along with its [avalanche](https://www.youtube.com/watch?v=qt_gDRXHrHQ&t=1s) data broadcast and transmission design, should provide sub-second finality times that scale with the log of the number of nodes in the network. This means we shouldn't have to restrict the number of validating nodes with a prohibitive 'minimum deposits' and expect nodes to be able to become validators with nominal amounts of SOL staked. This should also render validation pools, a proposed solution for economic censorship imposed by minimum staking amounts currently described in Casper, unnecessary and remove the concern for needing to put slashable stake at risk while relying on others to play by the rules. +Solana's trustless sense of time and ordering provided by its PoH data structure, along with its [avalanche](https://www.youtube.com/watch?v=qt_gDRXHrHQ&t=1s) data broadcast and transmission design, should provide subsecond confirmation times that scale with the log of the number of nodes in the network. This means we shouldn't have to restrict the number of validating nodes with a prohibitive 'minimum deposits' and expect nodes to be able to become validators with nominal amounts of SOL staked. This should also render validation pools, a proposed solution for economic censorship imposed by minimum staking amounts currently described in Casper, unnecessary and remove the concern for needing to put slashable stake at risk while relying on others to play by the rules. ### Stake-weighted Rewards