Rollups have the ecosystem buzzing with controversy. If you're scratching your head trying to make sense of it all, you’re not alone. We’ve noticed there aren’t many pieces of content that bring rollup architectures together in a digestible way, so we’ve decided to take a stab.

Note that this post isn’t attempting to dive deep, be comprehensive or focus on specific projects. The goal is to walk through popular rollup designs and offer easy ways to think about them.

Let's kick things off with a metaphor.

Imagine yourself in a crowded city, where people are constantly rushing from one place to another. The streets are filled with cars, buses, and motorcycles, each representing a smart contract transaction carrying important information and computations.

As the city grows, the streets become congested. The number of vehicles trying to move at the same time overwhelms the road infrastructure, causing delays and gridlock. This congestion mirrors Ethereum's current state, where an increasing number of transactions strain the network's capacity to process and record them in each block.

Now, imagine a proposed transportation system that solves the congestion problem. Lets call it “rollup”, that introduces a network of high-speed tunnels beneath the city. These tunnels serve as alternate routes for vehicles to travel, bypassing the crowded streets above.

In this metaphor, the Ethereum blockchain represents the streets; the transactions are the vehicles, and rollups act as the underground tunnels, efficiently handling and processing the transactions while minimizing the strain on the main blockchain.

Rollups move computational work off of a given blockchain without losing the security properties of that blockchain.

Instead of directly processing every computational step on Ethereum (we’ll use Ethereum as an example, but rollups can be built on other blockchains), they consolidate, bundle, “roll up,” or summarize the information into a condensed form. This bundled data includes "proofs," “state roots” and other “transaction data”. For simplicity, let’s refer to all of this as “rollup data”.

Rollups are often blockchains themselves. Rollup blockchains take user transactions, process them and securely store all rollup data on the main blockchain. Again, you can think about rollup as compressing data to fit more efficiently on the main blockchain (AKA base chain).

Revisiting the city metaphor: streets + high-speed tunnels = more scalable city. Similarly, rollups allow the Ethereum ecosystem (kinda like a city) to handle a much larger volume of complex transactions, making the network (technically a network of networks) more scalable and efficient.

However, not all rollups are the same. There are different designs to consider, each with different security properties.

Before we get into the different types of rollups, lets refresh ourselves on the core functions of a blockchain (yeah, we doing basics again).

1. Execution: executes transactions and lets only valid transactions result in state machine transitions.

2. Settlement: verifies proofs, resolves fraud disputes, and acts as a bridge between other execution layers.

3. Data Availability (DA): stores transaction data, ensuring its availability and accessibility.

4. Consensus: agrees on the order of transactions across the blockchain network, and that all participants reach a consensus on the validity and ordering of transactions.

Optimistic Rollups rely on fraud-proofs.

This approach operates under good faith, allowing batches of transactions to be posted with the assumption that they are correct. If a batch is indeed valid, no further action is required within the rollup system.

If a batch is discovered to be false, the system initiates a series of processes to identify and penalize the responsible party. Optimistic Rollups employ a dispute resolution system that verifies fraud proofs and carries out appropriate punishments. Typically, two main parties are involved in this process: the user who submitted the batch and the user who suspects fraudulent activity and submits the fraud proof.

Both participants are required to provide a bond in ETH, which will be slashed in the event of misconduct by either party.

ZK (Zero-Knowledge) Rollups use validity proofs.

They operate under a "guilty until proven innocent" approach, ensuring that transactions are submitted along with evidence of their correct execution. This evidence is a "zero-knowledge proof," a concise representation demonstrating that each step of the program execution sticks to the blockchain rules. By combining numerous transactions into a sizable batch, ZK rollups enable simultaneous validation of multiple transactions.

Each batch of transactions includes a cryptographic proof that comes in the form of ZK-SNARK or ZK-STARK. This enable users to securely transmit transactions across a blockchain completely encrypted. These transactions remain confidential and unreadable by anyone, yet the proofs validate their legitimacy and integrity.

You can learn more, here!

tl;dr: these are the rollups that we commonly encounter on Ethereum today.

Smart Contract rollups, such as Optimistic and ZK rollups (covered above), rely on a settlement layer (like Ethereum) to validate and order their blocks.

