Rollups As You Knew It

Table of Contents

1. Introduction

1-1. The Rollup Debate

1-2. So What?

2. Blockchain, Modular

2-1. Blockchain 101

2-2. Modular Architecture

3. Rollups As You Knew It

3-1. Rollup 101

3-2. Rollup’s Proof System

3-3. Trust-Minimized Bridge

4. Validating Bridges are not Rollups

4-1. Why Rollups Should Not Be Bridges

4-2. Then Who is ZK Rollup?

5. Declaration of Independence of Rollups

5-1. Blockchain Forks and Social Consensus (Governance)

5-2. Smart Contract Rollup and Sovereign Rollup

5-3. All Rollups are Sovereign Rollups

6. Conclusion

 

 

1. Introduction

1-1. The Rollup Debate

Not long ago, a fiery debate blazed across the online space among blockchain infrastructure researchers. It all started with a presentation called How rollups “actually” work by Kelvin Fichter of the Optimism Foundation. Fichter delved into the widespread misconceptions and misunderstandings surrounding rollups. He contended that our present understanding of how rollups operate and their potential is based on a model that was established roughly 4-5 years ago. He also pointed out that this outdated model has lost much of its precision since the advent of the modular blockchain narrative.

The spark set off a flurry of responses among infrastructure researchers for the subsequent weeks, prompting a series of articles and threads. Jon Charbonneau, a named researcher and investor at DBA, jumped into the fray after Fichter, adding fuel to the flames. He published a series of lengthy articles, challenging the mental models of rollups quite radically. On the other side, Dankrad Feist of the Ethereum Foundation (Proto-Dank sharding is named after him) responded with a series of tweets that blended counterarguments and satire. For weeks, the debate over the mental model of rollups has dominated conversations in blockchain infrastructure for weeks, stirring up an exceptional discourse between opinion leaders in the Ethereum and Layer 2 space.

In this article, we'll delve in the essence of the rollup debate and their interpretation of rollups within the context of a modular blockchain are. The rollup debate can be summarized as a clash between two different mental models: Do rollups exist solely to provide scalability for Ethereum, or do they represent a new type of modular blockchain. To deem a rollup as the same thing as its validating bridge is to regard them as a passive tool for transaction compression and scalability of Ethereum. The existing mental model of "bridge = rollup" significantly limits the potential of what a rollup blockchain can achieve. While rollups were originally designed to achieve scalability of Ethereum, the true potential of a rollup lies in the fact that it signifies a generalized implementation of modular blockchains. And yet, if rollups are to unlock their full potential, they first need to break out of the misperception of “rollup = bridge.” Before you read on, note that this article consists of 80% of facts and 20% of opinions. My caveat is that there is always room for different interpretation on the same architecture and mechanisms.

Here's an overview of the chapters. The next chapter introduces the basic concepts of modular blockchain related to the contents covered in this article. Readers familiar with the concept of modular blockchain can move on to the third chapter. The third chapter deals with the elements that make up roll-up and the operating principles. What makes a rollup a rollup is a proof system and a trust-minimized bridge to verify that the transition is executed correctly. Chapter 4 explains why roll-ups should not be identified with bridges. Currently, the most prevalent distinction bases itself on the proof system, Optimistic vs. ZK rollup, but falls short of a precise definition of rollup in the world of modular blockchains. It is even more so considering that an optimistic rollup may eventually upgrade to a ZK rollup in the future. The final chapter addresses the sovereignty and social consensus of rollup. A rollup is also a blockchain, and a blockchain can only be forked by social consensus among participants. In establishing independence from bridges, rollups need the authority to determine its own state as a blockchain, that is, to implement a hard fork. However, altering the bridge of a rollup will inevitably entail the cost of applying additional security assumptions or losing bridged assets.

1-2. So What?

The discussion surrounding the rollup debate in this article aims to correct the current mental model of rollups. Without a deep understanding of modular blockchains and rollups, this article wouldn’t be an easy read without a better grasp of the jargons and definitions. Before we get into the nitty gritty, I'd like to mention why we need to address the topic "what is a rollup.”

In my view, the reason the rollup debate has become such an important topic for many blockchain researchers and engineers is to answer the question "what are the real problems.” The current blockchain infrastructure is not yet capable of accommodating millions of users. While blockchains have just come out of its infancy through a brief but tumultuous period, an extensive array of challenges persists that must be addressed to realize the future we envision for blockchain. We prioritize problems based on our blueprint for the future and invest time and energy to solving them. For some, it might be building a good service or getting government regulations right and for others, it might be building a better blockchain infrastructure. Of all the challenges in the blockchain space, rollups stand out as one of the most dinamically evolving areas, fraught with various technical and philosophical complexities. For them, setting the right direction and identifying the priority of problems are never trivial.

Source: Modular Rollup Theory Through the Lens of the OP Stack, Kelvin Fichter

Kelvin Fichter, who started the rollup controversy and will often be mentioned in this article, introduced the OP Stack, a software architecture for modular blockchains, at last year’s Devcon in Bogotá. It should be noted that Optimism had previously developed its own execution environment, the Optimism Virtual Machine (OVM) 1.0, and a fraud proof mechanism that were halted without ever seeing the light of day. Fichter admitted that he and his team initially didn’t fully grasp the significance and potential of rollups; their focus was solely on building the essentials for rollups. As their work progressed, they began to develop an in-depth understanding of the system and eventually pivoted towards separating the execution environment from the proof system and creating an architecture for a modular blockchain—OP Stack. As deployments have just begun, it may be too early to judge the success of Optimism's pivot and OP Stack. Nonetheless, it still underscores that comprehending the implications of a new system that hasn't existed before and charting the right course can be more powerful than the ability to solve the imminent problems.

Even if you're not necessarily a builder of a rollup chain, the unfolding of the rollup debate will (inevitably) give you a deeper understanding of the theme of modular blockchains. Personally, I believe that modular blockchains are a necessary path for this industry to scale in the future. Regardless of occupation or interest, you’ll come across the topic of modular blockchains or rollups more often over time. The rollup debate will be an valuable case study to understand the principles and concepts of modular blockchains.

This article assumes that the reader already has a basic understanding of how blockchains and Layer2 work as well as the concept of modular blockchains. The second chapter of this article explains some of the fundamental concepts that will be frequently mentioned in this article. Since it may be a lot to take in in one sitting, if you're looking to dive a little deeper into the topic covered in this article, I highly recommend exploring the curated resources below.

