2.7 KiB
Leader Rotation
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 generated using a predefined seed. The process is as follows:
- Periodically use the PoH tick height (a monotonically increasing counter) to seed a stable pseudo-random algorithm.
- 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.
- Sort the active set by stake weight.
- Use the random seed to select nodes weighted by stake to create a stake-weighted ordering.
- 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. 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
The lifetime of a leader schedule is called an epoch. The epoch 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.
All T
ticks must be observed by the next leader for it to build its own
entries on. If entries are not observed (leader is down) or entries are invalid
(leader is buggy or malicious), the next leader must produce ticks to fill the
previous leader's slot. Note that the next leader should do repair requests in
parallel, and postpone sending ticks until it is confident other validators
also failed to observe the previous leader's entries. If a leader incorrectly
builds on its own ticks, the leader following it must replace all its ticks.