In this setup, the rollup focuses on executing transactions, while tasks like consensus, data availability, and settlement are handled by the underlying blockchain. To ensure trust and reliability, smart contract rollups rely on a set of smart contracts on the settlement layer. These smart contracts act as a bridge, establishing a secure connection between the rollup and the settlement layer.

Sovereign rollups bring additional features to the basic rollup architecture, introducing independence and autonomy. They publish their transactions to another blockchain for ordering (consensus) and data availability while maintaining control over their own execution and settlement.

Unlike smart contract rollups, sovereign rollups do not have secured bridges connecting them to a settlement layer. They lack a native trust-minimized bridge with the DA layer for settlement, which has been a point of contention.

What’s important to note is that sovereign rollups can still have general bridges for communication with external systems. These bridges allow them to interact and exchange information with other networks, even if they don't rely on them for settlement. This provides some degree of connectivity, but the absence of a secured bridge to a settlement layer remains a notable distinction for sovereign rollups.

Technically, validiums and volitions are not rollups but let’s consider them close cousins of rollups. They play an important part of the design space.

Validiums offer a different approach to processing transactions. Instead of executing transactions directly on L1, it processes them offchain before submitting them, along with a proof, to the parent chain. This part works the same as rollups.

What sets validiums apart from rollups is how they optimize data availability throughput by using a separate, offchain data availability layer. This trades off *some* security for use cases where high performance and low cost matter more.

Volitions are a blend of rollups and validiums. When using a volition, you can decide whether you’d like to operate in “rollup mode” or “validium mode”. In theory this decision will depend on the security / throughput needs of the use case.

Developers can configure the mode based on their application, or they can pass the decision through to end users.

Most of the rollups you are familiar with are Layer 2s (L2s). As we’ve discussed, L2 rollups post rollup data to the base chain.

However, there’s a new paradigm emerging where rollups post proofs to other rollups which then aggregate many proofs together and post that single proof to the base chain. Yes, we are describing rollups on rollups.

Note: this only applies to ZK rollups, not optimistic rollups.

Why L3s? The reason developers pick this design is to enable faster and cheaper ZK proving. This works via recursion, which you can read more about here.

When L3 rollups post proofs to L2 rollups, they are often said to be “settling” on the L2 rollup. Unsurprisingly, these constructions are called settlement rollups.

Note that the implementation of settlement rollups can vary. Some settlement rollups are, in reality, general-purpose smart contract platforms that L3 rollups use for settlement. Settlement rollups can also be designed specifically for verifying proofs and have no smart contract functionality at all.

Enshrined rollups mean that the rollup software is part of the base chain. For example, if Ethereum took the Scroll codebase and integrated it into the core Ethereum protocol, it would have “enshrined” the rollup. This would mean that when Ethereum upgrades or forks, so would the rollup. They’d be attached.

Note that enshrinement applies well beyond the rollup context. A few examples:

• You can think of Ethereum as a consensus and DA layer with enshrined smart contract and settlement functionality, as opposed to Celestia which is solely a consensus and DA layer.

• EigenLayer is an independent restaking protocol built on Ethereum smart contracts, but there are discussions about enshrining similar functionality into the core Ethereum protocol. See PEPC.

• Cosmos chains offers enshrined stake delegation, whereas Ethereum delegates this to be implemented as smart contracts.

Based rollups are rollups without sequencers.

Well, technically, based rollups use the base chain as an enshrined sequencer (the transactions still need to be ordered somehow). In this construction, users send transactions directly to L1 and validators order the transactions like any other L1 transactions. Rollup nodes then use this ordered list as input to their state transition function.

While we hope this post made rollup architectures more digestible, we understand that the design space is large and it’s still a lot to take in. This is what makes it even more important to understand, especially to make the most informed decisions possible about which rollup architecture to use for specific use cases.

It’ll be interesting to see the design space be fully explored over the coming years and which designs win out. See you down the rabbit hole!

1. The Complete Guide to Rollups and Rollups aren’t Real by Jon Charbonneau

2. Rollups, Rigor, and Reality by Kelvin Fichter

3. A thread covering High-level Rollup Architecture and Ecosystem by Stephy

