Original source: Offchain Labs

Compilation of the original text: James

Are ZK Rollups the future of general-purpose smart contract systems? We seem to have heard too much discussion on this issue. However, according to our practical experience from an open, secure, EVM-compatible Layer 2 running hundreds of DApps, hundreds of thousands of users, and millions of transactions, ZK Rollups will not become a general-purpose smart contract system. As for the reason , which will be explained in detail in this article.

first level title

text

1. People want a trustless blockchain that provides security, guaranteed progress, visibility, and fast finality — they want transactions on this blockchain to be cheaper and compatible with existing tools.

2. When providing the above services and functions, compared with ZK Rollup, we delved into the details of how to use Optimistic Rollup.

3. Optimistic Rollup can provide the functions that users want at a lower cost, because the off-chain cost of building a ZK Rollup proof is very high.

4. Since ZK proofs are very expensive, full participation in the ZK protocol may require specialized hardware and/or massive parallelism, making the network more centralized.

5. The so-called "advantages" of ZK Rollup, either Optimistic Rollup can also be supported, or important security or usability features need to be sacrificed.

first level title

let's start from scratch

First of all, we must first talk about Ethereum. Ethereum users create transactions to deploy or interact with smart contracts, and you can think of Ethereum transactions in a few different ways. On the one hand, you can think of it as an opaque block of data, but if you look at the content of the data, you will find that a transaction is of course much more than that; the so-called transaction should actually be a request, asking the smart contract to do something, such as : Log some information, move some assets, etc.

When a transaction is published on the Ethereum blockchain, two important things happen -

First things first: Once a transaction is included in the blockchain, Ethereum reaches consensus based on an ordered set of transactions.

first level title

Rollups: What do Optimistic Rollups and ZKRollups have in common?

If each Ethereum node executes each transaction, the cost will inevitably be very high, and Rollups is actually a kind of expansion solution that can significantly reduce the network load. The actual execution of the transaction is not completed on the Ethereum blockchain. Instead, move to Layer 2 ("L2").

But wait a minute - Rollups are supposed to be secured by Ethereum, no? Indeed, the security of these scaling solutions cannot be separated from Ethereum, which means that even if the transaction occurs on Layer 2, we still need Ethereum to ensure the correctness of transaction execution in some way. So, how can Ethereum give approval to the state of Rollups?

first level title

Rollups: What are the differences between Optimistic Rollup and ZKRollup?

These "proofs" seem like magic: allowing Ethereum to verify the Rollups state without actually executing the transaction. You might be wondering what these proofs look like, and how they are implemented in practice—and that's what sets the various Rollups styles apart.

Validity certificateValidity certificate(validity proofs), which rely on a party to issue a succinct cryptographic proof that this "proof" can establish that the party knows the validity of the blockchain ending in a particular state. That is to say, the "party that provides the proof" needs to execute blockchain transactions to know how to construct the proof, and then construct the "proof" through a series of complex cryptographic operations. These "proofs" will be checked by Layer 1 on-chain contracts. The "proof" of ZK Rollups is relatively simple, and verifying transactions is relatively cheap, so it can be done directly through Ethereum transactions.

proof of fraudproof of fraud(fraud proofs). As the name suggests, Optimistic Rollups are "positive, optimistic" because when they publish the updated state to the Ethereum blockchain, they don't publish any "proofs" at all. Anyone can publish a Rollup block, which contains a statement about the correct result of executing a certain transaction. When other nodes execute the same transaction, they can challenge it as long as they disagree with the first node's claim. An effective dispute protocol can resolve any disagreements, guaranteeing that the correct party will win the challenge. All parties have a strong incentive to only issue correct claims and not challenge incorrect ones, so in the common case all nodes "simply" execute all transactions and never need to call proof code - the whole process is done by Layer 1 contracts are responsible for management.

secondary title

Optimistic Rollup vs. ZK Rollup: Cost

costcost。

Optimistic Rollup requires nodes to simply execute the contract, for example, if the contract performs an add operation, the node performs that add operation.

In contrast, ZK Rollup needs to generate complex cryptographic proofs, requiring hundreds or thousands of elliptic curve operations to include addition operations in the proof, so it is expensive.More importantly, ZK Rollup incurs a cost per instruction in each contract, giving ZK Rollup an inherent cost disadvantage due to the need to generate complex cryptographic proofs for each instruction, not just executing the instruction —and a big disadvantage.

