Ethereum Rollups Technical Overview

Note: This post is supposed to be a high level overview of the current state of rollup scalability. I will try my best to include everything I can in this post. I plan on writing detailed posts for various sub-topics like Optimistic Rollups, Validiums, etc in the future, and will link to them here. This is also meant to be a working document, especially since the rollups ecosystem is evolving at a rapid pace.

The problem

- Ethereum chain is slow

- All nodes have to execute all the transactions happening on-chain by themselves, which means they have to re-execute around 8 years worth of transactions.

- If there is a weak node (eg something with a slower ssd) there is no way for it to keep up with the network.

- The load cannot be distributed between the nodes, and we limit ethereum's performance to the weakest node requirements (an active debate in the community)

One way to make Ethereum fast is to increase the hardware requirements for nodes to run the chain. for eg, solana

It is a tradeoff between decentralization and accessibility - you might want as many people in the world to be able to run the chain (ethereum's general stance)

One approach to solve scalability is sharding, but it was deprioritized in favour of rollup centric scaling. why?

Sharding

- Make many parallel chains that are interoperable and co-ordinated by beacon chain that provides staking and controls validators.

- Distribute all existing validators between all these chains so each validator secures the chain its assigned to.

- Eg: NEAR

Disadvantage of Sharding

- the economic security is split between shards.

- if 100 million USD is being used to secure a network, and there are 100 shards, then each shard is secured by 1 million USD.

- In Proof of Stake networks like ethereum, around 1/3 stake takeover will result in loss of finality and 2/3 takeover will result in complete takeover (rollbacks, etc)

Rollups

- Separate blockchains that prove their state with transactions on the L1.

- Has two way bridge built in the system

- Use proofs for L2 transaction validity(like ZK proofs)

What is a ZK Proof and why is everyone talking about it?

- Set of equations that allow you to prove outputs of some computations without actually having to run the execution, or access the inputs.

- Rollups can use either property (re-execution or private inputs) to prove that an execution happened on the L2.

- However, it is much harder to generate the proofs itself (orders of magnitude more difficult compared to verification) but it is very simple to validate them.

- We can outsource the proof generation to powerful computers, since it is still verifiable by anybody.

How does a ZK Rollup work?

A typical lifecycle of a rollup transaction is as follows:

- L2 transactions are batched, and a proposer submits it on L1 through calldata

- A sequencer reads this batch and re-executes it, and generates a ZK proof of this batch's validity and sends this proof on a Smart Contract on L1

- Smart Contract executes the proof, and if it is valid, updates the merkle root of the state and "finalizes" all the L2 transactions in the batch

Disadvantage of ZK Rollup architecture

- Calldata is limited, and hence, expensive

- There is an upper limit to how many L2 transactions we can store in one L1 block, because of gaslimit.

- Compression of the L2 state is useful, then we can fit many more L2 blocks on L1.

EIP-4844

- Introduces BLOBS

- it is a big amount of data that is stored separately from the blockchain

- It can be deleted later

- The blockchain only stores the hash of the commitment to the blob

- Currently, blobs are stored for 4096 epochs or ~18 days. After that, it can be safely discarded

- This give sequencers a lot of time to generate proofs so that it can be verified

- current blob size: 128KB

- number of blobs per block: 3 (will be increased in future)

Danksharding

- we can use the concept of execution sharding and apply it to data sharding.

- split all validators in groups and distribute all blobs to these groups equally

- all validators should store the blobs for certain amount of time. If the data is lost, then the validators get slashed

- validators outside of this group can make sure that the data isnt lost, by asking the validators for random small parts of the blob (Data Availability Sampling) and verifying its validity

- Number of shards: 64

- Number of blobs per block: 3*64 = 192

Rollup Scaling with danksharding

- You always need to prioritize compression of L2 state

- Danksharding will unlock huge performance gains on L2s

- There is a prover time bottleneck as well. The amount of time taken by a prover to generate a proof is the speed of the rollup.

Currently available Zk Stacks

- ZKSync: VM compatibility with Solidity and vyper

- Polygon zkEVM and Scroll: EVM compatibility

- Taiko: Entire Ethereum logic

There are also non-EVM rollups. Eclipse works on Solana VM, Fluent develops zkWASM, M2 is going to use Move VM which is used by Aptos and Sui, L1 blockchains. Starknet uses its own unique Cairo VM.

There are also different DA Systems, like Celestia, eigenda, etc, DAC, etc.

There are also decentralization levels associated with rollup stacks. Stage1, stage2, stage3.

Interoperability

- Is dependent on Fast Finality

- Most rollup stacks have training wheels in the form of finality delays. Scroll is 30 mins and xkSync is 24 hours

Consensus

- Forkability as a guarantee

- Currently rollups run centralized sequencers, have upgradable contracts, security councils backed by miltisigs, and other restrictions

Links:

- https://research.2077.xyz/blog/some-steps-towards-interoperability/

- https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016

- https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571