gaspersic/solana
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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

Browse Source 
* leader finality -> confirmation

Free up term "finality" to imply "economic finality."

* Reorder chapters
This commit is contained in:
Greg Fitzgerald
2018-12-04 20:52:38 -07:00
committed by GitHub
parent 2112c87e13
commit 209040e80e
5 changed files with 23 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
book/src/SUMMARY.md
View File

@@ -10,8 +10,8 @@
- [A Solana Cluster](cluster.md) - [A Solana Cluster](cluster.md)
- [Synchronization](synchronization.md) - [Synchronization](synchronization.md)
- [Ledger Replication](storage.md)
- [Leader Rotation](leader-rotation.md) - [Leader Rotation](leader-rotation.md)
- [Ledger Replication](storage.md)
- [Anatomy of a Fullnode](fullnode.md) - [Anatomy of a Fullnode](fullnode.md)
- [TPU](tpu.md) - [TPU](tpu.md)

35
book/src/cluster.md
View File

@@ -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 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 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 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, nodes participating in the cluster. Algorithmically, that's considered very
but in exchange for that time, a node is assured that it eventually has all the slow, but in exchange for that time, a node is assured that it eventually has
same information as every other node, and that that information cannot be all the same information as every other node, and that that information cannot
censored by any one node. be censored by any one node.
## Sending Transactions to a Cluster ## 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 by validator nodes and replicated by replicator nodes, effectively appending
them to the ledger. 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 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 implemented, confirmation times are expected to increase only with the
the number of validators, where the logarithm's base is very high. If the base logarithm of the number of validators, where the logarithm's base is very high.
is one thousand, for example, it means that for the first thousand nodes, If the base is one thousand, for example, it means that for the first thousand
finality will be the duration of three network hops plus the time it takes the nodes, confirmation will be the duration of three network hops plus the time it
slowest validator of a supermajority to vote. For the next million nodes, takes the slowest validator of a supermajority to vote. For the next million
finality increases by only one network hop. 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 timestamps a new entry to the moment when it recognizes a supermajority of
ledger votes. 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 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 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 wants to achieve low confirmation and attempts to do it using a gossip network,
will be forced to centralize to just a handful of nodes. 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. 1. Timestamp transactions with a VDF sample and sign the timestamp.
2. Split the transactions into batches, send each to separate nodes and have 2. Split the transactions into batches, send each to separate nodes and have

4
book/src/leader-rotation.md
View File

@@ -77,9 +77,9 @@ slot.
normal normal
3. `M` cycles through the ranks until one of them is leader, generating ticks for 3. `M` cycles through the ranks until one of them is leader, generating ticks for
slots where the leader is in `K`. 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. 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`). re-cast on `K` (after their vote lockout on `M`).
### Leader Timeout ### Leader Timeout

2
book/src/terminology.md
View File

@@ -40,7 +40,7 @@ consensus.
An entry on the [ledger](#ledger) either a [tick](#tick) or a [transactions An entry on the [ledger](#ledger) either a [tick](#tick) or a [transactions
entry](#transactions-entry). entry](#transactions-entry).
#### leader finality #### confirmation
The wallclock duration between a [leader](#leader) creating a [tick The wallclock duration between a [leader](#leader) creating a [tick
entry](#tick) and recognizing a supermajority of [ledger votes](#ledger-vote) entry](#tick) and recognizing a supermajority of [ledger votes](#ledger-vote)

2
rfcs/0007-staking-rewards.md
View File

@@ -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. - *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. - *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 ### Stake-weighted Rewards