Proponents of ZK Rollup sometimes argue that the solution requires only one party to create "proofs", whereas Optimistic Rollup requires the system to have many nodes. However, if you are running a large blockchain, it will have many nodes no matter which proof system you use. A real blockchain needs many nodes to serve various activities such as non-mutating calls, searching event logs, displaying transaction data to users, providing users with data needed to withdraw funds back to Layer 1, and so on. The security of an Optimistic Rollup blockchain relies on these nodes doing what they already need to do — execute transactions and track the correct state of the blockchain.

On the other hand, with ZK Rollup, expensive elliptic curve-based proofs are derived, which imposes a very large additional cost. In order to hope to prove ZK Rollup at scale, you need either dedicated hardware devices, or you need to support massive parallelism - or both, which are very expensive.

secondary title

text

An important consideration when we built Arbitrum was compatibility with the Ethereum Virtual Machine (EVM). Arbitrum is fully EVM compatible, and has the same RPC interface and accepts the same bytecode as the EVM, which means that any code written for Ethereum can be run on Arbitrum"plug and play”。

Optimistic Rollup has been running open, EVM-compatible blockchains (including testnets) for over a year now, and we have learned that being truly Ethereum-compatible is challenging. 95% compatibility at first is not too difficult, but in practice it's not good enough, and compatibility can only be made better with a lot of effort and building an architecture that doesn't get in the way of the product.

In terms of compatibility, the ZK Rollup system operates in a wide range. But some people think that ZK Rollup is an "old school" tool, because they still encourage people to learn their custom language. Also, some ZK Rollup systems don't try to be compatible with Ethereum, which of course is fine for developers and users who don't care about compatibility with Ethereum.

Objectively speaking,EVM is the best on-chain tool ever. We believe that the EVM itself has a very large practical advantage, given the number of developers, code, and developer tools that already work with it. Consider a project deployed on Ethereum. If the project wants to expand to Rollup, developers must rewrite their code in new languages, commission new security audits, and maintain multiple code bases. These tasks are not only tedious And error-prone. But even for new projects that haven't written any code, EVM compatibility is important because being EVM compatible means that these projects can take advantage of the code, tooling, and talent pool that exists around EVM.

systemsystemThe real compatibility is not very good, the system——

• Failed to implement ADDMOD, SMOD, MULMOD, EXP, SELFDESTRUCT and CREATE2 opcode compatibility;

• Removing support for XOR, AND, and OR is being considered;

• Standard transaction formats are not supported;

• Does not support any precompilation;

• May limit the number of contract calls in a transaction.

It seems that ZK Rollup mode is fundamentally not compatible with EVM, which is obviously far from the full compatibility achieved by Optimistic Rollups.

To clarify, there are still multiple examples of application-specific ZK Rollup systems (e.g. Zcash, ZKSync 1.0, Loopring). In fact, these systems work well, but the core difference is that they are fine-tuned and specially optimized for specific applications that are very suitable for ZK Rollup implementation. Although some teams claim to be working on a general-purpose compiler that allows "passing" EVM to ZK Rollup in a compatible way,However, there is no public code or benchmark available to illustrate the proof cost of a user-defined ZK-EVM contract, and based on current knowledge and all publicly available data, we believe this cost will be very high.

secondary title

Optimistic Rollupvs. ZK Rollup: Trustless Visibility and Compression

When designing trade arbitrage, one of the key properties of Optimistic Rollups is trustless visibility. In short, trustless visibility means that anyone can view or obtain the content of the blockchain without the help of a centralized organization. More importantly, this means not only that everyone can see occasional snapshots of the state — it also means that everyone can see the full history of the chain — how it arrived at its current state. A practical blockchain that allows anyone to run a node, while nodes can also support non-mutating calls, search event history, and view every transaction - without relying on centralized data providers, and trustless visibility make this possible.

Quite frankly, some ZK Rollup systems seem to be cutting corners when it comes to visibility and trying to talk about the fact that they are not providing full blockchain functionality. When you hear talk about "compression", think about it - are they saying they're encoding the contents of the chain more efficiently? (Arbitrum does, and will do better in our Nitro release) Or are they saying that some parts of the blockchain history are simply not available unless a centralized data provider is willing to share it with you later?

