blockworks-foundation
/
solana
mirror of https://github.com/blockworks-foundation/solana.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Take 2

This commit is contained in:
Greg Fitzgerald 2018-12-11 10:24:24 -07:00
parent af22de2cfa
commit eeb31074de
1 changed files with 36 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
rfcs/0004-leader-rotation.md
View File

@ -1,23 +1,49 @@
# Leader Rotation
The goal of this RFC is to define how fullnodes rotate in taking the leader role.
At any given moment, a cluster expects only one fullnode to produce ledger
entries. By having only one leader at a time, all validators are able to replay
identical copies of the ledger. The drawback of only one leader at a time,
however, is that a malicious leader is cabable of censoring votes and
transactions. Since censoring cannot be distinguished from the network dropping
packets, the cluster cannot simply elect a single node to hold the leader role
indefinitely. Instead, the cluster minimizes the influence of a malcioius
leader by rotating which node takes the lead.
Each validator selects the expected leader using the same algorithm, described
below. When the validator receives a new signed ledger entry, it can be certain
that entry was produced by the expected leader.
## Leader Schedule Generation
Leader schedule is decided via a predefined seed. The process is as follows:
Leader schedule is generated using a predefined seed. The process is as follows:
1. Periodically use the PoH tick height (a monotonically increasing counter) to seed a stable pseudo-random algorithm.
2. At that height, sample the bank for all the currently staked accounts, their assigned leader identities and weights.
3. Sort them by stake weight.
4. Use the random seed select nodes weighted by stake to create a stake weighted ordering.
1. Periodically use the PoH tick height (a monotonically increasing counter) to
seed a stable pseudo-random algorithm.
2. At that height, sample the bank for all the staked accounts with leader
identities that have voted within a cluster-configured number of ticks. The
sample is called the *active set*.
3. Sort the active set by stake weight.
4. Use the random seed to select nodes weighted by stake to create a
stake-weighted ordering.
5. This ordering becomes valid after a cluster-configured number of ticks.
The seed that is selected is predictable but unbiasable. There is no grinding attack to influence its outcome. To reduce the likelihood of censorship of leaders in the network the set of **staked accounts** is computed over a large period.
The seed that is selected is predictable but unbiasable. There is no grinding
attack to influence its outcome. The active set, however, can be biased by a
leader by censoring validator votes. To reduce the likelihood of censorship,
the active set is sampled many slots in advance, such that votes will have been
collected by multiple leaders. If even one node is honest, the malicious
leaders will not be able to use censorship to influence the leader schedule.
## Appending Entries
A leader schedule is split into *slots*, where each slot has a duration of `T` PoH ticks.
A leader schedule is split into *slots*, where each slot has a duration of `T`
PoH ticks.
A leader transmits entries during its slot. After `T` ticks, all the validators switch to the next scheduled leader. Validators must ignore entries sent outside a leader's assigned slot.
A leader transmits entries during its slot. After `T` ticks, all the
validators switch to the next scheduled leader. Validators must ignore entries
sent outside a leader's assigned slot.
All `T` ticks must be observed from the current leader for that part of PoH to be accepted by the cluster. If entries are not observed (leader is down) or entries are invalid (leader is buggy or malicious), a validator should fill the gap with empty entries and continue with PoH from the next leader.
All `T` ticks must be observed from the current leader for that part of PoH to
be accepted by the cluster. If entries are not observed (leader is down) or
entries are invalid (leader is buggy or malicious), a validator should fill the
gap with empty entries and continue with PoH from the next leader.