Read ZK Rollup and Optimistic Rollup in one article: Ethereum's important expansion direction

Foreword: For many years, scalability has plagued the public chain. Some solutions for scalability are in the proof of concept, and some are in the research and development. Optimistic Rollup and Zk Rollup are also extensible solutions and have drawn great interest from the crypto community. So, what exactly is Optimistic Rollup and ZK Rollup? Which technology route will win the future of Ethereum expansion? No matter how tortuous the road is, whether the previous efforts are useful (such as technological solutions such as plasma), but the road of Ethereum expansion has been moving forward, and it is not out of reach to meet mainstream scenarios. The author, Alex Gluchowski, is translated by "JOKO" in the Blue Fox Notes community.

Introduction

Optimistic Rollup is a technology that promises to expand the 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, with a reasonable trade-off between security and scalability. This will enable ETH 1.0 to meet growing demand.

ZK Rollup is a more complex technology. It can now be used for token transfer and specific applications. However, it will take a longer time to implement on the general smart contract, and even more research work is needed to effectively wrap the EVM in ZKP. (Blue Fox Note: ZKP means zero-knowledge proof)

• ChainsMap Weekly Report: Data Decrease During Long Holiday, Binance Bitcoin Inflow Declines 44%
• Science | What is a blockchain browser?
• Simple, boring and tedious Bitcoin

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 nasty tail risk: stealing funds through complex but viable attack vectors;
• Reduce the time to withdraw funds from 1-2 weeks to minutes;
• Support fast transaction confirmation and exit with an unlimited amount;
• Privacy is introduced by default.

Optimistic Rollup is great news for ZK Rollup. The transition to Layer 2 requires major changes to wallets, oracles, dApps, and user habits. Optimistic Rollup helps prepare the ecosystem for this action, bringing scalability into these dApps that cannot yet be built on ZK Rollup. This gives ZK Rollup enough time to mature and allow it to adopt completely seamlessly, while maintaining the growth momentum of Ethereum.

Rollup 101

* What is Rollup?

Rollup is a Layer-2 scalable 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 status) committed to. The sidechain status is maintained off-chain by users and operators, and does not depend on the storage of Layer 1 (this is the source of the biggest scalability victory).

What sets Rollup and Plasma apart 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).

