Scaling with Rollups — Optimistic and Zero-Knowledge

The last major upgrade of Ethereum called Proto-Danksharding moved Ethereum closer to a rollup-centric architecture by enabling blobs (Binary Large Objects).

Unlike platforms like Solana that scale by building high capacity into Layer 1 (L1), Ethereum plans to achieve scale by moving computation to Layer 2s (L2s). The concept is straightforward. Instead of executing and storing everything on the main Ethereum blockchain, execute and store many things on L2s and leverage the Ethereum consensus mechanism and security to ensure that the actions undertaken in L2 are valid.

The Solana strategy enables greater speed and efficiency. The downside is that the platform can hardly be described as decentralized. Since a few nodes build all blocks, the security is at greater risk of being captured by these few large validators.

Relying on L2s complicates Ethereum’s architecture but is worth the effort if decentralization and security are to be preserved.

What are Rollups?

L2s can be Rollups, Validiums or Plasmas. Today we’ll focus on Rollups.

Rollups operate off the Ethereum blockchain but are managed by smart contracts on-chain. They have 2 parts:

1. Off-chain Virtual Machine on which transactions are executed
2. On-chain smart contracts that store rollup blocks, transaction data, and state updates

Rollups benefit from the speed of an off-chain execution environment and the security of Ethereum’s consensus.

How do Rollups achieve scale and lower fees?

Rollups use several levers to increase scale and lower fees.

1. Off-Chain Execution — Blockchain capacity is used in (a) transaction execution and (b) data storage. Between the two, transaction execution is the real gas guzzler. Rollups save on gas by moving transaction execution to an off-chain Virtual Machine.
2. Bundling — Rollups bundle multiple transactions in one batch before posting to L1. The fixed cost of posting to Ethereum is amortized over all transactions in that bundle thus reducing fees.
3. Calldata — When posting to L1, the Rollup data is attached as Calldata or Blobs which are cheaper to store.
4. Data Compression — Before posting on L1, Rollups compress data so the required storage space is minimized.
5. Rollup fees — Validators on Rollups charge a fee (similar to gas fees on Ethereum). Fees however are much lower than on Ethereum, as Rollups have higher processing capacities and don’t face network congestion, which means that they don’t charge additional priority fees.

How are funds deposited into Rollups?

When tokens are deposited into Rollups, a bridge contract locks tokens on Ethereum, mints new tokens in the rollup, and sends them to the right rollup address.

Optimistic Rollups vs ZK Rollups

Rollups are broadly of 2 types — Optimistic and ZK.

Both rollup types relieve the load on the mainnet by executing transactions off-chain. Both are controlled by smart contracts on-chain that keep track of user deposits, rollup blocks, and state updates. The two however have different security mechanisms.

• Optimistic Rollups — assume that a block is valid unless it is challenged. They offer a monetary incentive to any operator who correctly identifies an erroneous block and penalizes the creator of that erroneous block.
• ZK Rollups — require Operators to use Zero-Knowledge proofs to prove that the blocks are correct before they are accepted by the mainnet.

Optimistic Rollups are easier to deploy and hence the largest Rollups today including Optimism, Arbitrum, and Base are Optimistic Rollups. Industry big shots like Vitalik Buterin however believe that in the long run, most rollups will be ZK Rollups.

A. Optimistic Rollups

Optimistic Rollups are called Optimistic because they optimistically assume that the block is valid unless challenged.

Computation capacity on Ethereum is an expensive resource. This approach ensures that no capacity is unnecessarily expended in proving the validity of transactions in a normal batch.

What prevents invalid blocks from being posted?

1. Carrot and Stick Incentive Structure

Batches are posted to the mainnet by Operators. Anyone can become an Operator as long as they post a bond. Once a batch has been posted to Ethereum, there is a period during which it can be challenged. If the challenge succeeds (i.e. the original batch is proven as faulty), the validator who posted the original batch (also known as “Assertor”) will be penalized by having its bond slashed. Part of the slashed bond will be transferred to the successful Challenger.

Challengers are other Operators monitoring posts. They execute the same submitted transactions and if they find a discrepancy between their execution and posted blocks, they compute a cryptographic proof that proves fraud. To discourage malicious challenges, Challengers also have to post bond which can be slashed if the challenge fails.

