Design for leader to leader transition between slots (#2715)
This commit is contained in:
parent
9c44c173df
commit
fb55d1c3d4
|
@ -39,6 +39,7 @@
|
|||
- [Fork Selection](fork-selection.md)
|
||||
- [Reliable Vote Transmission](reliable-vote-transmission.md)
|
||||
- [Bank Forks](bank-forks.md)
|
||||
- [Leader to Leader Transition](leader-leader-transition.md)
|
||||
- [Cluster Economics](ed_overview.md)
|
||||
- [Validation-client Economics](ed_validation_client_economics.md)
|
||||
- [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md)
|
||||
|
|
|
@ -0,0 +1,101 @@
|
|||
# Leader to Leader Transition
|
||||
|
||||
This design describes how leaders transition production of the PoH ledger
|
||||
between each other as each leader generates its own slot.
|
||||
|
||||
## Challenges
|
||||
|
||||
Current leader and the next leader are both racing to generate the final tick
|
||||
for the current slot. The next leader may arrive at that slot while still
|
||||
processing the current leader's entries.
|
||||
|
||||
The ideal scenario would be that the next leader generated its own slot right
|
||||
after it was able to vote for the current leader. It is very likely that the
|
||||
next leader will arrive at their PoH slot height before the current leader
|
||||
finishes broadcasting the entire block.
|
||||
|
||||
The next leader has to make the decision of attaching its own block to the last
|
||||
completed block, or wait to finalize the pending block. It is possible that the
|
||||
next leader will produce a block that proposes that the current leader failed,
|
||||
even though the rest of the network observes that block succeeding.
|
||||
|
||||
The current leader has incentives to start its slot as early as possible to
|
||||
capture economic rewards. Those incentives need to be balanced by the leader's
|
||||
need to attach its block to a block that has the most commitment from the rest
|
||||
of the network.
|
||||
|
||||
## Leader timeout
|
||||
|
||||
While a leader is actively receiving entries for the previous slot, the leader
|
||||
can delay broadcasting the start of its block in real time. The delay is
|
||||
locally configurable by each leader, and can be dynamically based on the
|
||||
previous leader's behavior. If the previous leader's block is confirmed by the
|
||||
leader's TVU before the timeout, the PoH is reset to the start of the slot and
|
||||
this leader produces its block immediately.
|
||||
|
||||
The downsides:
|
||||
|
||||
* Leader delays its own slot, potentially allowing the next leader more time to
|
||||
catch up.
|
||||
|
||||
The upsides compared to guards:
|
||||
|
||||
* All the space in a block is used for entries.
|
||||
|
||||
* The timeout is not fixed.
|
||||
|
||||
* The timeout is local to the leader, and therefore can be clever. The leader's
|
||||
heuristic can take into account avalanche performance.
|
||||
|
||||
* This design doesn't require a ledger hard fork to update.
|
||||
|
||||
* The previous leader can redundantly transmit the last entry in the block to
|
||||
the next leader, and the next leader can speculatively decide to trust it to
|
||||
generate its block without verification of the previous block.
|
||||
|
||||
* The leader can speculatively generate the last tick from the last received
|
||||
entry.
|
||||
|
||||
* The leader can speculatively process transactions and guess which ones are not
|
||||
going to be encoded by the previous leader. This is also a censorship attack
|
||||
vector. The current leader may withhold transactions that it receives from the
|
||||
clients so it can encode them into its own slot. Once processed, entries can be
|
||||
replayed into PoH quickly.
|
||||
|
||||
## Alternative design options
|
||||
|
||||
### Guard tick at the end of the slot
|
||||
|
||||
A leader does not produce entries in its block after the *penultimate tick*,
|
||||
which is the last tick before the first tick of the next slot. The network
|
||||
votes on the *last tick*, so the time difference between the *penultimate tick*
|
||||
and the *last tick* is the forced delay for the entire network, as well as the
|
||||
next leader before a new slot can be generated. The network can produce the
|
||||
*last tick* from the *penultimate tick*.
|
||||
|
||||
If the next leader receives the *penultimate tick* before it produces its own
|
||||
*first tick*, it will reset its PoH and produce the *first tick* from the
|
||||
previous leader's *penultimate tick*. The rest of the network will also reset
|
||||
its PoH to produce the *last tick* as the id to vote on.
|
||||
|
||||
The downsides:
|
||||
|
||||
* Every vote, and therefore confirmation, is delayed by a fixed timeout. 1 tick,
|
||||
or around 100ms.
|
||||
|
||||
* Average case confirmation time for a transaction would be at least 50ms worse.
|
||||
|
||||
* It is part of the ledger definition, so to change this behavior would require
|
||||
a hard fork.
|
||||
|
||||
* Not all the available space is used for entries.
|
||||
|
||||
The upsides compared to leader timeout:
|
||||
|
||||
* The next leader has received all the previous entries, so it can start
|
||||
processing transactions without recording them into PoH.
|
||||
|
||||
* The previous leader can redundantly transmit the last entry containing the
|
||||
*penultimate tick* to the next leader. The next leader can speculatively
|
||||
generate the *last tick* as soon as it receives the *penultimate tick*, even
|
||||
before verifying it.
|
Loading…
Reference in New Issue