Optimistic Rollups: The Present and Future of Ethereum Scaling

There is a lot of talk about how ZK Rollup is considered the future of general smart contract systems. And we disagree – this article explains why. It draws on the practical lessons we have learned from running an open, secure, EVM-compatible L2 chain with hundreds of dapps, hundreds of thousands of users, and millions of transactions.

We built Arbitrum as an Optimistic Rollup (OR) because we believe OR is the best way to meet users’ real-world needs for a secure, unconditional trust, EVM-compatible L2. We chose Optimistic Rollup over ZK because of the inherent scalability and cost advantages of the system; we would still make the same choice today. If you want to know why, read on.

Michael Johnson – originally posted to Flickr as apples and oranges – they don’t compare, CC BY 2.0 ,


etc! How long is this post?

Yes, this post is long and somewhat technical in places. What one expects from the chain is simple, but talking about the technology needed to provide these benefits requires us to delve into some details. We want the tech community to understand our point of view.

If you don’t want to read the entire article, here’s a brief outline.

  • People want a chain that can be unconditionally trusted to provide the properties of security, guaranteed progress, visibility, and speed — and they want low cost and compatibility with existing tools.
  • Compared to ZK Rollup, we delved into the details of how Optimistic Rollup can be used to provide these properties.
  • Since the off-chain cost of ZK is very high, Optimistic can provide the properties users want at a lower cost.
  • Since ZK proofs are very expensive, full participation in the ZK protocol may require special purpose hardware and/or massive parallelism, making the network effectively more centralized.
  • ZK’s claimed advantages either apply to Optimistic Rollup systems as well, or require sacrificing important security or usability features.
  • Optimistic Rollup wins big on operational cost because executing code is much cheaper than computing complex cryptographic proofs.

start from scratch

Let’s start with Ethereum first. An Ethereum user creates a transaction to deploy or interact with a smart contract. You can look at Ethereum transactions in a few different ways. On the one hand, it can be considered as opaque data. But if you look at its content, a transaction is of course much more than that; it’s a request for a smart contract to do something: record some information, move some assets, etc.

When a transaction is posted on Ethereum, two important things happen. First, it is included, and Ethereum agrees on a set of ordered transactions. Second, Ethereum executes these transactions and computes the resulting state updates.

Rollup: what Optimistic and ZK have in common

Getting every Ethereum node to execute every transaction is expensive, and Rollup is a class of scaling solutions that can significantly reduce this load. The actual execution of the transaction is not done on Ethereum, but is moved to the Layer 2 (“L2”) area.

But wait – Rollup should be guaranteed by Ethereum. This means that we need Ethereum to somehow guarantee the correctness of transaction execution, even if it happens on L2. So how does Ethereum grant its seal of approval to Rollup status?

In short, the answer is: proof. Rollup proves its correctness to Ethereum using proprietary proofs, which can verify the correctness of the transaction even without executing it.

Rollup: Difference between Optimistic and ZK

These proofs seem pretty magical: allowing Ethereum to verify the Rollup state without actually executing it. You may be wondering what these proofs look like and how they are implemented in practice. That’s what makes all kinds of Rollups different.

ZK Rollup uses proof of validity. ZK relies on a party to issue a succinct cryptographic proof that the party knows of a valid chain ending in a particular state. This requires the authenticator to execute the chain in order to know how to construct the verification, and then to construct the verification by performing a series of complex cryptographic operations. The proof is checked by the L1 contract on-chain. ZK proofs are succinct and the verification cost is cheap enough to be done with an Ethereum transaction.

Optimistic Rollup uses a different type of proof: fraud proof. As the name suggests, Optimistic Rollups are optimistic, and when they publish an updated state to Ethereum, they don’t have to publish any proofs at all. Anyone can post a Rollup block containing a claim about the correct outcome of executing certain transactions. Other nodes perform the same transaction and can issue challenges if they disagree with the first node’s claims. An effective dispute agreement can resolve any disagreements, guaranteeing that the correct party will win the challenge. There is a strong incentive for parties to only issue correct claims, not to challenge wrong ones, so in the usual case all nodes just execute all transactions and never need to call the proof code. The whole process is managed by the L1 contract.

OK, so which type of Rollup is better? In what follows, we will compare ZK and Optimistic Rollup on several dimensions and explain why we think the future is Optimistic, while Optimistic Rollups like Arbitrum are inherently more scalable.

