What are Rollups?
119 listicles that completely explain human behavior, none of them will SHOCK you
Author’s note:
This post was co-authored with Mark Tyneway at Optimism, who is a great friend and a great engineer. We wrote this together in mid 2021, and then sat in our drafts folder for ages. Our thinking on rollups has evolved significantly over the last 18 months. Particularly, this blog post does not distinguish between rollups hosted on a chain, and those hosted on a generic data-availability system. We’re choosing to yolo publish now just so it doesn’t sit in drafts any longer.
Part 1: What and Why Rollups
Blockchains believers tout the ways consensus over a global state can revolutionize markets by eliminating intermediaries and trusted third parties. However, blockchains have limited throughput, and users must bid against each other for the right to access them. As adoption has grown, some users have proven willing to pay very high fees for the right to update the shared state. Rising fees have already begun to squeeze out retail users. Blockchains must be able to scale far beyond their current limitations or risk becoming inaccessible for everyday users. Unfortunately, the nature of consensus systems makes increasing transaction throughput very difficult.
Nodes that want full security must process every transaction and store all state updates or fall out of consensus with the rest of the network. However, node software generally supports several levels of security. Users are free to choose their security level. Light nodes only check some of the consensus rules. They are good for lightweight applications, but rely on trust in other nodes on the network. A full node ensures the chain follows all consensus rules, performing much more work than a light node. Users who don’t want to run a node at all may outsource that responsibility to a service provider like Infura or Alchemy.
When designing a blockchain, engineers target full nodes running on specific minimum hardware. Because all full nodes perform the same validation work concurrently, the minimum hardware requirement limits the entire system’s throughput. Chain designers set limits on transactions to ensure that the target hardware can validate each new block before the next one is produced. Increasing throughput typically makes blocks more expensive to validate or makes blocks come more often. Therefore throughput increases generally require a corresponding increase in this hardware requirement. Bitcoin bakes this into the limits on block size and signature operations, while Ethereum uses gas-metered execution with a per-block gas limit. In other words, an increase in Ethereum’s gas limit means raising the minimum hardware requirement and kicking out nodes that don’t meet the new requirement.
This hardware target determines the “entry fee” for participating in the network. To get full value from the network, users must pay the entry fee by running a node. Users that don’t run a full node can run a light node that consumes fewer computing resources (a lower entry fee) but relies on trusted state providers for some features. Users that can’t run a light node must depend on a trusted third party and can be fooled by that provider. Although most users prefer a centralized provider even when a self-hosted node is available, it is important to keep the target node hardware affordable to ensure that full participation in the chain is not restricted to the wealthy.
As a result, the chain’s throughput (usually measured in transactions per second) is tightly constrained by the minimum hardware. This scarcity forces users to compete for transaction inclusion by paying high gas prices. Ideally, we’d like to increase throughput on the same hardware without compromising our security. We call our ability to increase throughput on specific hardware “scalability.” Better scalability means more transactions processed with the same resources. Scalability gains are much more desirable and much more challenging to achieve than throughput increases.
Over the past decade, many throughput solutions have been designed, but very few have been deployed. Bitcoin has Lightning channels. Ethereum has seen a parade of proposals, including Plasma, sharding, and state channels. For the last year, almost all Ethereum throughput research has focused on rollups. A rollup is a proposed class of throughput solutions that alleviate the need to run all state transitions on-chain. While several flavors of rollup exist, they all share a few key design elements:
Rollup nodes rely on the host chain to order their state updates.
Rollup nodes rely on the host chain to make their history available..
The host chain’s consensus does not follow the rollup state.
In addition, all rollup currently deployed on Ethereum have one more shared feature:
There is some mechanism for the host chain to retrospectively verify some part of the rollup state.
This verification mechanism can be thought of as an “enshrined” bridge. It is a bridge which is special-cased within the rollup mechanism, and is often inextricably linked to the mechanism. Rollups without enshrined bridges are called “sovereign rollups”. Starting with Omni (previously “MasterCoin”) hosted on Bitcoin in late 2013, sovereign rollups (also called “velvet forks”) have been deployed in the wild for years.
Most dialogue around rollups, however, focuses on systems with an enshrined bridge. The zk-based entry & exit mechanism designed in 2018 kicked off the present wave of rollup research and innovation. As a result, rollups are often referred to by the mechanism of the bridge. A zk-rollup derives bridge security from zero-knowledge proofs. An optimistic rollup uses an optimistic fraud proof to secure its enshrined bridge. Rollups with enshrined bridges are carefully designed to ensure that the bridge is economical to run on the host chain.
A rollup user runs a rollup full node. The rollup node, like any other full node, reads rollup data from the host chain and processes it locally to produce the rollup state. The host chain guarantees the necessary data is available. Because rollup data enters the host chain history, anyone can sync the rollup state at any time by syncing both the host chain and a rollup full node. Therefore a rollup full node generally requires a host chain full node to operate.
Blockchains require global consensus, which constrains their throughput. Solutions like sharding, channels, and rollups increase throughput by choosing a smaller set of consensus nodes that rely on the global consensus. This local consensus can set higher node requirements, change verification requirements, or accept less security. Throughput solutions can confirm more transactions than the main network because they can optimize for different applications by making specific tradeoffs. Each kind of throughput solution makes different tradeoffs. They keep some properties of the host blockchain and sacrifice others.
Part 2 - Partitioning
Over the last several years, we’ve been looking for the correct set of tradeoffs, and rollups seem to occupy a fascinating spot in the tradeoff landscape. Rollups attract us because they preserve a lot of the desirable properties of a blockchain:
Unlike sidechains, rollups have the same data availability guarantees as the host chain.
Unlike channels, anyone can join a rollup while it’s running.
Unlike shards, rollups are heterogeneous and dynamic.
In essence, rollups keep the best parts of the host chain while allowing for experimentation. Rather than making a second consensus set, like a shard or a side chain, they effectively create a partition within the host chain’s global consensus where the rules can be adjusted to target specific use cases. General-purpose machines (like the EVM) can perform any computation but can’t compete on speed or efficiency with specialized machines. Because the host consensus is naive of the rules inside the rollup, many different specialized models can be tried in rollups on Ethereum today.
The Fuel rollup is UTXO-based but hosted on an account-based chain! The Optimism and Arbitrum VMs mirror the EVM’s state model but are secured by fraud proofs. Matter Labs’ zkSync uses its account model, with zero-knowledge validity proofs for each state update. Aztec has built a UTXO-like note set with validity proofs. (If we didn’t mention your rollup here, please don’t yell at us. The list is very long these days). These rollups are free to tailor themselves to payments, contracts, or anything else. The rollup model’s benefits come from its ability to enable experimentation with the state, validation, and governance models in a dynamic, unpermissioned way.
Additionally, because rollups partition their state cleanly, Layer 1 users may run verifiers for specific rollups or ignore them entirely. Rollups are opt-in. Like channels, rollups isolate failures to the participants, and the host chain continues unaffected. Users sync only the rollups and rollup states they care about and don’t need to worry about others. Rollup validation is localized to those who want to participate rather than global across all nodes. Like any dApp, rollups compete with other L1 users for block space. However, they will use less L1 gas on average than if the same transactions were being executed on L1. Furthermore, L1 users do not pay any rollup-specific costs unless they are using it.
Essentially, rollups provide a sandbox where the rules of the chain can be relaxed or adjusted for any purpose. This partition between rulesets is a powerful tool that allows us to use different verification models like validity or fraud proofs. It even allows users to parallelize transaction processing, e.g. by using UTXOs. Instead of moving an application to a completely different L1, dapps can use an execution model that fits them better while still benefiting from the network effects of the Ethereum ecosystem. In other words, Rollups are not scaling solutions. Rollups are encapsulated & scalable state models, at the cost of partitioning the L1 validator set.
In case there are any lingering doubts, consider (as a thought experiment) a rollup deployed on Mina: a succinct chain with validity proofs. Its blocks are all proven valid by an accompanying zero-knowledge proof. If we added a zk-rollup to it, we wouldn’t get any throughput benefits. The host chain already uses zero-knowledge validity proofs, so adding a rollup with validity proofs does not benefit it. Anything that the rollup does can already be done on the base chain.
On the other hand, adding an optimistic rollup to Mina might improve Mina’s throughput by allowing evaluation of new types of transactions that would be prohibitively expensive to prove in zero-knowledge. The ORU can verify things more cheaply than the base chain in the average case. From here, it’s easy to see that the benefits of a rollup come from the ability to adjust the validation rules and security model. Rollups themselves are a mechanism for changing the rules of the chain without the permission of the chain. They are not a silver bullet solution to scaling.
Part 3 - Tradeoffs
Rollup benefits come from partitioning the consensus set so that a smaller group of nodes can change the state and validation rules to increase throughput. Unfortunately, we can’t simply adjust some numbers and increase the throughput. We’ve already pushed our scalability to the point where we need to make a tradeoff to receive any benefits. Rollups are a tool for running new targeted rulesets on a host chain. While partitioning prevents the rollup from externalizing many of its costs to the L1, the cost of enforcing those rules still has to be paid. Participating in a rollup is strictly more expensive than participating in the base chain for all users. This is why we say rollups are not a scaling solution for the chain: they have a higher node cost.
Rollups embed their history inside the host chain history. To follow the rollup, a verifier must sync the host chain history as well. Because the host chain enforces the rollup rules, the rollup verifier must verify the host chain’s history as well. In effect, rollups require the verifier to run a full node on the host chain. Because the rollup verifier must run both a host chain node and a rollup node, rollups have increased hardware requirements for verifiers. A minimum-hardware node on the host chain cannot participate in rollups. And users who cannot run a host chain full node also cannot run rollup verifiers. In effect, rollups raise the entry fee its users pay for full participation, and therefore do not satisfy the definition of scalability. It provides a way to increase available resources, without requiring all node operators to buy new hardware.
For users who don’t plan to run a full node, using a rollup will feel very similar to using Ethereum today. An Infura-like service will provide state to users on demand. Wallets will be built to rely on these centralized providers like wallets do today. As is the case today, if there are problems with the rollup or the state providing services, a user can always sync a full node. However, they must pay the increased costs to sync the verifier alongside the host chain full node and wait until both have synced. In exceptional cases, this can result in user funds being inaccessible until they sync a node. Users can plan for this unlikely event by trusting a high-quality state provider or buying access to a cloud node.
Conclusion
Rollups increase throughput and functionality—but not the scalability—of L1 blockchains. They do this by allowing a subset of the L1 verifying nodes to verify specialized rollup state. However, there is no free lunch. Because their finalization must include L1 finalization, rollups can’t finalize faster than their host L1. In addition, the cost to validate a rollup is strictly higher than the cost of validating its host L1 chain (because it necessarily includes validating that chain).
Today, most users decline to operate a fully-validating L1 node, and as a result, we’ve seen a massive trusted state provider ecosystem form. Users have the choice of connecting to their node or trusting any of a number of providers. We can expect a similar ecosystem to appear to serve rollup state to rollup users that choose to trust rather than verify.
We are excited about rollups because they preserve desirable aspects of blockchains -- like guaranteed data availability and permissionless participation -- while allowing the rollup designer to cater the validation and security to the applications’ needs. Rollups will be able to host many applications that are currently too costly to run on Ethereum.