Note that valid blocks will advance as long as there’s even one honest node in the system to create rollup blocks and challenge invalid ones. The worst thing a malicious node can do is cause delays.

2. Operators forced to publish transaction data

An Operator is a centralized entity responsible for processing transactions and submitting rollup blocks to the mainnet.

• What happens if a validator goes offline and stops processing transactions?
• What if once your funds are on a rollup, the validator decides to prevent you from withdrawing funds by refusing to process your exit transaction and refusing to provide you with Merkle ownership proofs?

The above situations are prevented because Optimistic Rollups force validators to publish transaction data to the mainnet. While this uses up valuable space, it is a crucial step that provides security.

• If a validator goes offline, another validator can step in and take their place. They can reproduce the last rollup based on published data and continue block production.
• Users can use the published data to create Merkle proofs of ownership themselves and withdraw funds from the Rollup.

Multi-Round Interative Proving Mechanism

When a rollup batch is challenged, the Verifier smart contract re-executes the disputed batch on the mainnet. Executing every transaction in the batch on the mainnet is not only expensive but also there might not be sufficient space in an Ethereum block to execute all the transactions in a rollup batch.

The solution is to have a Multi-Round Iterative Proving mechanism. When a rollup batch is challenged, the Assertor divides the Assertion into two halves. The Challenger then selects one half that it wants to challenge. The Assertor subdivides the selected half again into 2 halves and the process continues till only one single step remains. The Verifier Smart Contract eventually has to execute only 1 step on the mainnet to validate if the challenge is valid.

Withdrawing funds from Optimistic Rollups

Depositing funds into Optimistic Rollups is easy but withdrawing funds is time-consuming. This is because while transaction execution is fast, transactions are not considered final and settled till the challenge period (of say 7 days) is over.

This is necessary for security. It won’t be possible to reverse the rollup state update after a successful challenge if assets have left the rollup.

Users can verify if their exit transaction has been included in the block by computing the Merkle Proof. This way they can be sure that the exit transaction has been processed even if they can’t access the funds till the end of the challenge period. Hence, the security of funds is not an issue, liquidity and capital efficiency is.

Some Liquidity Providers offer a service where they transfer funds to you immediately and withdraw from the rollup after a week.

B. ZK Rollups

ZK Rollups Operators execute transactions off-chain and submit Zero-Knowledge Validity Proofs on-chain proving that the off-chain transactions are valid. The L1 contract doesn’t assume that the batch is valid, it has proof that the batch is valid.

Zero Knowledge Proofs are a technology through which one can prove that something is correct, without revealing what that something is. In the case of ZK Rollups, it proves that transactions in a rollup have been correctly executed, without revealing what the transactions are or requiring L1s to execute them.

Once a new batch and the validity proof have been verified by the Verifier contract, the rollup state is updated. Verifier contracts verify validity proofs for each batch. This is unlike the Verifier Contract in the case of Optimistic Rollups which verify validity proofs only when there’s a challenge.

Posting transaction batches to the L1 smart contract only after confirming that they’re correct, has two major positive implications

1. Settlement Finality — Transactions are considered final immediately after they’re posted to L1. There’s no challenge period after which the transactions can be reversed. This makes it possible to withdraw funds from a ZK-Rollup immediately after an exit transaction has been processed.
2. Less transaction data needs to be submitted to L1- Since the L1 has zero-knowledge validity proof that the transactions in the batch are valid, very little transaction data (compared to Optimistic Rollups) needs to be submitted. This saves on expensive storage space in L1.

If transaction data is already verified, why do ZK-Rollups post any transaction data?

By posting a little transaction data, ZK-Rollups implement censorship resistance.

A malicious Operator may decide to censor transactions or prevent a user from withdrawing funds from the rollup. The transaction data submitted to L1 makes it possible for anyone to validate the chain themselves and allows anyone to submit batches if the Operator tries to censor transactions or freeze accounts. They also allow users to query balances, prove that a withdrawal transaction was included in a batch and initiate withdrawal of funds directly from the rollup without relying on the Operator.

ZK-SNARK vs ZK-STARK

Zero Knowledge Proofs are of 2 types

