An Ethereum Debate: How Optimistic are we about Roll-ups?

Rolling into the Deep: A Deep Dive into Optimistic Rollups and Zero-Knowledge Proofs for Ethereum Scaling

Since DeFi Summer 2020, there is a lively debate in the Ethereum community regarding the best approach to scaling the platform. One side argues that zero-knowledge (”ZK”) rollups are the future, while another side advocates for Optimistic Rollups (”OR”). Same same, but different. In essence, the main difference between the two is the way they prove the correctness of transactions occurring on the Layer 2 (“L2”) chain.

ZK rollups use validity proofs (also known as zero-knowledge proofs / ZKPs), which require the proving party to execute the chain and do a series of complex cryptographic operations to construct the proof. This is expensive and requires special-purpose hardware devices or massive parallelism to prove at scale. On the other hand, the traditional OR uses fraud proofs that allow nodes to make a claim about what is the correct outcome of executing some transactions without posting any proof. Other nodes can execute the same transactions and can post a challenge if they disagree with the prior node’s record and this entire process is managed by a contract on the main Ethereum Layer 1 (“L1”). In most cases, all nodes will automatically process all transactions because parties are highly motivated to submit accurate claims and contest any incorrect ones. Consequently, there is usually no need to activate the proof code.

An original way I like to think about it is akin to when you plan to make a bank transfer. You could either (A.) instantly send money via a bank account or wallet using a password + OTP (ZKP method) or (B.) send in a cheque which needs to be cleared (OR method). In the case of (A.) the bank is able to validate your details based on the fact that you have provided both passwords to approve the transaction, therefore waiving the need to check your identity further. Whereas in (B.), the bank has the option to make call-backs while employing a short clearance and dispute period to ensure that the money being wired (especially for larger amounts) has been properly authorized and legally clean before making the transfer official.

With the beginner’s analogies out of the way, the debate between ORs and ZKPs has several dimensions and this essay will attempt to walk through some of them. Namely: Costs, EVM Compatibility, Trustless Visibility, Bridging Speed, Finality Times, Security Assumptions and Hardware Requirements.

TL;DR:

In summary, I’ve consolidated a quick cheat sheet below for easy reference:

Costs

In this regard, Optimistic Rollups (“OR”) have a large cost advantage over ZK Rollups (“ZK”). OR calls for the nodes to only perform contract execution, whereas ZK necessitates the generation of a intricate cryptographic proof that entails hundreds to even thousands of costly elliptic curve computations for each contract instruction.

This means that when it comes to the simple execution of instructions, ZK is inherently at a cost disadvantage due to the need to produce a complex cryptographic proof over every instruction. ZK proofs are also very expensive to construct, which means that full participation in a ZK protocol probably requires custom-built hardware and/or massive parallelism, making the network effectively more centralized, especially when scaled. In contrast, OR can provide the properties that users want, at lower cost, because of the very high off-chain costs of constructing ZK proofs. This means that ZK Rollups are generally more expensive than ORs, and this cost disadvantage could potentially limit participation in the protocol.

Overall, the inherent cost advantage of ORs over ZK Rollups makes ORs a more practical choice for developers who want to build scalable Decentralized Applications (“dApps”) on the Ethereum network. This means that ORs are currently more accessible, which can lead to greater decentralization and increased participation in the network.

EVM Compatibility

Another consideration is Ethereum Virtual Machine (EVM) compatibility. OR is fully EVM compatible, meaning any (byte)code written for Ethereum works out of the gate on OR. This is not the case for some ZK systems that disregard EVM compatibility as legacy tooling and encourage people to learn their custom languages. Some ZK systems are working towards an EVM compatible version, but it is hard to find any public code or benchmarks for what the costs of proving would be for user-defined zkEVM contracts.

Why is EVM compatibility is an important consideration in the development of smart contract systems? EVM compatibility is a big win for new projects that haven’t written any code yet, as it allows these projects to tap into the code, tooling, and talent pool that exist around the EVM. This is a huge benefit to new projects to kickstart their codebase, as EVM-compatibility enables them to leverage the existing code libraries, resources, and developers within the EVM ecosystem, which can be a significant advantage in terms of efficiency and cost-effectiveness.

Optimistic Rollups are fully EVM compatible, which means that they have the same RPC interface as the EVM. The best part is that EVM compatibility has minimal cost, making it an ideal choice for developers. On the other hand, some ZK systems either disregard EVM compatibility as legacy or encourage people to learn their custom languages (Rust, Solidity, Move, Cairo etc.).

