Dry goods | Technical comparison: Optimistic Rollup vs. ZK Rollup (Part-1)

Author: Alex Gluchowski

Translation: Ajian

Editor's Note: The original title is "Dry Goods | Optimistic Rollup vs. ZK Rollup: A Quest, Part-1"

Disclaimer: The author of this article has been developing ZK-Rollup since the concept of ZK-Rollup, so there is inevitably some bias. However, my experience also makes me very suitable for in-depth analysis and comparison of these two solutions from a technical point of view.

• Wuzhen·OKEx Xu Kun: System performance, security, asset quality and risk control are the four core competitiveness of the exchange
• Hong Kong's new regulations promote the development of securities-type certificates, "Goldmans" or the biggest winners
• EOS is now hot and the EOS is now congested, and the CPU price has increased by 1300 times.

Summary

 

Optimistic Rollup is a recently proposed technology designed to extend the universal throughput of smart contracts on Ethereum. If development is relatively fast, it can provide a simple solution for migrating existing dApps and services, and the security/scalability sacrifices are not too great. It helps Eth1.0 adapt to growing demand.

And ZK Rollup is a more complicated technology. Today it can be used for token transfer and customized applications. However, if you really want to use it to implement a universal smart contract, it will take longer and even more research work to efficiently package the EVM into zero-knowledge proof. But the good thing is that once ZK Rollup is developed, all Ethereum dApps and services can now be smoothly migrated to ZK Rollup without much effort.

ZK Rollup solves several fundamental problems on Optimistic Rollup:

• Eliminates the nasty tail risk: stealing funds from OR through complex but viable attack methods
• Reduce the time it takes to withdraw funds from 1-2 weeks to a few minutes
• Support fast transaction confirmation and exit, and there is no limit to the volume
• Default protection privacy

For ZK Rollup, the emergence of Optimistic Rollup is good news. Migrating to the Layer-2 extension requires significant changes to the wallet, oracle, dApp, and user habits. Optimistic Rollup can help the entire ecosystem prepare for such migrations and provide an extension path for applications that currently have no way to build on ZK Rollup. This gave ZK Rollup time to grow, so that the popularity of ZK Rollup can be as smooth as possible while maintaining the growth of Ethereum.

Rollup 101

What is Rollup?

Rollup is a Layer-2 extension similar to Plasma: keeps all the funds in a single contract on the main chain and saves a succinct cryptographic commitment to the "sidechain" state (usually an account) , Merkel tree composed of account balance and other status). The state of the sidechain is maintained by the user and the chain operator, and does not occupy the storage space of Layer-1 (this saving of storage space is the biggest source of scalability advantage).

Rollup differs from Plasma in that Plasma faces the problem of transaction data availability (and the biggest problem with Plasma). Rollup solves this problem by exposing some data to each transaction on the Layer-1 network (specifically, in Ethereum, this is achieved through CALLDATA transactions). Therefore, thousands of transactions can be rolled up into a Rollup block. Although the overhead of this method is O(n), which means that its overhead will grow strictly linearly as the number of transactions increases, it also provides a practical 100x throughput boost because CALLDATA has more overhead than Layer. -1 is much cheaper to store and calculate.

Rollup has also been repeatedly recognized by Vitalik Buterin as his favorite Layer-2 extension.

Depending on how the state transitions are guaranteed, two Rollup schemes can be distinguished: ZK Rollup and Optimistic Rollup. A brief history of the two options is clearly explained in this article .

What is ZK-Rollup (ZKR)?

In a ZK-Rollup system, the operator (s) must provide a concise zero-knowledge proof (SNARK) for each state transition; the certificate will be verified by the Rollup contract on the main chain. Such a SNARK proves that there are some transactions that were properly signed by the initiator and correctly updated the balance of the relevant account and changed the old Merkel root value to a new value representing the new state. This eliminates the possibility of the operator submitting an invalid state or tampering state.

More technical details can be found at the EthResearch Forum and the Matt Labs blog post. You can also try the ZK Rollup online demo for Matter Labs for ERC-20 token transfers.

What is Optimistic Rollup?

In an Optimistic Rollup system, operators do not need to be inspected for Rollup Smart Contracts each time they release a new status root. Instead, everyone assumes that the state transition is correct. but. If someone issues an incorrect state transition, other operators or users can point out illegal transactions and roll back incorrect blocks and punish malicious certifiers (however, to do this, you must always have time) Observe the Layer-1 Rollup contract and perform it yourself each time someone releases a state transition.)

The idea of ​​OR was first conceived by John Adler. Readers can find more details in this Optimistic Rollup AMA. Pay tribute to the great results of the Plasma Group!

Start comparing!

Flexibility: Universal Computing

Optimistic Rollup

Although OR can be used for special purpose calculations, the most important innovation of the Plasma Group is the OVM: Optimistic virtual machine. OVM can support the implementation of any smart contract logic. Almost all calculations that can be performed on Ethereum can be performed on OVM, including the composability of smart contracts. It can also be given to EVM, EWASM or any other virtual machine.

One of the great strengths of OVM is that if you use it with EVM, you can use Solidity to write code. Therefore, most existing code bases can be easily ported to the OR.

