A zero to 100 explanation of how Ethereum rollups work

This guide is intended to cover everything you need to know about rollups and how they work, in one place, with as little assumed knowledge as possible. We'll start with knowledge that > 90% of you already know, such as why scaling is needed, and very quickly delve into details that < 1% of the community fully grasps.

Because the guide is intended to cover everything all in one place, it's long. If you feel as though you already have a grasp on the basics, feel free to skip to some of the more advanced sections.

As the number of people using Ethereum has grown, the network has reached capacity. When this happens, costs for using the network go up, creating the need for scaling solutions.

The Ethereum network's (target) capacity is currently ~14 transactions per second (TPS). Any time there are more than ~14 TPS on the network, users will get into a bidding war to ensure that their transaction is prioritised. Only the top ~14 transactions each second, when ranked by how much they are willing to pay in fees, will have their transactions processed. In times of high congestion, this can lead to very high transaction fees as demonstrated in the graph below.

Ethereum cannot achieve its goal of becoming the world computer when it charges $20 per transaction. Vitalik claims that “the internet of money should not cost 5 cents a transaction,” implying that a transaction fee of even $0.05 is too high. Consider if you wanted to use Ethereum to buy a coffee, would you pay a $20 fee to purchase a $5 coffee?

The narrative used to be that blockchains could never scale and the industry was doomed. Fortunately, the narrative has shifted away from “whether or not blockchains can scale” to “which scaling solution will win.” We'll examine what's emerging as a potential winner: Rollups. Ethereum needs scaling solutions, like rollups, to bring its transaction fees way down or it risks being replaced by a more scalable competing blockchain network.

The Ethereum block gas limit sets the capacity of Ethereum by capping the maximum units of computation in each block. The block gas limit on Ethereum currently targets 15,000,000 units of gas per block. Each transaction on Ethereum costs a number of units of gas. A simple ETH transfer costs 21,000 units of gas, the more complex the transaction, the more units of gas it costs. The average gas cost of a transaction on Ethereum is currently ~90,000 units of gas.

The average Ethereum block can fit 15,000,000 / 90,000 = ~167 transactions. Blocks are produced on Ethereum every 12 seconds so we can calculate TPS as ~167 / 12 = ~14 TPS.

If the block gas limit sets the limit for Ethereum's scalability, why can't you just increase it? The short answer is you can, and we have. The long answer is 

When Ethereum first launched in 2015, it had a block gas limit of 5,000 units of gas. It has since been increased on 13 different occasions to where it sits today with a target limit of 15,000,000 units of gas and can increase to 30,000,000 units of gas during very high congestion. You can also increase Ethereum's capacity by keeping the block gas limit the same but reducing the units of gas it costs for a transaction.

the blockchain can process lots of transactions, measured in TPS.

Scalability

the blockchain is run by many “trustless” nodes across the world, not run by a small group of centralised “trusted” nodes.

Decentralisation

the blockchain is resistant to attack even if there are malicious nodes in the network. Ideally, it should be able to handle up to 50% of nodes being malicious.

Security

Most blockchains can achieve at least two of three desired properties but achieving all three is extremely difficult. Generally, optimising for one property comes at the cost of another.

Ethereum optimises for security and decentralisation but is poor at scalability. Optimising for scalability by increasing the block gas limit comes at the cost of decentralisation. Ethereum is decentralised because the cost to run a node is minimal - you can run an Ethereum node on a Raspberry Pi. Increasing the block gas limit requires the nodes to verify transactions more quickly and store more data over time, raising the computational power and storage requirements to run a node. If the block gas limit is increased too much, you might no longer be able to run an Ethereum node on a Raspberry Pi, instead, maybe only large companies with access to enterprise-grade hardware can run nodes. This would mean less decentralisation.

Many blockchains have been willing to make these trade-offs. Binance Smart Chain is a blockchain that optimises scalability and security at the cost of decentralisation. Polkadot and Avalanche are blockchains that optimise scalability and decentralisation at the cost of security.

Ethereum has been unwilling to trade-off either its decentralisation or security and has instead focussed on developing scaling solutions capable of optimising for all three.

Another way to scale a blockchain on-chain is sharding. Sharding is the process of splitting a database horizontally to spread the load. In an Ethereum context, sharding could reduce network congestion and increase TPS by creating new chains, known as “shards”. This would lighten the load for each validator who is no longer required to process the entirety of all transactions. This, in theory, achieves scalability without sacrificing security or decentralisation.