zkEVMs are relatively new and are being developed with varying degrees of Ethereum-compatibility and performance. While some, like Ethereum's research arm, are aiming for near-perfect compatibility with Ethereum, this comes at the cost of performance and may not be production-ready for some time. Other companies, such as StarkWare, have deployed high-performing zkEVMs like StarkNet, but these require the use of a new programming language called Cairo, which presents a challenge for adoption as developers need to learn how to execute their smart contract code in this new environment. Other projects, such as Polygon’s Hermez, zkSync Era, and Scroll, are working to address these challenges to make zkEVMs more accessible to developers.

However as it stands, most existing ZK systems are purpose-built and custom-engineered for particular applications that are well-suited for ZK implementation. One such use case which is worth checking out is my favorite perpetual DEX dYdX built on StarkWare technology.

On the whole, these fundamental incompatibilities with EVMs signal to us that even in the best case, zkEVM compatibility will merely asymptote and may never be on par with the full EVM-compatibility of Optimistic Rollups.

Furthermore on the flip side, existing ORs are taking a step further in scaling Ethereum by appealing to all blockchain developers. To achieve this goal, Optimistic Rollup solution Arbitrum’s recent release of Stylus is one such technical development that will allow multiple programming languages to live within a single Arbitrum chain, starting with Rust, C, and C++ (for devs who code in javascript). This development will open the doors to a white space of developers, web 2 users, and enterprises, making it easier for them to build on top of the Arbitrum ecosystem.

Trustless Visibility

Trustless visibility is another key property when designing a Layer 2 chain. OR provides trustless visibility, meaning anyone can see or derive, without help from a centralized party, the contents of the chain. This means that everyone can see the full chain history and how it arrived into its current state. ZK Rollups on the other hand post occasional state snapshots to the main ETH chain, by compressing the data further than OR. This data is only visible to the ZK prover but raises concerns on accountability and potential (accidental) exclusion of important data.

In terms of trustless progress, OR allows any node to claim a correct execution, while ZK dictates that only nodes meeting the high hardware requirements can create and post one of the ZK proofs needed to progress the chain’s state.

While the lack of visibility might be seen as a disadvantage by some, it is actually a perk for purveyors of privacy. ZK rollups can provide complete transaction privacy by using zero-knowledge proofs (ZKPs) to obscure transaction details. This means that transaction amounts, participants, and other sensitive information can be kept private while still maintaining the security and scalability benefits of a rollup. Additionally, because ZKPs allow for the verification of a transaction without revealing any details, they can also be used to enable private voting, personal identification, and other cases where confidentiality is critical.

Some novel use cases identified by Bessemer Venture Partners demonstrate the versatility of ZKPs in various industries, from finance to gaming. ZKPs allow for secure and private transactions while maintaining the integrity of the network. In the case of Filecoin, ZKPs ensure that users can check and trust that storage providers are actually warehousing the data. In ZK enabled games like Dark Forest, ZK tech enables players to explore the virtual universe cheaply and swiftly while maintaining their privacy. And in the case of undercollateralized lending, ZKPs provide a means for verifying a user's bank account balance without revealing sensitive information. As the use of ZKPs continues to grow, it will be interesting to see what other innovative applications emerge.

Source: Bessemer Venture Partners

Bridging to Ethereum

The one area where ZK rollups do have an advantage is when it comes to bridging to Ethereum. Optimistic rollups incur an expected weeklong delay to transfer funds from the rollup to L1 because of their designed 7-day fraud dispute window, whereas ZK rollups allow bridging as soon as a ZK proof has been posted to the L1. However we are seeing new bridging solutions such as Across Protocol which effectively reduces the Optimistic L2 to L1 wait-time to near instant (less a fee). Basically serving as the insurance middleman between urgent bridgoors and the bridges.

Finality Times

As we covered above, Optimistic systems provide trustless visibility at minimal cost, and frequent and regular finality. To complete a set of transactions, validators need to put the sequence on the L1 chain. The rollup has to include enough information so that anyone can check the transactions and verify that they're correct. A good rollup should post the sequence on the L1 chain as often as possible, (ideally every <1min). This ensures that users get quick confirmation that their transactions are done and final. OR achieves fast finality by separating sequencing of transactions from their execution. Finalizing the sequencing produces a deterministic function which verifies the sequence of transactions. ZKs, on the other hand, have exorbitant posting costs where proofs on-chain can cost between 500,000 and 5 million gas units (which for the uninformed, translates to a lot of $$), depending on implementation. Therefore we often see ZK proofs posted hourly, which lengthens finality time to an hour.

Security Assumptions

