diff --git a/rfcs/0002-branch-generation.md b/rfcs/0002-fork-generation.md similarity index 77% rename from rfcs/0002-branch-generation.md rename to rfcs/0002-fork-generation.md index 669a4d72eb..e9fb2dd7e6 100644 --- a/rfcs/0002-branch-generation.md +++ b/rfcs/0002-fork-generation.md @@ -1,17 +1,17 @@ -# Branch Generation +# Fork Generation -The goal of this RFC is to define how Solana generates branches. +The goal of this RFC is to define how Solana generates forks. ## Basic Design Idea -Nodes take turns being leader and generating the PoH that encodes state changes. The network can tolerate loss of connection to any leader by synthesizing what the leader ***would have generated*** had it been connected but not ingesting any state changes. The complexity of forks is thereby limited to a "there/not-there" skip list of branches that may arise on leader rotation slot boundaries. A leader can only transmit durring their predefined PoH slot. +Nodes take turns being leader and generating the PoH that encodes state changes. The network can tolerate loss of connection to any leader by synthesizing what the leader ***would have generated*** had it been connected but not ingesting any state changes. The possible number of forks is thereby limited to a "there/not-there" skip list of forks that may arise on leader rotation slot boundaries. At any given slot, only a single leader's transactions will be accepted. ## Message Flow -1. Transactions are ingested at the current leader. -2. Leader filters for valid transactions. -3. Leader executes valid transactions on its state. +1. Transactions are ingested by the current leader. +2. Leader filters valid transactions. +3. Leader executes valid transactions updating its state. 4. Leader packages transactions into entries based off its current PoH slot. 5. Leader transmits the entries to validator nodes (in signed blobs) a. The PoH stream includes ticks; empty entries that indicate liveness of the leader and the passage of time on the network. @@ -33,7 +33,7 @@ There are only two possible versions of the PoH during a voting slot: PoH with ` Validators can ignore forks at other points (e.g. from the wrong leader), or slash the leader responsible for the fork. -Validators vote based on a greedy choice to maximze their reward described in [branch selection](rfcs/0008-branch_selection.md). +Validators vote based on a greedy choice to maximze their reward described in [forks selection](rfcs/0008-fork-selection.md). ### Validator's View @@ -56,7 +56,7 @@ V +----+ hang on to E(L4) and E(L5 ``` -Note that an `E` appearing on 2 branches at the same slot is a slashable condition, so a validator observing `E(L3)` and `E(L3)'` can slash L3 and safely choose `x` for that slot. Once a validator commits to a branch, other branches can be discarded below that tick count. For any slot, validators need only consider a single "has entries" chain or a "ticks only" chain to be proposed by a leader. But multiple virtual entries may overlap as they link back to the a previous slot. +Note that an `E` appearing on 2 forks at the same slot is a slashable condition, so a validator observing `E(L3)` and `E(L3)'` can slash L3 and safely choose `x` for that slot. Once a validator commits to a forks, other forks can be discarded below that tick count. For any slot, validators need only consider a single "has entries" chain or a "ticks only" chain to be proposed by a leader. But multiple virtual entries may overlap as they link back to the a previous slot. #### Time Division @@ -73,4 +73,4 @@ This arrangement of the network data streams permits nodes to save exactly this ### Leader's View -When a new leader begins a slot, it must first transmit any PoH (ticks) required to link the new slot with the most recently observed and voted slot. The branch the leader proposes would link the current slot to a previous slot that the leader has voted on with virtual ticks. +When a new leader begins a slot, it must first transmit any PoH (ticks) required to link the new slot with the most recently observed and voted slot. The fork the leader proposes would link the current slot to a previous fork that the leader has voted on with virtual ticks. diff --git a/rfcs/0004-leader-rotation.md b/rfcs/0004-leader-rotation.md index 93db7052e6..3b3eff2c8a 100644 --- a/rfcs/0004-leader-rotation.md +++ b/rfcs/0004-leader-rotation.md @@ -1,29 +1,29 @@ # Leader Rotation -The goal of this RFC is to define how leader nodes are rotated in Solana. +The goal of this RFC is to define how leaders rotate in taking their 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 psudo-random algorithm. -2. At that height, compute all the currently staked accounts and their assigned leader identities and weights. +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. 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` `PoH tick counts`. +5. This ordering becomes valid in `N` number of slots. -The seed that is selected is predictable but unbiasable. There is no grinding attack to influence its outcome. The set of **staked accounts** and their leader identities is computed over a large period, which is our approach to censorship resistance of the staking set. If at least 1 leader in the schedule is not censoring staking transactions then over a long period of time that leader can ensure that the set of active nodes is not censored. +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 -* The leader is rotated every `T` PoH ticks (leader period), accoding to the leader schedule. This amount of time as represented by the PoH ticks is called a slot. +* 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. 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. -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 [branch generation](rfcs/0002-branch_generation.md). +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](rfcs/0002-fork-generation.md). ## Network Variables -`N` - Number of voting rounds for which a leader schedule is considered before a new leader schedule is used. This number should be large and potentially cover 2 weeks. +`N` - Number of slots before a new leader schedule becomes active after it is computed. `T` - Number of PoH ticks per leader slot.