Time to meet Ethereum’s rollups

For non-technical readers: It is helpful to consider this concept before reading. There are several inter-changed terms. Layer 1 (L1) refers to the native blockchain, for example, Ethereum and Bitcoin. Mainnet also means layer 1, the environment where transactions are broadcasted, verified and recorded on the blockchain. On-chain means on layer 1; Layer 2 (L2) refers to a secondary network built on top of layer 1. Off-chain means out of Layer 1.

Every blockchain tries to balance the trilemma of decentralization, security and scalability. Among the ever-increasing L1 general-purpose blockchains, Ethereum is the one that has the most enriched ecosystem and enjoys the highest decentralization and security. But high fees and congestion are a bottleneck for scaling up. Even when Ethereum successfully makes its Merge to Proof of Stake, it cannot properly scale up until Sharding. The rollups, representing the L2 protocols for Ethereum, provide solutions to improve scalability. They are expected to co-exist with L1. I believe Ethereum’s L2 will create an even richer ecosystem and bring in new developers and users — those like me that can’t afford the gas fee can finally heavily use it. I also dare to say that if L2s are proved to be successful, they will make copycat L1 chains obsolete. If you are in the Ethereum ecosystem or holding ETH, rollup is a topic you have to understand.

What is a rollup?

To explain rollup, we need first to understand where Ethereum’s scalability problem comes from. Each block on Ethereum has a limit on how many transactions it can hold. When more transactions are to be processed than a block’s limit, the miners will choose the transactions with higher gas fees to transact first. I know this is not fair.

Making transactions on-chain is more expensive and time-consuming than off-chain because miners need to validate the transactions and broadcast them onto the blockchain. However, there are pros and cons. On-chain transactions enjoy the attributes that an L1 blockchain offers: security, immutability and transparency. Off-chain transactions are equivalent to web 2. They can be managed by a central entity and do not have the attributes of on-chain transactions.

Rollups execute the transactions off-chain and submit the transaction data on-chain. Transaction data is included in L1 blocks, which allows rollups to be secured by native Ethereum security. Here is a real-life analogy to interpret the relationship between rollups and L1.

Four friends dine together in a restaurant. Each of them takes different plates and drinks: Mark has a double round of beer, Lisa and Alice share the desert… When the waiter brought the bill, they wanted to split it exactly who had consumed what. Annoying people!!

In this example, let’s assume the restaurant is Ethereum. What’s important for the restaurant is to receive the correct amount of money from its customers.

In dealing with the bill situation, either the waiter or the four friends should be bothered to do the work. The waiter can calculate the cost of each one and use the POS machine to get them to pay, one by one. This is L1 transaction execution.

Or the four friends can make the waiter’s life easier. They calculate each one’s cost and split the costs by themselves. Collect the correct amount and hand it to the waiter. This is an L2 solution.

The final result is the same for the restaurant. It does not care who pays what, but it cares to receive the correct total amount. L2 transactions take the complexity off of L1 and submit the final results to L1 as final confirmation.

In this example, the restaurant knows if the guests pay the correct amount because it knows what they ordered. In the rollup, how can we know the transactions that happened on L2 are valid? Proof between off-chain and on-chain data is important here.

Apart from moving the transaction execution off-chain, rollups also “roll” a bunch of transactions in a batch and submit it to L1. In this way, the cost of publishing data on L1 is compressed, like delivering all the parcels of recipients in the same building in a run, rather than delivering one by one in different runs.

Now let’s get to the two main types of rollups.

ZK rollup

ZK-rollup is an off-chain protocol that executes transactions outside of Ethereum (L1) but commits off-chain transaction batches to an on-chain rollup contract. Once the transaction data is accepted on-chain, the transaction record is immutable and registered on the Ethereum blockchain. That said, ZK rollup is the execution layer — where transactions happen, and Ethereum is the settlement layer — where updated transaction data is recorded and broadcasted.

ZK is short for Zero Knowledge Proof, which allows you to prove the truth of a statement without sharing the statement’s contents or revealing how you discovered the truth. The Ali Baba cave is a wonderful case to explain it. I strongly suggest you go through this case before continuing reading.

From Wikipedia

Zero Knowledge Proof applied in ZK rollup means the on-chain verifier (Victor) can verify if the data submitted from L2 operator (Peggy) is true and correct, and the layer 2 operator (Peggy) can prove the submitted data’s integrity and correctness without revealing the contents of the transactions.

How does ZK rollup work?

In ZK rollup architecture, we have these components:

• On-chain main contract — stores rollup blocks, tracks deposits and monitors state updates
• On-chain verifier contract — verifies zero-knowledge proofs submitted by L2 operators
• Off-chain virtual machine — the execution environment for transactions on the ZK-rollup
• L2 operators — process transactions, aggregate them into batches, and submit to L1; submit the validity proof to the verifier contract on L1

ZK-rollups publish state data for every transaction processed off-chain to Ethereum. Ethereum makes this data available to all participants of the network as calldata. This data allows everyone to reproduce the rollup’s state and validate the chain. L2 transactions are finalized only if the L1 contract accepts the validity proof.

