Free up term "finality" to imply "economic finality" (#2002)

* leader finality -> confirmation Free up term "finality" to imply "economic finality." * Reorder chapters
solana-labs · Dec 5, 2018 · 209040e · 209040e
1 parent 2112c87
commit 209040e
Show file tree

Hide file tree

Showing 5 changed files with 24 additions and 23 deletions.
diff --git 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
@@ -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.
-
-Solana defines leader finality as the duration of time from when the leader
+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 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
@@ -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
@@ -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
@@ -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