Another key difference between OR and ZKPs is the level of trust assumptions involved in transaction processing. OR assumes that most parties will act honestly, and if there is a disagreement, there is a mechanism in place that ensures the correct outcome. This requires a dispute period during which anyone can challenge the accuracy of the transaction, after which the transaction is finalized. On the other hand, the security of ZKPs is based on the assumption that the proving party cannot cheat. However, if the proving party has access to more computational power than the verifier, cheating may be possible. This means that as ZKPs become more heavily used, each contract instruction will require a more intricate and costly cryptographic proofs. Resulting in higher costs and a more centralized system, ultimately leading to the conclusion that their significant investment in hardware budget is the critical to their security.

Intriguingly on this front, Offchain Labs, the team responsible for the Arbitrum L2 scaling solution, has recently launched a new chain named Arbitrum Nova which aims to serve as a hybrid bridge between traditional ORs and ZKPs. Unlike their original Arbitrum One chain, which was built on the original OR technology, the Arbitrum Nova chain is built on AnyTrust technology that is optimized for strong security guarantees at extremely low costs.

Arbitrum One offers transaction processing with minimal trust assumptions, as all transaction data is batched and posted to L1 by the sequencer. In contrast, Arbitrum Nova adds a minimal trust assumption to the transaction data handling process, which assumes at least two honest committee members allowing any trusted member to push the chain sequence forward ensuring chain liveness. This differs from Arbitrum One's trustless design. Arbitrum One constantly puts all transaction data on Ethereum, while Arbitrum Nova utilizes a data availability committee (DAC) which includes OpenSea, Reddit and Consensys to name a few. The DAC is responsible for signing Data Availability certificates (DACerts) for transaction batches, which are the only items posted to L1. This results in much smaller storage requirements on the base layer. To maintain data availability, the committee runs Data Availability Servers that offer a standardized REST API for fetching data batches by hash.

Resultingly, thanks to the DAC members, transactions on Arbitrum Nova have significantly lower transaction fees compared to Arbitrum One. While Arbitrum One claims to be up to 97% cheaper than Ethereum for many transaction types, Arbitrum Nova will be even lower cost. This makes Arbitrum Nova perfect for projects with high transaction volume expectations like games that frequently mint new NFTs or currency or social projects with many layers of on-chain interaction. Simply put, Arbitrum Nova’s posting operations sits squarely between traditional ORs and ZKs.

Broadly speaking Arbitrum One is designed to be an EVM-compatible L2 solution for DeFi and NFT projects, and Arbitrum Nova is tailored towards gaming, social applications/dApps, and other use cases that require even lower transaction costs and higher transaction volumes.

Hardware Requirements

ZKPs require expensive elliptic-curve-based proofs, which require expensive purpose-built hardware devices or massive parallelism to prove at scale, as the cost of proving increases exponentially with the linear increase of instructions within a contract. This means that ZKP-based solutions can be resource-intensive and require specialized hardware like GPUs or FPGAs for efficient execution. This runs in contrast to ORs, which only require nodes to execute contracts, making them much cheaper. Ultimately, ZKPs require more specialized and expensive hardware compared to optimistic rollups. Therefore, in order for ZKPs to win wide adoption long-term, they must be using hardware and software that is readily available to anyone. I see two possible paths forward here: either improving ZK tech to reduce the requirements for building or buying exotic, special purpose hardware, or cut down on massive parallel computations. With Moore’s and Kurzweil's law in motion, one would hope it’s a matter of time.

Still, in conjunction with the security considerations discussed previously, it is possible that ZK proponents may view their high hardware budgets as a security moat, by creating a capital intensive barrier against potential malicious actors who may attempt to compromise their proofs or manipulate the posted calldata.

Conclusion

In summary, the debate between Optimistic Rollups and Zero-Knowledge Proofs is a complicated one with several trade-offs to consider. ORs provide a cost-effective, EVM-compatible, and trustless finality solution (for the most part), making them more accessible and potentially more decentralized. However, they lack the privacy-preserving properties of ZKPs, which are more expensive and require specialized hardware for efficient execution. ZKPs offer different levels of transaction privacy, allowing for secure and private transactions, while maintaining the integrity of the network. Additionally, they have shown versatile use cases in various verticals, from finance to gaming. As ZK adoption continues to grow, it will be interesting to see what other innovative applications emerge. Ultimately, developers must weigh the trade-offs between cost, security, privacy, and other factors to determine the approach that best fits their project's requirements. Either way, the user wins.

Disclaimer: This article is intended for informational and entertainment purposes only and should not be construed as financial advice or as representing the views or opinions of the firms which I represent. The information presented in this article is believed to be accurate and reliable, but no representations or warranties are made with respect to the accuracy, completeness, or reliability of the information. Any action you take upon the information presented in this article is strictly at your own risk and we will not be liable for any losses or mistakes that may occur. You are advised to conduct your own research and consult with a qualified professional before making any financial decisions.