The Practical Guide to Ethereum Rollups

In this article we aim to map out the technical landscape surrounding Ethereum rollups to provide a solid foundation that helps people understand how they fundamentally work and how they contribute towards realizing Ethereum’s scalability goals. Thereafter we establish a foundational framework which aims to enhance how credibly-neutral parties judge and assess different rollup implementations across Ethereum.

Rollups represent a crucial piece in the puzzle that makes up Ethereum’s endgame, therefore it is important that we improve the material available for understanding these complex but often misunderstood modular blockchains. While the rollup design space across the crypto landscape is overwhelmingly expansive, we seek to provide a more Ethereum-local perspective of the rollup landscape, specifically around rollups designed with Ethereum scaling in mind. Therefore it would be worth expressing that not every possible variation of rollups will be covered within this article, in particular, alt-VM rollups that exist on top of Ethereum are not covered (the reasons for this will be elaborated later).

With that context out of the way, let’s outline some of the topics that will be covered within this article:

1. Defining Blockchains: A brief overview of the basics of a blockchain system, crucial for establishing a mental model of rollups.
2. Establishing Abstract Ethereum Rollup Model: Defining what rollups are, how they differ from blockchains like Ethereum, and providing opinions on what the core characteristics of an Ethereum-scaling rollup should be.
3. Rollup Life Cycle: Walking through the basic life cycle of rollups.
4. Rollup Characteristics and Features: Covers how rollup finality works, the sequencer design space, trust-minimized bridging, emergency mechanisms.
5. Classic Rollups & Sovereign Rollups: Defining classic and sovereign rollups and exploring how they can be implemented in Ethereum and the key differences between these two types of rollups.
6. Introducing A Framework for Navigating the Ethereum Rollup Design Space: Using all information described up to this point, a framework for mapping out the design space for Ethereum rollups is introduced.
7. An Exploration of Rollup Security and Risk Vectors: Identifying and describing different types of risks that can be encountered with rollups
8. Potential Solutions to Tackle Rollup Security Risks: A section that dissects rollup security risks and highlights a variety of potential strategies and solutions that aim to improve security in multiple dimensions.

A Brief Definition of Blockchains

Before we dive into the rollup landscape of Ethereum, it would be helpful to quickly establish a mental model of blockchains. Generally, when we talk about a "blockchain”, we are referring to a system characterized by two things:

1. A Cryptographic Data Structure: An immutable, append-only linked list of blocks.

2. A Network: A decentralized network of nodes running a blockchain protocol that maintains this cryptographic data structure.

   
   

The term "blockchain" was initially used to describe the cryptographic data structures that these networks depend on, but nowadays, it’s common to refer to these networks as blockchains themselves (e.g. Ethereum is a blockchain). With that in mind, let's provide a brief definition of a "blockchain”.

Blockchains are decentralized, public platforms that allow users to transact with one another securely, in various ways, without the need for a central authority. They essentially exist in the form of a decentralized network of nodes running a blockchain protocol, which trustlessly executes and records a global history of transactions and system state through a cryptographic data structure (we will refer to this as the "chain" going forward).

This chain data structure is composed of a series of blocks, where each block contains a list of transactions as well as cryptographic hashes of the current blockchain state and the previous block. Therefore, this data structure resembles a "chain of blocks" which provides an immutable, tamper-resistant, global ordered list of transactions and system states. When a new block gets added to a blockchain, every node in the network independently executes the list of transactions contained in the block and updates its state and chain data structure accordingly. Through decentralized consensus, the network collectively synchronizes this update, advancing the blockchain forward by appending a new block and recognizing it as the current head of the blockchain.

Now that we have a better understanding of how blockchains work, we can think of their architecture as being composed of three layers that serve different purposes:

• Data Availability Layer: This layer ensures that all blocks and transactions are published and accessible to the network. It provides the data required to compute the current state of the blockchain at any given time.

• Consensus Layer: This layer is responsible for achieving network-wide consensus on the ordering of blocks and the transactions they contain.

• Execution Layer: This layer handles the execution of transactions within blocks and maintains the blockchain’s state.

  
  

At a high-level, this basically describes how Ethereum works and we characterize blockchains that independently implement this functionality and operate in this way as Layer 1 blockchains (or L1s). With the context established above, let's now turn our attention to rollups and learn what exactly these solutions are, as well as their relationship with Ethereum.

What Are Rollups?

Rollups are blockchains whose chain and state can be fully derived from the DA layer of an L1. When we talk about “rollups on Ethereum”, we are referring to rollups that use Ethereum as their DA layer.

Unlike L1s like Ethereum, which implement all three of their architectural layers (DA, consensus, execution), rollups only implement their own execution layer. They outsource the management of data availability and consensus to the L1. We illustrate the differences in architecture below:

So what does it mean for a rollup to outsource the management of DA and consensus to an L1 blockchain?

• DA: This refers to the global history of rollup transactions.
• Consensus: Consensus here refers to ensuring the integrity of the global transaction history such that the details and ordering of its contents cannot be modified once published to the L1 blockchain.

An L1 blockchain already provides security to the immutable details and ordering of data published to it, therefore when a rollup opts to use an L1 to provide similar guarantees to its blockchain. This demonstrates how the L1 provides DA and consensus guarantees to the rollup.

When we think about rollups and their relationship with Ethereum, we often refer to them as Layer 2 blockchains (L2s). The reason for doing so is because these blockchains are designed such that they leverage Ethereum’s security properties to enable them to do highly performant execution without compromising on security.

The end result is that Ethereum’s security makes these highly performant, but secure blockchains possible and therefore can be considered as efficient use of Ethereum to increase utility. When we think about rollups this way (specifically how Ethereum plays a crucial role in enabling these systems to exist in this secure form), we can consider the functionality provided by the L1 as being on-chain, while the functionality outside of the L1 (handled sovereignly by the rollup system itself) is considered off-chain.

In having a better understanding of how Ethereum provides DA and consensus guarantees to a rollup, let’s consider how the blockchain data structure carrying all the useful information about its system state and user transaction activity can be derived from Ethereum:

• Actors participating in a rollup can trustlessly construct the current state of the rollup blockchain by fetching the global rollup history from Ethereum. From here, this data can be run through a rollup’s node where it can apply the state transition and rules and deterministically compute the current state of the rollup blockchain.

• The procedure for handling this will be formally described within the technical specification of the rollup and is translated into the code that rollup nodes run – we refer to this procedure that manages this as a rollup’s chain derivation. It is through the chain derivation procedure that rollup nodes can read the ordered rollup history from Ethereum, parse the information and construct a chain of L2 blocks trustlessly.

• In managing computation of the rollup blockchain in this way, rollup nodes do not need to trust each other as the data securely existing on Ethereum simply just needs to be input into the rollup’s chain derivation procedure and all nodes should deterministically arrive at the same view of the rollup blockchain.

  
  

We illustrate the basic mechanics behind rollup chain derivation in action below:

How Do Rollups Scale Ethereum?

In providing motivation for how L1s like Ethereum make rollups possible, it would be useful to provide similar motivations around how they could classify to be a means to scale Ethereum. This is important, given how many protocols are described as “scaling Ethereum” despite not having the properties of a true Ethereum scaling solution.

As described earlier, rollups are blockchains that use an L1 (Ethereum in this case) to maintain the availability and canonical ordering of its global transaction history. This information is needed to deterministically compute the state of the rollup and continue doing so as it progresses forward with time and usage. Outsourcing the management of this responsibility to Ethereum means rollups can focus on providing better execution capabilities to enhance what users and developers can do with it.

While this demonstrates how Ethereum is instrumental in providing security and enabling rollups to focus more on execution to provide experiences not technical or feasible on Ethereum, this doesn’t provide a completely convincing answer to how they qualify as a solution to scaling Ethereum. If anything, this relationship can be characterized as Ethereum being a service provider to a rollup blockchain.

If rollups truly wish to practically contribute to Ethereum scaling (and earn the title of being classified as an Ethereum scaling solution), rollups need to be technically characterized by more than the simple constructions that define their blockchain type. So what do they need to do in order to objectively qualify and meet the technical criteria to be considered an Ethereum scaling solution?

Sharing the security properties of Ethereum is one requirement that is already satisfied, but more are needed. “Scaling Ethereum” means more than increasing the utility of its security infrastructure, it also means providing more utility and technical capacity to service Ethereum’s users, economic value, and application landscape. A step to getting here is having rollups be more tightly compatible and composable with Ethereum such that it extends instead of fragmenting Ethereum. With this in-mind, we will highlight two additional requirements that help endow rollups with the means to help make this goal a reality:

1. Composability with Ethereum

Stronger composability (such as L1 <> L2 application-layer communication) between Ethereum and its L2s establishes a strong technical and social arguments for rollups being classified as extensions of Ethereum and hence actual scalability solutions for it. While bidirectional interoperability between Ethereum and rollups is not a strict pre-requisite for technical scaling Ethereum, it can be considered as something that heavily provides for benefits (more on this later when we explore classic and sovereign rollup types).

Importantly, users, economic value, and applications should be able to be transferred to rollups without resembling a “vampire attack” or dilution of Ethereum’s ecosystem. In being tightly coupled with Ethereum in this way and productive for users, the experience of using rollups does not resemble users and value being removed from Ethereum but rather being put to work in different ways.

A good way to get intuition around this is to consider dApps that exist on Ethereum. When developers create a decentralized application on Ethereum, it may require users to lock value into it (sometimes even permanently depending on the use case), but this does not mean it fractures Ethereum’s global liquidity or userbase. Rather it demonstrates increased productivity that has been achieved on the blockchain application layer.

You don’t consider increased amounts of dApps being created on Ethereum as fracturing its total value and users, therefore the same ideology should be applied to how we think about rollups (provided we design them correctly for the purpose of scaling Ethereum). This means the explosion in the number of L2s (as evidenced by statistics from L2Beat) isn’t a problem for Ethereum’s competitiveness, value accrual, and sustainability insofar we design such rollups to be symbiotic and highly composable with Ethereum.

2. EVM-Equivalence

We consider the execution model of a rollup to be EVM-equivalent if the rules of its execution are compliant with the technical specification of Ethereum’s Virtual Machine. EVM-equivalence matters because we want rollups to, at the minimum, be capable of providing the native experience of using Ethereum’s application layer within the rollup. EVM-equivalent rollups updates their base execution model in unison with Ethereum, making rollups and Ethereum together resemble a single, homogeneous system **(**given the compatibility and synchronization of execution models and shared security.).

This contributes to helping extend the provision of Ethereum’s application layer network effects to users, providing them with familiar application-level experiences but at cheaper costs and higher-performance (translating to faster transactions). This not only extends the utility of Ethereum’s execution, but also demonstrates an off-chain means of using Ethereum’s native execution in a higher-performance manner while not compromising on the security that enables it.