Ethereum's initial scaling roadmap proposed the creation of 64 shard chains, each with separate execution, state, smart contracts, balances, etc… However, this solution introduces unnecessary complexity, a worse user experience and new attack vectors. Additionally, shuffling validators between shards is very difficult.

Ethereum has abandoned the concept of sharded execution chains from its scaling roadmap in favour of Danksharding (named after its creator Dankrad Feist), where there is only one execution chain and the other Shards are for storing blobs of data only.

However, even Danksharding is incredibly complex. For now, Ethereum will focus on even simpler solutions such as Proto-Danksharding (named after its creators Protolambda and Dankrad Feist). Vitalik jokingly asked at ETHCC 2022 “should we cancel sharding?” after demonstrating how much TPS could be achieved with Proto-Danksharding alone. Proto-Danksharding stores blobs of data on Beacon nodes instead of separate shard chains and introduces a separate fee market for storing the blobs.

Sharding is its own complex topic which we won't cover in this research piece.

Off-chain scaling is the concept of achieving scalability without modifying the main blockchain protocol and therefore without compromising the core protocol's scalability or security.

From now on we will refer to the main Ethereum blockchain / mainnet as Layer 1 (L1).

State Channels, Optimistic Rollups and Zk-rollups derive their security directly from the Layer 1 and will now be referred to as Layer 2 (L2) solutions.

Sidechains, Validiums and Plasma chains derive their security separately from the Layer 1 and whilst they are off-chain scaling solutions, they are not considered Layer 2 solutions.

State Channels and Plasma chains are mostly outdated scaling solutions as newer, better solutions have been developed. We won't focus much on these. The Raiden Network is an example of a State Channel on Ethereum and Omise Go was an example of a Plasma chain.

Sidechains were one of the first Ethereum scaling strategies and are still extremely popular today. Let's take a look at sidechains.

The most popular sidechain network is Polygon POS. Sidechains are completely separate blockchains connected to Ethereum via a 2-way bridge. Sidechains have their own consensus, block production, validators and design considerations. The purpose of sidechains is to help scale Ethereum and so their focus is on maximising throughput. Sidechains are willing to make the tradeoffs in decentralisation and security that Ethereum is not.

Sidechains put users in control of the tradeoff-making decision. If you value security and decentralisation, stick to mainnet, if you're willing to make the tradeoff, use the sidechain.

Sidechains are by design less secure than mainnet Ethereum. They might not be best for billion-dollar DeFi protocols but for low-value transactions, the popularity of Polygon POS has demonstrated that many users are willing to make the compromise in exchange for lower transaction fees. As one of the first scaling strategies, sidechain networks have had a first-mover advantage. Polygon POS is still the most popular and transacted on Ethereum scaling solution.

What makes sidechains less secure than Ethereum?

Polygon POS is a Proof of Stake blockchain. It relies on the assumption of an honest majority of validators, if this assumption is broken, the network is open to a series of attacks including double-spending. Polygon POS at the time of writing has $3 billion worth of Matic at stake securing the network across 100 validators. This is compared to Ethereum's beacon chain which has $21 billion worth of ETH securing the network across ~500,000 validators. The cost of a 51% attack on the Ethereum beacon chain is ~$10.7 billion and would require control of 250,000+ validators. The cost of a 51% attack on Polygon POS would cost ~$1.5 billion and would require control of as few as 6 out of the 100 current validators.

Polygon's staking implementation is done at the smart contract level. All $3 billion securing the Polygon chain is held within a single upgradable smart contract. Upgrade permissions to the contract are controlled by a 5 of 8 multisig wallet, four key holders are from Polygon with the other four key holders chosen by Polygon. In theory, Polygon would only need to collude with one external party or the 4 external parties would only need to collude with one keyholder from Polygon, to drain the network's entire security budget making off with at least $3 billion in the process.

Additionally, moving assets between Ethereum and Polygon POS requires cross-chain bridging which is notoriously insecure. Many of the largest blockchain hacks have been a result of vulnerabilities discovered in cross-chain bridges. If a vulnerability was exploited on the Polygon POS bridge any assets you had bridged between the networks could be lost.

All of the above security compromises are by design in return for an increase in TPS. Polygon has received much criticism for the security tradeoff choices they have made. However, Polygon POS is not the only Ethereum scaling solution that Polygon offers. Polygon has utilised the capital they have obtained from their success with the Polygon POS chain to push forward the entire Ethereum scaling ecosystem including the development of the first zkEVM rollups. The Ethereum scaling ecosystem and rollups would not be as advanced as they are today without Polygon. Polygon gives users the choice to decide for themselves which scaling solution to use based on their judgement of how much security they are willing to trade-off.