Rollups have the ecosystem buzzing with controversy. If you're scratching your head trying to make sense of it all, you’re not alone. We’ve noticed there aren’t many pieces of content that bring rollup architectures together in a digestible way, so we’ve decided to take a stab.

Note that this post isn’t attempting to dive deep, be comprehensive or focus on specific projects. The goal is to walk through popular rollup designs and offer easy ways to think about them.

Let's kick things off with a metaphor.

Imagine yourself in a crowded city, where people are constantly rushing from one place to another. The streets are filled with cars, buses, and motorcycles, each representing a smart contract transaction carrying important information and computations.

As the city grows, the streets become congested. The number of vehicles trying to move at the same time overwhelms the road infrastructure, causing delays and gridlock. This congestion mirrors Ethereum's current state, where an increasing number of transactions strain the network's capacity to process and record them in each block.

Now, imagine a proposed transportation system that solves the congestion problem. Lets call it “rollup”, that introduces a network of high-speed tunnels beneath the city. These tunnels serve as alternate routes for vehicles to travel, bypassing the crowded streets above.

In this metaphor, the Ethereum blockchain represents the streets; the transactions are the vehicles, and rollups act as the underground tunnels, efficiently handling and processing the transactions while minimizing the strain on the main blockchain.

Rollups move computational work off of a given blockchain without losing the security properties of that blockchain.

Instead of directly processing every computational step on Ethereum (we’ll use Ethereum as an example, but rollups can be built on other blockchains), they consolidate, bundle, “roll up,” or summarize the information into a condensed form. This bundled data includes "proofs," “state roots” and other “transaction data”. For simplicity, let’s refer to all of this as “rollup data”.

Rollups are often blockchains themselves. Rollup blockchains take user transactions, process them and securely store all rollup data on the main blockchain. Again, you can think about rollup as compressing data to fit more efficiently on the main blockchain (AKA base chain).

Revisiting the city metaphor: streets + high-speed tunnels = more scalable city. Similarly, rollups allow the Ethereum ecosystem (kinda like a city) to handle a much larger volume of complex transactions, making the network (technically a network of networks) more scalable and efficient.

However, not all rollups are the same. There are different designs to consider, each with different security properties.

Before we get into the different types of rollups, lets refresh ourselves on the core functions of a blockchain (yeah, we doing basics again).

1. Execution: executes transactions and lets only valid transactions result in state machine transitions.

2. Settlement: verifies proofs, resolves fraud disputes, and acts as a bridge between other execution layers.

3. Data Availability (DA): stores transaction data, ensuring its availability and accessibility.

4. Consensus: agrees on the order of transactions across the blockchain network, and that all participants reach a consensus on the validity and ordering of transactions.

Optimistic Rollups rely on fraud-proofs.

This approach operates under good faith, allowing batches of transactions to be posted with the assumption that they are correct. If a batch is indeed valid, no further action is required within the rollup system.

If a batch is discovered to be false, the system initiates a series of processes to identify and penalize the responsible party. Optimistic Rollups employ a dispute resolution system that verifies fraud proofs and carries out appropriate punishments. Typically, two main parties are involved in this process: the user who submitted the batch and the user who suspects fraudulent activity and submits the fraud proof.

Both participants are required to provide a bond in ETH, which will be slashed in the event of misconduct by either party.

ZK (Zero-Knowledge) Rollups use validity proofs.

They operate under a "guilty until proven innocent" approach, ensuring that transactions are submitted along with evidence of their correct execution. This evidence is a "zero-knowledge proof," a concise representation demonstrating that each step of the program execution sticks to the blockchain rules. By combining numerous transactions into a sizable batch, ZK rollups enable simultaneous validation of multiple transactions.

Each batch of transactions includes a cryptographic proof that comes in the form of ZK-SNARK or ZK-STARK. This enable users to securely transmit transactions across a blockchain completely encrypted. These transactions remain confidential and unreadable by anyone, yet the proofs validate their legitimacy and integrity.

You can learn more, here!

tl;dr: these are the rollups that we commonly encounter on Ethereum today.

Smart Contract rollups, such as Optimistic and ZK rollups (covered above), rely on a settlement layer (like Ethereum) to validate and order their blocks.