In expressing the importance that providing EVM-equivalence has in satisfying the technical criteria to qualify a rollup as being an Ethereum scaling solution, it would be worth clarifying that a rollup can be EVM equivalent while extending the capabilities of its execution model. It is simply a belief that a rollup that practically scales Ethereum, without fragmenting it, must provide EVM-equivalence at the bare minimum.

The motivation behind this belief lies with native composability between Ethereum and rollups. Being EVM-equivalent does not imply undying loyalty to the EVM itself, but more so to how Ethereum’s execution is managed – it's about maintaining compatibility. If an alt-VM rollup can completely translate Ethereum’s execution (and state involved) to its own execution model, then it can meet the technical criteria –

Note that this simply describes what EVM-equivalence is in the first case. This doesn’t mean that alt-VM rollups can’t play a role in contributing to technically scaling Ethereum, it is just my belief that they should not be positioned as L2s but potentially L3s that rely on an EVM-equivalent rollup for security (these are my speculative opinions of how best to utilize alt-VM execution to technical scale Ethereum, so take it with a grain of salt).

Having provided a description of how constraints applied to rollups help provide a stronger technical argument for qualifying as Ethereum scalability solutions, let’s keep such a foundational rollup specification in mind and explore how rollups in Ethereum work and the various parts that drive their functionality.

An Overview Of Core Rollup Functionality

In this section we will be thoroughly covering the core functionality within rollups, including how they manage their interactions with Ethereum along with the various components and design features they implement to drive their operation and provide security and performance guarantees.

The Lifecycle of a Rollup

In order to understand the functionality that needs to be implemented to drive rollup operation, we should first familiarize ourselves with the lifecycle of using a rollup. To do so we will walk through what happens when users submit transactions to a rollup and see what occurs from there:

1. Users submit their transactions to a rollup.

2. The rollup continuously streams transactions from users, immediately executing them. This action is performed by a privileged actor known as the Sequencer. When doing this, the Sequencer provides users with a soft guarantee of execution and how it will change the rollup’s state.

3. After a certain period of time (generally one Ethereum block: 12 seconds), the Sequencer batches the transactions received within this 12 seconds and publishes them to Ethereum within an L1 transaction. These batches contain all the transactions that will be trustlessly derived into L2 blocks by rollup nodes later. These batches are usually accompanied by additional batch metadata during publication (which might be published by another rollup operator instead of the Sequencer – this will vary depending on how specific rollup chooses to manage this step).

4. Rollup nodes watch Ethereum for published rollup batches and download them when observed.

5. Rollup nodes feed the downloaded batch data through their derivation logic which parses the batch data and produces a set of new L2 blocks to execute.

6. Rollup nodes update their chain data structure (appending new blocks from the batch to it). Showing that the soft guarantee provided by the sequencer becomes a hard one.

7. After the L1 blocks containing batches get finalized on L1, they are finalized on L2.

   
   

   
   

One key design detail that has yet to be clarified is how users actually pay for transactions in a rollup. In L1s like Ethereum, fees are always denominated in the native asset (ETH in the example of Ethereum). Rollups, on the other hand, generally leverage denominate transaction fees in ETH. There are three reasons for why this is a sensible decision when it comes to rollup design:

• Mature resource pricing: Considering that rollups are EVM-equivalent, the resource pricing implemented alongside the EVM was designed to represent true social costs of transaction and have users pay for these costs in rates denominated in ETH per unit gas. It therefore makes sense to simply use ETH as introducing a new native asset to price transactions may require extensive mechanism design work to ensure the economic equilibrium driven by rollup fee markets and resource pricing is stable.
• Ease of representing new costs unique to the rollup setting: Given the crucial tasks that rollups perform of publishing batches to Ethereum, these costs require the rollup actor to pay L1 transaction fees. These costs need to be amortized across users on the rollup in order to ensure the economic efficiency of the L2. Denominating transaction fees in ETH, makes the process of representing amortized costs of transactions simple therefore streamlining fee logic and resource pricing on the rollup.
• Composability with Ethereum: Rollups that leverage ETH to manage transaction fees provide a familiar experience to both users and developers that originated from Ethereum, this assists in maintaining the homogeneity of technical and user experience in using a rollup or Ethereum.

Having fees denominated in ETH isn’t a strict technical requirement, but for the reasons outlined above it begins to make sense why this is done.

Making Sense of L1 and Rollup Finality

When it comes to finality in blockchains, it is easy to think of it as a promise that can no longer be broken. On Ethereum when a block gets added there is a promise made by the network that says that transactions inside it will not get reversed, and while this is a strong promise, it is not an unbreakable one.

This promise could be broken if the specific block containing these transactions gets reorged out of the blockchain and the transactions involved are no longer contained in the new canonical chain record. However, with Ethereum’s transition to PoS, this is no longer the case.

After 2 epochs pass (64 blocks), all the blocks contained within those 2 epochs get finalized, meaning that the promise is now unbreakable (meaning the blocks will permanently exist with their contents and ordering being immutable). We will refer to this type of finality as hard finality.

When we walked through the rollup lifecycle above, we introduced a few versions of promises made for rollup transactions. In the case of rollups, there are several stages that a user’s transaction goes through where, in the end, the promise becomes immortalized through the finalization of L1. Let’s go through these stages to get a better understanding of how finality is achieved within rollups:

Sequencer Preconfirmation

When users submit transactions to the Sequencer, they receive a response in the form of a promise that the transaction will be executed according on top of the current latest version of rollup state that the Sequencer had at the time that the transaction was sent. The Sequencer goes ahead and locally executes the transaction according to their maintained record of the rollup blockchain and will maintain this ahead-of-time record of changes.

At this stage, a rollup is simply streaming in user transactions, executing them, and maintaining a relative ordering of the transactions from which it will create a batch to include all of these transactions received within a time period. The Sequencer will publish a batch of collected rollup transactions in every L1 block. Because the Sequencer is publishing batches to Ethereum, it manages the task of collecting, locally executing, and publishing batches every 12 seconds.

Soft Finality

When batches get published to Ethereum, we consider the transactions included in them to have soft finality. We consider these transactions to be softly finalized because they are now officially made available on the L1 which provides DA and ordering guarantees of not just transactions within the batches, but also the logical ordering of batches themselves.

When batches get published to Ethereum, rollup nodes detect and fetch them and perform their chain derivation logic from which new L2 blocks to add to the rollup chain are produced. Rollup nodes therefore will add these L2 blocks that were derived from batches to their record of the rollup chain, where these added L2 blocks will be considered softly finalized, until the L1 itself finalizes.

Hard Finality

Once the L1 finalizes, the Sequencer’s promise is now fully made unbreakable/irreversible. The L1 can’t reorg the data needed by rollup nodes to derive the chain and therefore the contents and ordering of L2 blocks and transactions encoded within batches become fully finalized and impossible to modify and remove from L1’s history.

Sequencing In Ethereum Rollups

The above two sections have provided us with more insight to how changes are applied to rollup as well as how they become finalized and irreversible once the L1 blocks holding newly published rollup batches finalize. In this section we will explore how the sequencing task performed within the rollup system is managed.

Sequencing is a concept that is unique to the rollup setting because on L1s like Ethereum**—**users are familiar with simply sending their transactions to the network where a block producer will either include their transaction in the next upcoming block or not in which case a future block producer will likely include it. Because of this, users can only get confirmation of their transactions going to get executed once a block is actually added to the blockchain.

In contrast, users on rollups get immediate responses regarding execution in the form of a sequencer promise (a preconfirmation), where any actor following whatever the Sequencer is doing can act on the state of the rollup blockchain ahead of time before the L2 blocks are even derivable from the L1. This ahead-of-time execution is what allows rollups to provide users with the experience of faster execution, and because of the structuring of the rollup’s blockchain architecture, transactions are additionally significantly cheaper compared to L1.

With this dynamic, users are able to get faster and cheaper transaction settlement on the rollup, where the rollup will ensure that these transactions are eventually finalized once the L1 blocks containing the ahead-of-time L2 blocks (encoded in batches and containing preconfirmed transactions) also finalizes.

The Sequencer has a crucial role within a rollup, not only providing users with preconfirmations of their transactions but also ensuring that the rollup network can deterministically sync to the latest version of the blockchain:

The above diagram highlights the integral role that the Sequencer has in driving the functionality of the rollup, therefore it is crucial that rollups take care in designing how sequencing is managed because if not implemented effectively it may be a single point of failure that disrupts the operation of the blockchain. In this next section, we will explore the design space for sequencing and describe various different approaches that rollups can take towards establishing their sequencer models.

Sequencer Design Space for Rollups

As described earlier, sequencers provide rollups with the ability to provide users with extremely fast feedback regarding the execution of their transactions via issuing preconfirmations. In practice, this results in user experiences such that a user can receive responses about their transactions in as quick as 100ms  (maybe even less at some point) which marks a significant improvement over Ethereum, which in the best case, only offers users feedback regarding the execution of their transactions in 12 seconds.

Depending on how a rollup designs their sequencing system, the time to provide these transaction preconfirmations will range. For example, if a rollup decides to implement their sequencing by having a single, trusted sequencer, the rollup could provide extremely quick preconfirmations to users compared to a rollup that introduces a consensus model to rotate which actors get to sequence transactions over specific time intervals. This is because sending transactions to a single sequencer actor is far more simple and involves less latency compared to a strategy that involves increased network communication and blocking behavior that stalls how quickly sequencing is done.

Ultimately this highlights a performance vs security tradeoff balancing act. Ideally we would like the sequencer role to be decentralized to ensure the integrity of the duties performed by actors taking on the role, but at the same time we want to provide users with valuable preconfirmation properties that rollups are uniquely positioned to provide. With this in mind we can more formally express what desired properties we want for rollup sequencing that balances security and preconfirmation speed.

Given that we seek to establish standards that describe how rollups should be designed to truly complement and contribute to scaling Ethereum, it’s worth expressing that it should be an overarching goal for Ethereum rollups to try provide security guarantees that are as close as possible to being as strong as Ethereum’s itself. In having such an alignment goal, it can guide the decision-making involved with designing rollup components such that consistency in the global rollup design is echoed across the implementation of all its components and features.

With this in mind, let’s describe some of the desired security properties that we may wish to guarantee when designing a sequencing scheme for a rollup:

• Liveness: We want to ensure that sequencing is designed such that the rollup has strong guarantees regarding its liveness, being robust to unexpected conditions.

• Censorship Resistance: We want to ensure that the transactions of users will always be included within some well-defined period of time (it would be worth clarifying that the context of some transactions require much shorter periods compared to others).

• Accountability: We want to ensure that rollups have the capability to audit how sequencing is done to ensure it is done honestly and according to the performance standards established. This therefore describes detectability functionality in which deviations from the requirements to sequence can be identified and attributed to a specific sequencer and mechanisms to deal with these violations can be dealt with.

  
  

Having a better idea of the desired properties surrounding a rollup’s sequencing model, there are various approaches that a rollup designer can take that depends on which properties they want to prioritize. We illustrate a basic sequence of sequencing levels (by trust) below:

