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.
(1) All Rollups using fraud-proof must accept the liveliness assumption. This assumption introduces a trade-off between security and challenge-period in Latency. In Arbitrum’s testnet case, they choose a challenge-period of 30 minutes, which is extremely short and practically unsecure. It means that a malicious operator could steal all Rollup SC funds in L1 by causing a 30-minute network congestion attack on Ethereum.
(2) Each time Loopring changes its functionality or data structure, a new setup ceremony is required. (The recent version uses a temporary internal setup ceremony.)
(3) For a circuit of 300k Tx/proof, Stark’s verifier requires 5M gas. However, the Stark circuit used by deversiFi costs more than 2M gas for about 150 Tx/proof. (For comparison: Plonk is 500k gas for proof of 300Tx, Recursive Plonk is 900k gas for 3000+ Tx, Groth16 is 300k gas for proof of 2000Tx).
(4) Prover’s time of normal Plonk is 2->14 minutes (depends on the number of Tx in the Block). For recursive Plonk, the time is double, but each proof requires x5->x10 in the number of provers. For Groth16 used in Loopring, the prover time is about 7 minutes.
(5) Optimal-case gas cost also depends on the functionalities of Rollups (transfer, exchange, or general-purpose), so it may not reflect the expense of Rollups correctly.
(6) In v1.0, Loopring requires more time to collect sufficient Tx for a block because they separate deposit, withdraw, settlement from each other.
(7) One of StarkWare solutions does not supply data on-chain but through a data-availability committee. However, the confirmation of this committee is put on-chain.
(8) For the prover cost’s problem, Zksync develops new Hardware (FPGA). For better maximum throughput, Zksync and Aztec improve the recursive circuit in Plonk.
(9) StarkWare have their own hardware for prover. They also focus on Stark’s solutions.
(10) 300 for Plonk, 800–3000 TPS for recursive Plonk.
(11) The Empirical throughput in ZK rollups depends on prover-time. For example, suppose that there are 50 provers: in Plonk (Zksync), the prover-time is about 720s for proof of 300Txs; therefore the Empirical throughput cannot exceed 50 x 300 / 720 ~20 tps. In Loopring’s case, 420s in prover-time are required to prove 2048 tx, limiting Empirical throughput at 50 x 2048/ 420=244 tps.
(12) The first mainnet version of Optimism’s Rollup costs 21k gas for each L2 Tx. However, the team promises an optimized version that costs 5k gas/ L2 Tx.
(13) Aztec provides private Txs which requires more call data.
User adoption: Rollups are considered novel and users are cautious about using this as-of-yet untested and unproven technology. Trade-offs aren’t always clear and the complex nature of this technology limits mainstream adoption.
Security: The choice in ZKP protocols, challenge period, and other factors all have a high impact in Rollup security. Analyzing and understanding these choices is not straightforward and auditing regular smart-contracts is challenging enough as it is without the added complexity of having these contracts embedded inside ZKP circuits. Auditing ZKRollup is a difficult task and requires skilled security experts.
Capital Requirement: Rollups, in their early phases, are expensive top operation while adoption is still lagging. Significant investment is required to launch a Rollup and keep it operating regularly for a small user set. In some cases, the capital requirement directly impacts the security of the L2 system. Building an economic system is necessary for the healthy operation of a rollup.
Rollup technology is a viable option for solving some of Ethereum’s most pressing scaling issues. There are multiple approaches to implementing and deploying rollups and given the complex nature and the multiple trade-offs, it is important to understand the various risks involved. Security, usability, cost, and throughput are all considerations teams deploying rollups or deploying DApps on rollups need to consider as they design their solutions.
Within this context, at Kyber Network we recognize the importance of providing users with faster and more cost-efficient methods of transacting, and we have therefore invested resources to research and build a rollup solution that will best serve Kyber Network’s future plans. We will be announcing more details in due course and we hope that in the meantime this post has provided you with a basic understanding and framework with which to evaluate rollup technologies.
By Trong Nguyen and Loi Luu