Linear Leios
This document is a specification of Linear Leios. It removes concurrency at the transaction level by producing one (large) EB for every Praos block.
In addition to the expected paramaters, we assume a two functions:
splitTxs: produces a pair of a list of transactions that can be included in an RB and a list of transactions that can be included in an EBisValidityChecked: whether validation of a given EB has completed by a given slot
Upkeep
A node that never produces a block even though it could is not
supposed to be an honest node, and we prevent that by tracking whether a
node has checked if it can make a block in a particular slot.
LeiosState contains a set of SlotUpkeep and we
ensure that this set contains all elements before we can advance to the
next slot, resetting this field to the empty set.
Block/Vote production
We now define the rules for block production given by the relation
_↝_. These are split in two:
- Positive rules, when we do need to create a block.
- Negative rules, when we cannot create a block.
The purpose of the negative rules is to properly adjust the upkeep if we cannot make a block.
Note that _↝_, starting with an empty upkeep can always
make exactly three steps corresponding to the three types of Leios
specific blocks.
Positive rules
In this specification, we don’t want to peek behind the base chain
abstraction. This means that we assume instead that the
canProduceEB predicate is satisfied if and only if we can
make an RB. In that case, we send out an EB with the transactions
currently stored in the mempool.
Predicate needed for slot transition. Special care needs to be taken when starting from genesis.
Voting happens within a window: it opens
3 * Lhdr slots
after the announcing RB’s slot (the equivocation-detection period) and
closes Lvote slots later. voteDeadline is the
last slot at which the current EB may still be voted on; when there is
no current EB (or it has not been received yet) the deadline is
0, so the deferral rule Roles₃ below is
vacuously inapplicable and abstention is governed solely by
Roles₂.
Linear Leios transitions
The relation describing the transition given input and state
Network and Ledger
Base chain
Note: Submitted data to the base chain is only taken into account if the party submitting is the block producer on the base chain for the given slot
Base₂ announces the EB recorded by EB-Role,
not a candidate recomputed from ToPropose. The premise
hasUpkeep EB-Role makes the party settle its EB role for
the slot first, either by producing (which sets proposedEB)
or by declining through Roles₂; without it a
Base₂ step scheduled early in the slot would announce
nothing and strand the EB the party goes on to diffuse.
Protocol rules
Deferral of the VT-Role: abstaining from voting is permitted while the current EB’s voting window is still open, even when a positive VT-Role step could fire. Together with
Roles₂ this yields bounded
liveness: at the deadline slot neither Roles₃ (window
closes) nor Roles₂ (a vote can still fire) applies, so a
vote must be cast by then.