While only four different sequencing models are described in the diagram above, there are many more that can exist beyond these. The above-four models aim to demonstrate the range of variation that can be applied through different sequencing models without exhaustively expressing every possible approach that can be taken to implementing rollup sequencing. To make reasoning about the application of different sequencing models within a rollup system easier, we condense the operational diagram expressed earlier below, demonstrating how any different sequencing model can be applied to the pink/purple circle element:

Single Sequencer Model

A single, trusted actor serves as the sequencer for the rollup. This setup ultimately provides the lowest possible latency to users due to two reasons:

1. No leader election process involved: In having a single, trusted actor being permanently responsible for sequencing, there is no time dedicated to managing rotation of sequencer duties. This is a form of pre-sequencing latency minimization.

2. No validation process involved: In having a single, trusted actor being permanently responsible for sequencing, it is the sole party responsible for validating the job it performs, meaning that no other network actors block progress by virtue of already trusting the sequencer. This is a form of post-sequencing latency minimization.

   
   

In there only being one actor always serving as Sequencer, a user is simply establishing a 1-to-1 connection line of communication with the Sequencer. Not only is this efficient due to the reasons listed above, it also means that there is no significant network-related latency introduced.

For example, in Ethereum (outside of private orderflow), a user would traditionally submit their transaction to a node which then gossips its existence over a P2P network, naturally this makes network-wide discovery of the transaction inefficient meaning that the time between when the user broadcast the transaction and when a block producer discovers it is non-negligible. With the single, trusted sequencer model, this discovery time is reduced significantly because the user (or wallets on their behalf) establish a direct connection to the Sequencer and broadcast their transaction to it, where it will immediately get serviced.

Permissioned Set Model

A list of whitelisted actors rotate the sequencer role among each other across time. This approach addresses the single point of failure concern introduced with the single sequencer model therefore improving liveness guarantees. In other words, sequencing has been improved by making it more fault-tolerant with this model. It still introduces strong trust assumptions because these actors are not independent and represent a permissioned set.

Classic, Sovereign BFT Model

In this model a BFT protocol (i.e. a decentralized consensus protocol)  is utilized to manage sequencer delegation. We refer to this model as being “sovereign” because in this model the rollup bootstraps its own permissionless network of actors to participate within the consensus process.

How a rollup utilizes BFT consensus can vary depending on what they aim to achieve with it when it comes to sequencing. In addition to this, different approaches may yield different performance and security guarantees. To highlight how different performance and security guarantees can be achieved depending on the approach taken in using a BFT protocol, let’s consider two rollups that use a BFT protocol for different purposes:

• Consensus for coordinating leader election: In this setup, a rollup leverages a BFT protocol solely for leader election (i.e. designating the sequencer role to a specific actor for a limited time).
• Consensus for coordinating leader election + validation of constraints: In this setup, a rollup leverages a BFT protocol to manage leader election as well as validation of the work done by each sequencer. In this process the consensus protocol is loaded with more responsibilities beyond leader election. In this case, the network of actors using the BFT protocol are coming to consensus on both who the active sequencer is as well as verifying the validity of transactions included by the sequencer batches before allowing the sequencer to publish it to Ethereum.

Similar to the permissioned set model for sequencing, a sovereign BFT model eliminates the single point-of-failure risk that the trusted, single sequencer model was exposed to which improves one of the desired security properties – liveness.  Where this model goes beyond the trusted, single sequencer and permissioned set models is by allowing untrusted actors to participate within sequencing where BFT consensus provides an incentive-compatible and cryptographically-verifiable means for the rollup to provide sequencing in a decentralized manner.

In addition to this, we can see stronger guarantees of security properties (censorship resistance, accountability) being achievable with this model. In relying on decentralized consensus, this model may require accountability gadgets to be included in the design of the system to ensure the neutrality of participants that will be delegated sequencing rights. This, in turn, helps ensure actors participating in the decentralized sequencer protocol perform their duties honestly and efficiently by giving the protocol a means to attribute deviations in acceptable behavior or performance to specific actors with sequencing rights at any time and penalize them for doing so (e.g. not providing the performance guarantees that are set as the standard for the rollup, behaving maliciously and censoring users).

While this approach to sequencing significantly improves trust assumptions compared to the first two sequencing models, it introduces more latency to the sequencing process given the increased work required in operating a BFT protocol. If a rollup decides to use a BFT protocol for both leader election and batch validation, latency increases even more. This increased latency results in the rollup providing much slower preconfirmations to users compared to the trusted sequencer models.

Based Sequencing Model

Before we dive deeper into what exactly based sequencing entails, it’s worth reminding ourselves of what is actually happening when a rollup sequencer publishes batches to Ethereum. When a sequencer is publishing a rollup batch to Ethereum, they are explicitly creating an L1 transaction carrying the batch to Ethereum.

This means that they need to incentivize an Ethereum block producer to include this transaction so that the L2 blocks encoded within the published batch can be given soft finality status. We illustrate below how a rollup sequencer, regardless of whatever choice was made for its sequencing model, has to broadcast an L1 transaction to Ethereum and incentivize them to include the batch-carrying transaction in an L1 block:

Having this understanding of what sits between the sequencer of a rollup and Ethereum, a natural thought was formed - why not have the L1 validator set have a more active role in sequencing rollup transactions? The L1 validator set is already targeting maximal decentralization and despite sentiment surrounding builder centralization and the centralization of stake, the diversity of actors explicitly registered as validators cannot be so easily written off as well as the mechanism design surrounding the core protocol to constrain the agency of centralized actors. With the L1 providing strong security properties such as liveness, censorship resistance, and accountability, it would be ideal if we could have sequencing inherit some of these security guarantees provided by these properties with a more tightly-coupled sequencing scheme driven by L1 block producers.

So the question is now how do rollups tap into L1 capabilities to assist in its sequencing and improve not just the trust assumptions surrounding sequencing but also the desirable experiences that sequencing can provide through the issuance of preconfirmations to users. This essentially leads us to base sequencing and the variety of solutions that target to provide such features to rollups.

Based sequencing is a relatively new approach to sequencer design in rollups**.** At the most fundamental level, it involves utilizing the validator set of L1 proposers in Ethereum to provide sequencing services for a rollup.

It is important here to understand that sequencing is primarily characterized as ordering transactions and publishing them to the L1 that provides DA to the rollup. Execution is not strictly required to sequence transactions, it merely enables a sequencing actor to provide preconfirmations to users if made to do so.

Considering the above description of what sequencing actually describes, we consider a rollup to be based-sequenced (a “based rollup”) if the task of collecting rollup transactions, batching them and publishing the batch to L1 is handled by an L1 block producer. We illustrate the most simple example of a base-sequenced rollup in the diagram below:

The most simple base-sequenced rollup has L1 block producers perform sequencing services on behalf of the rollup, but it appears from the basic definition that based-sequencing doesn’t provide preconfirmations. At this point this may be confusing to readers because aren’t sequencers meant to provide preconfirmations to users?

The answer is yes, but technically a base-sequenced rollup does provide preconfirmations – In this case, the preconfirmation and soft finality happen at the same point in time. Consider the diagram we provided that illustrated the different stages of rollup finality:

Let's observe what these stages of finality look like across time for a rollup that implemented the simple based-sequencing model described above:

The diagram above helps illustrate that preconfirmations technically are provided to users (by virtue of providing feedback before hard finality), but simply via published batches becoming public knowledge such that rollup nodes can inform users of soft execution guarantees. The issue is that when the time between soft finality and preconfirmations is zero, we lose all the valuable benefits that rollup sequencing provides compared to L1 blockchains – it just looks like L1 block times with cheaper transaction fees. Therefore we can assert that the usefulness of preconfirmations diminish as the time between them and soft finality occurrence becomes smaller.

The question now remains whether rollups that opt to implement based-sequencing (in favor of strong security properties) are forever resigned to forego the potential benefits preconfirmations ahead of soft finality time can provide? The short answer to this question is no, but it requires a more complex approach to designing the protocol driving the rollup’s based sequencing. In a similar manner to how the sovereign BFT sequencing model uses accountability gadgets to help enforce protocol-enforced penalization to ensure decentralized actors perform sequencing and issue preconfirmations both honestly and with expected levels of performance, the same strategies could be used to enable faster preconfirmation issuance from L1 block producers performing based-sequencing.

To get a better understanding of how these faster preconfirmations can be achieved with a based-sequencing model, let’s first familiarize ourselves with the concept of credible commitment mechanisms. A credible commitment mechanism describes a system designed to ensure that a party making a promise or commitment will follow through on that commitment in the future. It ensures this by making the commitment both verifiable and enforceable, through economic incentives, penalties and/or cryptographic guarantees.

Because L1 block producers are untrusted actors, a credible commitment mechanism helps align the interests of rollup transactors and these block producers performing sequencing on behalf of the rollup, by providing increased incentives (in the form of additional revenue) for the block producers while also holding them accountable if they reenage on the commitments they had previously made. In this case, the binding commitments and the potential punishments that will ensue from poor or malicious service delivery are quite similar to what the sovereign, BFT model of sequencing offers. The main difference here is that the credible commitment mechanism is exercised between rollup users and L1 block producers instead of being exclusive between actors within the rollup network.

The world of based sequencing designs is incredibly broad and actively being researched with many exciting new ideas like introducing new key actors like preconfers and includers, that utilize the L1 validator set to facilitate consistent sequencing patterns much more reliably. While it would be nice to explore these topics, they are largely out of scope for an article of this size, therefore it would worth clarifying that while the design space for based sequencing is growing, the goal remains providing the best security properties for the rollup that involve sequencing as well as providing users with fast preconfirmations that elevate the experience of using an L2.

Bridges between Ethereum and Rollups

Bridges between Ethereum and rollups are important for two key reasons:

1. Onboarding users onto rollups: As described earlier, Ethereum rollups mostly charge transaction fees in ETH, therefore in order for users to get started with using rollup, they need to somehow get ETH onto the rollup. The only way this is possible is via having a bridge mechanism between Ethereum and a rollup. In the exceptional case that a rollup that does technically meet the criteria to classify as a practical scaling solution for Ethereum does not use ETH as gas on the rollup, a bridging connection must still exist to enable value transfer provide the minimum required composability needed to be complementary to Ethereum.
2. Composability between Ethereum and rollups: In order for Ethereum and rollups to be composable with one another, they require a means to communicate with each other. Fundamentally bridges are the medium through which such communication is coordinated. They help users transfer assets between two different blockchains as well as doing arbitrary messaging where actions can be triggered from one blockchain to execute certain actions on the other blockchain.

Understanding Bridge Security

At a fundamental level bridging is simply messaging done between different blockchains to help enable atomic cross-chain actions. In this context, atomicity means ensuring that Action X on Chain A is performed if and only if Action Y on Chain B is performed, and vice versa if initiated in such fashion.

