Special thanks to Simon Brown, Mikhail Kalinin, Roberto Saltini, and Nicolas Liochon for their contributions to the research summarized in this blog post and for their valuable feedback.
Our objective is to make Linea an L2 chain fully decentralized. We present below an overview of some important proposals towards this goal. It is a high level proposal, and the final implementation can possibly (actually is likely to) be different.
L1-Finality & L2-Finality
Blocks that are part of Linea’s canonical chain and whose finality is guaranteed by Linea’s sequencer(s) but not necessarily by the L1 are said to be L2 finalized.
Linea is anchored on L1 via a smart contract to which block’s data and execution proofs are sent. We say of a Linea block that it is L1 finalized if there is a proof that this block and its data have been successfully accepted by this smart contract and that the L1-block in which it was accepted is final.
Decentralization of the block validation
Block validation on Linea uses a distributed Byzantine agreement protocol where any node staking some minimum amount can participate. This means that L2-finality will transition from trusted to proof of stake.
To guarantee fast L2-finality, we use QBFT consensus protocol. Among the different consensus algorithms guaranteeing consensus under partial synchrony, QBFT was chosen to leverage its already existing implementation, cf the github repo /hyperledger/besu. Given QBFT is efficient with a committee that is not too big, we orchestrate the selection and rotation of validators forming the committee amongst all the ones available using a so-called outer protocol.
Any node can join the validator set by staking a sufficient amount. From this validator set, the outer protocol randomly selects a subcommittee which is responsible for running QBFT for a predetermined number of blocks.
The accountability feature of QBFT combined with the validators’ stake guarantees L2-finality. Indeed, from the properties of QBFT, if a node does not follow the protocol, then evidence can be collected to prove it. In such a case, the outer protocol stipulates that a proof containing the evidence is sent to the L2 validator set smart contract via a discard message, allowing to slash the identified Byzantine node. Part of the Byzantine node’s stake is sent to the sender of the discard message and the rest is burnt.
Note that Byzantine nodes could try to censor discard messages on L2. This is not an issue given the subcommittee rotates which guarantees that the discard messages will eventually be included.
Also, given the protocol is permissionless, it could happen that at some point in time, the QBFT committee contains more than a third of Byzantine nodes. In such a scenario, the committee could produce conflicting blocks or even invalid blocks. Note that by design, L1-finality is not impacted in such an event: a Byzantine set can impact liveness but not validity. As this behavior violates the protocol, other nodes can produce a discard message leading to slashing (and hence removing the misbehaving L2 nodes from the validator set) similarly to what is done in Gasper. The proper choice of the committee size and the total amount of stake each validator has to provide is important as it determines the L2-finality and liveness guarantees.
The outer protocol is also responsible to handle potential liveness issues. For this each subcommittee must ensure that the last block they have produced is available on L1. It allows the outer protocol to detect inactivity and to rotate stalled subcommittees.
The outer protocol combined with QBFT provides a permissionless protocol reaching finality in a few seconds in a partially synchronous network and with liveness guarantees as long as L1 is live.
Recovery mode
In the unlikely case where the validator set is empty, or all validators are inactive, the block production on Linea would stop. Linea L1 anchoring smart contract has a safety measure to recover from such a situation. After six months, if no block has been produced, any node can start finalizing. In this scenario, Linea would begin functioning in a manner similar to a base rollup.
Block proposer
In QBFT, each block is proposed by one of the validators which has the role of leader. We propose to externalize this proposer role from QBFT. Instead of assigning the block proposer role to a member of the validator set, it will be assigned to the winner of a dedicated on chain auction.
This mechanism gives the opportunity to any node to propose a block.
The auction is described in detail in ethresear in the post called A design for APS-burn in the context of a Decentralized L2. In a nutshell, it runs as follow:
For each block number n, there is an independent auction consisting of three phases:
- Sealed bid: from slot n-k to slot n-k+t, any node (or node with little stake, not yet decided) can submit a bid to a dedicated smart contract. This bid specifies the address that will propose the block and an amount signed by this address which represents the amount the proposer agrees to burn as part of the block that will be proposed at slot n.
- Buffer period: for a fixed number of slots from n-k+t to n-k+t+b, no bid will be accepted for slot n.
- Reveal: on the block n-k+t+b+1 following the buffer period, bids are revealed. The address in the message which made the highest bid is the only one who can sign a valid block for slot n.
The objective of having a sealed bid auction and a buffer period is to mitigate concerns around multi-block MEV. The parameter t used to determine the duration of the sealed bid phase has to be chosen large enough to avoid censorship of the bids.
Nodes can be block proposers with no or little stake which should favor decentralization and inclusivity, but these nodes might not be incentivized enough to wellbehave. We put the following safeguards in place to prevent block proposer to play timing games:
- all the proposals for a block height must be unique. Any proposal will be ignored by the QBFT subcommittee if a given proposer proposes multiple blocks.
- QBFT subcommittee can vote on an empty block if it does not receive a proposal on time from the auction winner.
- in case there is no bid, the leader of QBFT is the block proposer.
Note that the effect of this auction mechanism is to capture part of the MEV that block proposer plans to get by burning some amount of token. Burning these tokens has a deflationary impact.
As a potential alternative to this mechanism to select block proposers, we still look at the progress of concurrent multi block proposals eg. the one described in the bitget post called Ethereum’s road to anti-censorship: BRAID and FOCIL, which one is better?
Finalization of Linea’s blocks on L1
The guarantees of the rollups properties are ensured by the use of ZK proofs at the time of Linea’s blocks are posted (process to which we refer to as finalization) on L1 whose high level process is as follow:
On one hand, multiple consecutive blocks are aggregated and posted on L1 using Blobs, and on the other hand execution, compression and aggregation proofs are generated and posted on L1. In order for the whole process to be cost effective, the blocks handled at once are selected so that once compressed they fit in one or multiple groups of up to 6 blobs.
This highlights that finalization cost is split in two categories: one for data availability which is driven by the cost of posting blob’s data on L1, and the other related to generating the proofs. On top of selecting the node responsible for handling finalization, the protocol allows to fairly determine how both categories contribute to the total cost.
To cover the future costs associated with finalization, each block proposer is required to provision some token at the time of block creation. Once the block is finalized, the actual price of data availability and proof generation are known and the provision associated with each block is used to cover the fees. Any leftover is refunded to the block proposer.
In order to select a node to perform the finalization at a fair price, a reverse auction is performed. This reverse auction happens on-chain and is handled by a dedicated smart contract. Any node can participate as long as it provides some stake. Participants bid for the price they propose to charge for the finalization. The winner of the auction is the participant with the lowest bid.
The scope of the finalization is the set of consecutive blocks that once compressed can fit in X6 blobs for some fixed parameter X (which is to be determined to balance latency and cost). In order to make the scope deterministic and to eliminate any potential dispute, each block proposer broadcast the blocks in their compressed form. The reverse auction terminates when the newly produced L2 block does not fit in this 6X blobs. The winner is the one who posted the lowest bid, and it becomes responsible for posting the blocks on L1 as well as performing the actual finalization.
Note that the winner can delegate proof generation to other actors. This part is not regulated by the finalization protocol.
In case the node which won the reverse auction does not post data or proofs in a timely manner, any other node can perform the finalization on his behalf. The first node completing it will get the reward. The stake of the faulty node is used to cover extra fees or burnt.
Once finalization happens, the real cost of data availability and proof generation is determined by taking into account the actual fees the node has paid to post data on L1, and the rewards it gets (which amount to its bid).
Note that given a ZK proof is either valid or invalid, for the protocol to be Sybil resistance, it is sufficient it provides liveness guarantees.
Reward allocation
To allow reward allocation to be decoupled from the consensus protocol, the validators are required to build a consensus state Merkle tree representing the different actions each participant has made, including votes and block proposals.
This Merkle tree keeps track of all activities validators are required to perform, and hence we can leverage it to compute the reward each of them is entitled to receive.
Each validator can then claim their reward asynchronously by providing some proofs on the activities they performed, the validity of their claims being checked against the consensus state Merkle tree.
One advantage of this approach is that no logic related to reward allocation needs to be added to the consensus layer or the execution layer.