It is ideal if OVM can reuse existing EVM bytecode directly, but it may not be that simple. A suitable implementation should change the transaction data (CALLDATA) format, and a complex challenge/response protocol similar to Truebit/Plasma Leap is required to receive the proof of error, which is likely to cause a difference from EVM, otherwise it cannot be processed. extreme case. This also means that there is still work to be done to adapt existing contracts to OVM.

Another difficulty in implementation comes from the fact that the erroneous proof of large blocks may be greater than the Gas upper limit of the Layer-1 block. Then these false proofs must be broken up into multiple ETH transactions.

ZK Rollup

To date, all existing ZK-Rollup implementations (including your own:) have only supported proprietary operations such as token transfers or atomic swaps. There are several reasons for this. First, there is no technology that can efficiently implement the succinct recursive proof composition of different zero-knowledge proof schemes. However, it is necessary to do such a technique in order to perform aggregation execution on different smart contracts in one block. Our best solution now is elliptic curve cycles plus Groth16 (this is also the case with Coda), which requires long fields to be computed and is completely inefficient for large calculations. .

Second, even if we have shorter fields, Groth16 needs a trusted initial setup process, and each smart contract, each new version requires a separate one! Obviously, this is absolutely unrealistic. We now have only one efficient zero-knowledge proof scheme that does not require a trusted initial setup, which is FRI-based STARKs, but where the verifier is only concise for a small subset of problem types (which can be expressed as concise arithmetic circuits). . A STARK verifier must execute all the constraints of the proven statement at least once, which means we can't iterate over a heterogeneous set of smart contracts.

But all of this will change after the arrival of SNORKs, a new generation of zero-knowledge proofs, with cryptographic primitives behind it that are slightly different from their predecessors – most notably polynomial commitments Schemes). This technique was proposed by Sean Bowe and was originally named Sonic ; in the summer of 2019, the technology codenamed PLONK and Marlin inherited this route. All of these technologies have one thing in common: although the entire solution still requires a trusted initial setup, the initial setup at this time is universal and updateable, as long as it is done once, it can be any number. Different projects are reused at any time.

However, the Kate polynomial promise scheme used by these proof systems still requires efficient elliptic curve loop operations for recursion, which is not yet possible. That's why we are excited about some of the latest, completely concise and transparent (no trusted initial setup) proof systems, such as Halo, SuperSonic, Fractal, and some new things being developed by the Matter Labs team. To make a long story short: The barriers to building a universal smart contract system on ZKP have recently been eliminated. ZK Rollup fully supports programming modes like EVM (including frictionless composability and interoperability). The first contract may require a customized DSL, although for Solidity developers, the learning time will not exceed one day. Ultimately, if ZKP certifier technology maintains current rates of progress, we can expect all existing Ethereum contracts (even EWASM contracts) to be easily and efficiently migrated.

Scalability & Transaction Costs

Optimistic Rollup

• According to John Adler, the current estimate is that after the EIP2028/Istanbul upgrade is activated, it can reach 4k gas per transaction (Translator's Note: The current Ethereum native trading scheme is 21k gas per transaction)
• Convert, TPS can rise to about 100
• With BLS signature aggregation technology, TPS can rise to about 500 (this number may stay for a long time without compromising EVM compatibility)
• If you are willing to break the EVM compatibility, the theoretical throughput can directly push the upper limit of ZKR.

Realistic throughput estimate (in token transfer transactions): 500 TPS .

It may be quite enough for now.

ZK Rollup

• Currently, on the Matter test network, the public data cost per transfer transaction is 16 bytes; after EIP2028/Istanbul upgrade activation, each transaction consumes 272 gas
• In addition, there is a proof cost that needs to be shared. The current estimate is 300k gas.
• Even if we estimate the worst case, we need to pay a proof cost of 1 million gas, and the ceiling is expected to be 2140 TPS.
• In some discussions, I heard that ZKP includes a lot of computational overhead and is therefore very expensive. In fact, the computational cost is negligible compared to the production cost of Gas; because the production of Gas is both anti-censorship and decentralization, its quantity is the real bottleneck. We also expect that the impact of this negative factor will be greatly reduced.

Realistic throughput estimates (in terms of token transfer transactions): Over 2000 TPS – just catch up with Visa .

However, for most application scenarios, ZK Rollup can provide greater overhead savings because it can (move larger blocks of data into the zero-knowledge circuit witness) and eliminate the need to store larger data in public data. Data blocks, as long as they are not required to rebuild the state transition delta. The core idea here is this: although OR always requires the user to publish the complete transaction input, we have a choice in ZK: 1) publish the transaction input, delete the witness data that does not affect the state transition; or 2) publish only Transaction output. Such a choice can be implemented quite elegantly without introducing much complexity.

Important examples:

• In multi-signature wallets, Argent-like account abstract wallets, or decentralized exchanges, users need to submit a signature for contract verification. These signatures are also useless for status updates, so they can also be omitted from public data.
• Contracts like Gnosis's Dfusion dutch decentralized exchange require a large amount of dataset input that does not directly affect storage and is only used to validate calculations.

After ETH 2.0 is implemented, because Rollup will reside in a single shard, the cost of CALLDATA (and the corresponding Rollup transaction cost) should not change much. Unless the bandwidth as a whole becomes cheaper.

(unfinished)

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