• Celestia - The modular stack
• Toghrul Maharramov - Rollups Through the Prism of the Bridges
• Jon Charbonneau - Rollups Are L1s (& L2s) a.k.a. How Rollups Actually Actually Actually Work
• Patrick McCorry - Deconstructing Rollups
• Kelvin Fichter - Rollups aren’t Real
• Kelvin Fichter - Rollup, Rigor, and Reality
• Celestia - Rollups as Sovereign Chains

2. Blockchain, Modular

2-1. Blockchain 101

Source: Rollups Are L1s (& L2s) a.k.a. How Rollups Actually Actually Actually Work, Jon Charbonneau

Before we dive in, I'd like to go over some of the key concepts and features of blockchain that would come up most often. If you're familiar with the mechanisms and the basic concepts of blockchain, you can skip ahead to the next chapter.

Essentially, a blockchain is a state machine that allows any participant in the network to read and write data. In computer science or mathematics, a state machine is a system where a machine can have only one state at a given point in time. To represent a state machine, we need a genesis state, state transition functions, and input values.

The elements that make up a blockchain state machine are as follows:

• State: A state indicates the value of assets, code and memory at all the addresses on the blockchain at any given time. Depending on the type of node, it may store all of the state data (full node) or just a summary of all the transactions in a block, called the Merkle Root (light node).
• Transaction: A transaction is an input value that changes the state of the blockchain. Examples include sending assets to another account or invoking a smart contract.
• State Transition Function: It is a predetermined rule for obtaining the next state for the given blockchain state and transactions. For example, EVM is the state transition function of Ethereum.

Therefore, the functions required to create a state machine like a blockchain can be divided into: 1) a database to execute the operations of the state transition function, and 2) security to ensure that all participants share the same state. Since the initial state of the blockchain and the state transition functions are values or operations determined by the client software, it is possible to calculate the state of the blockchain at any point in time by repeatedly executing them, as long as there are a list of transactions and the correct ordering. In this regard, as the name suggests, storing a collection of transactions in the form of blocks is a necessary and sufficient condition for determining the state of a blockchain.

A user of a blockchain (usually a light node) who wishes to verify if a transaction was executed correctly should be able to access and download the actual transaction data. In blockchain, data availability refers to the ability to provide transaction data, which ensures that any participant in the network can reproduce the current state of the blockchain.

A blockchain's consensus mechanism aims to determine the order of transactions that enter a state machine on a distributed system, and to make it difficult for a malicious actor to alter it. Since state machines generally do not have a commutative law, resultant states may vary depending on the order of data entry. When it comes to consensus, how and by whom consensus is reached is determined by the blockchain network. While Bitcoin employs Proof of Work (PoW) between Bitcoin nodes, Ethereum uses Proof of Stake (PoS) between Ethereum nodes to reach consensus. The effort (or economic contribution) of the nodes in each chain provides security to the network.

 

2-2. Modular Architecture

Source: Modular blockchains for beginners, Celestia

While a monolithic blockchain can handle the core functions of a blockchain, it is also possible to assign each function to separate blockchains. A system in which individual functions of a blockchain are allocated to each chain or protocol is called a modular blockchain. The fundamental functions of a blockchain can be categorized into three elements: execution, consensus, and data availability. The layers that constitute a modular blockchain represents each of these functions.

- Execution: The execution layer provides the environment and operations to obtain the next state of the blockchain. It receives transaction data from users and calculates the next state of the blockchain.

- Consensus: The consensus layer provides security to the network. It allows network participants to agree on the order in which transactions are recorded in blocks and makes it difficult to change the sequence of recorded data.

- Data Availability: The DA layer provides downloadable transaction data, enabling participants to verify and reproduce the state of the blockchain.

Tweet by @ptrwtts

 

The value offered by modular blockchains is not different from what vertical integration in traditional industries can offer. By separating roles of different nature, each blockchain can be optimized for the function it is intended to perform. With such focus on distinct functions, modular blockchains are opening up the possibility of designing new types of systems that have been considered difficult to apply in a conventional monolithic blockchain architecture. Notably, rollups, the type of modular blockchain to be addressed in this article, specialize in execution, delegating consensus and data availability to a Layer 1 chain. Conversely, there are chains such as Celestia that exclude the execution function and only perform data availability and consensus functions. Further, it presents the possibility of entirely new structural designs incorporating one or more of these layers.

Those familiar with the concept of modular blockchains might have noticed that a description of settlement is missing here. Generally speaking, settlement refers to the finalization of a transaction. However, it's one of the most ill-defined elements of a modular blockchain, and hence the main topic of the recent rollup debate. Details regarding the basic concept and recent discourse will be discussed in the following chapters.

3. Rollups As You Knew It

3-1. Rollup 101

One of the objectives of consensus mechanism is to make it difficult to change the order of transactions in a block. This implies that a blockchain that hasn't achieved a sufficiently large network of validators is more susceptible to attacks. As such, building a blockchain's consensus network has been singularly important in determining the stability of a network and poses a significant barrier to entry for new blockchains. In the context of modular blockchain, however, a consensus network is no longer a requirement for every chain. This is because not every blockchain has to build a consensus network. Instead, they have the option to submit transactions to a blockchain that has already proven its reliability such as Bitcoin and Ethereum. As Kelvin Fitcher puts it, consensus and data availability will no longer be a requirement for all blockchains, but will be replaced by a product or service (Consensus as a Service) that are available for a fee.

Source: An Introduction to Optimism’s Optimistic Rollup, Kyle Charbonnet

Rollup blockchains specialize in execution: it receives transactions from users and compute the next state of the database. Rollups inherit data availability and consensus by recording their blocks in a Layer 1 chain. For rollups, leveraging Layer 1 blockchains as an availability layer not only means that transaction data are recorded in the Layer 1 chain, but that nodes in the rollup blockchain refer to the data recorded in the Layer 1 chain to obtain their state. Rollups treat the block information stored in the data availability layer not just as an external repository of history, but as the only source of truth.