Optimistic Rollup vs ZK: Cost

Perhaps the most important difference between Optimistic Rollup and ZK is cost.

Optimistic Rollup requires nodes to simply execute the contract. For example, if the contract performs an add operation, the node will perform the add operation.

ZK, on ​​the other hand, needs to generate a complex cryptographic proof that requires hundreds or thousands of expensive elliptic curve operations to include addition operations in the proof. ZK bears this fee for each order in each contract. The need to generate complex cryptographic proofs for every instruction, not just for execution, is an inherent cost disadvantage for ZK — and a big one.

ZK advocates sometimes argue that only one party is required to create a proof, whereas Optimistic Rollup requires a system to have many nodes. However, if you are running a large chain, it will have many nodes no matter what verification system you use. A real chain would require many nodes to serve non-mutating call event logs, display transaction data to users, provide users with the data they need to withdraw funds to L1, etc. The security of Optimistic Rollup chains relies on these nodes doing what they already need to do – executing transactions and tracking the correct state of the chain.

On the other hand, ZK’s construction of expensive elliptic curves proves to be a very large additional cost. You need special purpose hardware devices or massive parallelism – or both, to be able to do massive proofs with ZK, but it’s expensive.

Conclusion: Optimistic Rollup systems have inherent, significant cost advantages.

Optimistic Rollup with ZK: EVM compatibility

An important consideration for us when building Arbitrum was compatibility with the EVM. Arbitrum is fully compatible with EVM; it has the same RPC interface and accepts the same bytecode as EVM. In practice, this means that any code written for Ethereum will work on Arbitrum out of the box.

We’ve been running open, EVM-compatible chains (including testnets) for over a year, and we’ve learned how challenging it is to be truly compatible. Top 95% compatibility isn’t hard, but it’s not good enough in practice, and doing better requires both a lot of effort and a product architecture that doesn’t get in the way.

The ZK system operates a wide range in terms of compatibility. Some see it as a legacy tool and encourage people to learn their custom language.

But some ZK systems are not trying to be compatible. Of course it’s fine for developers and users who don’t care about compatibility.

Optimistic Rollups: The Present and Future of Ethereum Scaling

We’re not arguing that the EVM is objectively the best ever. What we believe is that EVM has many practical advantages, given the amount of developers, code, and developer tools that already work with EVM. Consider a project deployed on Ethereum that wishes to scale to Rollup, would have to rewrite the code in a new language, delegate new security audits, and maintain multiple codebases, which is cumbersome and error-prone. But even for new projects that haven’t written any code yet, EVM compatibility is a big plus, as it allows those projects to take advantage of the code, tools, and talent pool that exists around EVM.

Some ZK projects are working on implementing an EVM-compatible version, but despite their vague claims, we are not aware of any code released so far that allows people to run EVM contracts while ZK Rollup. There are serious incompatibilities with existing preliminary systems. For example, a ZK system that claims EVM compatibility fails to implement ADDMOD, SMOD, MULMOD, EXP, SELFDESTRUCT, and CREATE2 opcodes; is considering removing support for XOR, AND, and OR; doesn’t support standard transaction formats; doesn’t support any precompiles ; and possibly limit the number of contract calls in a transaction. There appears to be a fundamental incompatibility with the ZK model, which guarantees that even in the best case, ZK EVM compatibility comes with a detailed print page, rather than the full compatibility implemented by Optimistic Rollups.

It is worth clarifying that several examples of application-specific ZK systems exist today (e.g. Zcash, ZKSync 1.0, loops). In fact, some of these systems work just fine. The core difference is that these are just fine-tuned and specifically optimized for specific applications that are well suited for ZK implementations. What doesn’t exist today is a general-purpose compiler that allows one to implement the conversion from EVM to ZK in a compatible way. While there are some teams claiming to be working on it, there is no available public code or a benchmark for the cost of proof of user-defined ZK-EVM contracts. Based on our knowledge and all publicly available data, we believe they are prohibitively expensive.

Conclusion: Only Optimistic supports full EVM compatibility at the lowest cost.

Optimistic Rollup and ZK: Visibility and Compressibility for Unconditional Trust

One of the key attributes we designed Arbitrum with was the visibility of unconditional trust. Simply put, unconditionally trusted visibility means anyone can see or access on-chain content without centralization. Importantly, this not only means that everyone can see a snapshot of the state; it also means that everyone can see the full history of the chain — how it got to the current state. Utility Chain allows anyone to run a node that can support non-mutating calls, search event history, and view every transaction — without relying on a centralized data provider. Untrustworthy visibility makes this possible.

