Special thanks to Nicolas Liochon, Grant Southey and Declan Fox for their valuable feedbacks on earlier versions of this post.
This post explores a possible architecture for Linea to become deployable as a based rollup without preconfirmations – preconfirmations come with different features for censorship resistance.
As per Justin Drake’s definition, ‘a based rollup is one where the next L1 proposer may, in collaboration with L1 searchers and builders, permissionlessly include the next rollup block as part of the next L1 block.’
In this post we assume that the reader is familiar with both based rollups concepts and the Linea architecture. We also consider some expected deliverables of the FABRIC project whose objective is to create components that facilitate the adoption of based rollups. The two features that are of interest are (1) the components being developed to enable block builders to construct blocks for multiple based rollups facilitating cross-rollup blob sharing. (2) a derivation layer which allows L2 state reconstruction from Layer 1. Note that the timeline for these components to be available is still to be defined. Also, regarding the first feature, an ideal solution would be that Layer 1 offers a blob mechanism allowing each rollup to natively provide data availability (DA) cheaply without the need to build components to share blobs.
Architecture overview
The diagram below represents the lifecycles of rollup blocks from sequencing to finalization and highlights the main actors involved in the based rollup.
The based rollup model relies on L1 proposer posting on L1 the blocks of the rollup. Note that L1 proposer can delegate the functionality of building the rollup blocks to a third party or it can fulfill it on its own. The Gateway represents the component providing the block to the L1 proposer.
Users send transactions to the rollup nodes via RPC endpoints. The rollup nodes broadcast the content of their mempools via P2P to the other rollup nodes, including the Gateways. A user can also send its transaction directly to a Gateway.
The Gateway is providing the rollup blocks for the different rollups that the L1 proposer has opted-in to build. For this it is required to connect to the rollups networks.
The rollup nodes can exchange blocks among themselves via P2P, but they need to follow the L1 chain which is the source of truth to validate the blocks produced.
Once the blocks are produced, included and finalized in L1, a second phase starts, handled by the Coordinator which consists in proving the proper execution of the rollup, and posting a finalization proof on L1.
Impact of based rollup design on Linea’s components
The impact of based rollups on the different functionalities is described in the following sections.
Block building
Block building is permissionless, and the sequencer logic is no longer run by a centralized actor.
Today, the centralized sequencer logic includes: (1) inserting only valid transactions from an EVM point of view; (2) inserting only provable transactions, taking into account prover limits (3) inserting only profitable transactions, taking into account the execution cost and the expected data availability cost.
A permissionless sequencer could include invalid or unprovable transactions. For this reason, an extra component in charge of proving invalidity (see below) is included. The data availability cost is simpler to calculate in a based rollup: the non-based rollup anticipates a possible price, while the based rollups knows exactly the price of the blob data it is going to include. This impacts the price estimation given to the user, see section below.
Calculating the prover limits is complicated and expensive, however these limits are actually being removed. As a consequence, the sequencing becomes much simpler, and the block builder can either (1) run the “official” Linea component, or run its own version (eg. optimized for MEV), with the few limits (eg. MODEXP) that still needs to be managed.
The block builder will have to take into account constraints on how the rollup blocks are represented in the blobs posted on Layer 1. In particular, the compression algorithm will need to be the one prescribed by Linea prover. Regarding the notion of batches within a block, the limitless prover will facilitate removing it.
Data availability
Linea currently creates blocks every two seconds, groups/conflates them so, once compressed they fill a full blob (~128KB. Linea then sends 6 blobs per transaction to minimize the L1 gas cost – the overhead cost to handle the blobs is similar for 1 blob or 6. A based rollup does not do this: the transactions are included if, and only if it is profitable.
How much of the blob capacity is filled has a direct impact on the cost and latency. If we need enough transactions to justify the block creation, the user will have to wait or to pay more, depending on the global activity: the fixed cost of including a set of blobs is around 400k L1 gas. This price could be lowered with various optimizations. Ethereum has today the capacity to include a maximum of 6 blobs per block with a target of 3. Without sharing blobs, it would be possible to have a maximum of 3 based rollups at the same time to match the target number of blobs. For this reason, it is mandatory to support shared blobs (see the work in progress by FABRIC). Shared blobs also decrease the DA cost. A possible workaround would be to use calldata instead of blobs. We have not investigated this solution, as the price of calldata is supposed to increase in Pectra (note, however, that L1 gas prices have been very low recently) to deter DA via calldata
Linea today includes a mechanism to “skip spikes”; i.e. wait until the price stabilizes before posting the DA. With a based rollup this mechanism is not possible anymore. Such spikes will have an impact on tx cost and latency as we will see later.
Price and price estimation
The price of rollup transactions is three dimensional. One relates to data availability, one to the execution cost, and one to proving cost.
In order to guarantee a smooth user experience, users must be able to predict a fair price so that they can properly build their transactions.
In a based rollup, the data availability is paid for directly by the L1 proposer. As this cost is known at the time of inclusion, the cost can be computed for each rollup transaction.
If the exact proving cost is not known at the time the block is built, the mechanism proposed in the block proving and finalization section allows the block builder to get an estimate of it. The block proposer uses this estimation to provision the proving costs.
With this information, it’s possible to determine the profitability of a transaction given the max fee per gas and the max priority fee.
The logic of the current linea_estimategas method can be reused in the context of based rollups to provide the end user an estimate of the cost of their transaction by using some recent blob fees and proving cost per gas.
What will need to be modified is how the blob fee and L1 gas costs are provided to the calculation. In Linea, the Coordinator retrieves it from L1 and sends the price to use in the sequencer. In the based rollup model, each gateway will have to get its own mechanism to determine what value to use. Given that the mechanism to skip spikes in blob fees is not applicable, the estimated gas cost will follow more closely the variation of the blob fees, and hence will be more volatile.
The parameters used for the linea_estimategas method can be propagated as it is done today via the extra data fields of the rollup blocks.
The increased volatility on the gas price will have an impact on rollup block production as an L1 proposer will not post rollup blocks if blob fees are too high to make it profitable. We discuss further the impact of based rollups on the latency in the next sections.
Latency for transaction inclusion
Currently, Linea blocks are produced every two seconds and the latency of a transaction to be included is directly linked to its profitability in the context of Linea only.
A based rollup is extended when a L1 block contains its blocks. Hence the latency of a based rollup is directly linked to the L1 block time and the frequency at which an L1 proposer posts blocks for this rollup. This is influenced by at least three factors: the number of L1 proposers supporting the rollup, the availability of enough transactions for the L1 proposer to build a profitable L1 transaction to extend the rollups it builds and, a sufficient pricing of the transaction to be selected by the L1 proposer as part of the rollup blocks it builds.
Regarding the first factor, if we have a fraction X of L1 proposers which opted in, the probability that one of them is in charge of proposing an L1 block exactly after k blocks is (1-X)^(k-1)X.
The average latency will then be (1/X*12 - 6 ) seconds given L1 blocks are produced every 12 seconds.
From this formula one can derive the average time after which an L1 proposer considers a transaction after it was posted. This means that the number of L1 proposers supporting a rollup is directly linked to the level of service the rollup can guarantee. This also raises the question of how to ensure L1 proposers support new based rollups.
When an L1 proposer builds its block, it includes rollup blocks if it is profitable. This means that if the total fees of the available transactions are too low, then no rollup block will be created. The transaction inclusion will be delayed to at least the next L1 proposer.
Similarly when an L1 proposer builds its block, if there are too many transactions to include all of them in the rollup blocks it is building, it will select only the most profitable ones. This means that the inclusion or not of a transaction in a rollup will be impacted by the activity on other rollups supported by the L1 proposer.
State reconstruction
With a based rollup, the L1 data is the reference before it is actually proven. As a consequence, other builders, RPC node providers, and simple clients must verify the data before the proof is available. Linea today removes the signatures from the transactions DA. This needs to change as signatures are needed for validity verification. Incidentally, state diff approaches for DA would not work as well if the state diff lacks a validity proof.
In order to reconstruct the L2 state using an L1 node, Linea already has a state reconstruction component, implemented in Java/Kotlin. We will need to integrate it with the derivation layer component of FABRIC’s. If this derivation layer was not available, an alternative solution will need to be implemented.
Given proposers could post invalid blocks, rollup nodes must validate the blocks it imports. A block can be invalid for multiple reasons such as non-parsable, or non-compliant with the EVM specifications, or violating some constraints imposed by the rollup (e.g. MODEXP parameters).
A rollup node simply ignores invalid blocks.
To ensure censorship resistance, the block invalidity must be proven as part of the finalization process.
Note that recent blocks can also be broadcasted through P2P to ease builders work, but the source of truth always remains the L1.
Block proving and finalization
In Linea we have an actor, called the Coordinator, which is responsible for facilitating both data availability and proof generation, as well as their submission.
In this based rollup model, data availability is ensured by the L1 proposer, hence it is removed from the Coordinator’s responsibility.
The Coordinator simply reads the content of the L1 blobs, batches rollup blocks as it is done today, requests execution proofs for the batches, compression proofs for the blobs, and when it has enough proofs, gets an aggregation proof, and finally posts a finalization transaction for the proven range of blocks.
The Coordinator role is auctioned in a way similar to the one described in the decentralization roadmap (Proposal - towards Linea’s decentralization). In a nutshell, there is a reverse auction for a deterministic range of blocks, typically up to a given gas limit #GAS_LIMIT, and the bids represent the prover cost per unit of gas to prove these blocks.
The auction is used to predict the proving cost, and each block proposer has to provision the prover costs as per the best current bid and the size of the block it produces. This provision ensures each proposer pays the fair share of the Coordinator costs. In case the bid for the prover cost decreases, block proposers are refunded any overprovisioned amount at posteriori.
Note that in order to avoid a cold start, a foundation (e.g. Linea Association) always guarantees to assume the Coordinator role at a max prover cost per unit of gas ($MAX).
The Coordinator auction is open to any entity with some collateral at stake. The collateral serves as a liveness guarantee: if the winner of an auction does not post the proof in time, its collateral is slashed. In such a case, any other entity can generate and post the proof. Having the collateral larger than $MAX*#GAS_LIMIT, ensures that it is sufficient to cover the cost of generating proofs at the maximum cost.
The Coordinator will be able to reuse the components currently run as part of Linea, including the Shomei state manager, Besu and its tracer plugin, as well as the provers.
Invalidity proofs
The Coordinator needs to be able to provide invalidity proofs. This is a new type of proof used to prove that a block is rightfully skipped because it does not comply with the protocol or the rollup’s requirements.
At finalization, the L1 smart contract will verify that all rollup blocks are associated with either an execution proof or an invalidity proof. This ensures that no block can be censored.
The design of invalidity proofs is beyond the scope of this document and will be analyzed separately.
Note: this opens up a potential attack where any one can post a dummy blob and force costly proof generation. This attack can be mitigated by forcing each block proposer to post some collateral to cover costs of invalidity proofs.
Multiprover
Block proposal is permissionless: The proposer can exploit any bug in the proof system. For this reason it is important to deploy a based rollup with the multiprover. Once the Coordinator has sent its finalization submission to L1, other provers can start posting proofs matching the one of the Coordinator. Once the number of required proof is reached, the finalization is validated.
Based rollups and finality
Linea blocks currently have two types of finality, L2 finality which is guaranteed by the sequencer, and L1 finality which is guaranteed by L1 and happens once the finalization proof is in a finalized L1 block.
In the based rollup model, a rollup block goes through four different states:
- in a non finalized L1 block
- in a finalized L1 block and no finalization proof is available
- in a finalized L1 block and a finalization proof is available
- in a finalized L1 block and a finalization proof is finalized
The first state covers both cases when a finalization proof is available or not. In the above example, it concerns the green rollup blocks 5 and 6. In this state, the finality of the rollup can’t be explicitly linked to an economic guarantee. A based rollup’s block is reverted/reorged when its underlying L1 block is reverted/reorged. This type of revert is scarce but will happen from time to time.
The second state is illustrated by green block 4 in the above example. If the block is valid, it will be proven. This corresponds to what we call L2-finality in Linea. If the content of the block itself is wrong and can’t be proven or finalized, (e.g. when an invalid native bridge message was anchored), a client will ignore it. It’s not part of the canonical rollup chain. This scenario happens when the L1 block proposer has violated the protocol requirements of the based rollup.
In the third state, as in the second state, the rollup client skips the block if it’s invalid. In this state, the client can observe that a valid execution proof was properly generated. For the finalization proof not to be finalized, L1 must revert and include a change in the finalization smart contract invalidating the proof.
In the fourth state, the rollup finality is backed by the L1 security guarantees. It will be reverted only if the L1 finality of the underlying L1 block does not hold. Rollup block 1 of the above example is in this state as both its underlying L1 block and the L1 block containing its proof are final.
MEV
With a centralized sequencer, the MEV policy is defined by the rollup itself –Linea does not capture any MEV today. A based rollup allows capture of MEV by the L1 proposer, including cross rollup MEV.
L1 state anchoring and message service
Currently, L1 to L2 message hashes are anchored by an entitled entity. In the context of based rollups, this entitlement must be removed.
To achieve it, we require that each rollup block contains the L1 state root hash of the parent of the L1 block in which it is posted.
This gives an easy and deterministic way for rollups nodes to validate that the L1 state root hash is properly anchored.
The finalization proof also needs to include this validation.
Given we have an L1 state anchored on the rollup, the L1-L2 message passing mechanism can be modified as follows: the part anchoring the message on the rollup is not required anymore, and the claiming part is modified to contain a proof that the original message exists in the anchored L1 state.
This allows to remove the validation of the anchored messages at finalization, given the anchored L1 state is properly validated instead.
Regarding the L2 to L1 anchoring, the current mechanism already guarantees that no extra messages can be anchored on L1 and that none can be censored, so we can reuse it in a permissionless environment as is.