It is therefore possible to bundle thousands of transactions together in a single Rollup block. Although the cost of this method is strictly linear (O (n) in 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 state transition, there are two Rollup methods: ZK Rollup and Optimistic Rollup.

* What is ZK Rollup?

In ZK-Rollup, the operator must generate a SNARK (Blue Fox Note: Succinct Non-interactive ARgument of Knowledge) for each state transition, and verify it by the Rollup contract on the main chain. This SNARK proves that there is a series of correctly signed transactions by the owner that update the account balance in the right way and make Merkle root from old to new. Therefore, it is impossible for the operator to submit an invalid or manipulated status.

* What is Optimistic Rollup?

In Optimistic Rollup, the new status 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 and restore 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.

Flexibility: General Computing

* Optimistic Rollup

Although Optimistic Rollup can be used for specific applications, the most important innovation of the 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 OVM could reuse existing EVM bytecode directly, but this may not be so simple. The correct implementation will require a change to the transaction data (CALLDATA) format and a complex Truebit / Plasma Leap-style challenge / response implementation to provide proof of fraud.

This could lead to divergence with EVM, which could lead to the inability to properly handle edge cases, which means that some work still needs to be done to fit into the current OVM contract. Another implementation challenge is that fraud proofs for large blocks may require more gas than allowed by the Layer 1 block gas limit. 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 transfers or atomic swaps. There are several main reasons for this.

First of all, there is no effective technique for concise recursive proof combinations for different ZKPs, which requires the execution of different smart contracts to be aggregated into a block. Our best approach is to use Groth16 (used by Coda) on the loop of an elliptic curve, which requires calculations on longer fields and is completely inefficient for large calculations.

Secondly, 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 for only a limited set of problems (which can be expressed as concise arithmetic circuits).

The STARK verification program must execute at least once for each constraint of the certified calculation statement, which means that we cannot iterate through a 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 cryptographic primitives (the well-known polynomial commitment scheme). Developed by Sean Bowe first 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 be reused for any number of different programs at any time.

However, the Kate polynomial commitment schemes used in these proof systems still require efficient elliptic curve cycles for recursion, which is not currently available. That's why we're excited about the latest proof systems that are completely simple and transparent (without trusted settings), such as Halo, SuperSonic, Fractal, and the exciting things the Matter Labs team has been tossing about recently.

Long story short: The obstacles to building a universal smart contract on ZKP have now been removed. ZK Rollup fully supports 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 ZKP prover technology, we expect that all existing ETH (even EWASM) contracts can be effectively ported with minimal effort.

Scalability & transaction costs

* Optimistic Rollup

• According to John Adler, after EIP2028 / Istanbul, the current estimate is about 4k gas per transfer tx.
• This means that it is equivalent to about 100tps.
• With BLS aggregation signatures, this number can go up to approximately 500 tps (to avoid breaking EVM compatibility, the tx parameter may be retained for a long time).
• If EVM compatibility is broken, the throughput may theoretically increase to the limits of ZKP.

Actual throughput cap (token transfer): 500tps

It might be ok right now.

* ZK Rollup

• The public data cost per transfer tx in Matter Testnet is currently 16 bytes, which will cost 272gas after EIP2028 / Istanbul.
• In addition, there will be proven amortization costs, estimated to be approximately 300,000 gas.
• Even if we assume the worst-case scenario that 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 generates a lot of computational overhead and is therefore expensive. In fact, compared to the gas cost, the calculation cost is negligible, which is the real bottleneck because of the anti-censorship decentralization. We also expect this factor to decrease significantly over time.

Actual throughput cap (token transfer): over 2000tps-similar to Visa's scale.

However, in many use cases, ZK Rollup will save even more, because large parts can be omitted from the public data (by moving them to the ZK circuit proof) without having to reconstruct the state transition increment.

The core insight is: Although Optimistic Rollup always requires users to post full transaction input, in ZK Rollup we have the flexibility to choose between the following two: 1) transaction input minus witnesses that do not affect state transition 2) transaction only Output. This choice can be implemented very elegantly without much complexity.

Famous example:

• In multi-signature wallets, abstract wallets or decentralized exchanges with Argent-style accounts, users need to submit signatures to obtain contract verification. These signatures are not required for incremental status updates and can be omitted from public data.
• Contracts like Gnosis's Dfusion Dutch DEX require a large number of data set inputs. These inputs do not directly affect storage, but are only used to verify the calculation results.

* After ETH 2.0

Since any Rollup will be in a single shard, it is unlikely that the cost of CALLDATA (and the Rollup transaction cost) will change significantly unless bandwidth generally becomes cheaper.

Meta transaction

Both types of Rollup are great for supporting meta-transactions and account abstractions.

Safety

* Optimistic Rollup

Unlike payment channels, all funds in Rollup are held by a single smart contract. Since Rollup is the most promising direction for expansion, 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 US dollars worth of assets, for well-known hackers, the Rollup contract is becoming a very attractive honeypot. If the attack has a chance, then no matter how complicated it is, May try.

Optimistic Rollup's security model is based on two assumptions:

1. At least one honest node among n nodes executes all Optimistic Rollup transactions, and submits a fraud certificate when an invalid state transition is issued;

2. 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's 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 are naturally motivated to check the correctness of each other's blocks because based on invalid blocks Building assets on the block will be deducted.

With enough trusted participants, one honest node operator in N nodes is a reasonable assumption. However, since the number of active participants is limited (several hundred?), Some sophisticated attacks may include: targeting the infrastructure of all operators (very difficult but not impossible), bribing / ransoming 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 implement, but should be actively defended, but they are more realistic than attacking Ethereum miners in the same way, especially because successful attacks on Optimistic Rollup will not be noticed until after they are completed.

* Powerful Layer 1 anti-censorship