• Let Chain A = Source
• Let Chain B = Destination

A user seeking to perform an action involving Source and Destination, could take the form of them seeking to send assets from one blockchain to another. This would require an atomic operation to be executed by both the Source and Destination (note that atomicity here does not imply simultaneous execution in the literal temporal sense, it is strictly governed by a logical constraint. That being said simultaneous, atomic execution can and would elevate composability and hence the level of benefits in favor of Ethereum scaling).

In order for this outcome to be achieved, the Destination needs to be sure that the action performed on the Source actually happened. There are multiple ways to manage this ranging from fully trusting someone attesting to the correctness of what happened on Source, to having a trusted party provide some light-weight, verifiable way to fact check their claims, all the way to having the Source run a full node of Destination to fact check every possible piece of information surrounding that chain.

Bridges enable features such as asset transfers and smart contract calls across different blockchains. The design space is extensive and we observe quite a few systems that are built around leveraging the utility of bridging.

While these benefits are great, bridging still comes with many challenges such as risks associated with bugs and other vulnerabilities related to bridge implementations. We have seen billions of dollars lost to such vulnerabilities and the number only continues to grow. This highlights the importance of minimized security assumptions when it comes to implementing bridges.

One factor surrounds the validation of activity happening on another side of the bridge which we described above, another factor describes the sovereignty status of the bridge itself. Bridges are often upgradeable and controllable by trusted parties, this is either done as a prior step in service of cautiously decentralizing the operation of bridges or a design decision made around the implementation of the bridge itself.

With context about how trust assumptions of bridges are influenced by how actors discern validity and how sovereignty plays a role in their augmentation, we get a more complete picture of what shapes the trust assumptions of bridges.

Bridging Requirements for Rollups: Trust-Minimized Bridging

A rollup must support trust-minimized bridging between itself and the underlying L1 it inherits security from. Trust-minimization here refers to the ability for either blockchain on the other side of a bridge to be able to verify the validity of transactions made of the other chain without trustlessly running a full node of the other blockchain to do so. Validity here implies that the transactions are being performed on the correct version of rollup state as well as the correctness of the transaction execution.

In the context of rollups this would mean providing:

1. Trust-Minimized Bridging from L1 to Rollup: Verifying L1 correctness on the rollup.
2. Trust-Minimized Bridging from Rollup to L1: Verifying rollup correctness on the L1.

Given that the rollup already inherits the security guarantees of the underlying L1, bridging from L1 to the rollup is already trust-minimized in nature by default (this is due to the fact that rollup nodes already are required to run Ethereum full nodes to trustlessly follow the rollup blockchain). Unfortunately, this is not the case with bridging from the rollup to L1.

For example, Ethereum cannot verify the correctness of the rollup’s execution nor be sure that the data published to it truly reflects the current state of the rollup blockchain. This means that Ethereum would have to trust actors attesting to the integrity of the rollup chain, where Ethereum would not have the means to verify such claims.

Without two-way, trust-minimized bridging between a rollup and its underlying L1, the true security level of the rollup ultimately gets reduced to that of its trusted, weakest point. This motivates the reason for why we have a strict requirement for bridges between a rollup and another blockchain being trust-minimized. Any other application-level implementations of bridges between a rollup and another blockchain are considered non-canonical to the implementation of the rollup and hence represent risks that a user chooses to accept in opting to use them.

This highlights that security guarantees of the rollup implementation of a bridge are bound to what are specified by the protocol specification. By default, there is a bare-minimum provided in the form of a one-way, trust-minimized bridging option from the L1 providing DA for the rollup to the rollup itself. For rollups that choose to enshrine a two-way validating bridge between two domains (classic rollups – more on these later), the protocol-enforced guarantees for bridging are augmented. We illustrate this with the diagram below:

Trust-Minimized, Validating Bridges

Lets quickly define what exactly trust-minimization means in the context of blockchains. Consider how light clients interact with a blockchain. They seek to query and verify data from the blockchain without having to manually execute every transaction to trustlessly assert correctness. To do so, light clients query information along with cryptographic proofs that can deterministically assert correctness.

This demonstrates the principle of trust-minimized verification, where a light client doesn’t trustlessly evaluate blockchain data to determine information but also doesn’t fully trust the information that full nodes provide them with – instead they are somewhere in the middle where they can fact check the information provided by full nodes via cryptographic proofs (in Ethereum and Bitcoin, this is managed via Merkle proofs which provide anyone a cheap means to verify the correctness of information described within the blockchain’s data structure).

As described in the previous section, bridging from L1 to the rollup is essentially “trustless” (trustless used as the term here to differentiate between extremely strong trust-minimization compared to other forms of trust-minimized verification) because rollup nodes already run Ethereum full nodes to sync with the rollup blockchain. But when it comes to bridging from the rollup to the L1, Ethereum doesn’t have the means verify the state of the rollup chain – essentially meaning there are strong trust assumptions by default if bridging this direction.

Fortunately, there is a strategy to make the rollup-to-L1 bridging more trust-minimized, and it relies on the same principles followed by light clients to do trust-minimized verification. Similar to how a light client can verify cryptographic proofs to assert correctness of its blockchain, similar functionality in the form of a validity enforcement mechanism can be introduced on the L1, to allow the L1 to verify the rollup blockchain in a trust-minimized fashion.

The implementation of such functionality to support rollup to L1 trust-minimized bridging comes in the form of a validating bridge on the L1. The end-result, is the potential to have bidirectional, trust-minimized bridging between a rollup and the L1 it inherits security from. With such a feature introduced, trust-minimized deposits and withdrawals to and from the rollup are possible.

A validating bridge aims to make bridging from the rollup to the L1 trust-minimized by providing a trust-minimized means of verifying the correctness of the rollup blockchain and execution done on it to L1. This simply means that a bridge between the rollup and its underlying L1 (like Ethereum) is designed in such a way that Ethereum has a more auditable means of verifying the correctness of the rollup chain and transactions made on it rather than just relying upon trusted attestations of validity.

• Trust-minimized L1 to L2 bridging: Messages from L1 to L2. The main applied use case for this bridging is to deposit assets from Ethereum onto a rollup. The rollup doesn’t need to be convinced of the correctness of Ethereum execution as it leverages Ethereum’s security already.

• Trust-minimized L2 to L1 bridging: Messages from L2 to L1. The main applied use case for this bridging is to withdraw assets back onto Ethereum. L2 to L1 bridging can be done in trust-minimized manner through the validating bridge which leverages a validity enforcement mechanism to provide Ethereum with a means to verify the integrity of correctness of the rollup prior to performing actions on the L1.

  
  

Let’s get a brief understanding of what two-way, trust-minimized bridging between a rollup and its underlying L1 achieves by walking through the lifecycle of deposits and withdrawals involving a rollup and the L1.

Let’s walk through what happens when a user seeks to deposit ETH into the rollup:

1. A user deposits 5 ETH into the validating bridge contract on Ethereum.
2. The rollup receives a message that gets relayed when this happens on Ethereum signaling that a deposit event happened.
3. The rollup mints 5 ETH and sends to the user's account on the rollup.
4. Since the rollup’s data gets published to Ethereum, the transaction that did this minting and transfer to the user can be verified by Ethereum without requiring trust.

So far, we haven't really seen the validating bridge do anything, but as described in the previous section, bridging from Ethereum to the rollup was already trust-minimized by design given that rollups inherit the underlying DA and consensus guarantees provided by Ethereum. Lets now look at what withdrawal from the rollup to Ethereum looks like and the role that the validating bridge plays in managing this in trust-minimized fashion:

1. A user requests to withdraw 5 ETH from the rollup onto Ethereum by making a request to the bridge contract to the rollup.
2. The withdrawal request is relayed to the validating bridge on Ethereum.
3. Through the use of the validity enforcement mechanism on L1, the rollup proves to Ethereum that the user had sufficient funds to request the withdrawal as well as the integrity of the chain state upon which the withdrawal request was made.
4. If the validity enforcement mechanism is satisfied, Ethereum acknowledges the withdrawal requests and releases 5 ETH from the validating bridge contract to the user on L1.

The validity enforcement mechanism exists to provide Ethereum with a way to verify the correctness of the rollup blockchain such that any messages made from the rollup to initiate actions on the L1 (such as withdrawals from the rollup onto Ethereum) without needing to either i) require Ethereum to execute rollup transactions to verify integrity/correctness ii) trust actors asserting to integrity/correctness of the rollup chain.

A simple way to understand the relevance of a validity enforcement mechanism is to compare an equivalent construction that exists within Ethereum itself and then frame the role of validity enforcement mechanism within classic rollups:

• How Ethereum proves correctness of its execution: When a new block is published to Ethereum, every node executes the block themselves to check that the block producer correctly described the execution results correctly. Thereafter, the canonical chain is converged upon by multiple through a consensus process. This essentially describes the validity enforcement mechanism native to Ethereum’s design.

• How Ethereum proves correctness of classic rollup execution: The only reason that Ethereum would need to verify the correctness of a rollup blockchain’s state is to help enforce more secure bridging. Rollups enshrine a validity enforcement mechanism into Ethereum (more specifically within Ethereum smart contracts that support the validating bridge) that allow Ethereum to verify the correctness of rollup state updates without executing them directly.

• This is somewhat similar to the idea of “light clients” who verify correctness of execution or pieces of state by requesting merkle proofs from full nodes, allowing them to verify things in trust-minimized manner instead of going completely “trustless” by independently running a full node to self-verify every single action.

  
  

Validity Enforcement Mechanisms (ZK Proofs, Fault Proofs)

Validity enforcement mechanisms, in isolation, have one specific role: Provide the L1 with a trust-minimized method of verifying rollup execution. As mentioned earlier, rollups typically transition from state to state (from the perspective of the L1) via batch updates. Therefore we can imagine a discrete “verification of rollup execution” event looking something like this:

In order for the L1-side of a bridge to do any actions, we need to ensure the correctness of transactions made from L2 (meaning their validity and that they were created on a valid version of the rollup blockchain). To achieve this, rollups will implement a validity enforcement system as part of their design which includes on-chain components that allow Ethereum to verify execution; it is this on-chain component that  we refer to as the validity enforcement mechanism of the rollup.

There are two leading approaches to providing an L1 with a validity enforcement mechanism, both taking radically different approaches to proving correctness of rollup execution.

1. ZK Proofs: This method involves the off-chain generation of succinct, cryptographic proofs (zero-knowledge proofs to be exact) that can be verified on-chain by Ethereum to assert correctness of rollup batch execution.
2. Fault Proofs (i.e. omission of faults): Instead of proving validity of execution, this method relies upon assuming everything is correct while providing a lengthy time period (more formally known as a challenge window) for any actor to provide evidence to the L1 of invalid state changes to rectify the “fault”. If evidence is produced, what ensues is a “search-and-resolve” game between a challenger and the actor who published contentious data (typically the Sequencer), which is arbitrated by the L1. If the challenge window passes without any faults being alerted for, Ethereum verifies all the batches within this period.

