Introduction
Optimistic Rollup is a promising technology to expand general smart contracts on Ethereum in the short term. If built fast enough, it can provide a way to easily migrate existing dApps and services, and can reasonably weigh security and scalability. This will enable ETH1.0 to meet the growing demand.
ZK Rollup is a more complex technology. It can now be used for token transfers and specific applications. However, it will take longer to implement on general smart contracts, and even more research work is needed to efficiently wrap EVM in ZKP. (Blue Fox Note: ZKP refers to zero-knowledge proof)
However, once ZK Rollup is fully developed, all existing Ethereum dApps and services can be migrated smoothly and easily.
ZK Rollup will solve several basic problems on Optimistic Rollup:
Eliminate the annoying tail risk: steal funds through complex but feasible attack vectors;
Reduce the withdrawal time from 1-2 weeks to a few minutes;
Support fast transaction confirmation and exit with unlimited quantity;
Privacy is introduced by default.
Optimistic Rollup is good news for ZK Rollup. The transition to Layer 2 expansion requires major changes to wallets, oracles, dApps, and user habits. Optimistic Rollup helps prepare the ecosystem for this action, bringing scalability to these dApps that cannot be built on ZK Rollup. This gives ZK Rollup enough time to mature and enable it to achieve completely seamless adoption, while maintaining the growth momentum of Ethereum.
Rollup 101
*What is Rollup?
Rollup is a Layer-2 scalability solution similar to Plasma: a single main chain contract holds all funds and concisely encrypts the larger "side chain" state (usually the Merkle tree of accounts, balances and their states) committed to. The side chain state is maintained by users and operators off the chain, and does not rely on Layer 1 storage (this is the source of the biggest scalability victory).
What distinguishes Rollup from Plasma is that it solves Plasms' huge problem: data availability by publishing some data for each transaction through the Layer 1 network (in Ethereum, tx CALLDATA is used specifically for this purpose).
Therefore, thousands of transactions can be bundled together in a single Rollup block. Although the cost of this method strictly increases linearly (O(n) of the number of transactions), it can actually increase throughput by 100 times because CALLDATA is cheaper than Layer 1 storage and calculation.
Rollup has been repeatedly recognized by Vitalik Buterin as its favorite Layer 2 scalability solution. According to how to ensure the correctness of the state transition, there are two types of Rollup: ZK Rollup and Optimistic Rollup.
*What is ZK Rollup?
In ZK-Rollup, the operator must generate a SNARK (Blue Fox Notes: Succinct Non-interactive ARgument of Knowledge) for each state transition, which is verified by the Rollup contract on the main chain. This SNARK proves that there is a series of transactions correctly signed by the owner, these transactions update the account balance in the correct way and make the Merkle root from old to new. Therefore, it is impossible for operators to submit invalid or manipulated status.
*What is Optimistic Rollup?
In Optimistic Rollup, the new state root is released by the operator and does not need to be checked by the Rollup smart contract every time. Instead, everyone wants the state transition to be correct. However, if an incorrect state transition is issued, other operators or users (must observe the situation in the Layer 1 Rollup contract and execute each single transaction) will be able to point out the wrong transaction, restore the wrong block, and reduce The deposit of malicious operators. The concept of Optimistic Rollup was originally proposed by John Adler.
Next, let us compare ZK Rollup and Optimsitc Rollup.
Flexibility: universal computing
*Optimistic Rollup
Although Optimistic Rollup can be used for specific applications, the most important innovation of Plasma Group is OVM (Optimistic Vitual Machine). OVM supports the realization of arbitrary smart contract logic.
Almost anything that can be implemented on Ethereum can also be implemented on OVM, including the composability of smart contracts. It is based on EVM, EWASM or any other virtual machine. The good thing about OVM is that if it is used with EVM, it will support writing code in Solidity. Therefore, most of the existing code base can be easily ported to Optimistic Rollup.
If OVM can directly reuse the existing EVM bytecode, it would be an ideal choice, but it may not be that simple. The correct implementation will require changes to the transaction data (CALLDATA) format and the implementation of a complex Truebit/Plasma Leap style challenge/response protocol to provide fraud proof.
This may lead to disagreements with the EVM, leading to inability to handle edge cases correctly, which means that some work still needs to be done to adapt to the current OVM contract. Another challenge for implementation is that fraud proofs for large blocks may require more gas than the layer 1 block gas limit allows. Then, these fraud proofs must be broken down into multiple ETH transactions.
*ZK Rollup
To date, all existing ZK-Rollup implementations have focused on specific operations, such as token transfer or atomic swaps. There are several main reasons for this.
First of all, there is no effective technology that can be used for concise recursive proof combinations for different ZKPs, which requires the execution of different smart contracts to be aggregated into one block. Our best method is to use Groth16 (used by Coda) on the elliptic curve loop, which requires calculations on longer fields and is completely inefficient for large calculations.
Second, even if our fields are shorter, Groth16 will require a separate and trusted setup ceremony for each smart contract and each new version. Obviously, this is absolutely unrealistic. The only effective ZKP technology that does not require trusted settings is FRI-based STARKs. However, the verification procedure is concise only for a limited class of problems (which can be expressed as simple arithmetic circuits).
The STARK verification program must be executed at least once for each constraint of the proven calculation statement, which means that we cannot iterate the collection of heterogeneous smart contracts.
With the advent of SNORKs, everything has changed. SNORK is a new generation of ZKP based on a slightly different set of encryption primitives (the famous polynomial commitment scheme). It was first developed by Sean Bowe in Sonic, followed by PLONK and Marlin in the summer of 2019. All of these have one thing in common: although trusted settings are still required, they are now universal and updatable. Once done once, it can reuse it for any number of different programs at any time.
However, the Kate polynomial commitment scheme used in these proof systems still requires an efficient elliptic curve loop for recursion, which is currently not available. This is why we are excited about the latest completely concise and transparent (no trusted settings) proof systems, such as Halo, SuperSonic, Fractal, and the exciting things the Matter Labs team has been tossing about recently.
To make a long story short: the barriers to building a universal smart contract on ZKP have now been removed. ZK Rollup can fully support the same programming model as EVM, including seamless composability and interoperability. Although the learning curve for Solidity developers will not exceed one day, the initial contract may require a dedicated DSL. In the end, given the current pace of development of ZKP prover technology, we expect all existing ETH (even EWASM) contracts to be effectively transplanted with minimal effort.
Scalability & transaction cost
*Optimistic Rollup
According to John Adler, after EIP2028/Istanbul, the current estimate is about 4k gas per tx transfer.
This means that it is equivalent to about 100 tps.
Using BLS aggregation signatures, this number can rise to about 500tps at most (in order not to damage EVM compatibility, the tx parameter may be retained for a long time).
If EVM compatibility is destroyed, theoretically throughput may increase to the limit of ZKP.
Actual throughput limit (token transfer): 500tps
It might be pretty good now.
*ZK Rollup
The public data cost of each transfer of tx in Matter Testnet is currently 16 bytes, which will cost 272 gas after EIP2028/Istanbul.
In addition, there will be proof of amortization cost, which is expected to be approximately 300,000 gas.
Even if we assume the worst case, which requires 1 million gas to prove the cost, the estimated transfer limit will still exceed 2140tps.
In some discussions, one can hear people arguing that ZKP will incur a lot of computational overhead and is therefore expensive. In fact, the computational cost is negligible compared with the gas cost, which is the real bottleneck because of the decentralization of censorship resistance. We also expect that this factor will decrease significantly over time.
Actual throughput limit (token transfer): more than 2000tps-similar to the scale of Visa.
However, in many use cases, ZK Rollup will save even more, because large chunks can be omitted from the public data (provided by moving them to the ZK circuit) without the need to reconstruct the state transition increment.
The core insight is: Although Optimistic Rollup always requires users to post complete transaction input, in ZK Rollup, we can flexibly choose between the following two: 1) Transaction input minus witnesses who do not affect state transition 2) Transaction only Output. This choice can be implemented very elegantly without too much complexity.
Famous examples:
In multi-signature wallets, wallets with Argent-style account abstractions or decentralized exchanges, users need to submit signatures to obtain contract verification. These signatures are not necessary for incremental status updates and can be omitted from public data.
Contracts like Gnosis's Dfusion Dutch DEX require a large amount of data set input, which does not directly affect storage, but is only used to verify the calculation results.
*After ETH 2.0
Since any Rollup will be in a single shard, the cost of CALLDATA (and the cost of Rollup transactions) is unlikely to change much unless the bandwidth generally becomes cheaper.
Meta transaction
Both types of Rollup are very suitable for supporting meta-transactions and account abstraction.
Safety
*Optimistic Rollup
Unlike payment channels, all funds in Rollup are held by a single smart contract. Since Rollup is the most promising expansion direction, we should see a large number of users migrate among them, and a lot of value is concentrated in this type of contract. Holding assets worth tens of millions (or even billions) of US dollars, the Rollup contract is becoming a very attractive honeypot for well-known hackers. If there is an opportunity for an attack, then no matter how complex it is, there will be May try to proceed.
The safety model of Optimistic Rollup is based on two assumptions:
At least one honest node among n nodes executes all Optimistic Rollup transactions, and submits fraud proofs when invalid state transitions are issued;
The underlying Layer 1 network has strong censorship resistance
*At least one honest node participant in N nodes
For the first point, the realistic expectation is that only Rollup operators will actually monitor and execute transactions. Ordinary users have neither the motivation nor the technical ability to handle high-load transactions (if they can, where does the extension come from?) Fortunately, operators naturally have the motivation to check the correctness of each other's blocks, because they are based on invalid blocks. Assets will be reduced when building blocks on the site.
There are enough trusted participants, and it is a reasonable assumption that there is 1 honest node operator in N nodes. However, since the number of active participants is limited (a few hundred?), some complex attacks may include: targeting all operators’ infrastructure (very difficult but not infeasible), bribing/ransomware development engineers to secretly install malicious code, targeting Rollup software update distribution channels, etc., of course, may also be a combination of these attacks.
These attacks are difficult to achieve, but they should be actively defended, but they are more realistic than attacking Ethereum miners in the same way, especially because the successful attack on Optimistic Rollup will not be noticed until completion.
*Strong Layer 1 censorship resistance
The second assumption is the tricky one. In fact, the design of Ethereum provides an economic mechanism, which is very effective against ordinary censorship. However, when counter-mechanisms appear, these mechanisms cease to function. Attackers can create a fully automatic bribery mechanism to coordinate 51% attacks by miners, which prevents honest miners from including fraud proofs in their blocks.
Interestingly, for the participating miners, the direct cost of this attack is zero, and if it can be clearly attributed to censorship, it will not be included in the social cost of the angry community response. This part is also very tricky, because the mechanism provides reasonable denial for the participants of the attack: "Given the credible promise of the majority of attackers, if I don’t participate, my block will be discarded, so I must Do it not for profit, but to avoid loss."
Unfortunately, under PoW, this kind of attack is very realistic. There is no effective way to punish anonymous miners who participate. After turning to PoS, the community will be able to punish miners by reducing their pledge rights, if a broad social consensus is reached.