Recall that a ZK Rollup proof really only proves a valid chain that the "prover" knows, but the "proof" by itself doesn't tell you what that chain is, and even if you have enough data to verify the "proof", there probably isn't enough. Data to reconstruct the historical data of the blockchain.

For example, suppose Alice submits a transaction of 1 ETH paid to Bob, and soon Bob submits a transaction of 1 ETH paid to Charlie. Next, you need to verify a proof that Alice has 1 ETH less than before, Bob's balance has not changed, and Charlie has 1 ETH more than before.

But what happened? Did Alice pay Bob? Did Bob pay Charlie? Maybe Alice paid Charlie directly, maybe Alice destroyed an ETH, and the 1 ETH Charlie got was paid by someone else, maybe this "other person" was named Diana, not Bob. If we look for Bob's payment proof from the blockchain, but for some ZK Rollups that do not provide blockchain visibility, it is impossible to distinguish and find Bob's payment transaction.

Many smart contract applications require knowledge of not just a few checkpoints, but the entire chain — understanding what happened and how the final state was reached.ZK Rollups sometimes boast better "compression" than Optimistic Rollups, but they hide the data of the blockchain, which means that only the "prover" knows that the data is not compressed, and they may even delete vaguely important data.If ZK providers say that they "don't need" to publish the history of the entire blockchain, what they really mean is that they cannot guarantee the visibility of the blockchain, and giving up the visibility guarantee of the blockchain is not what Optimistic Rollup is willing to do. compromise.

secondary title

Optimistic Rollupvs. ZK Rollup: Trustless, Timely End

When evaluating Rollup, we need to identify a key requirement: whether Rollup needs to provide trustless, timely finalization. In simple terms, this means that after you submit a transaction, you and everyone else should know the outcome of the transaction in a timely and certain manner, and no one can change or reverse the transaction.

In our opinion, the best way to achieve timely finality is to separate the ordering of transactions from their execution. Sorting produces a final sequence of proposed transactions and attempts to execute transactions in that sequence. If the execution of transactions is deterministic, as it is based on Arbitrum, then determining the order of transactions is sufficient to determine the outcome, since the outcome is a deterministic function of the order of transactions. If everyone knows the order of transactions, everyone can easily determine the outcome.

Completing a sequence requires posting the sequence to the Layer 1 chain with enough information to allow anyone executing the transaction themselves to know the outcome without trust. The ideal rollup is to publish sorted transaction data to the Layer 1 chain as often as possible.

In the Optimistic Rollup system, the cost of publishing to the Layer 1 chain is the lowest. In fact, Arbitrum usually publishes sorted transaction data to the Layer 1 chain every minute or so, providing users with fast certainty and guaranteeing that no one can undo their trade. In addition, Arbitrum also generates a new Optimistic Rollup Result Assertion every hour or so, but since the sequence is already finalized and execution is deterministic, it doesn't slow down finalization at all.

In principle, a ZK Rollup system could also operate in a similar fashion; i.e., by separating the ordering of transactions (which can often be published to Layer 1) from later verification and occasional proof of validity. However, a ZK Rollup operating in this manner would need to publish essentially the same data to the Layer 1 chain as the Optimistic Rollup system publishes data, which is not supported by the (so-called) "compression" technique discussed above. In order for ZK Rollup to make the "compression" technique work, it must prove the validity of a series of Layer 2 transactions in real time, within the same Layer 1 transaction, and it must do so every time a batch of Layer 2 transactions are issued.

Therefore, although the so-called "compression" technology is highly touted by ZK Rollup, when encountering the above situation, they have to make two choices:

1) Publish sorted transactions and proofs of execution every minute or so: This maintains fast finality, but requires ZK proofs to be generated off-chain every minute and verified on the Layer 1 chain. Depending on the implementation, the cost of issuing a ZK proof on a blockchain chain is estimated to be between 500,000 and 5 million gas.

