Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add design for the leader validator loop #2650

Merged
merged 21 commits into from
Feb 13, 2019
Merged
Show file tree
Hide file tree
Changes from 20 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions book/src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,3 +48,4 @@
- [Economic Sustainability](ed_economic_sustainability.md)
- [Attack Vectors](ed_attack_vectors.md)
- [References](ed_references.md)
- [Leader-to-Validator Transition](leader-validator-transition.md)
85 changes: 85 additions & 0 deletions book/src/leader-validator-transition.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
# Leader-to-Validator Transition

A fullnode typically operates as a validator. If, however, a staker delegates
its stake to a fullnode, it will occasionally be selected as a *slot leader*.
mvines marked this conversation as resolved.
Show resolved Hide resolved
As a slot leader, the fullnode is responsible for producing blocks during an
assigned *slot*. A slot has a duration of some number of preconfigured *ticks*.
The duration of those ticks are estimated with a *PoH Recorder* described later
in this document.

## BankFork
garious marked this conversation as resolved.
Show resolved Hide resolved

BankFork tracks changes to the bank state over a specific slot. Once the final
tick has been registered the state is frozen. Any attempts to write to are
rejected.

## Validator

A validator operates on many different concurrent forks of the bank state until
it can prove a PoH record at a height within the slot it is scheduled to be the
mvines marked this conversation as resolved.
Show resolved Hide resolved
slot leader.

## Slot Leader

A slot leader builds blocks on top of only one fork, the one it last voted on.

## PoH Recorder

Slot leaders and validators use a PoH Recorder for both estimating slot height
and for recording transactions.

### PoH as a Validators
mvines marked this conversation as resolved.
Show resolved Hide resolved

The PoH Recorder acts as a simple VDF when validating. It tells the validator
when it needs to switch to the slot leader role. Every time the validator votes
on a fork, it should use the fork's latest block id to re-seed the VDF.
Re-seeding solves two problems. First, it synchronizes its VDF to the leader's,
allowing it to more accurately determine when its leader slot begins. Second,
if the previous leader goes down, all wallclock time is accounted for in the
next leader's PoH stream. For example, if one block is missing when the leader
starts, the block it produces should have a PoH duration of two blocks. The
longer duration ensures the following leader isn't attempting to snip all the
transactions from the previous leader's slot.

### PoH as a Slot Leader
mvines marked this conversation as resolved.
Show resolved Hide resolved

A slot leader use the PoH Recorder to record transactions, locking their
positions in time. The PoH hash must be derived from a previous leader's last
block. If it isn't, its block will fail PoH verification and be rejected by
the cluster.

The PoH Recorder also serves to inform the slot leader when its slot is over.
The leader needs to take care not to modify its bank if recording the
transaction would generate a PoH height outside its designated slot. The
leader, therefore, should not commit account changes until after it generates
the entry's PoH hash. When the PoH height falls outside its slot any
transactions in its pipeline may be dropped or forwarded to the next leader.
Forwarding is preferred, as it would minimize network congestion, allowing the
cluster to advertise higher TPS capacity.


## Fullnode Loop

The PoH Recorder manages the transition between modes. Once a ledger is
replayed, the validator can run until the recorder indicates it should be
the slot leader. As a slot leader, the node can then execute and record
transactions.

The loop is synchronized to PoH and does a synchronous start and stop of the
slot leader functionality. After stopping, the validator's TVU should find
itself in the same state as if a different leader had sent it the same block.
The following is pseudocode for the loop:

1. Query the LeaderScheduler for the next assigned slot.
2. Run the TVU over all the forks.
1. TVU will send votes to what it believes is the "best" fork.
2. After each vote, restart the PoH Recorder to run until the next assigned
slot.
3. When time to be a slot leader, start the TPU. Point it to the last fork the
TVU voted on.
4. Produce entries until the end of the slot.
1. For the duration of the slot, the TVU must not vote on other forks.
2. After the slot ends, the TPU freezes its BankFork. After freezing,
the TVU may resume voting.
5. Goto 1.