In this setup, the rollup focuses on executing transactions, while tasks like consensus, data availability, and settlement are handled by the underlying blockchain. To ensure trust and reliability, smart contract rollups rely on a set of smart contracts on the settlement layer. These smart contracts act as a bridge, establishing a secure connection between the rollup and the settlement layer.

Sovereign rollups bring additional features to the basic rollup architecture, introducing independence and autonomy. They publish their transactions to another blockchain for ordering (consensus) and data availability while maintaining control over their own execution and settlement.

Unlike smart contract rollups, sovereign rollups do not have secured bridges connecting them to a settlement layer. They lack a native trust-minimized bridge with the DA layer for settlement, which has been a point of contention.

What’s important to note is that sovereign rollups can still have general bridges for communication with external systems. These bridges allow them to interact and exchange information with other networks, even if they don't rely on them for settlement. This provides some degree of connectivity, but the absence of a secured bridge to a settlement layer remains a notable distinction for sovereign rollups.

Technically, validiums and volitions are not rollups but let’s consider them close cousins of rollups. They play an important part of the design space.

Validiums offer a different approach to processing transactions. Instead of executing transactions directly on L1, it processes them offchain before submitting them, along with a proof, to the parent chain. This part works the same as rollups.

What sets validiums apart from rollups is how they optimize data availability throughput by using a separate, offchain data availability layer. This trades off *some* security for use cases where high performance and low cost matter more.

Volitions are a blend of rollups and validiums. When using a volition, you can decide whether you’d like to operate in “rollup mode” or “validium mode”. In theory this decision will depend on the security / throughput needs of the use case.

Developers can configure the mode based on their application, or they can pass the decision through to end users.

Most of the rollups you are familiar with are Layer 2s (L2s). As we’ve discussed, L2 rollups post rollup data to the base chain.

However, there’s a new paradigm emerging where rollups post proofs to other rollups which then aggregate many proofs together and post that single proof to the base chain. Yes, we are describing rollups on rollups.

Note: this only applies to ZK rollups, not optimistic rollups.

Why L3s? The reason developers pick this design is to enable faster and cheaper ZK proving. This works via recursion, which you can read more about here.

When L3 rollups post proofs to L2 rollups, they are often said to be “settling” on the L2 rollup. Unsurprisingly, these constructions are called settlement rollups.

Note that the implementation of settlement rollups can vary. Some settlement rollups are, in reality, general-purpose smart contract platforms that L3 rollups use for settlement. Settlement rollups can also be designed specifically for verifying proofs and have no smart contract functionality at all.

Enshrined rollups mean that the rollup software is part of the base chain. For example, if Ethereum took the Scroll codebase and integrated it into the core Ethereum protocol, it would have “enshrined” the rollup. This would mean that when Ethereum upgrades or forks, so would the rollup. They’d be attached.

Note that enshrinement applies well beyond the rollup context. A few examples:

• You can think of Ethereum as a consensus and DA layer with enshrined smart contract and settlement functionality, as opposed to Celestia which is solely a consensus and DA layer.

• EigenLayer is an independent restaking protocol built on Ethereum smart contracts, but there are discussions about enshrining similar functionality into the core Ethereum protocol. See PEPC.

• Cosmos chains offers enshrined stake delegation, whereas Ethereum delegates this to be implemented as smart contracts.

Based rollups are rollups without sequencers.

Well, technically, based rollups use the base chain as an enshrined sequencer (the transactions still need to be ordered somehow). In this construction, users send transactions directly to L1 and validators order the transactions like any other L1 transactions. Rollup nodes then use this ordered list as input to their state transition function.

While we hope this post made rollup architectures more digestible, we understand that the design space is large and it’s still a lot to take in. This is what makes it even more important to understand, especially to make the most informed decisions possible about which rollup architecture to use for specific use cases.

It’ll be interesting to see the design space be fully explored over the coming years and which designs win out. See you down the rabbit hole!

1. The Complete Guide to Rollups and Rollups aren’t Real by Jon Charbonneau

2. Rollups, Rigor, and Reality by Kelvin Fichter

3. A thread covering High-level Rollup Architecture and Ecosystem by Stephy