2) Publishing sorted transactions and proofs every hour: This approach makes the cost of ZK proof checking slightly reasonable, but extends the finalization time to an hour. In the time between a user submitting a transaction to the ZK Rollup operator and its posting to the status chain, users have no guarantee that their transaction will be included and can only trust the ZK Rollup operator.

If you are building a ZK Rollup system, you will find that the above two options are actually unacceptable -The first costs too much and the second does not provide timely closure. So if you end up using the same type of sequencer, you need to publish essentially the same data in Arbitrum's ZK Rollup version as our Optimistic Rollup version.

If you hear someone touting that ZK Rollup can compress hours of data into a single point, don't worry. If they only publish a single point of data at the end of a long period of time, then that means they did not provide finality during that time.

secondary title

Optimistic Rollupvs. ZK Rollup: trustless activity

Trustless liveness means anyone can force the system to make progress. (A trustless security property ensures progress is correct.)

Optimistic Rollup allows any node to claim that the transaction was executed correctly. Making this statement only requires the node to execute the transaction of the chain, and then deposit a pledge that can be refunded after the agreement confirms the statement.

On a ZK Rollup system, the process requires that any node can create and issue the ZK proofs needed to advance the state of the blockchain, but not everyone can do it using common hardware and software. Therefore, if you want to complete the ZK proof, you must build or buy specific special-purpose hardware and perform massively parallel computing. Even on ordinary devices, it is necessary to build a suitable ZK proof path. A ZK provider that does not provide this function or publishes the code for generating proofs for its system cannot provide a trustless process, and the system does not have any liveness guarantee. That is, ZK Rollup's system is centralized because only provers with special equipment can push the process. (It's unclear whether the leading ZK rollup offering this would provide a viable proof for the average user.)

secondary title

Optimistic Rollupvs. ZK Rollup: Bridging

Of course, ZK Rollup is not useless, it has great advantages in one field, namely:Ethereum cross-chain connectionIt should be emphasized that,

It should be emphasized that,The bridging advantage of ZK Rollups is actually not very big: because it can only be used to bridge back to Ethereum from Layer 2.Once upon a time (circa 2019), many people thought that Ethereum scaling solutions would not appear so quickly, and maybe there would be only one or two DApps slowly rolling out. But in practical applications, Rollup users will find themselves needing to switch back and forth between Layer 1 and Layer 2, which is actually not supported by ZK Rollup. In contrast, Arbitrum has a thriving ecosystem with hundreds of DApps are everywhere in the DeFi field, and many users are connecting to Arbitrum and staying there for a long time. In addition, in terms of providing cross-chain support for users, Arbitrum not only supports Ethereum, but also docks with other Lauer 1 and side chains. For this direct bridge, the advantage of ZK Rollups is not as great as that of Optimistic Rollups.

Summarize

Summarize

After a comprehensive comparison of Optimistic Rollup vs ZK Rollup systems, we believe that the Optimistic Rollup system is the clear winner. Optimistic Rollup costs less, is fully compatible with EVM and existing tools, and the only real downside in practice is the slower Layer 1 bridging speed without fast cross-chain bridging services. Many of ZK Rollup's supposed advantages require sacrificing blockchain visibility or finality time, which we don't think users want.

Not only that, but it seems unlikely that ZK Rollup would want to make a change. ZK proofs of EVM-compatible contract execution will still be significantly more expensive than Optimistic Rollup execution, and ZK Rollups will also struggle to achieve guaranteed progress, blockchain visibility, and decentralization requirements. We are willing to switch Arbitrum to ZK Rollup based transaction execution if the situation changes, but we don't think they will make an optimization change.

The last thing to say is that people tend to compare what Arbitrum currently provides with what the ZK system claims they will provide in the future, but this comparison is really meaningless, because we want to compare, compare with existing systems . Optimistic Rollup scaling solutions like Arbitrum are the only open deployment systems that support generic smart contracts. Or, if future systems are to be compared, then we should be comparing future Arbitrum to future ZK systems.

We are constantly improving Arbitrum. For example, in our upcoming Nitro version, we will provide users with lower transaction costs and better on-chain optimization of lossless compressed data. Not only that, we are working tirelessly to Improve trade arbitrage and reduce costs to theoretical limits. As we analyze in this post, we believe that Optimistic Rollups are the clear real winner when considering the two systems currently in existence and their respective theoretical constraints.