Frankly, some ZK systems have weakened in terms of visibility and trying to talk around the fact that they do not offer full blockchain functionality. When you hear talk about “compression”, listen carefully: do they say they are encoding things on-chain more efficiently (Arbitrum does and will do it better in our Nitro release) ? Or are they saying that parts of the on-chain history will never be available unless the centralized data provider is willing to share it with you later?

Recall that ZK proofs only prove that the prover knows a valid chain. The proof doesn’t tell you what the chain is, and even if you have enough data to verify the proof, you probably don’t have enough data to reconstruct the chain’s history.

For example, suppose Alice continuously submits 1 ETH transactions to Bob, and Bob continuously submits 1 ETH transactions to Charlie. Later, you verify the 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 pays Charlie directly. Maybe Alice burned an ETH and Charlie was paid by someone else. Maybe Diana was the intermediary, not Bob. Bob is counting on the blockchain to find proofs, but some ZK Rollups don’t provide on-chain visibility and he can’t tell the difference.

Optimistic Rollups: The Present and Future of Ethereum Scaling

Many smart contract applications require more than the occasional knowledge of a checkpoint. They need to understand on-chain – know what’s going on and how to get to the final state. ZK Rollups sometimes boast better “compression” than Optimistic Rollups, but in fact hides the chain’s data so that only the prover knows it’s not compression – it removes important data. If ZK providers say they “don’t need” to publish on-chain history, what they’re really saying is that they cannot guarantee chain visibility. Giving up on-chain visibility guarantees is not a compromise we would like to make.

Conclusion: The Optimistic Rollup system provides unconditional trust visibility at the lowest cost.

Optimistic Rollup and ZK: Unconditional Trust, Timely Ending

A key requirement when considering a Rollup is whether it provides unconditional trust, timely end results. In short, this means that after you submit a transaction, you should know the outcome of that transaction to you and others quickly and with certainty, and no one should change or revoke it.

We believe that the best way to achieve timely finalization is to separate the order of transactions from their execution. Sorting produces a final sequence of proposed transactions, and the execution attempts to execute the transactions in that sequence. If the execution of transactions is deterministic, as on arbitration, then the order in which transactions are completed is sufficient to finalize the outcome, as the outcome is a deterministic function of the sequence of transactions. If everyone knows the transaction sequence, everyone can easily determine the outcome.

Finalizing the sequence requires publishing the sequence into the L1 chain with enough information so that anyone can execute the transaction themselves to know the outcome with unconditional trust. The ideal rollup is to publish sequence transaction data to the L1 chain as often as possible.

In the Optimistic Rollup system, the overhead of publishing to the L1 chain is minimal, in fact, Arbitrum usually publishes serialized transaction data to the L1 chain every 1 minute or so, providing users with fast final results and guaranteeing that no one can revoke them ‘s transaction. A new Optimistic Rollup result assertion is made approximately every hour, but since the sequence has already completed, and execution is deterministic, this does not slow down the final result.

In principle, the ZK system could operate in a similar fashion; that is, separate transaction ordering (which can be published to L1 frequently) from verification done later, with occasional proofs of validity. However, a ZK Rollup operating in this way would require that data published by the basic and Optimistic Rollup system be published onto the L1 chain; none of the (so-called) “compression” techniques discussed above would be available. For these “compression” techniques to work, each time a batch of L2 transactions is published, the validity of a series of L2 transactions within the same L1 transaction must be verified in real-time.

So ZK Rollups looking to use the touted “compression” technique are left with two options:

  1. Publish serial transactions and execute proofs every minute or so: This preserves speed, but requires ZK-Proofs to be generated off-chain every minute and verified on the L1 chain. Depending on the implementation, the cost of issuing a ZK proof on-chain is estimated to be between 500,000 and 5 million gas.
  2. Sequential transactions and proofs are issued hourly: This makes the cost of ZK proof checks reasonable, but extends the final time to one hour. In the hours between when a user submits a transaction to the ZK operator and when it is posted on-chain, the user is not even guaranteed that their transaction will be included, but simply trusts the operator’s message.

If we were building a ZK system, we would find these two options unacceptable – the first is too expensive and the second does not provide a timely end result. So we end up using the same sequencer as the Optimistic Rollup version and publishing essentially the same data online in the ZK version of Arbitrum.