The second assumption is a tricky one. In fact, the design of Ethereum provides an economic mechanism, which is very effective against ordinary censorship. However, when counter-mechanisms occur, they stop working. Attackers can create fully automatic bribery mechanisms to coordinate 51% attacks by miners, which prevents honest miners from including fraudulent proofs in their blocks.

Interestingly, for the participating miners, the direct cost of this attack was zero, and if it could be clearly attributed to the censorship, it would not be included in the social costs incurred by the angry community response. This part is also tricky because the mechanism provides reasonable denial for the participants in the attack: "Given the majority of the attacker's credible commitment, if I don't participate, my block will be abandoned, so I must Do it not for profit, but to avoid loss. "

Unfortunately, under PoW, this attack is very realistic. There is no effective way to punish anonymous miners involved. After turning to PoS, the community will be able to punish miners by reducing their pledged equity if a broad social consensus is reached.

After all, such censorship attacks can be viewed as aggression against the entire network, although it can also be said that miners simply follow the agreement honestly and are not obliged to act in a manner that violates their best economic interests.

However, after the DAO fork, at least it can be said that this will be a very controversial discussion, and the results are unpredictable. In a recent community poll conducted by Vitalik, 63% of voters opposed any manual 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 of even one validator (Blue Fox Note: here refers to the pledged funds), let alone clear the rights of most validators.

The recent release of more research on collusion and conspiracy, as well as new attacks against fraud proofs in PoS environments, suggest that Optimistic Rollup's censorship attack risk in PoS is at least as high as PoW.

A more realistic way to counter this attack is to quickly mobilize the community in UASF (user-activated soft fork) to force miners to include certain transactions. From an engineering and social perspective, this scenario is complex and will definitely require a relatively long challenge window to provide proof of fraud, at least one week, and preferably two weeks.

At the same time, in view of the fact that major DeFi operators are in a good position to determine the outcome of this fork, and it is in their best interest to avoid noisy interference events. So, their best bet may simply be to follow the attacker quietly (this will keep Ethereum the longest chain and generate less controversy than a successful soft fork).

Overall, the risk of fraud certification review is relatively low, but it cannot be ignored.

Due to the challenge period of 1-2 weeks for fraud proofs and the lack of too much funding at stake, Optimistic Rollup may not be a problem: operator / miner collusion will not be worth the hassle and risk. However, if the value in the rollup rises, the lurking black swan will become increasingly worrying.

* ZK Rollup

In ZK Rollup, each state transition is verified by a Rollup smart contract before it becomes valid. Strictly speaking, operators cannot steal funds or disrupt Rollup status. ZK Rollup relies on Layer 1's censorship resistance, just for its activity, not for security. No one is required to monitor ZK Rollup. After block verification, user funds are always guaranteed to be eventually recovered, even if the operator refuses to cooperate.

Therefore, ZK Rollup more fully embodies the basic idea of ​​the crypto world: replacing the trusted party with the incentive mechanism of cryptography and game theory to achieve flexibility. However, for completeness, I must mention some potential risks unique to ZK Rollup.

Trusted settings

If the ZKP used in ZK Rollup requires a universal credible setup, we will draw the hypothesis of "one-nth" honest participants. Depending on the number and quality of participants, this may be an acceptable risk or an unacceptable risk. But security is safe, which is why I am very excited about the latest progress of efficient and trustless SNARKs, especially Matter Labs is building.

Cryptography

Compared to Groth16, the latest generation of SNARKs is using more proven cryptographic primitives. 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:

* Similar to the RSA challenge, a large number of bonuses must be deployed with lower security parameters than the actual product version. If an actual attack is found, researchers will overcome the challenge years before the product code was breached.

* All state transitions must be sent only by the ZKR operator, which essentially acts as a two-factor protection layer.

Delay (time required to reach verifiable finality)

* Optimistic Rollup

Due to the issues mentioned in the security section above, Optimistic Rollup can only be secure during the challenge window of 1-2 weeks of fraud proof. Until this time has elapsed, no transaction can be considered final, and neither internal rollup tx nor exit is final.