But what if scaling could be achieved without compromising on security? Enter rollups.

As we saw with sidechains, as soon as you take block production and consensus of the chain's state off of Ethereum, the sidechain needs to rely on its own security model which is almost always going to be less secure than Ethereum.

But what if your new blockchain and each of its blocks were contained inside of Ethereum and validated by Ethereum's L1 validators with the full strength of Ethereum's $21 billion security budget, whilst still moving execution of transactions within blocks off-chain? This is rollups.

making sure that the transaction data is available to users and block producers (consensus nodes).

Data availability

ensuring nodes agree on the order of transactions included in a block.

Consensus

where execution layers verify proofs, resolve disputes, and transfer assets between execution layers.

Settlement

the layer where applications live and state is updated.

Execution

Ethereum is considered a monolithic blockchain. An Ethereum client like (pre-merge) Geth will handle all four key functions of the Ethereum blockchain. Rollups are modular blockchains that split the four key blockchain functions up between different blockchains depending on their implementations. We'll look at smart contract rollups.

Rollups rely heavily on the concept of compressing transactions. To understand rollups, we need to understand how an ETH L1 transaction looks. Below, we'll break down a randomly chosen ETH transfer transaction. If you know how to do this, you can skip to the next section.

Let's break down the following real transaction from the Ethereum blockchain. This transaction was chosen at random. This is a simple ETH transfer from one address to another. You can see the chosen transaction on Etherscan here:

https://etherscan.io/tx/0xe9ab7969753ac82c2135d57059989fd74b1bbc226142f98a66106bcbf2886596

First, we need to gather the raw transaction data for this transaction. This can be done for this transaction by providing the transaction hash to Etherscan's API using the following URL:

https://etherscan.io/getRawTx?tx=0xe9ab7969753ac82c2135d57059989fd74b1bbc226142f98a66106bcbf2886596

The raw transaction data (stored as hexadecimal) for this transaction is:

We'll convert it to JSON format to make it more human-readable as below:

{
    nonce: 0,
    gasPrice: 22400000000,
    gas: 21000,
    to: 0x76a031c079a0482b573eb53db867f3991d564d7f,
    value: 2032025600000000000,
    data: 0x0,
    V: 38,
    R: 0x1165e2adb7d5a1c3b26d872e0314019220139f3b42c2f10029e818e9654bc8b2,
    S: 0x337b4110eb2f65bc2afea40b36740ae6b162a68afe9dcd711fc8d46dfdf947f2,
}

A transaction counter that reflects how many transactions this address has previously sent. The nonce value is required to prevent replay attacks.

nonce

the amount of ether (in wei) willing to be paid for each unit of gas.

gasPrice

the maximum gas the originator is willing to buy for this transaction.

the amount of ETH to transfer from sender to recipient (in wei).

value

an optional field to include arbitrary data. 0x0 means no data.

data

the V, R & S fields form the signature and are generated when the sender's private key signs the transaction and confirms the sender has authorised the transaction.

V, R & S

together form the signature. Sig = (r , s).

R & S

the recovery identifier. Multiple (r, s) values on the elliptic curve can be derived without it. Also specifies the chain ID to prevent replay attacks on other chains. Calculated as CHAIN_ID*2+36. A value of 38 is used for Ethereum transactions (ETH mainnet CHAIN_ID = 1).

For the sake of demonstration, we'll convert from hexadecimal to binary to break the transaction down into its individual components and measure its size (you can use any hexadecimal to binary converter):

This transaction is 880 bits or 110 bytes which is approximately the size of any standard ETH transfer transaction. The binary is encoded using 

 (RLP) serialisation. You can use an RLP decoder to decode the transaction, however, we will decode the binary step by step to show the process below. If you don't care about understanding the breakdown you can skip to the Size Summary Table.

The first two bytes of an RLP encoded transaction are put there by the RLP encoder to assist in decoding the transaction.

The third byte will specify the size (in bytes) of the next value. The size is determined by taking the decimal value of the third byte and subtracting 128. For this transaction, the third byte equals 128 meaning that the nonce value is 128 - 128 = zero bytes or just 0.

The fourth byte specifies the size (in bytes) of the gas price. For this transaction, the fourth byte equals 133, meaning 133 - 128 = 5. Thus the gas price takes up the next 5 bytes worth of data.

The above process is repeated for the transaction as follows below.

If the value is only 1 byte long (e.g. V in our transaction), no size specifier precedes the value. You can know if the value is only 1 byte long as its value will be less than 128.

