With Ethernet Square development of eco-pull people’s demand for blocks of space to grow, trading on Ethernet Square base layer becomes extremely expensive. However, the supply of block space remains unchanged. Interacting with DeFi applications requires paying hundreds of dollars in gas fees, which discourages many end users. Rollup aims to transfer user transactions to the lower-cost Layer 2 for execution, and then package the proofs of these L2 transactions into an L1 transaction in batches and submit them to Layer 1 for settlement, thereby greatly reducing the occupation of block space , To ease the demand pressure on Layer 1.
Rollup is divided into multiple types, with different trade-offs in throughput, latency, security, versatility, and operating cost. This article develops a Rollup analysis framework around these trade-offs, and analyzes why this framework is suitable for different Rollup implementations. We hope that this framework can provide a basic reference for project parties to choose Rollup solutions on demand.
Introduction
Since the birth of Ethereum, its throughput limitation has been a well-known problem. ETH 2.0, which adopts the proof-of-stake and sharding mechanism, has always been regarded as a solution to the scalability problem. Although ETH 2.0 launched Phase 0 and launched the beacon chain in December 2020, it cannot effectively alleviate scalability and throughput issues before Phase 2 is launched.
At the same time, Rollup has actually become a short-term solution to alleviate scalability issues. In a recent article, Vitalik proposed a Rollup-based Ethereum roadmap, saying that “the Ethereum ecosystem may completely rely on the Rollup solution (and some plasma and state channels) to achieve scalability in the short and medium term.” Many teams have already begun to work hard to achieve this roadmap. Click here to read Vitalik’s comprehensive analysis of Rollup.
Rollup has made great progress in 2020: Fuel Labs and Optimistic released the first version of Optimistic Rollup on the main network; Loopring’s ZK-Rollup has a total lock-up volume of more than 100 million US dollars; Starkware launched the Cairo tool chain, which is convenient for developers Use zero-knowledge proof technology. We have seen many breakthroughs in rollup technology, including the introduction of recursive computing capabilities by Aztec and ZkSync by improving PLONK. In 2021, we will see more progress.
Building a separate layer on the basis of Ethereum is very complicated, and it is not easy to analyze the existing Rollup implementation. The Rollup team is vigorously promoting the theoretical best performance and functionality of its solution, but little information about its risks and trade-offs is known. Let’s take a closer look at how to analyze Rollup’s trade-off relationships and risks, and how well existing implementations conform to these risk models.
Analysis framework
We defined and explained the main considerations of Rollup—security, versatility, cost, latency, throughput, capital requirements, and user experience—and built an analysis model of trade-off relationships on this basis. We can use these characteristics to evaluate existing implementations, so that we can not only understand the risks and trade-offs of each Rollup from the micro level, but also grasp the overall situation of Rollup from the macro level.
Rollup’s metrics:
safety
The security of Rollup (that is, the integrity and security of the assets stored in Rollup by users and operators) relies on the underlying Layer 1 blockchain (this article refers specifically to Ethereum). However, certain assumptions of some Rollup schemes and the way they are constructed are also related to safety.
- Honest watchtower hypothesis
The assumption is that at least one honest “watchtower” can successfully submit the fraud proof to the Layer 1 smart contract during the challenge period. This assumption introduces a trade-off between security and latency, because the longer the challenge period, the higher the probability of an honest watchtower submitting a fraud proof; conversely, the shorter the challenge period, the lower the probability.
- Bulk exit hypothesis
This assumption assumes that all Layer 2 users can successfully execute exit transactions during the batch exit period. This assumption introduces a capital efficiency trade-off because the operator’s funds are locked during the batch exit period.
- Setup
Each ZK-Rollup scheme uses a zero-knowledge proof protocol to create a proof of validity. The zero-knowledge proof system encapsulates the logic and relations that a proof needs to check into a circuit that can satisfy all constraints. The zero-knowledge proof protocol requires a predefined configuration called “start-up settings” between the prover (Layer 2 operator) and the verifier (smart contract).
Zk-Rollup mainly has three types of settings: Trusted Setup, Updatable Setup (CRS) and Transparent Setup.
- Trusted setting: Under this setting (such as Groth16), the gas cost is lower and the maximum throughput is higher. However, each circuit only supports certain fixed functions. In addition, every time the circuit is upgraded, a trusted setup process needs to be completed.
- Updatable setting: Under this setting (such as recursive Plonk), the gas cost is higher and the maximum throughput is lower. However, the main advantage of this setting is that custom smart contracts can be introduced without modifying the circuit, all thanks to recursion.
- Transparent setting: Under this setting (such as Stark), when the Layer 2 block is filled, the gas cost is very low, but in non-ideal situations like empty blocks, the gas cost will become abnormally high.
Versatility
- Fully compatible with EVM
Fully compatible with EVM means that the Layer 2 system is fully compatible with the existing smart contracts on the Ethereum mainnet.
- Custom smart contract
The Layer 2 client can customize and introduce a limited number of smart contracts. Layer 2 users and partners can use various tools to introduce their smart contracts in the form of zk-SNARK circuits (representing the logic of smart contracts), but the circuits will bring limitations (circuits may not support infinite iteration loops).
- Fixed function
Some dApps or smart contracts can be added, but they must be implemented through system upgrades.
Operator’s cost
- gas cost
- Optimal gas cost: depends on call data cost and fixed cost.
- Suboptimal gas cost: Depends on the optimal gas cost, fixed cost and the probability of achieving the optimal gas cost.
- Fixed cost: Including the storage capacity of Layer 2 block header, Layer 2 block root, and the cost of zero-knowledge proof. When demand is low (in a suboptimal situation), fixed costs will account for the vast majority of transaction costs.
- Computing costs
- Prove time: In Zk-rollup, the prover needs a lot of time to generate the proof. The proof process requires a lot of calculations to verify the millions of restrictions in the proof. Generally speaking, the prover time of zero-knowledge proof depends on the size of the circuit and the capacity of the hardware used in the proof process. If it is Plonk, the prover time may be 2 to 14 minutes; if it is Loopring v3.0, the prover time may be 7 to 10 minutes; if it is Stark, the prover time may be 3 to 5 minutes. This is the main determinant of Zk-rollup’s hard finality delay.
- The cost of the prover: The resources consumed by the prover to generate the proof depend on the prover time and empirical throughput.
Final delay
- Hard finality: the time it takes to finalize the Layer 2 block. For Optimistic Rollup, this time is the length of the challenge period; for Zk-rollup it is the prover time.
- Soft finality: the time it takes to submit a Layer 2 block to Layer 1.
- Withdrawal time: Some fast transaction schemes need to submit the Layer 2 block before further processing.
Throughput
- Theoretical maximum throughput: Based on the gas cost of operations on the chain and the maximum gas of each block on Ethereum.
- Empirical throughput of Zk-rollup:
1) The empirical throughput depends on the prover time.
2) Prove that there is a trade-off between cost, empirical throughput, and capital requirements. Higher throughput requires higher certification costs and capital requirements.
user experience
- Is the experience similar to using Ethereum?
capital
- Capital requirement: The funds stored by the operator in the smart contract to ensure the security of the system.
- Capital efficiency: The funds locked in the smart contract by the liquidity provider/operator within x time.
(1) All Rollups using fraud proofs must accept the liveness assumption. This assumption introduces a trade-off between safety and latency (reflected in the length of the challenge period). Arbitrum’s testnet case set the challenge period to 30 minutes, which is very short and actually not safe. This means that malicious operators can launch a 30-minute network congestion attack on Ethereum, and then steal all funds in the Rollup smart contract on Layer 1.
(2) Every time Loopring changes its function or data structure, a new setting is required. (The latest version of Loopring uses an internal temporary kick-off ceremony.)
(3) In terms of a circuit that generates a proof for every 300,000 transactions, Stark’s verifier needs 5 million gas. However, the Stark circuit used by deversiFi generates a certificate for every 150 transactions, which requires more than 2 million gas. (In contrast, Plonk generates a certificate for every 300 transactions and requires 500,000 gas; recursive Plonk generates a certificate for every 3000 + transactions and requires 900,000 gas; Groth16 generates a certificate for every 2000 transactions, which requires 30 Million gas).
(4) Regular Plonk’s prover time is 2 to 14 minutes (depending on the number of transactions in the block). If it is a recursive Plonk, the prover time will double, but to generate a proof requires 5 to 10 times the number of provers. If it is Groth16 used in Loopring, the prover time is about 7 minutes.
(5) The optimal gas cost also depends on the function of Rollup (transfer, transaction or multi-purpose), so it may not correctly reflect the cost of Rollup.
(6) In version 1.0, Loopring needs more time to collect enough transactions and package them into a block, because deposits, withdrawals and settlements are all independent of each other.
(7) One of StarkWare’s solutions does not provide on-chain data, but introduces a data availability committee. The confirmation of the Data Availability Committee will be on the chain.
(8) In order to solve the problem of the cost of the prover, Zksync has developed a new hardware (FPGA). In order to increase the maximum throughput, Zksync and Aztec improved the recursive circuit in Plonk.
(9) StarkWare has specially built hardware for the prover, and is also committed to developing Stark-based solutions.
(10) The tps of Plonk is 300, and the tps of recursive Plonk is 800 to 3000.
(11) The empirical throughput of Zk-rollup depends on the prover time. For example, suppose there are 50 provers: In Plonk (Zksync), the prover time is about 720 seconds (one certificate is generated for every 300 transactions), so the empirical throughput cannot exceed 50 x 300/720 ~ 20 tps. In Loopring, the prover time is 420 seconds (one proof is generated for every 2048 transactions), so the empirical throughput is 50 x 2048/ 420=244 tps.
(12) In Optimism ‘s first Rollup mainnet version, each Layer 2 transaction requires 21,000 gas. However, the team promised to provide an optimized version that will reduce the gas cost to 5000.
(13) The privacy transaction provided by Aztec requires more call data.
The published theoretical performance of each Rollup scheme
StarkWare
–Judgment criteria–The optimal throughput has been published 3000 tps The number of transactions that can be accommodated by a single certificate has been published 300.000 The time of the public prover is 3-5 minutes Undisclosed Fixed cost 2-5 million gas Undisclosed delay 6-12 hour
Note: Due to the high fixed costs, Stark’s Rollup solution needs to collect enough transactions to batch process them and generate proofs. Therefore, in the early stages of StarkEx, the delay mainly depends on the transaction collection time.
Zksync
–Judgment criteria–It has been disclosed that the tps of the optimal throughput Plonk is 300; the tps of the recursive Plonk is 800 to 3000. The number of transactions that can be accommodated by a single public proof is that Plonk generates one proof for every 100 transactions; recursive Plonk generates one proof for every 315 transactions. The gas cost of undisclosed fixed cost Plonk is about 500,000; the gas cost of recursive Plonk is about 900,000. Undisclosed prover time Plonk’s prover time is 4 to 12 minutes. The cost of an undisclosed prover cannot be derived from on-chain data. Undisclosed empirical throughput is undisclosed.
Loopring
–Judgment criteria–The optimal throughput of 2150tps has been published. The number of transactions that a single certificate can hold. 2048. The time of the prover has been published for 7 minutes. The fixed cost of 300,000 gas has been published. Undisclosed empirical throughput. Undisclosed. Undisclosed and credible. The new version is set by default. A public ceremony is not public. The cost of validators cannot be launched through on-chain data.
Remarks: The use of zk-SNARK technology means to accept the assumption of a trusted start-up setting, that is, all parameters in the setting should be permanently hidden. If we generate credible start settings through the process, as long as at least one participant of the process completely destroys its toxic waste, this assumption will not be broken.
Arbitrum
–Judgment criteria–The optimal gas cost has been disclosed~ 2000 gas The optimal throughput has been disclosed 390 tps The challenge period has been disclosed 30 minutes on the testnet Undisclosed The upper limit of protected funds has not been officially announced
Note: In the Optimistic Rollup/Arbitrum solution, if a Layer 2 operator launches a network congestion attack on Ethereum, it can steal funds. Therefore, the upper limit of funds protected by the Rollup scheme cannot exceed the cost of the attack. The longer the challenge period, the higher the attack cost.
Optimism
–Judgment criteria–undisclosed optimal gas cost ~ 5000-21000 gas undisclosed optimal throughput 50-200 tps undisclosed challenge period undisclosed undisclosed protected funds upper limit not officially announced
Note: Optimism did not provide any specific analysis on its Rollup program.
Fuel
–Judgment criteria–The optimal gas cost has been disclosed~2000 gas The optimal throughput 500 tps has been disclosed The challenge period has not been disclosed 2 weeks The upper limit of protected funds has not been officially announced
Note: The mainnet Rollup browser stops on the third Layer 2 block. There is no follow-up information for this version.
challenge
User adoption rate : Users are usually cautious about new technologies like Rollup that have not been tested and verified. Unclear trade-offs and complexity limit mainstream adoption.
Security : Factors such as the choice of zero-knowledge proof protocol and the challenge period have a great impact on the security of the Rollup solution. Analyzing and understanding these choices is not easy. Although there is no complexity brought by the embedded zero-knowledge proof circuit, auditing conventional smart contracts is inherently challenging. Auditing the Zk-rollup program is a very difficult task, and only very good security experts can do it.
Funding requirements : In the early stages, the cost of Rollup is high, but the adoption rate has been low. Creating and running Rollup regularly for a small number of users requires a lot of money. In some cases, funding requirements directly affect the security of the Layer 2 system. Therefore, in order to ensure the healthy operation of Rollup, it is essential to establish an economic system.
to sum up
Rollup technology is one of the feasible solutions to the scalability problem of Ethereum. There are many ways to implement and deploy Rollup. In view of the complexity of the technology and multiple trade-offs, we need to understand the related risks. For those teams deploying Rollup and dApps on Rollup, security, availability, cost, and throughput are all factors that need to be considered when designing solutions.
In this context, Kyber Network recognizes the importance of providing users with economical and fast trading methods. Therefore, we have invested a lot of resources to research and build Rollup solutions to better serve our future plans. We will announce more detailed information in due course, hope this article can help you understand and evaluate Rollup technology.