Unfortunately, for end users, there is no faster way to check if a transaction is final than to execute all transactions through the entire previous challenge period. It is important to note that users cannot rely solely on game theory to ensure the finality of the block, because loopholes or (hacking) in a single operator node may still lead to restoration.

Final time (under PoW): 2 weeks

Final time (under PoS): 1 week

* ZK Rollup

ZKP is currently computationally intensive. At present, for 1000tx blocks, we can have 20 minutes of proof generation time on ordinary server hardware. The ongoing GPU proof program implementation (Matter Labs and Coda implementation) is expected to increase tx speed by at least 10 times. In the near future, dedicated hardware may have higher computing power. In the end, we expect to see the finality of the block completed in one minute.

Final time (now): 20 minutes

Final time (future): within 1 minute

Quick confirmation inside Rollup transactions

In both types of Rollup, by depositing a certain amount of security deposit (if the transaction does not include a promised block, the deposit will be reduced), the operator can issue an instant transaction confirmation to the user. This provides financial assurance for finality.

This approach has limitations. It works well for the transfer of interchangeable tokens, but is not suitable for NFT and general contract requests. The NFT may have no market value, or when the owner of these assets does not want to "sell" it immediately under any circumstances. The general contract request is not applicable because if some previous transactions on the chain are restored, it is not easy to accurately quantify the currency value. Simple example: In order to accept the final price of stablecoin oracle price broadcast, how much money should operators pledge?

Withdraw funds quickly

Quick exit is similar to quick internal Rollup confirmation. Operators can work with liquidity providers to instantly withdraw interchangeable tokens to users without waiting for exit transactions to become final transactions in Rollup. This requires a lot of collateral, which is proportional to the time it takes to reach finality. Assuming that for Optimistic Rollup, the actual finality time in the near future is 1 week, and ZK Rollup is 5 minutes, then Optimistic Rollup will need 2,000 times the collateral of ZK Rollup to support the same weekly withdrawal amount.

privacy

* Optimistic Rollup

Optimistic Rollup can support any available privacy solution on Layer 2 Ethereum (mixer, etc.). Since Optimistic Rollup itself is also Layer 2, any privacy solution implemented on it will serve as Layer 3. This may lead to a more decentralized privacy service and a smaller anonymous set, which makes the practicality of privacy very low (we can even observe on zcash that transactions are not hidden by default)

* ZK Rollup

For true privacy, the system must support it by default. From a technical point of view, ZK Rollup can easily support private transactions that transfer tokens at the protocol level by default, and can also distinguish between public and private smart contracts.

At the same time, building a completely anonymous zcash-style transaction (that is, not only hiding the amount, but also 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 It is 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 a long-term and landing perspective, Blue Fox Notes is more optimistic about ZK Rollup.) We hope to implement product-level implementation soon. If it proves that it is relatively easy to port existing code, then the project will gradually begin to adopt it and build a new infrastructure: Layer 2 support will appear in the wallet, the oracle will start broadcasting to Optimistic Rollup, etc.

ZK Rollup has become more mature in specific applications (such as the transfer of ERC20 tokens), but will gradually develop towards a fully universal smart contract. In the end, it is also possible to migrate any smart contract based on EVM and WASM to ZK Rollup. At the current speed of technological development, this may take several years to complete.

For both types of Rollup, similar infrastructure changes will occur in wallets, oracles, and other smart contract components. This requires a lot of work, which will accelerate as more projects become interested in Layer 2 extension technology. Since Optimistic Rollup promises to implement a universal EVM-based smart contract earlier than ZK Rollup, it will greatly promote the community's motivation to adopt Layer 2.

For users and dApps, jumping from one Rollup to another will be easier than initially migrating from ETH to Layer 2. Bridging makes this process smoother. Due to the ease of this switch, this solution will gain significant advantages in UX, and in the long run, it is likely to be the only winner.

Regardless of the outcome, this will be a very important and exciting development. In any case, the ultimate winner is the Ethereum community.

——

Risk Warning: All articles of Blue Fox Notes can not be used as investment advice or recommendations. Investment is risky. Investment should consider personal risk tolerance. It is recommended to conduct in-depth inspection of the project and make good investment decisions.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!