Polygon Research: Ethereum Scaling with Rollups

Special thanks to Ed Felten, John Adler, and Georgios Konstantopoulos for review.

With the wide adoption of Ethereum, we see a steady increase in submitted transactions on Ethereum, leading to higher gas prices as transactions fight for limited space in the block. This has led to various Layer-2 (L2) solutions that aim to process a high number of transactions without compromising on security.

Among the many scaling solutions that have emerged in the recent past, Plasma has had the most promise. However, the development has proved to be tricky and it has been plagued with issues like mass exit scenarios, the data availability problem, and lack of support for arbitrary smart contracts. The limitations of Plasma have necessitated the community to come up with better solutions and in recent years, Rollups have gained traction.

So, what are Rollups?

In a nutshell, Rollups provide a neat way to bypass the problem of all Ethereum nodes having to execute all transactions present inside a block in order to verify whether only valid transitions are included. In Zero-knowledge based ZK-Rollups, transactions are executed off-chain and a validity proof that only valid transitions were accepted is provided on Ethereum. The low verification cost of ZK-Proofs allows smart contracts on Ethereum to verify hundreds of transactions without consuming much gas. This amortizes the on-chain cost per transaction to a very low value.

Optimistic Rollups, on the other hand, depend on fraud proofs in place of validity proofs. The execution still remains off-chain but a claim is put on Ethereum with a challenging period. Within this period, other operators can verify the claim and put forward a challenge or fraud-proof on-chain, in case they do not agree with the claim. An on-chain dispute resolution protocol decides which party is correct and based on that on-chain transaction finality is reached. Because each claim or challenge needs to be backed up by stake, malicious parties are disincentivized to provide incorrect claims or challenges.

Hmm, but which one is better?

The community has split opinions about which one of the two approaches is better. On one hand, ZKP is bleeding edge and while that holds much promise, it is hard to design ZK systems that can be deployed in practice. In the short term, there are many roadblocks to adoption. ZKP generation can take a significant amount of resources. There are tradeoffs between trusted setup, proof generation cost, and verification cost. For arbitrary smart contract transitions, designing the ZK circuit is cumbersome and proof generation extremely inefficient. All of these have contributed to the fact that no EVM-compatible ZK system has been deployed in production yet.

Optimistic Rollups today can support most Ethereum opcodes resulting in easier migration and the theory behind is much simpler compared to ZK. However, because of the lack of immediate finality, they suffer from liquidity challenges (which we discuss later). Optimistic Rollups also depend on censorship resistance for the security, unlike ZK Rollups which only depend on it for liveness.

While the two technologies fight for supremacy, if we were to bet for the long run, we would surely put our money on ZK-Rollups. Zero-knowledge research every day is pushing us closer to the aim of realizing efficient ZK-Rollups for arbitrary state transitions.

Enough technology. Tell me which is better for my money?

Both ZK Rollups and Optimistic Rollups today can handle financial transactions very well. However, from a user’s perspective, the experience will be fundamentally different. To better understand the differences, we first need to define finality in a rollup-centric world. Conventionally, a transaction is called final when it is known to be included in a block and its order cannot be changed. In a rollup world, users reach transactional finality as soon as they are confident of their outcome. In some scenarios, this is different from withdrawal latency which depends on when Layer 1 recognizes the transaction.

A user participating in a rollup needs the following wait times:

ZK Rollups:

After an operator picks up the transaction, the user needs to wait for off-chain proof generation, on-chain proof submission, and corresponding ZK verification and finalization on Ethereum. Both the finality and withdrawal latency is equal in such cases as the user can be confident of the outcome only after the proof is submitted and verified. For simple financial transactions, it might take tens of minutes to a few hours today. However, these timings vary greatly depending on the application, amount of batching, the complexity of transactions, etc.

Optimistic Rollups:

Liquidity providers can help by cooperating with operators and issuing tokens to users “immediately”. Such pools only help with fungible tokens but for NFTs, users have no option other than waiting for the entire challenge period. There are challenges in terms of generating the liquidity pool, matching withdrawers and depositors, etc., but existing production systems have already surmounted such challenges. As these systems see more adoption it will be interesting to see how they handle the issues in production.

Awesome! So Rollups answer all scaling challenges?

In the short term, rollups would significantly reduce the cost of transactions. Several rollup chains are already in the test phase and impressive with their results. Both the rollup variants have achieved hundreds to thousands of transactions per second. However, the numbers are not representative of the actual cost and nuances. The ZK Rollup systems are not general-purpose yet and are optimized for a single application. Often, ZK Rollups amortize the cost of proof generation resulting in very high TPS at the cost of delayed finality. One needs to look beyond the published numbers to understand the real potential of the systems and choose the one which best suits their use case.

In spite of the mind-boggling performance that these systems promise, there is a glass ceiling to the number of transactions they can process. Even if rollups execute thousands of transactions, they need to submit all transactional data on-chain. To reduce the cost, today we use calldata but there is an upper limit to the number of calldata that the Ethereum network can hold. As multiple rollups deploy on Ethereum and see mass adoption, this higher bound will impede the throughput.

Are we doing something about it?

Sure. In the next parts of this series, we will explore this area and discuss how the community is working towards addressing the issue. We are excited about the developments in this space and hope our readers will share the same enthusiasm.

Detailed view: