From af22de2cfac22392396ad51019e07f85f22e3f1d Mon Sep 17 00:00:00 2001 From: Greg Fitzgerald Date: Mon, 10 Dec 2018 10:30:05 -0700 Subject: [PATCH] Cleanup leader rotation RFC --- rfcs/0004-leader-rotation.md | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/rfcs/0004-leader-rotation.md b/rfcs/0004-leader-rotation.md index bc0890d2ee..83cdfc83a1 100644 --- a/rfcs/0004-leader-rotation.md +++ b/rfcs/0004-leader-rotation.md @@ -1,29 +1,23 @@ # Leader Rotation -The goal of this RFC is to define how leaders rotate in taking their role. +The goal of this RFC is to define how fullnodes rotate in taking the leader role. ## Leader Schedule Generation Leader schedule is decided via a predefined seed. The process is as follows: -1. Periodically at a specific `PoH tick count` use the tick count (simple monotonically increasing counter) as a seed to a stable pseudo-random algorithm. -2. At that height, example the bank for all the currently staked accounts and their assigned leader identities and weights. +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. Using the random seed select nodes weighted by stake to create a stake weighted ordering. -5. This ordering becomes valid in `N` number of slots. +4. Use the random seed 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. -## Leader Rotation +## Appending Entries -* The leader is rotated every `T` PoH ticks (leader period), according to the leader schedule. This amount of time as represented by the PoH ticks is called a slot. +A leader schedule is split into *slots*, where each slot has a duration of `T` PoH ticks. -Leader's transmit for a count of `T` PoH ticks. When `T` is reached all the validators should switch to the next scheduled leader. Leaders that transmit out of order can be ignored. +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 network. If `T` ticks (and any intervening transactions) are not observed, the network optimistically fills in the `T` ticks, and continues with PoH from the next leader. See [fork generation](0002-fork-generation.md). - -## Network Variables - -`N` - Number of slots before a new leader schedule becomes active after it is computed. - -`T` - Number of PoH ticks per leader 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.