Beyond the implementation details of each of these methods rollup validity enforcement to inform the L1, a key difference between these two approaches is regarding when the L1 verifies the discrete batch execution events of a rollup.

• In a rollup using ZK proofs (more commonly known as a ZK rollup): Once the ZK proofs corresponding to a batch have been generated off-chain delivered to the L1, the L1 can verify correctness instantly.
• In a rollup using fault proofs (more commonly known as an Optimistic rollup): When the challenge window passes and no fault proof challenges were presented to the L1, the L1 can verify the correctness of batches once the challenge window period of time has elapsed.

This demonstrates that with optimistic rollups, batches have to wait for this challenge window to pass (on average this is around 7 days) while in ZK rollups, batches can be verified as soon as ZK proofs asserting to their correctness are published to L1. When batches have been verified correct by Ethereum with either of these means, this knowledge can be used to authorize actions originating from the rollup to do things on Ethereum (e.g. withdrawing assets from the rollup back onto Ethereum).

Rollups seeking to implement a trust-minimized validating bridge between their blockchain and their underlying L1 will make a decision regarding which approach to take in providing their validating bridge with the functionality to make them trust-minimized, but in the end both approaches require trust in the robustness and integrity of each validity enforcement mechanism. So while these supporting validity mechanisms improve the trust assumptions around bridging, the weaker trust assumptions surrounding reliability and agency in interacting with these systems should still be considered.

Emergency Mechanisms

Sequencers are the entry point through which users have their rollup transactions serviced but what happens if a sequencer is offline or is deliberately ignoring user transactions? If a rollup does not provide fallback measures that address these scenarios, the security and reliability of the rollup are essentially undermined. Susceptibility to both of the above scenarios demonstrates weaknesses in liveness and censorship resistance.

Consider the broad definitions for liveness and censorship resistance once again:

• Liveness: We want to ensure that rollups will continue to function as expected over time.
• Censorship Resistance: We want to ensure that the transactions of users will always be included within some well-defined period of time (it would be worth clarifying that the context of some transactions require much shorter periods compared to others).

Assuming sequencer failure, we wish to provide fallback/emergency mechanisms through which users can navigate around failed critical paths and interact with a rollup and help drive its operation in these extreme cases. A popular solution to providing users with the means to bypass sequencer failure or censorship, is via having a rollup enshrine a forced transaction inclusion mechanism on the L1 (providing DA for the rollup).

From here the logic within a rollup’s derivation procedure can periodically look for transactions submitted in this manner and sync them on the rollup blockchain. Providing such a means to bypass the sequencer not only accommodates sequencer downtime but also the censorship vector if a sequencer is deliberately preventing the inclusion of a specific user’s transaction.

Classic Rollups & Sovereign Rollups

A lot has been covered up until now, so it would be best to reiterate some opinionated definitions:

A rollup is strictly defined as a blockchain that is completely derivable from another underlying blockchain (an L1) which provides availability of the rollup’s input data as well as ordering over it which allows any actor running a rollup node to trustlessly and deterministically compute the rollup’s state at any point in time.

A rollup that scales Ethereum (opinionated classification)  is defined by the following characteristics:

• Rollups are completely derivable from data made available on Ethereum.
• Rollups are EVM-equivalent.
• Bridging between the rollup and Ethereum is trust-minimized
• Has a sequencing model
• Can have a validating bridge (with a validity enforcement mechanism)

Up to this point, we expressed the various design decisions that a rollup designer can make such as the manner in which they implement their sequencing model, methods through which to implement a validating bridge between the underlying L1 and the rollup etc. But now we reach a critical point where a design decision will determine the fundamental type of rollup we are dealing with.

While many people believe the choice of sequencing strategy or choice of validity enforcement mechanism used should primarily characterize a rollup, it is my belief that the primary means of classifying a rollup should come down to a single question – Does it enshrine a validating bridge between it and the underlying L1 it derives its security from?

The enshrinement of the validating bridge is the key identifier here. In answering “Yes” or “No” to the above question, we get two types of rollups in existence:

1. Classic Rollups: Rollups that have an enshrined, validating bridge between it and the underlying L1 it derives security from.
2. Sovereign Rollups: Does not have an enshrined, validating bridge between it and the underlying L1 it derives security from. This DOES NOT mean a validating bridge between the L1 and the rollup cannot exist, it simply is a design preference for it not to be defined as a canonical element in the specification of the rollup.

Classic Rollups

Classic rollups are rollups that have an enshrined, validating bridge with Ethereum. This enables two-way, trust-minimized bridging between Ethereum and the rollup. Therefore the enshrined, validating bridge is a defining architectural component that characterizes these types of rollups. As evident by the naming, an enshrined, validating bridge is characterized by two key details:

1. Enshrined: The bridge between a rollup and Ethereum is baked into the design of a rollup blockchain. What this means is that, there is a canonical bridge implementation between the rollup and Ethereum.
2. Validating: The bridge gives Ethereum the trust-minimized means of verifying the state of the rollup and execution applied to it off-chain. This simply means that with the design of the bridge is such that Ethereum has a more auditable means of verifying the current state and correctness of actions made on a rollup rather than just relying upon trusted attestations.

The technical differences between classic rollups and sovereign rollups have already been stated, it comes down to the decision of whether to enshrine a validating bridge between the rollup and the underlying L1 providing DA and consensus or not – it’s as simple as that.

What this means is that the rollup blockchain is defined with a default, canonical bridge between it and its underlying L1 (Ethereum here).

The result of this is that the definition of a classic rollup extends beyond simply being derivable from data available from an L1, and now includes that along with the requirement to have a validating bridge between the rollup and this L1. This design decision intrinsically establishes a much closer relationship between the rollup and the underlying L1. To get a better understanding of what is meant here, remember that a rollup, at its foundation, is defined by the graphic below:

With the enshrinement that comes with classic rollups, we now extend the relationship between the rollup and its underlying L1 beyond simply being a transactional relationship for DA and consensus. The relationship now includes building a validating bridge between the DA layer and the rollup. The relationship between the rollup and the L1 is now characterized by both of these at the rollup protocol level:

The consequence of this design decision is that more fluid interoperability between Ethereum and the rollup is achieved as the bridge between the L1 and the rollup is enshrined as a first-class citizen within the system (think of this being somewhat analogous to special smart contracts on Ethereum that help facilitate validator staking on the Beacon chain).

The goals of classic rollups can therefore be more easily understood. Classic rollups aim to scale the Ethereum by scaling the native experience of using the L1 via rollup blockchains. Classic rollups aim to achieve this goal via targeting two objectives:

1. Offloading execution strain from Ethereum: By doing EVM-equivalent execution off-chain, classic rollups can provide users with similar experiences that could be provided on Ethereum but with cheaper fees and faster transaction settlement.
2. Composability between classic rollups and Ethereum: In inheriting the security properties of Ethereum (by relying on its DA and consensus) as well as being EVM-equivalent blockchains that are connected to Ethereum via trust-minimized bridging, classic rollups not only offload execution from Ethereum but also introduce stronger interoperability capabilities not just with Ethereum but also other classic rollups, ensuring that Ethereum’s ecosystem and liquidity does not become fragmented. Such cross-chain composability means that classic rollups can enhance Ethereum by adding capacity without isolating themselves from the rest of the ecosystem.

When people generally talk about rollups in Ethereum, classic rollups are generally what people have in mind – An L2 blockchain that inherits some of the security properties provided by Ethereum and easy to move to and from relative to Ethereum. While the intuition behind classic rollups is somewhat simple to grasp (given reasonable context), it often ends up becoming the poster child for rollups entirely.

Classic rollups are incredibly powerful and useful solutions in their own right, but they do not represent the design space for rollups entirely, even when it comes to aligning on the scaling goals of Ethereum. It's important to remember that the derivability of the rollup blockchain from its L1 remains the defining aspect that earns a blockchain its rollup classification. What this aims to convey is that a rollup can scale Ethereum in far more ways than simply being an L2 blockchain with close interoperability to it. This is where the design space around sovereign rollups comes into play.

Sovereign Rollups

Sovereign rollups can be described as rollups that choose not to enshrine a validating bridge with the underlying L1 they use for DA and ordering. Given this design decision, this makes it easy to distinguish them from classic rollups.

The starting blueprint for an Ethereum sovereign rollup is illustrated in the diagram below:

Sovereign rollups can be a bit of a confusing concept in comparison to classic rollups. But one of the most useful things they teach us is how a rollup can depend upon one blockchain to provide DA and ordering guarantees and use a light client of this L1 DA layer to enable trust-minimized bridging between the rollup and entirely different, independent blockchain. While this is not necessarily relevant nor complementary to Ethereum scaling, it is extremely useful for demonstrating the design space for sovereign rollups.

As it is with classic rollups, sovereign rollups share the same trust-minimized capabilities for bridging from Ethereum (the underlying L1) to the rollup with the distinction of not “natively” being able to provide trust-minimized bridging from the rollup to Ethereum. With this in mind, and given the constraint of only deeming trust-minimized bridging acceptable for rollups, is there any benefit to having rollups that provide one-way trust-minimized bridging from Ethereum to rollups when it comes to goals around scaling Ethereum?

The answer is yes. As expressed in earlier sections, rollups that offload execution burdens while retaining executional compatibility with Ethereum (while inheriting the security guarantees of Ethereum) provide tangible scalability impacts extending what can be done with Ethereum. In this case, bridging back to Ethereum wouldn’t be possible (outside of doing so via trusted means), which hurts composability but does establish boundaries that could promote more application-specific use of a rollup (e.g. If bridging back from a rollup is not possible, it would be in the best interest of a user to make sure they entered the rollup domain for a purpose).

Such limitations on agency are potentially instrumental in deterring Sybil/inorganic activity on the rollup. This in itself is quite a powerful concept, because it provides the benefit of offering users cheaper and more performant execution but also presenting them with a decision to commit some allocated capital into this system or not. If they would prefer something more composable, they could simply look at participating within a classic rollup on Ethereum.

On making a case for the practicality surrounding one-way trust-minimized bridging between a rollup and its underlying L1, we can also begin to see how bridging can be implemented within sovereign rollups in a variety of ways. A good example would be to demonstrate how a sovereign rollup could implement a validating bridge between it and the L1 it relies upon for DA and ordering. This would simply require rollup actors to deploy smart contracts to the L1 which implement validating bridge functionality where a mechanism for trust-minimized verification is made available to Ethereum:

This highlights how sovereign rollups can be molded to arrive at the same ends as classic rollups (all just without an enshrinement sticker of approval). The key differentiator between sovereign rollups and classic rollups is around how each rollup type chooses to approach their bridging options.

When it comes to Classic Rollups, it is easy to describe the bridging dynamics and motives behind them succinctly. Classic rollups are designed with a distinct purpose, bidirectional interoperability with the L1 it derives much of its security from. From this decision, you can confirm with reasonable certainty that the rollup has long-term goals of maintaining strong coupling with Ethereum by its commitment to enshrine a validating bridge.