Typically, the nodes in a rollup consist of Sequencer nodes and Verifier nodes. The Verifier node is sometimes referred to as the Full Node of the rollup. Although not shown in the figure above, rollups, just like Layer 1 blockchains, also have a Light Client that only validates the header and part of the data in the block. A rollup's sequencer is responsible for ordering transactions submitted by users and writing them to the Layer 1 chain. Verifier nodes and light clients verify if transactions have been executed correctly by comparing the state values recorded in the Layer 1 chain with the state of the rollup internally computed.

 

3-2. Rollup’s Proof System

A blockchain is a state machine that is siloed and unable to communicate with external networks that have different state transition functions. What if it needs to send and receive transactions from one blockchain to another, such as a rollup or sidechain? This is where blockchain bridges come into play. A bridge holds a user's assets on one chain and sends a message to the other chain to issue new tokens in the same quantity. After receiving the tokens, the user performs a series of transactions on that chain and withdraws their assets back to the original chain through the bridge contract.

In the previous chapter, I wrote that a rollup inherits the consensus and data availability of its parent chain by submitting transaction data to a Layer 1 chain. However, strictly speaking, simply writing data to the parent chain does not necessarily mean inheriting the security of the Layer 1 chain. Sidechains, which are often cited as a comparison for rollups, can also record transactions on a Layer 1 chain and transfer assets over a two-way bridge. However, sidechains do not inherit the security of the Layer 1 chain. Users of Polygon PoS, for instance, assume trust in Polygon validators in addition to trust in Ethereum. Protocol security assumptions will be discussed in more detail in the following chapter.

 

Source: An introduction to sovereign rollups, Celestia

To qualify as a rollup, a blockchain requires an additional condition: the ability to prove the accuracy of transaction execution to the Layer 1 chain. Consider the situation of withdrawing funds from a rollup chain to Ethereum via a bridge. The user of the rollup chain would request the bridge contract on the Ethereum to bring back his funds, claiming that that he has burned corresponding assets on the rollup chain. However, from Ethereum's perspective, the transaction on the rollup chain is unverified off-chain data. A rollup user who wishes to withdraw their assets from Ethereum will have to provide a proof that the transaction actually happened and the state values were updated correctly.

Rollup's proof system serves as the mechanism for validating the correct execution of transactions within the rollup chains. Remember the explanation of the blockchain's state machine mechanism mentioned earlier. In instances of fraud proof, the rollup chain ensures transaction accuracy by reconstructing the state of the rollup blockchain (e.g., Arbitrum) within the recipient blockchain (e.g., Ethereum). This reconstruction involves starting from the blockchain's initial state and re-executing the state transition function for a set of transactions. As the transaction details are already stored in the Layer 1 bridge, Arbitrum's state transition function should be enabled within the Ethereum bridge contract. As you’re probably well aware, there are two types of proof systems for rollups: Fraud Proof and Validity Proof. Since these systems have been tossed around so often, I'll be brief on this part:

• Fraud Proof: By default, all transactions are assumed to be valid. If a validator node within the rollup identifies an invalid transaction, it can request verification. In order to detect and verify fraudulent transactions, there is a 7-day challenge period between block submission and confirmation.
• Validity Proof: A Prover submits a proof confirming the accurate execution of all transactions. Zero-knowledge proofs are commonly used to generate the proof. Transaction validation is completed when the Verifier confirms that the Prover has submitted the correct proof.

Note that proof systems are often regarded the same as or as a part of a bridge system. Or else, as the title of this chapter suggests, they are also referred to as validating bridges, meaning that the proof system is an embedded bridge.

 

3-3. Trust-Minimized Bridge

Next, let's dive a little deeper into blockchain bridges and security assumptions. We trust and use rollup chains not because we have faith in the entities operating the rollup, but because rollups’ operational foundation relies solely on trust in the Layer 1 chain. When designing a new blockchain, one most significant barrier is not a high TPS but a validator network large enough to earn trust. If the network is small or not sufficiently battle-tested, it will be more vulnerable to exploits, causing users to be doubtful of the blockchain and refrain from storing assets on it. Rollups, on the other hand, allow users to use them with no or minimal trust in the operating entity. This means that users can send assets or execute transactions with rollup blockchains (e.g., Optimism), maintaining only the level of trust necessary for interacting with the Layer 1 blockchain (e.g., Ethereum).

Source: Trust Models, Vitalik Buterin

A protocol's security assumptions are the preconditions for trust. Trust models can be categorized based on security assumptions of a blockchain protocol. According to Vitalik Buterin's framework for trust models, the following criteria should be considered to determine a protocol's security assumptions:

- How many validators does the blockchain have?

- How many of them need to behave as you expect?

- What are the incentives (economic or non-economic) for validators to behave as expected?

- What is the worst-case scenario that could results from potential errors in your security assumptions?

 

Now, focusing on the first and second criteria, let’s break down some key differences in security assumptions and explore possible scenarios. In general, a model is deemed more secure when it demands a larger population for the trust assumption and relies on a smaller number of honest participants. For instance, a protocol that expects 51 out of 100 people to be honest is less secure than one that expects only 1 out of 1000 people to be honest because it requires a smaller percentage of participants to function as expected. The graph above illustrates this. If we break down the security assumptions by the number of honest participants, we get the following categories:

• 1 of 1: A trust model where the protocol is managed by a single, centralized entity. The protocol can only operate properly if that single entity behaves honestly. Should a protocol qualify as a blockchain, it must adopt a better trust model than this.
• N/2 of N: A trust model that expects more than half of all participants to behave honestly. Most Layer 1 blockchains use the Honest Majority condition as a trust assumption. A user can trust and use a blockchain with the assumption that at least half of the validators (or miners) are honest.
• 1 of N: A trust model that expects at least one of all participants to act honestly. An example of this is off-chain data verification using fraud proofs. If even one person reports an invalid transaction, the transaction is invalidated.
• 0 of N: A trust model that doesn’t rely on anyone. Examples include validating blocks within a single blockchain or validating off-chain data using validity proofs.

Note that the risk of the code itself is not included in the security assumptions. If a DeFi protocol on Ethereum gets hacked due to a bug, it has nothing to do with the security of Ethereum. Of course, the risk of a protocol being attacked or not functioning as intended due to code bugs is not insignificant. The risk tends to increase as the complexity of such mechanisms, such as blockchain clients or zero-knowledge proofs, increases. However, codes that are made available to the public on a blockchain (or as open source) does not presuppose trust in any particular entity, and is something anyone willing and capable can verify on their own.

Source: Optimism Bridge

Blockchain bridges can also be categorized by their security assumptions. For example, if a user of Optimism wants to withdraw to Ethereum, they can choose either an official bridge or a third-party bridge. When using the official bridge, which uses a fraud proof system, users can withdraw their assets with no additional trust assumptions (1 of N) beyond those applied to Ethereum. However, the user has to wait for a 7-day challenge period for the fraud proof process to be completed. In contrast, if a user uses a third-party bridge, they can transfer assets to Ethereum in as little as 20 minutes. This means that the user follows the security assumptions used by the bridge (most often 1 of 1 or N/2 of N).

Source: Clusters: how trusted & trust-minimized bridges shape the multi-chain landscape, Celestia

The security assumptions applied to a bridge determine the security of not only the bridge, but also the chains connected to it. Sending and receiving data between different blockchains necessarily requires additional security assumptions while sending and receiving data on a single blockchain doesn’t. In other words, the security of a Layer 2 chain on Ethereum cannot exceed that of Ethereum. According to Celestia's model, blockchain bridges can be categorized into two models based on the security assumptions applied:

- Trust-minimized bridges: Also known as trustless bridges, these are bridges with 1 of N or 0 of N security assumptions. Typical examples include bridges between rollups and Layer 1 chains that use fraud proofs or validity proofs. Chains connected by trust-minimized bridges are defined as a cluster as they can validate each other's transactions without external intervention.
- Trusted bridges: These are bridges with a security assumption of N/2 of N or higher. Blockchains connected by trusted bridges (such as Ethereum and Solana) cannot directly validate each other's transactions. Inter-cluster communication is possible under the assumption of trust in the existence of a Trusted Third Party (TTP) outside the network.
The security assumptions applied to bridges serve as the basis for determining the scalability of Layer 1 blockchains. In blockchain terms, scalability is the ability for users to gain access to additional computing power within the same security assumptions. If a network requires additional security assumptions besides the existing trust model to achieve scalability, the network is not considered to have offered additional computational power to users. The key to increasing scalability is to boost the throughput of the network without compromising the trust model.

Bridges play an important role in helping blockchains achieve scalability by providing users with access to the computing power of other blockchains. Suppose there is a Layer 2 blockchain that utilizes the Bitcoin network as its Layer 1 chain. While recording transactions that occur on the Layer 2 blockchain onto Bitcoin ensures data availability and consensus (transaction order), execution cannot be verified since the Bitcoin network does not support smart contracts. Therefore, the blockchain can be considered as secure as Bitcoin (in terms of data availability and consensus), but not as a rollup on Bitcoin. In this case, the blockchain inherits the security of Bitcoin, but does not scale Bitcoin. Scaling Bitcoin requires that assets can be sent off-chain and transactions can be processed within the same security assumptions.

Ethereum users can use rollups connected by trust-minimized bridges and withdraw back to the Ethereum chain without any additional security assumptions. Rollups directly provide scalability in the sense that they play a passive role of processing operations off-chain and delivering the results that would otherwise be performed on Ethereum. On the other hand, if the same process were implemented on a sidechain, it would not be considered an extension to Ethereum.

Nonetheless, scalability cannot be strictly determined by security assumptions of a bridge; It's more a matter of perspective than a technical definition. Some believe that Ethereum’s scalability is enhanced solely by the absence of additional security assumptions beyond trust in Ethereum, such as in the case of rollups. Others might view solutions that may compromise trust assumptions to some extent but maintain robust security, like sidechains, increase the scalability of Ethereum.

4. Validating Bridges Are Not Rollups

4-1. Why Rollups Should Not Be Bridges

Source: How Rollups actually work, Kelvin Fichter

In the previous chapter, we discussed the role of the proof system in Layer 1 blockchains, which verifies the state by executing transactions submitted by the rollup chain. In this chapter, we will delve deeper into why Kelvin Fichter argues that proof systems differ from rollups and why they should not be confused with each other. Trust-minimizing bridges and proof systems explain the raison d'être of rollups in their own right. The primary objective of using rollups is to allow users to engage with Ethereum without introducing any additional trust assumptions, achieved by processing transactions off-chain within rollups. As a result, the concept took root that the transaction data and proof system of a rollup, recorded on a bridge, define the rollup itself. In essence, the bridge equals the rollup.

Today, the most common way for categorizing rollups is based on the proof method employed by the verification bridge. In this proof system-based classification, rollups are divided into two categories: Optimistic Rollups, which use fraud proofs, and ZK Rollups, which use validity proofs. However, this classification based on the proof system does not provide a strict definition of a rollup in the context of a modular blockchain narrative. Optimistic and ZK rollups both rely on Ethereum's consensus and data availability, and their primary functions involve validating user-submitted transactions and calculating the blockchain's state. The only distinguishing factor between these two rollups is how transactions are validated by the validation bridge. However, the proof system is not inherent to the rollup blockchain, but rather a smart contract that exists on a blockchain external to the rollup blockchain called Ethereum. In other words, the purpose of the proof system is to determine whether "Ethereum" should validate the execution of transactions on the "rollup" chain. Consequently, there is no inherent necessity to classify Optimistic rollups and ZK rollups do not need to be distinguished as distinct entities within the chain itself.