Be careful if you hear someone bragging that ZK can compress hours of data into a single node in time. If they only post a single data point at the end of a long period, then that means they didn’t provide an end for that period.

Conclusion: Practical considerations force Optimistic Rollup and ZK systems to handle finalization in time in the same way.

Optimistic Rollup and ZK: The Vitality of Unconditional Trust

The dynamism of unconditional trust means that anyone can force the system to progress. (The security property of unconditional trust ensures that this progress is correct.)

An optimized Rollup allows any node statement to execute correctly. Making a claim simply requires the node to perform an on-chain transaction and then deposit a stake, which can be returned after the claim is confirmed by the protocol.

On the ZK system, progress requires that any node can create and publish one of the ZK proofs required to advance the chain state. This must use hardware and software that is readily available to anyone. As such, it must never require building or purchasing special-purpose hardware, nor can it do massively parallel computing. There must be a way to build proper ZK proofs on common devices. ZK providers that do not provide this service, or do not publish the code that generates proofs for their systems, do not provide unconditional trust in progress, nor do they have liveness guarantees for the system. Their system is centralized because only parties with special equipment can force progress. (It’s unclear if the leading ZK Rollup provider will make the proof viable for the average user.)

Conclusion: In an Optimistic Rollup system, it is easier to have unconditional trust progress.

ZK vs. Optimistic Rollup: Bridging

One area where ZK Rollup does have an advantage is bridging with Ethereum. The Optimistic Rollup system anticipates a one-week delay of funding from Rollup to L1, while ZK Rollup allows for the racking up immediately after the ZK proof is released to L1. In practice, this doesn’t make that much of a difference, as Optimistic Rollup users can take advantage of a fast-bridging service that swaps L2 funds for low-latency L1 funds. Therefore, ZK’s advantage is mainly that its users can avoid paying the small fees charged by bridging services (which compete with each other on price). This is not just theoretical: there are many real-time fast bridge services today that provide instant withdrawals from Arbitrum.

Importantly, the bridging advantage of ZK Rollups is fairly narrow: it only applies to bridging from L2 to Ethereum. Once upon a time (circa 2019), many believed that Rollups would provide a slow rollout of a live dapp or two. In such a world, Rollup users would constantly find themselves switching back and forth between L1 and L2. But that’s not the world we live in. Arbitrum has a thriving ecosystem with hundreds of dApps in every corner of Defi, and many users are building bridges with Arbitrum and staying there for the long haul. Also, since users skip multiple chains, they are not just going to Ethereum. They will also use other L1s and sidechains, and for this kind of direct bridging, ZK Rollups have no advantage over Optimistic Rollups.

Conclusion: The ZK system has a slight advantage in bridging with L1, but it is largely eliminated in practice due to fast bridging and multi-chain usage patterns.


Comparing the Optimistic Rollup to the ZK system, we think the Optimistic Rollup system is the clear winner. Optimistic is much cheaper, fully compatible with EVM and existing tools, the only real downside in practice is that L1 bridging will be slower without the fast bridging service. Other hypothetical advantages of ZK require sacrificing visibility or fastness of the chain, which we believe is not a tradeoff that users want.

None of this is likely to change. ZK-proof EVM-compatible contract execution will still be significantly more expensive than Optimistic Rollup execution, and the requirements to achieve guaranteed progress, on-chain visibility, and decentralization will also remain the same. While we’d always be willing to switch Arbitrum to a ZK-based execution if things change, we don’t think they will.

Finally, we conclude with caution. People tend to compare what Arbitrum provides today with what the ZK system represents in the future. But this comparison is meaningless, because if we compare the systems that exist today, Optimistic Rollups like Arbitrum are the only ones that support open deployment of general smart contracts. Or, if we compare future systems, then we should compare future Arbitrum and future ZK systems. We are continuously improving Arbitrum – for example, our upcoming version of Nitro includes cost reduction and better optimization for lossless compression of data on-chain. We are working tirelessly to improve Arbitrum and bring the cost down to the theoretical limit. As we show in this post, we believe that Optimistic Rollup is the clear winner when considering the systems that exist today and their respective theoretical limitations.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/optimistic-rollups-the-present-and-future-of-ethereum-scaling/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-01-11 09:28
Next 2022-01-11 09:29

Related articles