This is, however, tangential to its alignment goals associated with Ethereum which sovereign rollups aiming to scale Ethereum also share. The decision made for enshrinement simply favors use-cases such as composability with the L1, meaning expectations that the future will involve more frequent cross-domain interactions whether it be in the form of asset transfers or more generic cross-chain messaging. It's important to note here that composability may enhance efforts towards Ethereum scalability, but it doesn’t necessarily mean it's a strict requirement to provide it.

Misconceptions surrounding sovereignty benefits in rollups

One of the more prominent arguments for sovereign rollups pertains to increased sovereignty that a rollup ecosystem supposedly has in comparison to its underlying L1 when implemented as a sovereign rollup. Sovereignty here describes the ability for a rollup ecosystem to dictate the rules of its blockchain outside of the influence of its underlying L1 or another other blockchain it may establish bridging relationships with. This helps explain why sovereign rollups do not commit to enshrining a validating bridge with its underlying L1.

The problem with this current distinction made between sovereign and classic rollups, is that they both possess these abilities. The only real difference is that a classic rollup has a lot more friction to impose the will of the rollup ecosystem to augment the mechanics of a validating bridge between the rollup and Ethereum.

Beyond this, both classic and sovereign rollups remain defined by the logic set in their nodes – and not whatever bridges exist between them and other domains including the underlying L1 it derives its security from. Whatever rollup data is made available on the underlying L1 is processed in whatever way rollup nodes define their logic.

While the above demonstrates the convergence of technical sovereignty shared by both classic and sovereign rollups, economic forces equally apply pressure to both rollup types. While we can technically say bridges have no part in defining a rollup, the collateral from which value is derived on the rollup can dictate the social consensus of what the rollup should be (similar to how people signal what fork of a blockchain they believe to be canonical).

Actual sovereignty benefits that can be realized – practical ossification

In the above section, a picture was painted that expressed that sovereign and classic rollups are more similar than you think – and to emphasize more explicitly, this is quite aligned with reality. While this sentiment may have dampened some conviction in the value of sovereign rollups over classic rollups, an argument will now be made to appeal for the adoption of a sovereign rollup approach.

Because classic rollups signal their commitment to enshrining a validating bridge between the rollup and Ethereum, they take a cautious approach to the implementation of bridging functionality. What this means is that while they have made a long-term (and ideally permanent) commitment to using the enshrined bridge, they adopt a steady/paced approach to ossifying the validating bridge. This is done for risk management purposes, but introduces sovereignty trust assumptions (remember that bridge trust assumptions can be assessed via the manner through which validity is asserted as well as the how the functionality of the bridge can be altered via privileged actors).

The mutability/upgradeability of bridges is definitely a concern but it is not done out of desire to exercise control over users, but rather to ensure that any possible bugs can immediately be addressed to protect users from potentially catastrophic outcomes. It would be useful to remind readers that rollups are less than a decade old and while there has been much research, shipping and reporting on them, we still have a long way to go when it comes to safely realizing their potential.

This is where the decisions to be a sovereign rollup (i.e. not to enshrine and commit to an opinionated direction for the rollup) show distinctive benefits. In not committing to enshrine a bridge, a sovereign rollup can adopt an approach of implementing more immutable bridges and if the need arises to upgrade, simply express the need to change to a newer implementation where thereafter users can signal whether they agree with the upgrade details.

This could technically be done with classic rollups and the upgradeable enshrined bridge. But it requires a more concentrated effort of social consensus to bring the same result and likely the coercive pressure of complying with the opinionated upgrade path of the enshrined bridge will be harder to overcome. It's also useful to bear in mind that the increased sovereignty over the rollup domain, remains complementary to the scaling efforts of Ethereum (if we are assuming the rollup is EVM-equivalent), and simply provides increased user agency over decisions made about bridging implementations.

A Framework for Navigating the Ethereum Rollup Space

While the primary way to classify whether a rollup is of the classic or sovereign type is quite clear, design choices made around a rollup’s characteristics/features can also further categorize the kind of rollup we are dealing with. There are many ways that one could employ to further map out the rollup design space, therefore this article seeks to describe one possible approach which takes the following into consideration:

1. Sequencing: As explored earlier, there are a spectrum of sequencing models available for a rollup to choose to adopt but the main difference will ultimately come down to whether a rollup is going to independently manage its sequencing or involve the underlying L1 DA layer to assist with this. A rollup can therefore be considered either based or non-based, depending on the decision made here.
2. Trust-Minimized Rollup Verification Support and Methods: As described earlier rollups can provide light-client-like functionality  to enable features such as trust-minimized bridging from the rollup to another blockchain. If this option is provided as part of the rollup’s design, it enhances the secure bridging opportunities available to rollup users. If supported, the method through which trust-minimized verification capabilities can be provided help distinguish the kind of rollups we are dealing with.

• If the rollup uses ZK proofs to help provide trust-minimized verification, the rollup can be considered ZK.

• If the rollup uses fault proofs to help provide trust-minimized verification, the rollup can be considered Optimistic.

  
  

With the above-described factors, we can construct a matrix to represent the rollup design space more formally:

The table above demonstrates an effort to help navigate and better classify whatever approach is taken when implementing a rollup system. You will notice that the decisions made around sequencing and trust-minimized verification capabilities are independent of whether a rollup is of the classic or sovereign nature.

Though it would be useful to note that in the case for example where a rollup system offers no trust-minimized verification method, this makes enshrinement of a validating bridge impossible which effectively rules out a classic rollup from existing in this specific column. The rollups in those columns are simply vanilla or based sovereign rollups without light client support that can be leveraged by other blockchains (meaning only one mono-directional trust-minimized bridge exists between a rollup and its DA layer).

With such a system, we can more systematically reason about different rollups and cultivate standardization for rollups that can be reduced down to being described by a single cell in this matrix. Essentially every possible type of rollup (within our self-described Ethereum, scaling framework) can be mapped to a single cell within this 3D matrix.

For example, let’s take a look at how the top three rollups on Ethereum could be classified within this matrix (going by market capitalization valuations described on L2Beat). All three of these rollups (Optimism, Arbitrum One, Base) can be identified as Classic Optimistic Rollups which currently employ non-based sequencing. Therefore we can see which cell in the matrix they fall under:

There are two key benefits to this designed framework:

1. More systemized classification of Ethereum rollups: Essentially, establishing a more detailed classification system allows the Ethereum ecosystem to better organize our understanding of the rollup landscape. Organizations like L2Beat are already leading the way in this regard, but they cannot do it alone, nor should they be expected to. In the spirit of open collaboration, the Ethereum community should be motivated to consolidate, extend and scrutinize everything that is being done across the rollup landscape (including the proposal of assessment frameworks to reason about systems in a credibly neutral way). This classification system aims to contribute to that and augment whatever the global community consensus around rollup assessment becomes.
2. Guiding the design of more context-aware security models for specific rollup implementations: With this classification system, we can potentially assess security of different rollup implementations by establishing more context-aware security models instead of potentially making unfair comparisons, which lead to incorrect assumptions that are only relatively correct depending on what reference plane is being used.

With the benefits of the classification framework described above, there is an opportunity to more intuitively and systematically map out the Ethereum rollup landscape. In building upon much of the efforts of various teams and researchers, it can provide a good foundation for organizing and aligning expectations of actors seeking to realize the vision of Ethereum’s rollup-centric roadmap. It could even be extended to include useful information such as rollup stages that were conceptualized by Vitalik Buterin and more formally fleshed out by L2Beat.

Up to this point, the framework has aimed to capture as much details and semantics as possible without being too opinionated about the more nuanced details which may be subjectively contentious. This is done in order to present the idea of a classification framework in as neutral a way as possible. The main goal is to sufficiently advocate for the adoption of a framework with sufficient foundations to be extended upon. With this in mind, let’s move on and explore some of the security concerns around Ethereum rollups with the goal of providing Ethereum with enough context to potentially extend this or any other framework it may inspire.

Mapping Out Security Considerations Around Rollups

In understanding the usefulness of a rollup classification framework, we can start to think about what kind of information can augment the value of it in being a productive tool for the Ethereum rollup ecosystem. Security remains a crucial tenant of rollups, aiming to position them as the most secure L2 blockchains that can be built to enhance the utility of on-chain systems.

While it may be obvious to infer which security refers to, it would be worth giving a brief overview of what security actually aims to achieve. Security in rollups refers to the ability of a rollup to provide its users and various independent operators with strong guarantees around its functionality and services. The rollup should technically function in a well-defined way and the experience of using it should be fair and indiscriminate for all users.

With this in mind, let’s go over some of the most pressing security concerns currently facing rollups in an attempt to map out what the Ethereum ecosystem should be aware of and seek to improve when it comes to rollups.

Technical Risks

Technical risks refer to potential risks surrounding the technology involved that enables the rollup to function and provide utility to its users and independent operators performing crucial system tasks with expectation of revenue. These risks can surface in a variety of ways:

• Protocol Risks: These types of risks describe bugs in the actual protocol specification, meaning that while a rollup node running protocol software may technically be running without faults, the actual protocol specification may have a vulnerability that leads to unexpected or catastrophic failure.

• Client Risks: These types of risks are associated with the broad functionality of rollup nodes that run software that aims to faithfully implement a rollup protocol. The risks here come in the form of code implementation where bugs can lead to unexpected or catastrophic behavior (e.g. an undetected race condition which makes rollup nodes deviate from the protocol and enter an unrecoverable failure state).

• Trust-Minimized Verification (Prover) System Risks: These types of risks refer to bugs or other form of vulnerabilities/defects in the system that enables external parties to perform trust-minimized verification of the rollup blockchain (e.g. via verifying ZK proofs or having a dispute resolution protocol that leverages fault proofs in an optimistic rollup design). The risks here can lead to unexpected or catastrophic failure in trust-minimized bridging functionality.

• Smart Contract Risks: These types of risks refer to bugs that could exist in smart contracts that help drive the functionality of the rollup. These smart contracts could exist on both the rollup or the underlying L1 it inherits its security properties from. Such bugs could result in loss of funds, unexpected behavior that erodes the user experiences (e.g. incorrect L1 attributes leading to incorrect fee logic on the rollup) and more. Because smart contracts are largely used on Ethereum as a form of light client to enable much of the rollup-native functionality, bugs in smart contracts could be a potential existential risk for a rollup system including for L1 users who had expectations around the integrity of the entire system.

  
  

There are definitely more risks that could be discussed in this technical risk section, but largely these describe the many types that we are more aware of and do not excessively overlap with the next risk area – centralization risks.

Centralization Risks

Centralization risks are characterized as being risks that are imposed by the concentration of authority a single actor (or a group of actors) has over providing core functionality or configurability for the rollup. These risks can surface in a variety of ways:

