Understanding ZK Rollup and Optimistic Rollup in one article: an important expansion direction of Ethereum
Editor's Note: This article comes fromBlue Fox Notes (ID: lanhubiji), reprinted by Odaily with authorization.
Blue Fox Notes (ID: lanhubiji)
Introduction
, reprinted by Odaily with authorization.
Foreword: Scalability has plagued public chains for years. Solutions for scalability are either in proof of concept or in R&D. Optimistic Rollup and Zk Rollup are also scalability solutions and have attracted great interest from the crypto community. So, what exactly are Optimistic Rollup and ZK Rollup? Which technical route will win the future of Ethereum scaling? No matter how tortuous the road is and whether the previous efforts are useful (such as plasma and other technical solutions), the expansion of Ethereum has been advancing, and it is not out of reach to meet the mainstream scenarios. The author of this article is Alex Gluchowski, translated by "JOKO" of the Blue Fox Notes community.
secondary title
Introduction
Optimistic Rollup is a promising technique for scaling general-purpose smart contracts on Ethereum in the short term. If built quickly enough, it can provide a way to easily migrate existing dApps and services, with a reasonable tradeoff between security and scalability. This will allow ETH1.0 to meet the growing demand.
ZK Rollup is a more complex technique. It can be used today for token transfers and specific applications. However, implementation on generic smart contracts will take a bit longer, and wrapping the EVM in a ZKP efficiently will require even more research work. (Blue Fox Note: ZKP refers to zero-knowledge proof)
However, once ZK Rollup is fully developed, all existing Ethereum dApps and services will be able to migrate over smoothly and easily.
ZK Rollup will solve several basic problems on Optimistic Rollup:
Reduced withdrawal time from 1-2 weeks to minutes;
Rollup 101
Privacy is introduced by default.
Rollup is a Plasma-like Layer-2 scalability solution: a single mainchain contract holds all funds and succinctly encrypts the state of a larger "sidechain" (typically a Merkle tree of accounts, balances, and their states) promise. Sidechain state is maintained off-chain by users and operators and does not depend on Layer 1 storage (which is where the biggest scaling wins come from).
secondary title
So thousands of transactions can be bundled together in a single Rollup block. Although the cost of this approach scales strictly linearly (O(n) in the number of transactions), it can actually improve throughput by a factor of 100 because CALLDATA is cheaper than Layer 1 storage and computation.
*What is Rollup?
Rollup is a Plasma-like Layer-2 scalability solution: a single mainchain contract holds all funds and succinctly encrypts the state of a larger "sidechain" (typically a Merkle tree of accounts, balances, and their states) promise. Sidechain state is maintained off-chain by users and operators and does not depend on Layer 1 storage (which is where the biggest scaling wins come from).
What separates Rollup from Plasma is that it solves the huge problem of Plasms: data availability, by publishing some data for each transaction through the Layer 1 network (in Ethereum, tx CALLDATA is used exclusively for this purpose).
So thousands of transactions can be bundled together in a single Rollup block. Although the cost of this approach scales strictly linearly (O(n) in the number of transactions), it can actually improve throughput by a factor of 100 because CALLDATA is cheaper than Layer 1 storage and computation.
Rollup has been repeatedly recognized by Vitalik Buterin as his favorite Layer 2 scalability solution. According to how to ensure the correctness of state transitions, there are two Rollup methods: ZK Rollup and Optimistic 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 that updated the account balance in the correct way and brought the Merkle root from old to new. Therefore, it is impossible for operators to submit invalid or manipulated status.
*What is Optimistic Rollup?
*Optimistic Rollup
In Optimistic Rollup, the new state root is published 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 (who must observe what is happening in the Layer 1 Rollup contract, executing every single transaction) will be able to point out the wrong transaction and revert the wrong block, reducing Deposits from malicious operators. The concept of Optimistic Rollup was originally proposed by John Adler.
Next, let's compare ZK Rollup and Optimsitc Rollup.
secondary title
Flexibility: General Computing
*ZK 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 implementation 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 nice thing about OVM is that if it is used with EVM, it will support writing code in Solidity. Therefore, most existing code bases can be easily ported to Optimistic Rollup.
It would be ideal if the OVM could directly reuse existing EVM bytecode, but it might not be that simple. A proper implementation would require a change to the transaction data (CALLDATA) format and require the implementation of a complex Truebit/Plasma Leap style challenge/response protocol to provide fraud proof.
This could lead to divergence from the EVM, resulting in edge cases not being handled correctly, which means some work still needs to be done to accommodate the current OVM contract. Another implementation challenge is that fraud proofs for large blocks may require more gas than the Layer 1 block gas limit allows. Well, these fraud proofs have to be broken down into multiple ETH transactions.
To date, all existing ZK-Rollup implementations focus on specific operations, such as token transfers or atomic swaps. There are several main reasons for this.
First, there is no efficient technique for combining succinct recursive proofs against different ZKPs, which requires aggregating the execution of different smart contracts into one block. Our best approach is to use Groth16 (used by Coda) on loops over elliptic curves, which requires calculations over long fields and is completely inefficient for large calculations.
STARK verifiers must execute each constraint of the proven computation statement at least once, which means we cannot iterate over collections of heterogeneous smart contracts.
Everything changed with the advent of SNORKs. SNORK is a new generation of ZKP based on a slightly different set of cryptographic primitives (the famous polynomial commitment scheme). Pioneered by Sean Bowe in Sonic, followed by PLONK and Marlin in Summer 2019. All of these have one thing in common: while a trusted setup is still required, it is now generic and updatable. After it's done once, it's ready to be reused for any number of different programs.
*Optimistic Rollup
However, the Kate polynomial commitment scheme used in these proof systems still requires efficient elliptic curve loops for recursion, which is not currently available. That's why we're excited about the latest fully concise and transparent (no trusted setup) proof systems like Halo, SuperSonic, Fractal, and the exciting stuff the Matter Labs team has been working on lately.
Long story short: the barrier to building general-purpose smart contracts on top of ZKPs has now been removed. ZK Rollup is fully capable of supporting the same programming model as EVM, including seamless composability and interoperability. Although the learning curve for Solidity developers should not exceed a day, initial contracts may require a dedicated DSL. Ultimately, given the current pace of development of ZKP prover technology, we expect all existing ETH (and even EWASM) contracts to be ported over efficiently with minimal effort.
secondary title
Scalability & Transaction Costs
According to John Adler, after EIP2028/Istanbul, the current estimate is about 4k gas per transfer tx.
This means, equivalent to about 100tps.
*ZK Rollup
Using BLS aggregated signatures, this number can go up to about 500tps (the tx parameter will probably be kept for a long time in order not to break EVM compatibility).
If EVM compatibility is broken, throughput could theoretically grow to the limit of the ZKP.
Actual throughput cap (token transfer): 500tps
It's probably fine for now.
The public data cost of each transfer tx in Matter Testnet is currently 16bytes, which will cost 272gas after EIP2028/Istanbul.
In addition, there will be an amortization fee for proof, which is expected to be approximately 300,000 gas.
Even if we assume the worst case and require 1 million gas to prove the cost, the estimated transfer limit will still exceed 2140tps.
In some discussions, people can be heard arguing that ZKPs are computationally expensive and therefore expensive. In fact, the computational cost is negligible compared to the gas cost, which is the real bottleneck due to censorship-resistant decentralization. We also expect this factor to decrease significantly over time.
Practical throughput cap (token transfer): over 2000tps - similar to the scale of Visa.
However, in many use cases, ZK Rollup will save even more, since large chunks can be omitted from public data (by moving them to ZK circuit proofs) without having to refactor state transition deltas.
The core insight is that while Optimistic Rollup always requires users to publish full transaction inputs, in ZK Rollup we have the flexibility to choose between: 1) transaction inputs minus witnesses that do not affect state transitions 2) transactions only output. This selection can be implemented very elegantly without much complexity.
Contracts like Gnosis' Dfusion Dutch DEX require massive dataset inputs that don't directly affect storage but are only used to validate computational results.
meta transaction
secondary title
Safety
*Optimistic Rollup
meta transaction
Both types of Rollup are well suited to support meta-transactions and account abstraction.
secondary title
Safety
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 to it, and a lot of value is concentrated in this type of contract. Holding tens of millions (or even billions) of dollars worth of assets, Rollup contracts are becoming very attractive honeypots for well-known hackers, and if an attack has the opportunity, no matter how sophisticated, there is Might try to proceed.
The security model of Optimistic Rollup is based on two assumptions:
1. At least 1 honest node out of n nodes executes all Optimistic Rollup transactions and submits fraud proofs when invalid state transitions are issued;
2. The underlying Layer 1 network has strong resistance to censorship
*At least one honest node participant among N nodes
For the first point, the realistic expectation is that only Rollup's operators will actually monitor and execute transactions. Ordinary users have neither the incentive nor the technical ability to handle high transaction loads (if they can, where does the scaling come from?) Fortunately, operators are naturally motivated to check the correctness of each other's blocks, because based on invalid blocks The above-built blocks will be reduced in assets.
With enough trusted participants, 1 honest node operator out of N nodes is a reasonable assumption. However, since the number of active actors is limited (hundreds?), some sophisticated attacks could include: targeting all operators' infrastructure (very difficult but not impossible), bribing/extorting development engineers to secretly install malicious code, targeting Rollup software update distribution channels, etc. Of course, it may also be a combination of these attacks.
These attacks are difficult to pull off, but should be actively defended against, but are far more realistic than attacking Ethereum miners in the same way, especially since a successful attack on an Optimistic Rollup will not be noticed until it is complete.
*Strong Layer 1 anti-censorship
The second assumption is the tricky one. In fact, Ethereum's design provides economic mechanisms that are very effective against ordinary censorship. However, when counter-mechanisms are present, these mechanisms stop working. An attacker could create a fully automated bribery mechanism to coordinate a 51% attack on miners, which would prevent honest miners from including fraud proofs in their blocks.
Interestingly, for the miners involved, the direct cost of the attack was zero, excluding the social cost incurred by the outraged community reaction if it could be clearly attributed to censorship. This part is also tricky, because the mechanism provides plausible deniability to the participants in the attack: "Given the credible commitment of the attacker majority, 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, such attacks are very real. There is no effective way to punish anonymous miners for participating. After moving to PoS, the community will be able to punish miners by cutting their stake, if a broad social consensus is reached.
After all, such a censorship attack could be seen as an aggression against the entire network, although it could also be argued that miners are simply following the protocol honestly and are not obliged to act in a manner contrary to their best economic interests.
However, after the DAO fork, it will be a very contentious discussion, to say the least, with an unpredictable outcome. In a recent community poll conducted by Vitalik, 63% of voters opposed any human intervention on an immutable blockchain to rescue users, regardless of the level of attack. Needless to say, it is very difficult to clear the rights and interests of even one validator (Blue Fox Note: here refers to the pledged funds), let alone clear the rights and interests of most validators.
More research on collusion has recently been published, as well as new attacks on fraudulent proofs in PoS environments, suggesting that the risk of censorship attacks in Optimistic Rollup is at least as high in PoS as in PoW.
*ZK Rollup
A more realistic way to resist this attack would be a quick mobilization of the community in UASF (User Activated Soft Fork) to force miners to include certain transactions. This scenario is complex from both an engineering and a social point of view, and will certainly require a relatively long challenge period window to provide proof of fraud, at least a week, preferably two weeks.
Overall, the risk of fraud proof review is relatively low, but not negligible.
trusted settings
Therefore, ZK Rollup more fully embodies the basic idea of the crypto world: to replace trusted parties through cryptography and game theory incentives to achieve resilience. However, for the sake of completeness, I must mention some potential risks specific to ZK Rollups.
Cryptography
trusted settings
If a ZKP used in a ZK Rollup requires a universal trusted setup, we will arrive at the assumption of "one in N" honest participants. Depending on the number and quality of participants, this may or may not be an acceptable risk. But security is security, which is why I'm very excited about the latest developments in efficient trustless SNARKs, especially what Matter Labs is building.
Cryptography
The latest generation of SNARKs is using more proven cryptographic primitives than Groth16. Matter Lab's work is based on FRI, so it can even be said to have post-quantum security. However, to completely calm down, two mitigation strategies should be applied:
*Optimistic Rollup
*Similar to the RSA challenge, large bounties must be deployed with lower security parameters than the actual product version. If an actual attack is discovered, researchers overcome the challenge years before production code is compromised.
*All state transitions must be sent only by the operator of ZKR, which essentially acts as a protective layer for double verification.
secondary title
Latency (time needed to reach verifiable finality)
*ZK Rollup
Due to the issues mentioned in the security section above, Optimistic Rollups are only safe during the challenge window of 1-2 weeks for fraud proofs. No transaction can be considered final until this time has elapsed, neither internal Rollup tx nor exits are final.
Unfortunately for end users, there is no quicker way to check whether a transaction is final than to execute all transactions through the entire last challenge period. It is important to note that users cannot rely purely on game theory to guarantee block finality, as a bug or (hacking) in a single operator node could still result in a reversion.
Finality time (under PoS): 1 week
Current ZKPs are computationally intensive. Currently, for a block of 1000tx, we can have a proof generation time of 20 minutes on common server hardware. Ongoing GPU proof program implementations (Matter Labs and Coda implementations) promise at least a 10x faster tx speedup. In the not-too-distant future, specialized hardware may have higher computing power. Eventually, we expect to see block finality within a minute.
Finality time (now): 20 minutes
secondary title
Fast Confirmation Inside Rollup Transactions
secondary title
privacy
*Optimistic Rollup
Quickly withdraw funds
*ZK Rollup
Fast Exit is similar to Fast Internal Rollup Confirmation. Operators can partner with liquidity providers to instantly withdraw fungible tokens to users without waiting for an exit transaction to become final in a Rollup. This requires a large amount of collateral, proportional to the time to finality. Assuming that for Optimistic Rollup, the finality time of the near future reality is 1 week, and ZK Rollup is 5 minutes, then Optimistic Rollup will need 2000 times the collateral of ZK Rollup to support the same weekly withdrawal amount.
privacy
in conclusion
Optimistic Rollup can support any privacy solution available on Layer 2 Ethereum (mixers, etc.). Since Optimistic Rollup itself is also Layer 2, any privacy solution implemented on top of it will be Layer 3. This can lead to more decentralized privacy services and lead to smaller anonymity sets, which makes privacy very less practical (we can even observe this on zcash, where transactions are not hidden by default)
For true privacy, the system must support it by default. From a technical point of view, ZK Rollup can easily support private transactions of token transfer at the protocol level by default under certain circumstances, and can also distinguish between public and private smart contracts.
At the same time, constructing a completely anonymous zcash-style transaction (that is, not only hiding the amount, but also hiding the participants of the transaction), it will require changing the storage model of ZK Rollup from an account-based model to a UTXO-based model, which will cause many problems, and Unlikely to happen.
in conclusion
Optimistic Rollup is currently in the PoC stage. (Blue Fox Notes: PoC refers to the proof-of-concept stage. From the perspective of long-term and implementation, Blue Fox Notes is more optimistic about ZK Rollup) We hope to achieve product-level implementation soon. If it proves relatively easy to port existing code, projects will gradually start adopting it and building new infrastructure: Layer 2 support will appear in wallets, oracles will start broadcasting to Optimistic Rollup, etc.