RLP encoded transactions are of the order: nonce, gasPrice, gas, to, value, data, V, R, S.

We can summarise the size of each value, including its RLP encoding component, of the transaction above as follows:

Understanding breaking down an Ethereum transaction is important as generally the larger the transaction size the more expensive it is to execute on the Ethereum network. Rollups can achieve the same Ethereum transaction whilst only sending ~12 bytes of data to the Ethereum network allowing for much cheaper transactions. We'll find out how this is possible later on.

Rollups are blockchains inside of a blockchain - hence the name rollup. Rollups store blocks for their blockchain within smart contracts on the L1. There are two types of smart contract rollups:

. Each rollup block contains transaction data for the transactions executed on the rollup chain. However, the transaction data is only stored as callData within the rollup smart contract on Ethereum, rather than being executed like a regular transaction. Execution of transactions is done on the rollup chain according to the transactions defined in the rollup blocks on Ethereum.

The minimum cost to conduct a transaction on the Ethereum blockchain is set at the protocol level as 21,000 units of gas (“the base gas fee”). Even the simplest of transactions, an ETH transfer, will cost 21,000 units of gas. However, storing bytes of data as callData on the Ethereum blockchain only costs:

16 units of gas per byte of non-zero data

4 units of gas per byte of zero data (i.e. 00000000)

As we recall, a simple ETH transfer is ~110 bytes of data. Storing a single ETH transfer transaction as callData rather than executing it only costs 110 * 16 = ~1,760 units of gas.

To create a rollup block with the above transaction, the base gas fee of 21,000 units of gas still needs to be paid, as writing the callData to the blockchain is executing a transaction. The rollup can produce a block with only one transaction in it, however, this will cost a total of 21,000 + ~1,760 = ~22,760 units of gas which is more expensive than just executing the transaction on Ethereum mainnet. However, most rollup blocks will contain more than 1 transaction per block and 

the genius of rollups is that the 21,000 gas base fee only needs to be paid once per block.

A rollup block with just 100 ETH transfer transactions would cost a total of 21,000 + ((110 * 16) * 100) = ~197,000 units of gas or just ~1,970 units of gas per transaction. Executing each transfer on mainnet would cost 21,000 * 100 = 2,100,000 units of gas in total or 21,000 gas per transfer. 

A basic rollup delivers a ~10x increase in TPS on ETH transfer transactions 

(equivalent to a 90% reduction in fees) whilst still relying on the full security and decentralisation of the L1.

Rollups can achieve much more than a 10x increase in TPS. The table below shows a comparison between storing an ETH transfer in a basic rollup vs a compressed rollup.

If we don't need to execute transactions on L1, we can remove redundant data and apply some clever compression tricks. We'll outline a theoretical transaction compression strategy originally proposed by Vitalik below.

- Rollups don't need RLP encoding and can save 10 bytes. RLP transactions ‘waste' two bytes with the RLP header and a byte specifying the size for each transaction parameter (even for parameters that don't exist). This can reduce the transaction size to ~100 bytes.

- Rollup transactions don't need a nonce. As the nonce is incremented by 1 for each transaction, it can be recomputed when needed for execution by looking at the prior state of the blockchain. Our transaction doesn't save any data by nonce omission as its nonce value is 0 (bytes). Any transaction with a nonce value greater than 0 would save data.

- Gas prices are stored in wei and are generally large numbers. In our transaction, it took 5 bytes of data to store a gas price of 22400000000. Instead, we could set gas based on a fixed range of prices. For example, choosing a Gas Price as 16 consecutive powers of two. By limiting Gas Price to only 16 possible values, you could store the gas price for only 0.5 bytes or less. This would reduce the transaction size to ~95.5 bytes.

- As above, this field could be limited to a small range of options. This saves a further 1.5 bytes, reducing the transaction size to ~94 bytes.

- The address field takes up a lot of data (20 bytes). Instead of storing the full address, rollups can store an index for a mapping of addresses stored elsewhere. E.g. send to the 1034th address in the mapping. By only storing the address index in the transaction, we can reduce the to field to ~4 bytes. The transaction is now ~78 bytes.

- The value field in an Ethereum transaction is priced in wei, making it a large number. We cannot omit the value field or reduce it to a fixed set of values. However, we can write it in scientific notation instead of wei to save on data. Using scientific notation will save a further ~5 bytes bringing the total transaction size down to ~73 bytes.

- The data field does not apply to an ETH transfer so it can be emitted entirely (however, it would be required on more complex transactions). This field was already omitted on our mainnet transaction, so no savings are recorded here.