Rebased rollups

# Rebased Rollups **Rebased rollups** are a novel solution that combines the benefits of based and non-based rollups by offering **synchronous composability** and **credible neutrality** without the latency and cost drawbacks of traditional based rollups. By being "based on-demand" for periods even shorter than an Ethereum slot, rebased rollups leverage Ethereum's existing proposer set to achieve **faster transactions and higher throughput at low cost**, enabling a spectrum of rollups that are neither fully based nor non-based. ## Layer 2 Solutions and Composability Problems Ethereum’s **lack of throughput** and **transaction latency** drove the need for Layer 2 (L2) solutions. This was a major **paradigm shift** for users and developers, as they had to rethink how they interacted with Ethereum. The adoption of L2s came with new challenges: - **Fragmentation**: The introduction of L2s fragmented the ecosystem. Users and decentralized applications (dApps) that were once seamlessly interoperable on L1 Ethereum became siloed on different L2 networks. - **Loss of Synchronous Composability**: Traditionally, Ethereum contracts could interact in a synchronous, atomic manner. Ethereum does not deal with partial state transitions. This is no longer the case when different applications reside on separate L2s. ## What is Synchronous Composability? Synchronous composability refers to the ability of **smart contracts** to interact with **ACID properties**: - **Atomicity**: All operations occur, or none do. - **Consistency**: The system moves from one valid state to another. - **Isolation**: Operations are independent and unaffected by other concurrent transactions. - **Durability**: Once a transaction is complete, its changes persist. ## Solving fragmentation Multiple proposals exist to solve the fragmentation problem, but none have managed to gather consensus across L2s primarily because of **two conflicting issues**: 1- **High latency and cost** (based rollups) 2- **Lack of credible neutrality** (non-based proposals) ### What Are Based Rollups? In essence, **based rollups** are a novel approach that leverages the decentralization and credible neutrality of Ethereum by aligning the L2 sequencer with the eligible L1 proposer: The **L2 sequencer and the L1 block proposer are the same entity**. Based rollups thus enable **synchronous composability** not just between multiple L2s but also directly **with L1**. #### Based Rollups: The Good - **Synchronous Composability**: Achieves the same level of composability as native L1 contracts. - **Decentralization**: By relying on Ethereum’s existing proposer set, it avoids centralization risks associated with centralized L2 sequencers. - **Credible Neutrality**: The protocol for composability is tied to the Ethereum protocol, no rollup ecosystem or new company capitalizes on interops. #### Based Rollups: The Bad - **Latency of Ethereum**: Based rollups inherit the **12-second slot time** of Ethereum, which can be a bottleneck for some applications. **Preconfirmations** can help alleviate this problem, but the number of preconfirmations economically secured by an L1 proposer is **limited by the stake of said L1 proposer**. - **Cost of Ethereum**: submitting a commitment and corresponding blob per Ethereum slot is **not necessarily the optimal periodicity of commitments** for the based rollups in terms of cost, not just latency. The inability of a sequencer other than the L1 sequencer building atop based rollups can thus incur a higher cost on the users of based rollups compared to non-based ones. - **Binary Choice**: Based rollups must always be based or not; there is no flexibility to be "based on demand." *Note: based rollups "on demand" are indeed possible, and in fact is something I talked about at TUM Blockchain earlier this year in what I call hybrid-based rollups and what Espresso has recently called ad-hoc based rollups.* - **Bootstrapping**: Based rollups can contain many empty Ethereum slots if many consecutive L1 proposers do not want to be L2 sequencers for the eligible based rollups. Solutions like [vanilla based rollups](https://ethresear.ch/t/vanilla-based-sequencing/19379) attempt to mitigate this issue. ## What about ACID for non-based rollups? The above issues concerning latency, costs, and the binary choice, translate into **serious doubts for well-established rollups to become based**. Put differently, if Arbitrum Nova, ZKsync Era, Base, Scroll mainnet, or OP mainnent experience a ridiculously low latency and cost compared to L1, and have significant demand of transactions happening internally compared to only a few transactions that currently drive demand for interops with other chains, why would they sacrifice these benefits in favor of a **synchronous composability** that **is not necessarily going to drive the same demand** for their systems? These concerns for all these rollups are not to be disregarded, and in fact, multiple proposals are trying to solvent these issues outside the credibly neutral Ethereum umbrella, in what we can call **shared layers**. ### Shared layers: Composability at faster-than-Ethereum latency Many proposals try to achieve composability at faster-than-Ethereum-latency but with reasonable guarantees. When two L2s **interact at faster-than-Ethereum latency** (i.e. before they commit their state transitions to L1), there are **three** (fundamental) **issues** that rollups need to deal with: **Equivocation, invalidity, and non-settlement**. > *In reality, there are other issues rollups need to deal with, such as liquidity fragmentation when withdrawing, but let us disregard these for the purpose of this document. These issues also exist with based and rebased rollups before settlement.* Suppose Alice owns **10 ETH at Scroll** mainnet and wants to **transfer** them **to Bob in Arbitrum Nova**. The L1 native way to do this is for Alice to withdraw from Scroll to L1, waiting for L1 settlement of Scroll mainnet, then claim the funds in L1 and deposit them into Arbitrum nova. Clearly, this is suboptimal for Alice: she needs to wait an amount of time in the order of **tens of minutes** for settlement, and pay at least one L1 transaction. The problem is even more significant in the **opposite direction**, since withdrawals from Arbitrum Nova take **7 days**. Clearly, there are **incentives** for Arbitrum and Scroll to **collaborate to find faster in-protocol ways** to let Alice **move liquidity** between these two chains natively. Suppose such a solution existed, and Arbitrum credited Alice with 10 ETH in Nova before Scroll submitted anything to L1, what can go wrong for Arbitrum? Three things are possible: 1- **Equivocation**: Scroll equivocates by submitting a different state transition in which Alice's 10 ETH are actually sent to Zksync's Era, **effectively robbing 10 ETH from Arbitrum Nova** (which needs to reorg to be able to settle). 2- **Invalidity**: Scroll does not equivocate, but the state transition that contained the correct transaction is invalid, and thus Scroll **can never settle** it (i.e. prove it) on L1 and give the funds to Arbitrum. Arbitrum needs to reorg again to settle. 3- **Non-settlement**: Scroll does not equivocate and the state transition is valid, but Scroll's designated **provers go offline** and thus settlement never happens. Arbitrum needs to reorg again. By Arbitrum integrating the 10 ETH sent from Alice in Scroll before Scroll commits on L1 (in the case of equivocation) and before Scroll settles (in the case of invalidity and non-settlement), Arbitrum takes a risk in its chain dependent on the security considerations of Scroll. It is still to be defined how based rollups deal with the problems of invalidity and non-settlement, same as rebased rollups, though they get equivocation-prevention from L1. Optimistic rollups have no problem with non-settlement since a valid state transition will settle automatically after enough time. Similarly, once zk proof generation latency becomes practical enough, both non-settlement and invalidity will be trivially solved. In the meantime, solutions relying on TEEs and timeouts that allow any prover to step in and prove a state transition can solve these two problems. The problem of **equivocation is** however **fundamentally different**, as we discuss below. ### Equivocation prevention: Mesh and Hub solutions The first that must be understood is that **zk proofs do not solve everything**. Even if Bob sees a zk proof for a state transition that contains the payment from Alice, this **does not mean** that this state transition is the **one and only valid state transition** (non-equivocation). A zk proof can prove that Alice sent 10 ETH to Bob in Arbitrum Nova, but it does not prove that Alice can only settle this state transition on L1: Alice and Scroll can create a different, conflicting zk proof proving that it sent those same 10 ETH to Zksync's Era. In particular: **Zk proofs alone do not solve and will never solve equivocation.** For equivocation prevention, there are two fundamental solutions, that we can call **mesh and hub**. **Mesh** solutions mean that **rollups** simply **trust** their **counterparties not to equivocate**, e.g. Arbitrum trusts Scroll. Solutions like this **increase the dependency** set of Arbitrum **by the number of rollups** that Arbitrum interacts with at faster-than-Ethereum latency. At the time of writing, examples in this space are OP superchain, Arbitrum chain clusters, or Polygon AggLayer. **Hub** solutions improve equivocation prevention by providing a **shared layer** that all can **trust for interops** at faster-than-Ethereum latency. This way, regardless of how many rollups Arbitrum interacts via the hub, as long as the **hub does not equivocate** none of these rollups can pose a security risk on Arbitrum via equivocation. Solutions in this space include Espresso or Elastic Chain. Ethereum can in turn be seen as a Hub that all rollups use. In both cases, the security implications on a rollup to join any of these services are fundamentally different: rollups need to **trust at least 1 shared layer besides Ethereum** (hub), **or all other rollups** they interact with. Furthermore, in the mesh approach, **trust must respect transitivity**: if Arbitrum trusts Scroll but not ZkSync, then Scroll cannot trust ZkSync while maintaining Arbitrum's trust. Only disjoint "trust groups", i.e. **cliques of rollups**, can interact with each other in a mesh. So far it seems thus that the hub approach is fundamentally better than a mesh, but in reality, it is much **easier to build** non-credibly neutral **mesh protocols**, as they do not modify rollups interactions with L1. The **hub** approach becomes better at preventing equivocation by directly becoming a shared layer in all fast-path interactions between each rollup and Ethereum. As with any in-protocol change, hub designs require a much more **credible neutrality** for rollups to include this **important dependency** in their architectures. This helps explain the success of mesh protocols compared to non-credibly neutral hub-based solutions so far. ### Mesh and Hub: The Good - **Low latency and cost**: they both achieve composability at faster-than-Ethereum latency and without necessarily having to pay for L1 transaction costs. - **Synchronous composability**: Not just asynchronous but also synchronous composability can be enabled by these solutions ### Mesh and Hub: The Bad - **Risk**: a rollup making its state dependent on a state transition of another rollup that is not yet committed or settled on L1 can translate into new **security considerations** that affect all its users. - **Lack of credible neutrality**: all non-based composable proposals are either directly opinionated on the requirements of participating rollups (only allowing rollups forking **particular SDKs**) or the result of design decisions made by **only one team** (lacking consensus across the teams and needs of different rollups). Especially for hub-based solutions (that are the only solutions that scale with the number of interoperating rollups), credible neutrality is critical for the success of a proposal. ## Rebased Rollups: The Best of Both An **ideal** solution would achieve **credible neutrality**, as based rollups do, while also achieving **composability** at **faster-than-Ethereum** latency and at a **fraction of the L1 cost**, like non-based solutions. Perhaps one day all rollups organize to jointly design a hub-based shared layer that offers these benefits without the technical debt of having to reuse L1 as the only credibly neutral component across all rollups. I take the chance here to invite the Ethereum Foundation to coordinate this effort, which I believe is more useful for everyone than letting competing protocols be proposed by rollups that will never subjugate to the hubs of each other. Until then, we can find ways to build upon the original based rollup idea making it more practical. **Rebased rollups** aim to combine the benefits of based and non-based composability, namely: - **Credibly neutral** ground for **synchronous composability** without added dependencies, and - **Fast and cheap transactions** for participating rollups. Rebased rollups achieve this by a radical idea: **being based on-demand for periods even shorter than an Ethereum slot**. Let us explain this with a simple example of one type of rebased rollup: 1. During the based period, the rebased rollup gives the **L1 proposer** the right to build the next block at the beginning of its Ethereum slot. This right is only for **one block** (i.e. the rebased rollup is only based for 1 Ethereum slot). 2. Even if the L1 ethereum **slot** for the based proposer has **not yet finished**, the centralized **L2 sequencer** of the rebased rollup can continue **building upon the L1 proposed, based block** as soon as it receives it. This allows the centralized L2 sequencer to **build new blocks** just after [2-4 seconds of the start of the based period](https://youtu.be/M4Kxw4NtB_A?t=24105) (in the good case, 80% of all proposals are distributed through GossipSub before the 2 seconds mark). 3. 4 seconds before the end of any Ethereum slot, the centralized sequencer **decides whether the rollup becomes based** for the next Ethereum slot, in which case it propagates a new L2 block formally giving the sequencing rights to the next L1 proposer. 4 seconds has been used as an example, and different value can be used. *Note: there is no issue if the L1 proposer receives this right to sequence too late other than delayed block generation: it will be the next L1 proposer that will build it. The next L1 proposer could unlock the work of the L2 proposer in the meantime with preconfs*. 4. Repeat 1. According to results from the time to propagate and build blocks even when maximizing MEV ([1](https://blog.sigmaprime.io/attestation-analysis.html), [2](https://ethresear.ch/t/on-attestations-block-propagation-and-timing-games/20272)), it follows that in most cases the L1 proposer will see and be able to build upon the latest rebased block (it will receive the block that acknowledges the rebased rollup starting a new based period). Also, in the cases when the L1 proposer block is received by the centralized L2 sequencer within the first 4 seconds of its Ethereum slot, the likelihood of this block becoming orphaned is significantly low, meaning that the work for the L2 proposer will rarely result in a reorg in the good case. This means that even in the **conservative case** in which we reserve the first 4 seconds for the L1 proposal of the based block and the last 4 seconds for the next L1 proposer to build on the latest non-based block, that leaves **4 seconds** per based slot during which a rebased rollup can **increase throughput** and issue L2-level preconfirmations. However, several **low hanging fruits** can make this proposal much more appealing, namely: - **Less conservative assumptions** on block propagation and building time - The usage of **L1 preconfirmations** instead to start building on preconfirmations instead of propagated L1 blocks - Dynamically increasing the confidence on no reorgs happening as time passes via tracking attestations, at the same time that more blocks are appended to that of the L1 proposer. The intuition for the name "rebased" should now be clear: similarly to forks of a github repo rebasing, rebased rollup's built blocks are eventually merged into the main branch when it becomes based, but it may need to "*rebase*" to build on top of a new L1 block if the L1 block it had built upon becomes orphaned. ### Rebased rollups: The good - **Increased throughput** and **reduced latency**: rebased rollups can benefit from greater throughput and lower latency compared to based rollups and even compared to [ad-hoc based rollups](https://hackmd.io/@EspressoSystems/BasedEspresso), as they can propose blocks at faster-than-Ethereum latency even during the Ethereum slots in which they synchronously compose with L1 and other (re-)based rollups. - **Credible neutrality**: L1 synchronous composability between two based rollups is indistinguishable from composability between a based rollup and a rebased rollup, or between two rebased rollups (no added assumptions for composability because of a rollup becoming rebased instead of purely based). - **Horizontal scalability of economic security**: by tracking attestations of the based block (the block proposed by the L1 proposer), while all centralized sequencers independently append blocks in their respective rebased rollups, rebased rollups do not have to share the economic security of any sequencer except for the blocks that are based. This a more efficient usage trade-off of the stake of both L1 proposers and centralized sequencers compared to the number of preconfs they can economically secure. ### Rebased Rollups: The Bad (Let’s Be Honest) It would be misleading not to outline that relying on preconfirmations and L1 proposals before the end of a slot (or ultimately, finality) implies reduced security guarantees compared to waiting for the end of the slot (non-negligible probability of a fork/reorg). This should not come as a surprise though, and it is my firm belief that our community should be transparent in outlining that not just rebased rollups or preconfs, but actually **all types of rollups increase throughput but don't reduce latency** (from the perspective of reusing L1 security). For this reason, although I list this as a danger of rebased rollups, it should actually be noted that this is a danger caused by us, as a community, by focusing on lower latency through preconfs, centralized sequencers, and generally issuing blocks at faster-than-Ethereum latency. ### Why not preconfs + based rollups? Preconfirmations are a fantastic tool for issuing low security and low latency guarantees of inclusion or execution. But **they do not chain too well** in terms of latency. That is, during slot *i*, then the next proposer can economically secure a limited number of preconfs for slot *i+1*. The **number of preconfs is limited by the economic security of that proposer** in particular (understood as the amount of stake that this proposer loses if he dishonors the preconfs). But this can be **scaled horizontally via rebased rollups**: rebased rollups' sequencers can also economically secure a limited number of L2 preconfs in the same slot, secured by the same economic security via stake on L1. This way, the number of preconfs that can be given in a particular L1 slot in the good case horizontally scales with the number of rebased rollups, at the simple cost of each of them staking the same amount as an L1 proposer, for example. ## Conclusion: The future of rebased rollups Faster-than-Ethereum latency via centralization and lowered economic security, despite its dangers, will simply happen (it is already happening). Even the recent proposals for faster finality in Ethereum will provide [blocktimes of 4 seconds](https://youtu.be/Plvy7fgFCm4?t=234) and [finality times of 3 slots](https://youtu.be/M4Kxw4NtB_A?t=22273). This is far **too much latency for too many applications** that are already enjoying much lower latency via preconfs and centralized sequencers. I believe there is great space for different gradients of economic security offering different gradients of latency for transactions. Rebased rollups enable **tapping into multiple proposers within one L1 slot**, obtaining the best benefits of based rollups, preconfs, and non-based rollups: competitive economic security, credible neutrality, and low cost and latency.