• Liveness Risks: Given that specialized operators (such as rollup nodes doing a variety of critical tasks) play an important role in maintaining the continued operation of the rollup, there are risks that exist in the form of liveness failure where the rollup may not be able to continue operating if there is no fallback mechanism in the case that the rollup enters an unexpected failure state. This could render a user’s assets on the rollup frozen with no option for recovery unless privileged actors are able to transition back to “good state” and function as expected.
  • If sequencing is a trusted role and the designated Sequencer goes offline with no fallback option for users to get their transaction executed on the rollup, users are potentially stuck with no options to access their assets or even withdraw their assets from the rollup.
• Trust-Minimized Verification (Prover) System Risks: If the system designed around providing trust-minimized means for the underlying L1 to verify the rollup is inherently centralized, the system is essentially trusted by default irrespective of whether it is trust-minimized by specification. While for cryptographic proofs this may come across as an impossibility, it's worth highlighting that no amount of cryptography can eliminate the centralization risk imposed here if the technical risk of the trust-minimized system is not adequately addressed (e.g. a cryptographic proof may be binding and tamper-resistant, but could be verifying the truth of some other statement instead of the one the verifying party expected it to be asserting correctness of).
• Censorship Risks: These types of risks are similar to those of liveness risks in the sense that it involves dependency on trusted operators. A trusted operator could maliciously censor a user or another security agent, in a non-attributable way and if there is no mechanism to prevent or constrain this behavior, users are exposed to potential harm and unfairness.
  • This can take the form of transaction censorship which prevents users from getting their transactions executed on the rollup. This could also include preventing a user from withdrawing funds from the rollup onto the L1 or another blockchain that has a trust-minimized bridge from the rollup to it.
• Value Extraction Risks: These types of risks are similar to censorship risks in the sense that they involve dependency on trusted operators who could maliciously grief users. In this scenario, an unconstrained sequencer or security actor could use the contextual information of a user’s transaction to profit from their activity or even harm the welfare expectations a user had around their transaction. If no mechanism exists to deter the opportunistic strategies of trusted agents to act upon this information, users are exposed to potential hard and unfairness.
• Upgradeability Risks: Rollups that heavily depend on smart contracts to ensure the function loop of their systems often employ upgradeable contracts to hedge against technology risks associated with smart contracts. While intentions may be noble (or not), leaving the upgradeability of critical smart contracts to trusted actors is coercive and forces users to comply, often without any time period for a user to decide whether to exit the rollup system due to disagreement with how the system is being altered.
  • Although some smart contracts do allow for upgrade windows to provide users with ample time to exit the rollup system in the case that they don’t want to participate in the system anymore, not all parts of upgradeable smart contracts have these windows and are often instantaneous changes (if trusted parties deem the upgrade to be highly urgent). In addition to this, upgrade windows are often not enough to guarantee users with the opportunity to exit the system due to censorship risks that can either completely censor or delay a user’s transaction to the point that they miss the upgrade window entirely.

Illuminating the Security Problem Space and Presenting Solution Paths

As described above there are various security risks in the form of both technology and centralization risks, which often overlap in complex ways resulting in them adding up and becoming larger and more glaring problems in what should be a highly secure blockchain on paper.

The goal of this section is not to provide complete solutions to many of the potential risks described in the previous section, but to highlight some potential avenues through which we can minimize and possibly entirely eliminate some of these existing problems.

Let's start by grouping and highlighting risk areas to get a better sense of what problems are seeking to be solved and what potential solutions contribute towards navigating these select problem spaces:

1. Engineering: The best way to describe this is by expressing that it's simply the technical implementation details which transform specifications into tangible, physical components (theoretical to practical transformation). With engineering, we are not primarily concerned with the system design decision-making but only translating specifications into executable mediums. Engineering concerns ensuring the correctness of the technical implementation of the protocol, client software, proof systems, and smart contracts. The scope of concerns revolve around ensuring bugs and race conditions do not threaten the integrity of the rollup system.
2. Upgradeability: This concerns the upgradeability of the rollup, which covers all parts of the system, but also more tangibly the smart contract upgrade controls which significantly influence the behavior of the rollup compared to more software development-oriented housekeeping.
3. System Resilience: This concerns ensuring the resilience of the rollup system. By resilience we mean the ability to withstand and recover from unexpected faults which can be due to both conventional distributed system bugs as well as Byzantine behavior (malicious behavior like censorship, trying to intentionally disrupt or trick the protocol into doing forbidden actions). A resilient system should be robust to both honest implementation faults and malicious attacks, providing dynamic resistance and recovery processes against both kinds of failure without requiring trusted intervention.

Engineering

As expressed above, engineering is concerned with technical implementation details. This spans from the protocol specification all the way to the application layer via smart contracts.

• Protocol Specification: The protocol specification basically describes a formal document that mathematically describes how the rollup protocol works. This covers what clients (rollup nodes) need to implement to follow the protocol along with describing how the L1 is used to provide DA and consensus as well as what basic functionality needs to be implemented involving the L1. Covering the engineering risks with the protocol specification involves formally verifying that the details of the specification match the functional requirements specified.
• Client: This involves the implementation of node client software which plays a crucial role in ensuring the operation of the rollup. This includes ensuring the client implementation correctly translates the protocol specification into software.
• Prover System: The validity enforcement system of the rollup (also referred to as the prover system) is correctly implemented such that whatever blockchain (be it the underlying L1 or another monolithic L1) can implement functionality to ensure trust-minimized bridging from the rollup to the L1.
• Smart Contracts: Smart contracts are likely to play a significant role for a rollup system, whether it be around ensuring trust-minimized bridging through smart contracts implemented on both L2 and L1, or contracts that relay crucial information from the underlying L1 to the rollup to assist with syncing of the rollup blockchain. It is essential that these smart contracts are adequately audited and measures to recover from unexpected conditions are in place.

When it comes to protocol specifications and client considerations, there isn’t a great deal of options available but at the same time, the degrees of cost with these two areas are considerably lower compared to prover systems and smart contracts. With this in mind, the strategy to optimally minimize engineering risks around protocol specification and client implementation will involve scaling the established methods of rigorously testing both of these, be it via formal verification to prove the mathematical correctness of protocol specifications or conventional software testing practices when it comes to client implementation.

When it comes to optimally minimizing the risks of a rollup’s prover system and smart contract implementations, we enter more complex territory – It would be more adequate to describe this as uncharted territory. Unlike protocol specifications and client implementations, these are more novel concepts and therefore come with a lot more uncertainty of what to even watch out for when it comes to mitigating technical risk.

When it comes to implementing systems that are both novel and complex in nature, a better understanding of the design spaces is needed. Unfortunately, such an effort is not something that can simply be brute-forced overnight, even with the best intellectual capital at one's disposal. In understanding what it takes to transition novel technology from a disruptive, novel stage to a stage of maturity where a wider understanding of the problem profile is cultivated, it is known that the efforts to transition require significant investment in resources (be it temporal, monetary and intellectual in nature).

The problem is that while this holds true, it does not negate the fact that until we get to such a stage, that significant risks exist in the form of trusting experimental technologies. The natural solution is to implement “guard rails” such that if and when problems surface, they can be quickly resolved. Unfortunately, such an approach introduces strong trust assumptions where authority over changing these systems is placed in the hands of a small, non-independent authority. This is obviously not ideal in the blockchain setting, because these systems are designed to be both open and trustless in nature (these are the asymptotic goals driving all efforts within the industry).

Philosophically, the above approach contradicts the whole motive behind building blockchain-based systems and while this is very obvious, it unfortunately reflects the current reality of how we are navigating the implementation of prover systems and smart contracts within rollup systems. The irony is not lost on the Ethereum ecosystem and rollup designers, it unfortunately is a product of not having any better solutions around how to navigate the risks.

• On one end, rollup designers deciding to give up control immediately would be taking on a strong assumption that the technology works and will always work forever which is not a pragmatic stance to hold.
• On the other side, rollup designers understand the technology risks that come with experimental systems and proactively decide to exercise greater control over these systems until we can trust them as strongly as we trust the laws of nature or the security guarantees dictated by information theory. The risk here is that the complacency to transition these systems to be more trustless becomes the norm.

This effectively highlights the conundrum that rollup designers face, where there are pressures to relinquish control over experimental technology but also expectations that the experimental technology works as expected – either way, there are trust assumptions in one form or another being placed on the designers of these systems. With this context, the question remains of how we can improve upon the trust assumptions that are currently forced to be taken on without introducing elevated technology risk?

Defense in Depth (DiD)

Defense in Depth is characterized as being a strategy that secures a system via a multi-layered approach to security. When it comes to securing experimental systems, more explicitly the prover mechanisms that help facilitate trust-minimized bridging through validating bridges, a DiD-centric approach offers a good alternative to securing these systems while cautiously managing trust risks.

So what does a DiD improvement look like in rollups?

Before we go ahead and answer this question, let's look back at what is probably going to be the most common practical example of a rollup’s proof system being used – implementing a validating bridge between a rollup and an L1:

In previous sections, we built up an intuition around prover systems by referring to them as “validity enforcement mechanisms”, and as described back then, these systems are responsible for providing a way for anyone to verify the current state of a given rollup without needing to run a rollup full node.

This essentially describes the experimental technology that we are trying to minimize trust around while ensuring that technology risk is sufficiently accounted and planned for. These systems involve a combination of on-chain and off-chain logic that collectively provide the trust-minimized functionality described above.

This is why smart contracts and the prover system are grouped together when discussing these risks as smart contracts are often the vehicle through which this “light client” behavior is made accessible to an L1. In the future this vehicle may come in different forms such as being built into the P2P networking layer of the L1 in a similar way to how it would provide services to its own native L1 light clients – but for now, we will consider that systems outside of the rollup interface with a rollup’s prover system via smart contract interfaces as illustrated in the system diagram further above.

With this in mind, there are two potential strategies that employ DiD to improve the trust assumptions of a rollups prover system. Both these strategies aim to identify and halt functionality that relies upon the rollup prover system:

Multi-Provers

This approach entails having a rollup system implement two or more distinct proof systems to assert an equivalent rollup output. If the proof systems generate inconsistent results, this can alert that a critical bug with one of the proof systems has been detected. For example there could be a ZK rollup which employs a ZK prover mechanism as its primary means for providing trust-minimized verification functionality, but then there could also be a proof system that relies upon SGX attestations to verify correctness.

If the outputs of the two proof systems diverge, this will signal that one of the proof systems has a bug. With knowledge of this, the rollup could coordinate to halt functionality that relies upon the prover mechanism and schedule an upgrade to rectify this issue. Alternatively, there could be logic described within the rollup protocol to identify which prover system has an issue and allow the system to independently divert to using the back up proof system while social coordination to schedule an upgrade of the bugged prover instance (where thereafter the system will revert back to the primary means of proving).

Multi-Verifiers