1. ZK-SNARKS (Zero Knowledge Succint Non-Interative Argument of Knowledge) — ZK-SNARKS is currently the more popular method as the creation and verification of proofs is easier. It however is less secure as it requires a trust ceremony to generate a Common Reference String (CRS). If the information used to create the CRS falls in the wrong hands, it can be used to generate false validity proofs. The way to get around this problem is to have multiple parties contribute to the creation of the CRS. If even one party destroys their input, the ZK-SNARK proof is secure
2. ZK- STARK (Zero Knowledge Scalable Transparent Argument of Knowledge) — is considered superior but is currently not being used extensively as proofs are more complicated, larger, and more expensive to verify. It however is more scalable, transparent, and quantum-resistant

• Transparent — It does not require a trust ceremony to create any CSR
• Scalable — It requires less time for creating and verifying large data sets making it ideal for apps requiring heavy computation.
• Quantum Resistant — If and when quantum computing becomes a reality, most cryptography will be at risk. Elliptical Curve Cryptography used in ZK-SNARK is known to be susceptible to quantum computing. ZK-STARK is quantum resistant.

Advantages of Optimistic Rollups over ZK Rollups

1. EVM Compatibility — Optimistic Rollups are EVM Compatible. ZK Rollups are not.

Assets can easily move between Ethereum and Optimistic Rollups. DApps (Decentralized Applications) built on Ethereum can easily be ported to Optimistic Rollups and new dApps can be created directly on Optimistic Rollups using Ethereum tools. This saves time for developers who can use Ethereum tools including programming languages, code libraries, testing tools, etc. Developers can also feel more secure as Ethereum tools have been battle-tested and well-audited.

ZK Rollups currently can handle only basic transactions like fund transfers from Alice to Bob. Creating validity proofs for complex EVM transactions is not yet feasible. This limits the dApps that can be deployed on these rollups which in turn limits the funds that are ported to the rollup.

=> Some progress has been made through zkEVMs to get to EVM compatibility.

2. Complexity and potential Centralization

Creating Validity Proofs is a technically and computationally complex task requiring specialized hardware. Therefore, few entities can offer Operator services to ZK-Rollups. This increases the possibility of centralization. The cost of creating and verifying validity proofs in ZK-Rollups is substantial and is passed on to users. Optimistic Rollups avoid this cost.

Advantages of ZK Rollups over Optimistic Rollups

1. Less data posted on Mainnet — Since validity proofs prove that the transactions are correctly executed, ZK-Rollups need to publish less transaction data on the mainnet and save on expensive storage space. Optimistic Rollups need to post more transaction data to make challenging blocks possible.

2. Settlement Finality — Transactions on ZK-Rollups are considered final once published to the main chain as validity proofs confirm their validity. Transactions on Optimistic Rollups on the other hand are not considered final till the challenge period is over. This is especially a problem when withdrawing funds from the rollup.

3. Recursive Proofs — Recursive Proofs are when one proof can verify an earlier proof. With ZK-Proofs, recursive proofs are possible. Currently, ZK-Rollups provide a separate proof for every batch. In the future, they will be able to use recursive proofs which means that it will be possible for multiple batches to be verified with one proof thus increasing throughput.

4. Fraud proofs are not live on most Optimistic Rollups — The security of transactions on Optimistic Rollups relies on the fraud-proof mechanism. Without it, nothing is stopping a malicious operator from posting invalid blocks. Among the largest Optimistic Rollups, Fraud Proofs are live only in Arbitrum. Optimism and Base don’t have fraud proofs yet.

Challenges for Rollups

Interoperability — Transferring tokens from one Rollup to another is not straightforward. One can’t just transfer from Optimism to Arbitrum by entering an Arbitrum wallet address. Funds will first need to exit Optimism, wait out the challenge period, and then be deposited into Arbitrum.

Liquidity fragmentation — Liquidity gets distributed among different Rollups which leads to higher slippage and suboptimal execution.

Most Rollups use a single sequencer- Sequencers control ordering and are the only entity allowed to submit blocks to the mainnet. The single sequencer cannot alter account balances or post invalid transactions but it decides the order of transactions, can delay transactions, and is in a position to extract MEV.

Conclusion

I see no reason for deploying blockchain technology if one is not preserving decentralization. Traditional financial infrastructure is far more efficient. Hence my preference for the L2 model. Each L2 will eventually have different levels of security and decentralization. Use cases like Social Media require less security than financial products like cross-border payments and lending.

A superchain with interoperable L2s is more secure than interoperable L1s. Vitalik Buterin explains why cross-chain applications between independent blockchains are inherently risky here.