What if there are bugs or attacks in the Proof system's code, causing the bridge to malfunction? In the worst-case scenario, only the funds locked up in the rollup bridge of the "Ethereum" chain would be at risk of being stolen. This is because the proof system is not a required component for the rollup chain to work; instead, it serves as a system for Ethereum to measure the rollup blockchain. In a rollup blockchain, users' assets remain secure. While the failure of the proof bridge would indeed result in a substantial loss of value and affect the rollup’s reputation, it will not affect the rollup blockchain’s operational capabilities (the only consequence would be that rollup's assets will be undercollateralized because there are no longer any assets held on the bridge). The rollup blockchain can continue to function normally by receiving transactions from users and recording them on the Layer 1 chain, unaffected by the state of the proof system.

Assuming the rollup's clients are designed to serve general purposes sufficiently, the rollup doesn't need to be limited to a single bridge. Any rollup can transition to a different proof system or add a new proof system as needed. The fact that the current Optimistic rollup employs a fraudulent proof does not imply that it must forever remain an Optimistic rollup. Also, it is not entirely implausible for a ZK rollup to bridge to a fraud proof. If the trust model can be compromised to some extent, the validation of the execution of a transaction can be implemented by governance rather than by fraud proof or validity proof. By having a trusted entity or group (such as a DAO or multi-signature) verify the correctness of the transaction execution, you can create a roll-up blockchain that can operate without implementing a complex fraud proof system or using the ZK formula.

In the previous year, Vitalik Buterin proposed the Multi Prover System, a concept that integrates multiple prover systems into a single rollup with the aim of enhancing the code reliability of the prover system. In his model, a rollup validates off-chain data (Layer 2 transactions) through one or more proof systems that employ both fraud proofs and validation proofs. Vitalik's model can be integrated with a governance structure, such as requiring a majority of submitted proofs to undergo validation, as a measure to mitigate the code implementation risk associated with the proof system. While the topic and context of this article may differ, it is entirely reasonable to envision a modular blockchain with multiple proof systems simultaneously linked to a single rollup.

Source: Optimism Risk Analysis, L2Beat

On the other hand, other rollup projects view his argument as potentially undervaluing the role of proof systems. The PoS system is a fundamental module that should be given top priority by all rollup projects to inherit Ethereum's security. The core value proposition highlighted by rollup projects centers on their scalability solutions, which inherit the security of Ethereum. While users may be reluctant to store their assets on a new, unproven chain, using a rollup chain (in the ideal scenario) necessitates no more than an assumption of trust in Ethereum. Nevertheless, whether or not rollups effectively achieve their goals, those without a proof system largely negate the purpose of "scaling Ethereum."

Nonetheless, Optimism, despite its relatively long history, has yet to implement a functional proof system. The rollup chain itself lacks the capability to achieve consensus on transaction data, thus data availability and consensus are delegated to the Layer 1 chain. Without a proof system, other network participants cannot validate or challenge transactions at Layer 2, making them effectively no different than data stored on their own servers. A rollup without a proof system is akin to a centralized sidechain operating through a single node, relying on 1-of-1 trust in the sequencer node. Had Optimism been categorized as a sidechain rather than a rollup, it raises doubts about whether it could have attracted the same level of user and ecosystem adoption it enjoys currently. Conversely, other rollup projects invest years of dedication in building proof systems, making it seem absurd that Optimism is listed on L2Beat as a rollup when it does not truly fit that classification.

Source: Introducing the OP Stack

Optimism's failure to build a proof system can be attributed more to a shift in priorities rather than a lack of capability. Following the discontinued effort to implement its own execution environment (OVM 1.0) and fraud proof  system in late 2021, Optimism has shifted its focus to creating a comprehensive architecture for modular blockchains, with strong emphasis on simplicity and standardization. For the concept of modular blockchains to transition from theory to practical implementation, it necessitates a corresponding architecture. Enter OP Stack, a code base designed for modular blockchains. With the recent Bedrock upgrade, OP Stack was successfully deployed on the Optimism mainnet, taking a step towards Optimism's aspiration of becoming a Superchain. Though by no means a minor subject to be glossed over quickly, the comprehensive description of OP Stack's architecture within the confines of this article is constrained. We intend to explore it in greater depth in a future opportunity.

Reflecting on the history of Optimism, Kelvin Fichter's message highlights the view that current rollup projects may be excessively constraining the capabilities of rollups with their proof systems. By limiting the role of rollups primarily to serving as validation bridges, the execution environment of rollup clients is restricted not only to the EVM itself, but also lacks flexibility for future upgrades. However, rollups represent more than just a combination of smart contracts and off-chain data to make Ethereum more scalable; they represent the first implementation of a modular blockchain. While its original purpose was to enhance Ethereum’s scalability, rollup’s scalability and modularity need not to be limited to Ethereum. In a modular blockchain world, rollups can use Bitcoin as a data availability layer, or it can implement specialized execution environments that are not bound by the EVM.

In summarizing the debate between the two Layer 2 camps, it is evident that they present distinct perspectives on the meaning of rollups and the prioritization of the challenges they aim to solve. As is the case across the blockchain technology, none of the rollup solutions are currently near their ultimate objectives. The prioritization of current issues to be addressed can vary significantly depending on the blueprint one envisions for the future of their rollup. The market will of course be the ultimate judge, and the decisions made today will undoubtedly wield a substantial influence on who the market favors in the future.

4-2. Then Who is ZK Rollup? 

Currently, when assessing the potential value of rollups, the consensus suggests that ZK rollups will dominate in the long run due to the limitations of fraud proofs. Indeed, Rollup, functioning as a modular blockchain, has the capability to integrate with various proof systems. Nevertheless, it's crucial to acknowledge that creating an entirely new zero-knowledge proof system, one that has yet to be fully implemented by anyone, is a highly complex undertaking. Rollups relying on fraud proofs do indeed exhibit clear limitations when contrasted with full ZK Rollups utilizing validity proofs for transaction validation. These limitations stem from the necessary withdrawal delay, which not only impairs the user experience but also undermines the seamless execution and interoperability of transactions across different chains. On the other hand, the benefits of zero-knowledge proofs are currently limited in practicality due to the lengthy process of proof generation and slow verification times, alongside substantial expensive computation. If a zero-knowledge proof rollup were to emerge, performing flawlessly with rapid proof generation and verification times, it raises questions about whether the existing narrative surrounding modular blockchains would face challenges.

Source:  Tweet by @jessepollak

The definition of a ZK rollup is about to get even more ambiguous with the latest attempt to validate fraud proofs of Optimistic rollups using zero-knowledge proofs. The Optimism Foundation recently released a request for proposals (RFP) for a Zero Knowledge Fraud Proof (ZKFP) system, which appears to be an attempt to move away from traditional fraud proof-only verification and introduce zero-knowledge proofs. We are currently developing a zero-knowledge fraud proof system with optimistic rollup based on a zero-knowledge virtual machine (zkVM) (no E!) that works in a common execution environment on RISC Zero and LayerN.

Zero Knowledge Fraud Proof (ZKFP) is a hybrid model that combines traditional fraud proof methods with zero-knowledge proofs. In the traditional fraud proof approach, it becomes necessary for the Rollup to fully re-execute all transactions within Layer 2 blocks on the Layer 1 chain (Ethereum), necessitating enforcing compatibility with the EVM and incurring significant gas fees for proof generation. In a ZKFP fraud system, instead of re-executing all of the transactions submitted by the rollup to compare state values, disputes are resolved by submitting just one zero-knowledge proof that the rollup's state transformation was incorrect. However, ZKFPs do not completely address all of the limitations associated with traditional fraud proofs. Similar to traditional fraud proofs, ZKFPs require a dispute grace period (shorter than 7 days) as they do not verify each individual transaction. Even with a reduced duration, the grace period can still be seen as somewhat an incomplete solution, imposing substantial constraints on user experience and compatibility.

Source: Optimism’s OP Stack, Karl Floresch

The introduction of ZKFPs is not primarily aimed at immediately overcoming the limitations of fraud proofs. Instead, it is more fitting to consider them as an interim outcome,  leveraging the advantages of a modular OP Stack structure and common execution environment, with the goal of evolving current Optimistic rollups to ZK rollups. In the previous section, we described the background and intentions behind Optimism's pivot from developing its own execution environment (OVM 1.0) to building a common architecture for modular blockchains (OP Stack). One of the key ideas behind the OP Stack, as implemented by Optimism, was to decouple the proof system from the execution environment, thus allowing it to be compatible with general-purpose systems. Optimism chose a more practical and pragmatic approach by implementing the proof system using a lower-level language capable of accommodating the intricate and demanding conditions of the EVM. This decision opens the door to support for nearly all computer-based execution environments and programming languages, presenting a more viable alternative compared to customizing the chain's execution environment to meet the demands of the EVM. Examples of such execution environments include WASM in Arbitrum's Nitro and MIPS in Optimism's Cannon.

Source: Tweet by @jadler0

The pursuit of simplicity and modularity in modular blockchains may position Optimistic Rollups a more suitable choice for ZK rollups. Most of the ZK rollup projects are channeling their efforts into developing zero-knowledge proof systems that are tailored to a specialized execution environment known as the EVM. This is because an EVM-compatible zero-knowledge proof system is an inherent requirement for  ZK rollups. However, the integration of a bridge and a proof system into a rollup inevitably imposes limitations on its potential to evolve into a general-purpose blockchain system. Current ZK rollup projects are perhaps repeating the mistakes that Optimism made in the past with OVM 1.0.

Ethereum's EVM is not an ideal target because it regularly updates its execution environment, introducing changes to its structure and adding new opcodes. On the other hand, generalized execution environments used in current optimistic rollups (WASM, MIPS, etc.) provide simplicity and flexibility that make them more suitable for implementing zero-knowledge proof systems. Programs coded in low-level languages have the advantage of not inherently tied to a specific blockchain or programming language. Consequently, they can adapt to various blockchain with minimal adjustments. For Optimism's modular architecture, adding a new proof system is not a complicated process. It primarily involves modifying or adding a zero-knowledge proof system to their proof system, which is already designed to run in a lower-level language.

The flexibility to choose different layers in a modular architecture is not limited to rollups alone. When developed with a sufficiently generalized purpose, a single proof system can also function as a settlement layer for multiple rollups. This means that a proof system can be selectively applied to rollups or simultaneously to multiple chains. Given this perspective, the question arises: Why start over with a "ZK-only" chain that offers low compatibility and limited ecosystem when we can integrate a more scalable zero-knowledge proof system into a rollup chain that already has an established user base and ecosystem?

Certainly, developing a zero-knowledge proof system that seamlessly integrates with existing optimistic rollups will take a lot of time and effort. However, considering that no chain has achieved the status of a fully developed ZK Rollup at this point, the implementation of a zero-knowledge proof system tailored for common execution environments seems to be a factor that could potentially challenge the current dominance of Optimistic rollups over ZK rollups.

5. Declaration of Independence of Rollups  

5-1. Blockchain Forks and Social Consensus (Governance)

A blockchain is a single state machine in which all participants in the network share the same state. Satoshi Nakamoto's great invention used a combination of math, economics, and game theory to implement a system where all participants "agree" on the same state. When multiple states exist simultaneously on a blockchain, the network's participants reach a consensus to determine the "canonical" chain.

Consensus in blockchains can be categorized into two types: machine consensus, which refers to crypto-economic protocols, and social consensus among participants. Machine consensus, often referred to as the Fork Choice Rule, plays a crucial role in selecting a specific state from among various states that coexist within different blockchains. This mechanism encompasses a set of rules for the creation of blocks and the selection of eligible chains, constituting a blockchain's consensus algorithm. Short-term forks, which occur from time to time based on the consensus algorithm, are typically resolved by machine consensus within a short timeframe.

The rollup debate primarily revolves around the fork selection determined by the blockchain's social consensus (governance). While machine consensus may operate perfectly, sharing the same database necessitates agreement among all network participants regarding the use of a  same "version" of the software. In this context, a version of a blockchain refers to a state transition function, making the upgrade of client software essentially synonymous with blockchain forking. A blockchain is also a software program consisting of a set of code, which requires periodic upgrades and code modifications even after its initial release. In these cases, the network’s participants collectively determine the legitimate version of the software through social consensus.

Sourceㅣ Yes, this kid really just deleted $300 MILLION by messing around with Ethereum’s smart contracts., Hackernoon

Unlike machine consensus, which is based on math and cryptography, social consensus is based on political interests and may not necessarily converge on a single state. When individuals within a blockchain network hold differing views on a software upgrade, typically due to differences in opinion, it can result in a permanent fork of the blockchain. In theory, an infinite number of forks can exist simultaneously for a single blockchain. Determining which chain is considered legitimate, or, in other words, which chain receives the “official”name is purely driven by the political dynamics among the participants. The name associated with a blockchain signifies not a specific technology or product but rather the brand’s identity. A prime example is the 2016 hack of The DAO, which resulted in Ethereum splitting into Ethereum and Ethereum Classic. The scale of The DAO hack was significant enough to threaten the very existence of the newly launched Ethereum chain. At the time, "some" Ethereum participants agreed to "officially" revert to the pre-hack state through social consensus. Others opposed the reversion. The former network is now known as Ethereum, and the latter as Ethereum Classic.

So how does a rollup blockchain, which records its block information on another blockchain, upgrade or fork? In the event of a major hack on a rollup blockchain, can it be reverted to a previous state through social consensus, similar to Ethereum’s? In Chapter 4, "Validating Bridges are not Rollups," we explained why rollups shouldn't be limited to just serving as bridges. The central question addressed in this chapter is: do rollups have the sovereignty to determine their own state? The question of rollup sovereignty has been a significant point of contention among researchers in the rollup debate, and it was the focus of Jon Charbonneau's “Rollups Are L1s (& L2s)” and Kelvin Fichter's “Rollups, Rigor, and Reality.” This chapter aims to provide a concise summary of the key arguments presented in both original articles. Some sentences are directly excerpted and paraphrased, so for a more in-depth exploration, I recommend reading the original articles.

5-2. Smart Contract Rollup and Sovereign Rollup 

The rollups described above all revolve around the concept of smart contract rollups. Smart contract rollups are the most well-known form of rollups today, where user-submitted transaction data is recorded and validated by a bridge smart contract on a Layer 1 blockchain. Smart contract rollups are a trust-minimized, enshrined-bridge blockchain, which means they are considered "baby chains" of Ethereum. The bridge incorporates an inherent proof system that serves as an on-chain light client responsible for confirming the correct execution of transactions within the rollup. The smart contracts on the settlement layer become the source of truth for determining the correct rollup chain.

Source: An introduction to sovereign rollups, Celestia

On the other hand, sovereign rollups introduced by Celestia don't necessarily require transactions to be validated by bridges on the Layer 1 blockchain. Similar to smart contract rollups, they utilize the Layer 1 blockchain for consensus and data availability layer, but transactions are not required to be validated or for rollups to be defined by bridge contracts. A sovereign rollup can validate transactions and determine eligible chains as it operates like a Layer 1 blockchain. The verification of transactions, which rollups traditionally execute on Layer 1 bridge contracts, has now transitioned to a peer-to-peer proof exchange system among rollup nodes. While sovereign rollups can be connected to Layer 1 or other blockchains as a trust-minimized bridge, it is only an option and is not considered a chain-determining entity like a smart contract rollup. In the case of sovereign rollups, the Layer 1 blockchain serves not as an authoritative entity defining the rollup but rather as a means to ensure the storage and alignment of data, which can be referenced by all participants in the network.

Sovereign rollups can be upgraded via forks, much like Layer 1 blockchains. When a new software version is proposed, the nodes in the rollup have the freedom to decide whether to adopt the upgrade based on their decisions. The sovereignty of the rollup does not imply that democracy or token governance will lead to a unified consensus on a single qualified chain. Even if the majority of nodes follow the upgrade, as seen in the Ethereum Classic case, some nodes may opt to maintain their current software version. By allowing each node to choose its preferred software version, different rollups that were once part of the same blockchain can exist simultaneously.

Source: Tweet by @celestiaorg

The key distinction between a smart contract rollup and a sovereign rollup lies in the presence or absence of a settlement layer. In the context of modular blockchains, a settlement layer most commonly refers to a consensus protocol that collectively agrees on the balance of all accounts according to an ordered list of transactions. Settlement is a distinct element that differs from a monolithic blockchain model. In a monolithic model, once a transaction is executed and included in a block by a node, its confirmation is guaranteed within a specified time frame. However, in systems where security is determined by other blockchains, such as rollups, the timing of transaction verification at each layer may vary. The determination of when consensus is achieved, or at which stage or chain, defines the settlement layer. In a smart contract rollup, where the Layer 1 chain serves as the settlement layer, only transactions validated on the Layer 1 chain (specifically, the bridge contract) are considered as the source of truth. Sovereign rollups, on the other hand, use transactions validated by their own nodes as the source of truth.

5-3. All Rollups are Sovereign Rollups 

Source: Tweet by @_prestwich

James Prestwich has previously criticized the ambiguity of the term "settlement layer." Typically, the concept of settlement, as we commonly use it (and why this usage may be incorrect), can be categorized into the following three distinct groups:

1. Ledger of Record: This refers to a definitive accounting ledger that tracks a specific asset. For instance, ETH represents Ethereum while SOL represents Solana. It is important to note that the settlement layer for a particular asset is not exclusive. Take USDC as an example; it can settle transactions on various blockchains like Ethereum, Solana, Tron, and Avalanche. For some users, transactions are also settled on Coinbase and Binance.
2. Transaction validation on the bridge: In the context of smart contract rollups, Ethereum’s reference to the "settlement layer" implies that transactions are validated on the bridge. However, this process differs from transactions being confirmed on the rollup blockchain. Transactions on Arbitrium are confirmed as soon as they are recorded on the Layer 1 blockchain, not when they are validated on the bridge (after the 7-day dispute period). Bridges are not rollups.
3. A marketing buzzword: For the most part, “settlement layer” is just a buzzword used for marketing purposes, often overstating the value of the blockchain. Many individuals who employ this term lack a comprehensive understanding of its genuine meaning.

In the context of rollups, Ethereum is referred to as a "settlement layer" because of the perception that the bridge contract defines the rollup itself. In an optimistic rollup, when a transaction is confirmed after seven days indicates the point at which the bridge contract validates them as true, rather than the rollup blockchain confirming them. However, as demonstrated in Chapter 3-3, the rollup is an entity distinct from the bridge. Consider the scenario where Arbitrum introduces the Multi Prover System to provide additional zero-knowledge proofs and proofs by governance. In the case of a user-submitted transaction, a governance-based bridge can verify the accuracy of what the Arbitrum chain writes to Ethereum. On the other hand, a bridge employing zero-knowledge proofs would confirm the transaction only after receiving and validating the proofs for a batch of transactions, which might take several hours. In contrast, a bridge employing fraud proofs would delay confirmation of transactions until seven days later. Although all these approaches leverage Ethereum as a settlement layer, their views on the state of the Arbitrium chain are not identical. The bridge serves as a means for Ethereum to observe (view) rollups rather than defining them.

As for sovereign rollups, Mustafa Al-Bassam from Celestia pointed out that “To ‘not enshrine a settlement layer’ is primarily a social distinction rather than a technical one.” Transaction confirmations take place both within the rollup blockchain and the bridge contract of the Layer 1 chain. If there is a collective consensus that what is confirmed by the bridge contract in Layer 1 represents the truth, then we call it a smart contract rollup. Conversely, if we reach a consensus that the nodes’ verification in the rollup is the truth, then we identify it as a sovereign rollup. In Chapter 5-2, we described sovereign rollups as counterparts to smart contract rollups, however, it is more appropriate to view them as a broader concept. All rollups are inherently sovereign. The fact that they are connected to a Layer 1 blockchain through a trust-minimized bridge does not alter their fundamental nature of rollups. So, the question arises: Can any rollup transition to a new chain (or bridge) solely based on social consensus?

A rollup's bridge contract comprises three key elements: 1) Block information from the Layer 2 chain, 2) a proof system to validate transaction data, and 3) assets held by users, intended for transfer to the rollup chain. Given the presence of a hard-coded proof system within the bridge, making adjustments to the bridge contract becomes necessary to modify (a.k.a. upgrade) the rollup's state transition function. Yet, since users' assets are stored on the bridge, making changes to the bridge inevitably results in the loss of some assets. It is important to distinguish between a rollup's ability to modify the bridge contract through a hard fork and the process of moving assets held on the bridge. Again, a rollup is not a bridge. A sovereign rollup can determine, through social consensus, which forked version of the blockchain to adopt. However, assets held on the bridge cannot be forked. If assets held on a bridge are transferred to the bridge of a new rollup, users who remain with the existing rollup can no longer withdraw their assets to the original chain and the same applies to the opposite scenario. This situation forces the rollup to make a binary choice between upgradeability or facing the loss of bridged assets.

Source: Tweet by @arbitrum

It's essential to recognize that the cost of changing the bridge depends on how many assets are tied to the bridge of the rollup. The TVL in a rollup can be categorized into two groups: 1) assets issued through the bridge and 2) assets issued on the rollup blockchain. Assets issued directly on the rollup blockchain remain unaffected by a rollup’s hard fork. This is because the rollup blockchain itself represents the definitive Ledger of Record for those assets. However, the redeemability of bridged assets may vary,  depending on whether they are transferred to the new bridge. Consider, for instance, the case of the USDC token on both Arbitrum and Optimism. USDC recently announced the issuance of its own token on the Arbitrum chain. Therefore, USDC tokens on the Arbitrum chain are not transferred from Ethereum, but are self-minted tokens, which means that their value can be maintained even if the bridge is changed using only Arbitrum's block information (ledger of records). In contrast, the USDC in Optimism represents an asset transferred from Ethereum to the bridge, functioning more as proof of collateral than a token with intrinsic value. If an Optimism changes bridges without transferring assets from the existing bridge, the value of USDC in the new Optimism will converge to zero.

Currently, most rollups are bridged, with assets transferred via bridges make up the majority of TVL. When sovereign rollups connect to Layer 1 blockchains through trust-minimized bridges, and bridged assets represent a substantial portion of the total, a social consensus is formed, cementing the notion that "rollups = bridges." A smart contract rollup, which was once an sovereign rollup no longer has the power to independently upgrade to a new state transition function or to choose the state of the blockchain at will.

Source: Tweet by @_prestwich

If a rollup splits into two chains due to a disagreement in social consensus, as in the case of Ethereum Classic, it becomes inevitable that one side will lose bridged assets. However, in the case of a hard fork where unanimous consensus is achieved, much like a typical software upgrade, the assets held on the old bridge are simply transferred to the new bridge and there is no loss of assets. As part of a recent upgrade to Bedrock, Optimism used the multisig contracts to transfer assets from the old bridge to the new bridge. This transition allows users to continue using the same assets on the new chain, whether they were initially bridged or issued. However, transferring assets held on bridges necessitates additional trust assumptions to be placed in entities beyond Ethereum (multisig, DAOs, and more).

The sovereignty of rollups and the trust model with Layer 1 are inherently contradictory. The concept of upgradable rollups inevitably introduces the need for significantly expanded security assumptions, particularly concerning the governance entities responsible for the rollup and the bridge. Revisiting our earlier discussion on blockchain scalability, it becomes increasingly challenging to assert that sovereign rollups continue to offer direct scalability to Ethereum. For users exclusively seeking to process Ethereum transactions externally, rather than using the rollup chain itself, sovereign rollups can no longer be considered a system that shares the same network as Ethereum. In the most extreme scenario, the social consensus of sovereign rollups might even lead to the decision to change the Layer 1 blockchain if they no longer perceive Ethereum as an effective DA layer. Ethereum may be rollup-centric, but rollups may not be Ethereum-centric.

Framing rollups as a type of sovereign rollup rather than a verification bridge has important implications for builders in terms of how their systems can potentially evolve. Many of the misconceptions surrounding rollups stem from the "rollup = bridge" conceptual framework, a topic we explored in Chapter 3. This perspective significantly restricts the potential for rollups to become more autonomous systems than the current state. Users also need to understand the risks associated with holding assets in a particular rollup chain. For instance, as mentioned in the USDC example earlier, the potential for a rollup upgrade does not entail the sudden loss of all your assets. Rollups, like any other blockchains, serve as tools for facilitating social consensus, and the code and transaction data on the bridge does not define the rollup blockchain itself.

 

6. Conclusion

In a nutshell, the heated discourse surrounding rollups boils down the question of which mental model to support—whether rollups exist solely to provide scalability for Ethereum, or as a new form of modular blockchain. Chapter 3 discussed rollup's proof system and trust-minimized bridges to explain why the current perception of "bridges are rollups" is so prevalent. However, limiting rollup's role to bridges significantly limits its potential as a system. Rollups represent a generic implementation of modular blockchains that can be leveraged not just for a single function (e.g., scaling Ethereum), but as a blockchain to achieve broader purposes. Chapter 4 covered sovereign rollups and social consensus. Rollups are also blockchains, and all of the complex cryptography and math behind them are just tools to achieve social consensus. Social consensus can certainly change rollups. Recognizing their sovereignty, rather than viewing them solely as bridges, has important implications for assessing their potential for both builders and users of rollups.

This article has covered the structure and workings of rollups quite extensively. Yet, the answer to the question of whether a rollup is the same as a bridge is more of a judgment call than a strict technical definition. For some, a rollup is essentially a way to leverage off-chain computational resources without compromising any of Ethereum's trust assumptions. For others, the significance of rollups as a general-purpose system for modular blockchains overrides the importance of scaling Ethereum. As a final note, while this article aims to present the gist of the debate that took place among blockchain researchers in a balanced manner, it should be noted that the opinions in this article reflect the author's personal opinions and may not be entirely objective.