When we talk about verifiers, we are generally talking about smart contracts which, for the majority of rollups in existence today, describes how a validating bridge is able to perform trust-minimized verification. In the same way where equivalent outputs are compared between two different implementations, so too can this be applied to the implementation of a validating bridge.

For example, you could have two different smart contracts (e.g. one implemented in Solidity and the other in Vyper) which are independent of one another but share the same storage. The primary smart contract that implements the validating bridge on the L1 could do an additional check to assert equivalence before committing changes during execution, where if inequality is detected follows a similar recovery path to that of the multi-provers.

The concept of DiD introduced via solutions like multi-provers and multi-verifiers therefore offer a newer option that adds more layers of security while paving an avenue for relaxing trust assumptions. But while this solution does provide an improvement, it introduces technical redundancy which does translate to increased costs. Therefore whether we choose to standardize using this approach will come down to assessing how practical and useful it actually is in both moving the needle when it comes to security improvements warranting the increased costs.

Upgradeability

When it comes to upgradeability, we generally are referring to critical smart contracts required for continued operation of a rollup system. As described above, this can come down to bridge contracts on both L1 and L2 as well as the verifier contract on L1 that drives the functionality of the validating bridge.

With upgradeability, we aim to reduce the amount of trust and hence coerciveness associated with updating core smart contracts that drive rollup functionality. If a rollup is going to upgrade a smart contract, there should be a window in which users have the opportunity to decide whether they want to opt out of the rollup system and be able to do so  if they don’t agree with the details of whatever upgrade is being implemented.

To provide this guarantee to users we need to ensure two things:

1. Eliminate Emergency Upgrades: Upgradeability can only be applied within a large enough time period such that users can process a rollup exit request.
2. Censorship Resistance: Ensure that a user wishing to exit a rollup system due to an upgrade event cannot be grieved by censorship preventing them to do so.

In the previous section we introduced the idea of multi-provers and multi-verifiers and how they can help minimize trust assumptions while still providing protection against technology risks. It is through the improvements to trust-minimization via the multi-layered security approaches they introduce that the requirements for emergency upgrades can be relaxed.

When it comes to ensuring censorship resistance, we seek to ensure that no malicious actors can prevent a user from exiting during the upgrade window leading up to the actual shipping of an upgrade. The solution to this, which is largely currently used in practice today, is providing users with the means to force transaction inclusion via the L1 DA layer (which in this case involves rollup transactions requesting to withdraw assets from the rollup) where the rollup protocol provides a means to bypass trusted actors like the sequencer to ensure their withdrawal requests can be serviced well before the upgrade event.

System Resilience

Resilience in computer systems refers to the capabilities of a system to autonomously employ strategies to improve a system’s availability and ability to adapt to unexpected challenges. When we talk about resilience of a rollup we refer to two things:

1. Operational Resilience: This refers to a rollup system being able to adapt and recover from failures that emerge on the critical path of rollup operation such as sequencer and/or proposer failures.
2. Adversarial Resistance: The ability of a rollup system to be resistant to malicious attacks imposed by independent actors participating within the network, be it users of security operators.

It's important to express that operational resilience and adversarial resistance aren’t mutually exclusive areas, in fact quite a few of the desired characteristics of operational resilience depend on guarantees provided with adversarial resistance. Adversarial resistance is simply concerned with addressing some highly specific issues which will be discussed in a moment.

Operational Resilience

Liveness represents a crucial requirement for achieving operational resilience, therefore a rollup system needs to ensure that it employs the necessary functionality to detect and address potential liveness issues autonomously without requiring trusted intervention. Let’s assess where liveness issues may potentially emerge in rollup systems.

• Sequencing:  A sequencer is responsible for streaming user transactions, creating batches and publishing them to the L1 DA layer where rollup nodes will sync these changes and update the rollup chain. If the sequencer is unavailable and no fallback mechanism is in place, a user will not be able to have their rollup transactions executed.
• Proposing: Proposing refers to the task of publishing rollup state roots to the L1. This is generally done by sequencer alongside publishing batches but is envisioned to be decoupled in the future. State roots are used alongside the prover mechanism to allow the L1 to perform its trust-minimized verification through its validating bridge to authorize rollup withdrawals. If only a privileged actor is allowed to publish state roots and they are offline, this technically would prevent the validating bridge from processing withdrawal requests representing a liveness failure from the perspective of a user solely focused on withdrawing assets from the rollup.

To help provide improved operational resilience for sequencing, a rollup system should provide users with an emergency mechanism to bypass the sequencer and self-sequence transactions. This is fundamentally the principle behind L1-forced transaction inclusion mechanisms. With this mechanism, a user can publish their rollup transaction through an L1 contract, where they will be queued and eventually executed on the rollup as part of the sync process.

Transactions executed through an L1-forced inclusion mechanism will typically get included within 12 hours to 24 hours depending on how a rollup chooses to implement this optional, back-up mechanism. They therefore provide the guarantee of “eventual transaction inclusion” in worst-case scenarios such as temporary or prolonged sequencer failure.

State root proposing can either be permissionless or permissioned and we currently see both methods being used in practice. In the permissioned case, liveness guarantees can be improved by adding a proposer fallback mechanism for proposing state roots in the case that a permissioned set of proposers has been inactive for an extended period of time.

Adversarial Resistance

Adversarial resistance is concerned with providing defense against malicious attacks. Malicious attacks describe any efforts that attempt to exploit rollup functionality or censor user transactions:

• Exploiting Rollup Functionality: This describes any malicious attempts made to force invalid state changes about the rollup to get accepted. While the rollup blockchain itself is robust against these attacks (due to L1 security and rollup chain derivation logic), validating bridges that connect other blockchains to the rollup are not.
• Transaction Censorship: Transaction censorship describes the ability of a malicious actor to prevent a user’s transaction from achieving its goal.

Exploiting Rollup Functionality

As expressed above, a rollup’s functionality can be exploited at the validating bridge level. How it works is that a malicious actor could trick the bridge into releasing funds from the L1 smart contract (in the case of a classic rollup on Ethereum for example) by tricking it into believing in an invalid rollup state transition. This would result in bridged assets on the rollup becoming under-collateralized. This poses a significant systemic risk to the rollup because the under-collateralization of bridged assets propagates a contagion effect that breaks multiple applications that depend upon the security of the validating bridge to function properly.

For this reason, it is essential that the rollup prover mechanism securing the validating bridge works properly and cannot be prevented from doing its duty. Therefore an adequate approach to mitigate this risk vector would be to ensure the technical robustness of the rollup prover system along with its ability to withstand malicious attempts to prevent it from allowing the validating bridge to perform its duties securely.

Transaction Censorship

The second key defense we seek to provide against malicious attacks pertains to providing transaction censorship-resistance. Transaction censorship describes the ability for a malicious sequencer to prevent a user’s transaction from achieving its goal. When it comes to a user transactions, we can intuitively think of them as being characterized by two things:

1. The user’s intent: This describes the goal that a user seeks to achieve with their transaction request.

2. The physical transaction payload: This describes the transaction object that will actually get included and executed on the rollup.

   
   

We consider transaction censorship to be successful if a malicious sequencer causes a user’s transaction payload to fail in satisfying the user’s intent. This failure to satisfy a user’s intent can happen in two different ways:

1. Transaction payload exclusion: If the user’s transaction never reaches the rollup blockchain, the user’s intent cannot possibly be fulfilled.

2. Transaction payload execution does not satisfy user’s intent: A user’s transaction payload gets included and executed on the blockchain successfully but the effects of its execution does not satisfy the user’s intent  (e.g. consider a user is margin trading and is about to have their position liquidated therefore they want to urgently add more collateral to prevent this from happening. The sequencer would intentionally prevent/delay this from happening to grieve the user for whatever reason they have. Therefore by delaying the transaction, the user’s account gets liquidated and even if the transaction gets executed, their intent was not fulfilled and they are left worse off).

   
   

The information expressed above helps express how transaction censorship is more than simply preventing the inclusion of transactions on the rollup; it more broadly concerns the prevention of satisfying the intents surrounding a user’s transaction requests. This essentially highlights how bypass measures such as L1-forced inclusion mechanisms, alone, are not enough to provide adequate censorship resistance guarantees to users.

It is therefore a goal in rollup systems to provide defenses that combat these censorship vectors that users may potentially be exposed to when a malicious sequencer arises. One of the primary approaches to minimize the probability of this occurring is by decentralizing the sequencer and providing some accountability gadgets to enhance the guarantees of more timely transaction inclusion. Via decentralizing the sequencer role, we can potentially ensure both the liveness and neutrality of the sequencer role by ensuring the role is only temporarily held by individual actors before being rotated.

Accountability gadgets can be used to provide some forensics to attribute liveness (downtime) and malicious faults (censorship) to specific sequencer actors such that they can be punished for undermining the security properties of the rollup. Such gadgets that complement a decentralized sequencing model of a rollup could involve a form of inclusion list functionality that can help identify potentially censored transactions or even involve approaches that attempt to use more network-wide discovery of transactions (such as consolidating multiple transaction list views of multiple nodes in the decentralized set of sequencer actors).

Lastly when it comes to this line of solutions, more complex preconfirmation systems can be introduced to the sequencer setup where binding commitments (via some form of credible commitment mechanism – e.g. staked or restaked system) to fulfill transaction intents of users can be established and opted into resulting in more efficient transaction servicing as well as increased censorship resistance (especially in the case of time-sensitive transactions).

An alternative to the above (which may borrow some of the accountability and BFT consensus elements) is to reduce the surfacing of transaction information through encrypted mempools to make selective censorship more difficult. However, we are still quite early in our exploration of approaches of this nature, though it may be a worthwhile option for rollups to consider exploring to combat censorship concerns.

In the end these are just potential avenues rather than fleshed out solutions, therefore we leave it up to others who may build upon the information provided here to pave a path forward.

Final Thoughts and Conclusion

To wrap things up, let’s reiterate what exactly was covered within this article and what was aimed to be achieved with its creation:

• Technical Foundations of Rollup Systems: Providing a technical understanding of rollups, from the ground up, and identifying key design elements and processes that drive their operation.
• Technical and Social Alignment of Rollups and Ethereum: Describing how rollups can be designed to more objectively complement and align with Ethereum and its scaling objectives.
• Rollup Security Risks and Potential Solutions: Describing the various security risks that rollup systems still currently face and providing several avenues of explorations through which solutions were provided.
• Ethereum Rollup Assessment Framework: Introducing a framework to help reason about the Ethereum rollup landscape from a well-established point of reference.

The rollup landscape is truly quite expansive, therefore providing users and developers with the means to more productively navigate and reason about different solutions remains more important than ever, similar to manner in which people need to assess the differences between different L1s in helping inform them of where to invest their time, efforts, financial resources, as well as providing them with a strong understanding of the risks they are taking on. It is my hope that with this article, the foundations established can play a greater role in helping Ethereum’s rollup ecosystem reach increased maturity all across the board.

---

Author's note: A version of this article was previously published here.