Table of contents
- Details Around Componenents and Sub-Components of Based Rollups from Fabric’s POV
- L1 Components
- L2 Components
Details Around Componenents and Sub-Components of Based Rollups from Fabric’s POV
Building on Based Rollup 101, this document provides context on the key components and subcomponents of a based rollup stack. You’ll find a visual representation of these elements, followed by a description of each and its role within the stack.
If you want to learn more about each component, we encourage teams to visit the relevant sections of the Fabric repo, where more documentation can be found or will become available.
Please note that not all components have been fully researched, agreed upon, built, or documented. Additionally, the following focuses only on the green boxes and non-stretch goal components.
L1 Components
Changes to L1 infrastructure are required to support block building for based rollups. Below are sub-components that are focused on smart contract and API changes.
Commit-Boost
What is it
- Commit-Boost is an Ethereum validator sidecar focused on standardizing the communication between validators and third-party protocols (i.e., preconfs).
- Enables validators to run a single sidecar while easily making multiple commitments without additional devops overhead.
- Provides tools to streamline the development of off-chain proposer commitment protocols (e.g., standardizing validator signature requests).
- Allows proposers to make a commitment to issue a preconf or future types of commitments.
Resources: Repo, Intro post, and Docs
Constraints API
What is it
- A minimal set of endpoints extending the existing PBS architecture for proposers to add constraints during block building. This unlocks proposer commitments, particularly for unsophisticated proposers who delegate block building responsibilities.
- While the first use case is based preconfs, the Constraints API is designed to be generic and future-proof, accommodating a wide range of proposer commitments as the space evolves.
- The spec defines how Proposers, Gateways, Builders, and Relays communicate to issue, prove, and verify constraints.
Resources: OpenAPI, Annotated API, and Proposer / Gateway / Builder specs
Commitments API
What is it
- A standardized API that defines how validators (or its delegate) receives commitment requests and issue signed commitments. While the first use case is preconfs, it includes flexibility in the schemas to support future commitment types, given the evolving design space (e.g., inclusion, execution, state lock).
- In the context of preconfs, this enables consumers (Users, Wallets, Dapps) to request and verify preconfs from the party issuing the preconfs.
- Helps converge on a standard messaging format, reducing implementation friction for parties issuing commitments.
- Helps translate user “intents” into actionable requests within the block-building supply chain or in other terms, maps the commitment to a constraint that can be understood by the rest of the PBS pipeline.
- Enables block explorers and wallets to agree on a way to report the statuses of preconfed transactions.
Considerations
- Nice to haves include: 1) A way for users to get commitment pricing information and 2) A way for users to query gateway capabilities
Resources: Repo
URC
What is it
- A minimal smart contract that enables registrations and slashing to enhance the credibility of generic proposer commitments.
- Designed to be lightweight, avoiding enshrining any specific restaking protocol’s slashing logic.
- Key design considerations can be found here
Resources: Repo (includes docs, history, and discussion items)
L2 Components
For a rollup to adopt based sequencing, it needs to make changes to its L2 infrastructure. Below are sub-components that help with this.
Lookahead Window
What is it
- A smart contract that provides an on-chain view of the beacon chain lookahead. This is essential for most based rollups to move beyond “total anarchy mode” by granting sequencing rights ahead-of-time—such as for enforcing state locks for L2 execution preconfs.
- Proving the lookahead each epoch is gas-intensive, but costs can be amortized if shared across multiple based rollups.
- No single entity has an incentive to bear these costs alone (tragedy of the commons), making it suitable for a subsidized entity like Fabric to coordinate and help getting funding / support as a public good.
Considerations
- A generic lookahead contract would report on-chain all upcoming BLS keys for the epoch. To grant state locks ahead-of-time, rollup inbox contracts still need to know which of the validators are preconfers for their rollups.
- A lookahead is just one way to assign sequencing rights in a based rollup and ideally protocols do not have to tightly couple a lookahead with their inbox contracts, but can instead optionally tap into one.
- The lookahead can be determined off-chain during L2 derivation which avoids the need for an on-chain lookahead contract at all - see Dido.
Resources: Nethermind/Taiko implementation
Inbox Contracts
What is it
- The L1 smart contract where sequencers post DA. It is responsible for determining who can submit data and how they do it.
- Since based sequencing requires rollups to delegate sequencing rights to validators, the inbox contract’s design significantly impacts the complexity of this process.
- Different rollup stacks vary in how they implement this (e.g., EOA-submitted for OP Stack vs. contract-based for Taiko and others), so standardization an inbox contract interface will help current and future rollups maintain compatibility with based sequencing.
Considerations
- EOA-based submission is cheaper and a competitive advantage for OP stack chains but introduces complexity for based sequencing.
- The OP stack allows for individual transactions to be posted, whereas Taiko allows delayed batches. Both designs have their tradeoffs and the interface will likely need to be opinionated.
- The inbox contract should be decoupled from the leader-election process.
- Ideally we can enshrine “total anarchy mode” and generic message passing into a design by default. Rollups can apply their leader election process on top (e.g., use the lookahead or elect a centralized sequencer).
Discussion
- Should alt-DA support be a priority now or deferred to avoid scope creep?
- Should EXECUTE support be a priority now or deferred to avoid scope creep?
- Is it worth pushing this now?
- Non-based rollups also benefit from a standardized inbox because they can share the same messaging format.
- But there will be headwinds convincing incumbent rollups to modify their inboxes as it affects their derivation rules, especially if they have to adopt a competitor’s inbox format.
- But real-time proving could be a forcing function for change - if you want shared settlement each slot the shared bridging / blob sharing / inbox all start to collapse.
Blob Sharing
What is it
- Until blob supply is abundant, rollups need a way to share a single blob efficiently to reduce transaction costs.
- Blob sharing helps to:
- Increase competition – Lowers the barrier for smaller rollups that can’t efficiently fill a full blob.
- Improve based rollup efficiency – Based rollups post blobs more frequently than classical rollups, preventing long amortization periods. Based rollups can improve efficiency by amortizing blob costs across multiple rollups (this also helps classical rollups)
- Enables atomic inclusion - If you can guarantee that rollup A and rollup B share a blob then their data is either posted together or not at all.
Considerations
- Shared L1 transactions – Instead of multiple based L2s each paying 21,000 gas for separate L1 transactions, they can share a single transaction to amortize costs.
- Streaming Compression – Compress → Pack to allow for parallelization.
- Shared calldata packing – Support multi-rollup calldata aggregation for when it’s economical to use.
- Nethermind has received an EF grant to work on blob sharing 🔥
Discussion
- Should we prioritize transactions, state diffs, or both?
- Transactions are more intuitive for based sequencing, but real-time proving could make state diffs more viable.
Resources: Lin’s blog post, Spire’s demo and Blob Research
Sequencer Resolution
What is it
- Rollups need to determine if a blob was submitted by a valid sequencer to consider it when calculating their L2 state.
- Classical rollups like the OP stack will verify the designated sequencer’s signature on the blob.
- Based sequencing implies that there will be multiple valid sequencers for a given rollup so rules are required to determine which sequencer is allowed and when.
- These “sequencer resolution” rules will be necessary to expand rollup sequencer sets, but there are different approaches to how this can be done.
Considerations
- Can be done on-chain at the inbox level - see Nethermind/Taiko PoC
- Can be done off-chain during L2 derivation - see Dido.
Sequencer Shared Blob Parsing
What is it
- If rollups agree to share blob space then they are opting into a shared encoding scheme.
- For the rollups to derive their correct L2 state, they need to be able to decode the shared blob.
- This is a new step in a rollup’s derivation process that requires changes.
Considerations
- The decoding naturally follows the blob sharing implementation / standard.
- If rollups want to modify the shared encoding scheme, it is ideally straightforward to modify the shared blob parsing step without hard-forking the rollup node software.