The workflow goes like this:

1. Users submit transactions.
2. L2 operators sequence and process the transactions and include them into batches to submit for L1.
3. L2 operators compute validity proof of the submitted transactions.
4. L1 verifier contract verifies the validity proof.
5. If the validity proof is valid, the submitted transactions are accepted and recorded on Ethereum. Ethereum guarantees that user operations cannot be reversed once finalized on L1

How does ZK rollup prove layer 2 transactions’ validity?

The ZK rollup uses a Merkle tree to compute and verify the Validity Proof. The L2 operators run a series of checks before accepting the transactions. If the checks are ok, they then execute the transaction and apply the state (accounts, balances, etc.) changes on the sender and receiver’s accounts, hash the updated account data and combine it with the Merkle proof to generate a new root. The new state root is the result of updates. The L2 operators submit these to L1.

The verifier contract on L1 verifies the proof’s validity by assessing the pre-state root reflecting the L2 chain’s last known valid state, post-state root reflecting the L2 chain’s newest state, batch root, and transaction inputs. In ZK rollup, the Validity Proof can confirm the correctness of off-chain state transitions without re-executing transactions on L1. If the verifier contract gives a positive result, the submitted transactions and data are accepted and confirmed on Ethereum.

Withdraw funds from L2

Withdrawal from L2 is fast and does not have a “freeze” period. Users initiate the withdrawal transaction by sending their assets to a specified account for burning. When the operator includes the transaction in the batch, the user can submit a withdrawal request to the on-chain contract.

Optimistic rollup

Optimistic rollup is an L2 scaling protocol for Ethereum that moves computation and state storage off-chain. It executes transactions outside Ethereum but posts transaction data to Mainnet as calldata. Its operators bundle multiple off-chain transactions and submit them to L1.

The difference to ZK rollup is how it proves the authenticity of off-chain transactions. Optimistic rollups are “optimistic” about the validity of off-chain transactions, assuming they are valid until someone jumps out and report a “fraud proof”.

How does Optimistic rollup work?

In Optimistic rollup architecture, we have these components:

• On-chain contracts — stores rollup blocks, tracks deposits, and monitors state updates
• Off-chain virtual machine — the execution environment for transactions
• L2 operators — process transactions, aggregate them into batches and submit them to L1

The optimistic rollup’s state is organized as a Merkle tree. The operator should compute a new state root for every state transition and submit both old and new state roots when posting batches. The rollup contract accepts new state roots from operators immediately after they are posted. However, it can later delete invalid state roots to restore the rollup to its correct state.

The workflow goes like this:

1. Users submit transactions.
2. L2 operators sequence and process the transactions and include them into batches to submit for L1.
3. A time window (challenge period) during which anyone can dispute the submitted transactions’ validity.

• If someone disputes an assertion, then the rollup protocol will initiate the fraud proof computation, re-executing transactions on L1 to detect fraud.
• If no one disputes, the submitted transactions and the new states will be recorded on Ethereum.

As seen in the workflow, Optimistic rollups rely on the fraud proof to authenticate L2 transactions’ correctness.

The challenge period brings a blocked time window when withdrawing assets from Optimistic rollups. It usually lasts 7 days.

Comparison of the two rollups

The common points of ZK rollup and Optimistic rollup are:

• They both execute the transactions off-chain and submit the transaction data to L1
• They both rely on operators
• They both use Merkle Tree for storing and tracking changes of states
• They both publish calldata on Ethereum, compressing the cost for users

Their differences are:

• how to prove the validity. ZK rollups use Validity Proof and Optimistic rollups use Fraud Proof, which delays users’ withdrawal from L2.
• ZK rollups require substantial computing and special hardware for producing and verifying validity proof; In Optimistic rollups, regular L2 nodes can make fraud proof.
• Optimistic rollup must post all transaction data on chain; ZK-rollups only have to post the minimal data required to rebuild the latest state
• Optimistic rollups are more EVM compatible than ZK rollups, allowing Ethereum developers to port native Ethereum smart contracts to rollups more easily.

Are there risks in rollups?

Yes, quite a few.

The most prominent risk to me is the power of operators. Both ZK rollup and Optimistic rollup rely on the operators to do all the crucial work. We have to rely on their integrity and trustworthiness for running the protocols. This makes the whole system very centralized. A truly decentralized system should be one that does not need to trust the operators, eliminating human factors.

Is there autonomy for users to withdraw funds from L2 without the operators? Withdrawal requires you to present the Merkle proof of your state. Is there a way or a dapp for doing it?

Are the L2 bridges stress tested enough? Does the model of bridges have a fatal design that can lead to the exploits of liquidity?

Are there critical vulnerabilities in constructing the validity proof? These will be the targets of hackers.

Closing thoughts

The prospective benefits that rollups can bring to Ethereum are massive and will help the mass adoption. However, the tech is complex, and there are technical and human vulnerabilities for potential attackers to exploit. As a user, even though I’m bullish about it, I move only funds I “afford to lose” to rollups at the moment. We are still early.