Transacting on Ethereum’s base layer has become extremely expensive as demand for block space has increased with the growth of the Ethereum ecosystem, while on the other hand, block space supply has remained the same. Interacting with DeFi applications can cost hundreds of dollars in gas and many end-users have effectively been priced out. Rollups aim to reduce some of this demand pressure on the base layer by moving transactions to a cheaper secondary layer (L2) where transactions can be carried out cheaply before proofs of these transactions are batched into single transactions and submitted to the base layer for settlement, thus requiring significantly less block space for any given number of transactions.
Rollups come in various flavors, each with its own set-off trade-offs across throughput, latency, security, usability, and operational costs. This blog post lays down a Rollup analysis framework around these trade-offs and analyses where the various Rollup implementations fit within this framework. We hope this can provide teams with a good starting point when considering which Rollup approach is best suited for their needs.
Since Ethereum’s inception, its throughput limitations have been well known and ETH2.0, with its sharded proof-of-stake structure, has always been envisioned as a solution to this scaling constraint. Although ETH2.0 launched Phase 0 with the beacon chain in December 2020, it is not before Phase 2’s launch a few years down the line where it can have a meaningful impact on scaling and throughput.
In the meantime, Rollups has emerged as the de-facto solution to alleviate some of the short-term scaling limitations. In a recent post, Vitalik presented his proposed roadmap for a rollup-centric Ethereum stating “the Ethereum ecosystem is likely to be all-in on rollups (plus some plasma and channels) as a scaling strategy for the near and mid-term future” and many teams have started working in earnest to deliver this roadmap. We encourage readers to read Vitalik’s comprehensive explainer on rollups here.
Rollups made great headway in 2020 with Fuel Labs and Optimistic launching the first versions of optimistic rollups on mainnet, Loopring accumulating more than 100M in TVL in ZK rollups, and Starkware introducing the Cairo toolchain to make Zero-Knowledge Proofs (ZKPs) more accessible to developers. We saw many breakthroughs in rollup technologies including Aztec and ZkSync introducing recursivity through advancements in PLONKs, and more are expected throughout 2021.
Building a separate layer on top of Ethereum is very complex and analyzing the current rollup implementations is not easy. Rollup teams advertise their solutions’ theoretical optimal performance and capabilities but information on the risks and trade-offs are not readily available. Let’s take a deeper look at how to analyze rollup trade-offs and risks and where the existing implementations fit within these risk models.
We formalize our approach to analyzing tradeoffs by defining and explaining the major considerations of a rollup: Security, Usability, Cost, Latency, Throughput, Capital, and User Experience. This allows us to measure the existing implementations against these characteristics, and we can get not only a granular picture of any particular rollup’s risks and tradeoffs but an overall picture of the current rollup landscape.
Criteria of Rollups:
Rollups derive their security (ie. the integrity and safety of users’ and operators’ assets in a rollup) from the underlying layer 1 blockchain they are built on (for the purposes of this blogpost, Ethereum). However, certain assumptions some rollups make as well as how they are set up also has bearing on their security.
- Honest watchtower assumption
This assumes that at least one available honest watchtower can successfully submit a fraud-proof to the L1 Smart Contract within the challenge period. This assumption introduces a trade-off between security and latency since the longer the challenge period, the more likely an honest watchtower is available to submit a fraud-proof, and vice-versa, the shorter the challenge period, the less likely an honest watchtower is available to submit a fraud-proof.
2. Mass Exit Assumption
This refers to the ability for all L2 users to successfully perform exit transactions to L1 within the mass exit period. This assumption introduces a trade-off with Capital Efficiency as operators’ funds are locked during the mass exit period.
In each Zk-Rollup, a ZKP protocol is employed as validity proof. ZKP systems wrap logics and relations checked inside a proof in the form of a circuit where every constraint is combined. ZKP protocol requires a predefined configuration called a “setup” between the prover (L2 operators) and the verifier (the Smart-Contract).
There are three main types of setup in Zk-rollup: Trusted Setup, Updatable Setup(CRS), and Transparent Setup. The choice of setup determines the trade-offs between Usability, Gas Cost, and Throughput.
- Trusted Setup. For Trusted Setups (such as Groth16), gas costs are lower, and the maximum throughput is higher. However, each circuit can then only support certain fixed functionalities. Additionally, a ceremony of the trusted setup is required each time the circuit is upgraded.
- Updatable Setup. For Updatable Setups (such as recursive Plonk), gas costs are higher while the maximum throughput is lower, but the main advantage is that customizable smart contracts can be introduced without modifying the circuit thanks to recursivity.
- Transparent Setup. For Transparent Setup (such as Stark): Gas costs when the L2 blocks are full are low, but in suboptimal cases where the blocks are empty, gas costs can be exceptionally high.
Full-EVM refers to a Layer 2 system’s full compatibility with existing smart contracts on the Ethereum mainnet.
2. Customizable Smart-contract
A restricted list of smart contracts can be customized and introduced by the Layer 2 clients. Through various tools, L2 users or partners can introduce their smart contracts in the form of a Zk-circuit that represents the logic of the smart contract although there will be limitations depending on the circuit (circuit might not support loops with unbounded iteration)
3. Fixed Functionality
Some DApps or smart contracts can be included, but the process must go through a system upgrade.
- Gas cost
- Optimal case gas cost: depends on the call-data costs and fixed costs.
- Sub-optimal case gas cost: depends on optimal case gas cost, fixed cost, and the probability of achieving the optimal case.
- Fixed cost: includes the cost for L2 Block header, L2 Block root’s storage, Zk-proof. When the demand is low (in sub-optimal cases), fixed cost dominates the txs’ expense.
2. Computation Cost
- Prover-time: In Zk-rollups, the prover requires significant time to generate the proof. Many heavy computations are included in the proving process in order to cover millions of constraints checked inside a proof. The prover-time of Zk-proof generally depends on the size of the circuit and the capacity of the hardware used in the proving process. It can vary from 2 to 14 minutes for Plonks, 7–10 minutes for Loopring v3.0, and 3–5 minutes for Stark. This is the main factor determining Zk-rollup’s hard finality latency.
- Prover cost: It is the resource consumed by provers to generate proofs. It depends on prover-times and the Empirical throughput.
- Hard-finality: Time for finalizing an L2 block. This duration links to the challenge period in Optimistic Rollup and the prover-time in Zk-rollup.
- Soft-finality: Time for submitting the L2 Block into L1:
- Withdrawal-time: some fast transaction approaches require the submission of the L2 Block before further processing.
- Maximum theoretical throughput: Based on gas-cost for on-chain operations and the maximum gas per block on Ethereum.
- Empirical throughput for Zk-Rollup:
1)The Empirical throughput depends on the prover-time.
2)There is a trade-off among prover-cost, Empirical throughput, and capital requirement. Better throughput requires higher prover-cost and higher capital requirement.
- Capital requirement: the fund deposited by operators inside the SC for system security.
- Capital efficiency: the fund of liquidity provider/operators locked inside the SC x locked time.