Introduction

There have been a number of approaches to designing ZK-Rollups. Examples include:

• Starkware using the validity proof optimized language Cairo
• zkSync designing their rollup to be EVM-compatible at the language level
• Scroll and Hermez designing their rollups to integrate the EVM at the bytecode level

This report seeks to provide a better understanding of the significance of the EVM integration into a ZK-Rollup and a general overview of various ZK-Rollup models.

What is the EVM and why is it important?

The Ethereum Foundation: “The EVM is what defines the rules for computing a new valid state from block to block.” It enables permissionless participation and the execution of code in a trustless environment where the outcome is guaranteed through deterministic smart contracts."

Source: Ethereum

Ethereum has the greatest wealth of infrastructure, tooling, and developers of any blockchain ecosystem. This infrastructure and tooling have been built to work with the EVM - creating a very strong network effect around Ethereum and specifically to the EVM.

EVM dominance is demonstrated by the rise of L1 blockchains. BNB Chain, Avalanche, and Fantom notably rose to prominence in 2021 - all of which are EVM compatible. A noticeable exception is Solana, but even they are experimenting with the EVM via Neon. A key benefit of EVM compatibility is that users are familiar with the tooling around it such as Metamask.

Source: Defillama as of 14/07/22

The network effect of the EVM is apparent in that 9 of the top 10 chains by TVL have EVM compatibility and the other is aiming to become EVM compatible.

The EVM’s popularity is not because it is objectively better than other virtual machines but due to its first-mover advantage and the unrivalled ecosystem built around it.

• Developers are familiar with it and have far greater tooling to work with
• Users are familiar with the applications
• It also allows developers to build composable applications and projects to benefit from the large amount of liquidity that has been accumulated on the chain

Source: Electric Capital

The report by Electric capital demonstrates the strong dominance of Ethereum in terms of open-source developers. However, EVM dominance should not be taken for granted.

Crypto remains a very niche market and has a notoriously unfriendly user experience. There have yet to be any applications that truly bring crypto mainstream. It is plausible that the EVM can lose its dominance in the future, and different frameworks that are optimized for their specific application will take the industry to the next level. The EVM is simply the path of least resistance for developers due to the infrastructure built around it and familiarity with the current crop of users and developers.

The EVM is a generalized design structure that makes a number of tradeoffs, meaning it is not optimized for various use cases. Ecosystems like Polkadot and Cosmos are built on the premise that builders should have sovereignty regarding how their chains are designed so that they are completely optimized for their applications. In fact, dYdX has opted for a Cosmos chain in order to further optimize its product.

ZK-Rollup Refresher

ZK-Rollups are widely regarded as the most exciting scaling solution in crypto. At a high level, ZK-Rollups can be broken down into three characteristics:

1. Transaction computation and sequencing occur in an off-chain environment on L2.

   • ZK-Rollups batch a large number of off-chain transactions and generate a mathematical proof regarding their validity.
   • Examples of validity proofs are STARKs (StarkEx, StarkNet) or SNARKs (ZK-Sync, Aztec Network).

2. Transactions are then sent to L1.

   • These validity proofs are then posted to the Ethereum mainnet (L1).

3. There is a rollup smart contract on L1 that verifies the proof.

   • This crucially means that rollup transactions inherit the underlying security and decentralization of L1.

Rollups essentially move computation data storage off-chain, while retaining L1 security by posting the transaction data and a mathematical proof of its off-chain computation on L1 where it can be validated. It is currently mathematically impossible to include fraudulent validity proofs meaning that ZK-Rollups can rely on the mathematical integrity of the proofs.

ZK-Rollups take a ‘guilty until proven innocent’ approach whereby transactions are validated before being posted to L1. This differentiates them from Optimistic Rollups which take an ‘innocent until proven guilty’ approach to transaction validation.

Key actors in a ZK-Rollup include:

• Prover: Conducts mathematical validity proof to attest to the integrity of transactions.
• Sequencer: Block producer, arranges transactions in a block.
• Verifier: A smart contract on L1 that verifies the proof. This leverages the security and decentralization of L1.

The prover and sequencer are different roles but can be conducted by the same entity. In order to achieve censorship resistance in ZK-Rollups, these roles will need to be decentralized. This may work by having various provers/sequencers on standby and/or having a random rotation.

ZK-Rollups Today

ZK-Rollups remain a nascent but rapidly growing technology. The greatest adoption of a ZK-Rollup is currently StarkEx - which is essentially a scaling engine offered by Starkware (a software company developing ZK-Rollup blockchain scaling solutions).

StarkEx

Notable applications on StarkEx include:

• dYdX
• Sorare
• Deversifi
• Immutable X

These applications have demonstrated the high throughput and minimal cost of operating using this scaling technology. Controversially, dYdX has decided to build its next version on Cosmos rather than StarkEx - which is a public rebuke of the technology in favor of one that gives greater customization and decentralization (at present).

Source: StarkEx

StarkEx and StarkNet use the Cairo programming language which is optimized for STARK validity proofs. This is an example of a non-EVM compatible language being used that is optimized for its use case - rather than the generalized one-size-fits-all EVM. Using Cairo to build applications that use STARK validity proofs objectively makes sense. However, it means that it must overcome the major challenge of developer adoption. A Solidity to Cairo compiler is being worked on for quasi-EVM compatibility but this is arguably a sub-optimal solution as it does not fully implement the EVM, leaving developers with some additional challenges deploying in this way.

While some very high-quality applications have been built using StarkEx, they lack composability. Applications have a lower overhead through their customized circuit design and require knowledgable developers to implement this in the first place. For example, the StarkWare team helped develop aspects of dYdX’s product. Larger developer adoption of Cairo will be key.

Beyond StarkEx, StarkNet is in advanced stages of development. This is a smart contract platform that will utilize ZK-proofs and will enable composability among applications built on it.

Others are taking a more EVM-focused approach. Again, this is not because the EVM is inherently a better framework, but because it represents a far easier path to adoption.

zkEVM

zkEVM is a design to enable an EVM-compatible/equivalent ZK-Rollup. It is designed to allow smart contracts to execute in such a way that is compatible with validity proof computations. This leverages both the benefits of validity proof/ZK-proof technology with the infrastructure, tooling, and familiarity of Solidity and the EVM.

The EVM is inherently unsuited to validity proofs. However, there are various designs in implementing a ‘zkEVM’ that aim to enable mainnet applications to seamlessly port over the ZK-Rollup. Rollups that are implementing zkEVM are abstracting complexity away from developers who would otherwise need to build their own circuit, and enabling them to deploy in a familiar environment.

zkSync

zkSync (developed by Matter Labs) is developing a smart contract ZK-Rollup platform. However, compared to Starkware’s solutions, the Matter Labs team is placing greater emphasis on EVM compatibility - going as far as dubbing their solution ‘zkEVM’. Note that some claim that this is misleading as it achieves this by transpiling EVM code to its zkVM, meaning it is not actually a zkEVM.

Matter Labs essentially enables EVM compatibility by designing a VM that adapts EVM development tools and works well with validity proofs. This is not fully EVM equivalent, with Matter Labs optimizing their design to be more conducive to validity proofs. This design choice reduces the burden on Matter Labs to build a system that is compatible with all EVM opcodes which is far more complicated.

This means that some adaptation may be required for dApps porting to zkSync than would be the case with a more EVM-equivalent design. zkSync compiles code written in Solidity (primary EVM language) into Yul. Yul is an intermediate language for Solidity to be compiled to bytecode in LLVM - a compiler framework. This enables zkSync to achieve EVM compatibility.

In addition to Solidity, developers can use Zinc (a Rust-based language) for smart contracts and general-purpose zk-proof circuits. zkSync uses TinyRAM for implementing the common set of EVM opcodes but uses its own circuit for opcodes such as SHA256 which is a heavy gas consumer. For efficiency, recursive aggregation is used to aggregate all the proofs.

zkSync claims that 99% of code can be deployed directly to zkSync 2.0 without any need for alterations. It will be interesting to see how this transpires in practice. By not implementing EVM at the bytecode level, zkSync is arguably riskier than a bytecode-level zkEVM - however, this remains hypothetical as neither have been deployed on mainnet and therefore there is no empirical evidence.

The following diagram shows how this works at a high level:

Source: DeGate

Matter Labs recently open-sourced their Solidity compiler code. This can be viewed here.

zkSync can be described as EVM-compatible at the language level. This means that the zkVM transpiles EVM language e.g. Solidity to a SNARK-friendly VM. This adds some transpiler risk to the protocol.

Source: Polynya Twitter

The above diagram shows the relationship between various ZK-Rollups and EVM. As can be seen, Starkware and zkSync’s EVM compatibility occurs at the language level, whereas Hermez and Scroll are going a step further, by building a VM that can interpret EVM bytecode. This approach is notably more complex to build and was long considered unfeasible.

Scroll

Scroll is building a ZK-Rollup that seeks to be EVM-equivalent. This goes beyond the EVM-compatible zkSync Matter Labs is building which requires an additional step of an intermediary transpiler.

This was previously thought unfeasible, however, various advancements in technology have enabled this. These improvements include:

• Advancements at the hardware level (GPU, ASIC)
• Reduction in recursive proving costs.
  • Previously very large overhead costs. New techniques have been made that greatly reduce this cost.
• Lookup tables and customized gadgets
  • Lookup tables enable significant savings for ZK-unfriendly primitives.
• Polynomial commitments
  • Enables customized optimizations and choice in backend compared to previous proof protocols.

Scroll is building a rollup that aims to incorporate the EVM at the bytecode level by using a modular design. This means that tasks will be split among various different components that operate under independent constraint sets and have separate (but not unrelated) execution traces. (Source: Begassat et al)

Intermodule communication enables them to delegate computations outside their specialization to the relevant submodules. These connections are enabled by lookup arguments.

Scroll is seeking to enable an L1 user experience with near-instant transaction confirmation and significantly reduced gas fees. Scroll is using a fork of native GETH for block production - in order to create a protocol that is as close as possible to a native L1 implementation.

Custom circuits are built for each opcode. These sub-circuits are designed to ensure the same behaviour as that of the EVM.

At a high level, Scroll is designing circuits for each opcode that prove each opcode in the transaction trace is correct and consistent. While this would create a massive overhead cost if done directly, Scroll have arranged so that:

• Read/write and computation are done in 2 different proofs:
  • One contains the elements needed for all the opcodes.
  • The other proves the computation is carried out correctly.

On Scroll, transactions are sent to a node off-chain where the zkEVM generates a succinct validity proof attesting to the validity of state changes in the system. The proof is then confirmed on Layer-1. Scroll is working with the Ethereum Foundation on implementing the zkEVM.

Hermez

Polygon Hermez is also implementing the EVM at the bytecode level. It is very similar to Scroll in terms of architecture, however, technical differences arise whereby Scroll focuses more on a native implementation, while Hermez recreates EVM opcodes that can be deployed as smart contracts to create its zkEVM. Hermez uses SNARK and STARK validity proofs to achieve this end.

• STARK proofs are used where it is more efficient to do so - they enable very fast proving times.
• However, because STARK proofs are larger than SNARKs and therefore consume ~10x more gas, SNARKs are used to prove the validity of STARKs used in the system.

2 processes will be followed for verification of validity proofs:

• Batching of transactions
• Validation of batched transactions

These processes are carried out by Sequencers and Aggregators.

Sequencers

• Propose batches to the network
• Anyone should have the ability to become a sequencer
• Sequencers are required to pay a fee in MATIC to create and propose batches
• Sequencers are rewarded by users of the network
  • Note that it will need to be economically viable for sequencers given that they need to pay in order to participate. Therefore, the rewards must be greater than what they need to pay.

Aggregators

• Produces validity proofs attesting to the legitimacy of transactions.
• The fee paid by Sequencers is distributed to Aggregators.

Consensus Model - Proof of Efficiency (PoE)

This is designed to facilitate the permissionless participation of multiple actors to produce transaction batches at L2. This is a novel consensus mechanism that, like the rest of Hermez, is yet to be implemented in practice. In addition, the team is stated to be exploring combining this model with PoS.

The following diagram illustrates how this works: Source: Polygon Hermez

Volition

Hermez will also implement volition - whereby users can choose between rollup mode (where transaction data is posted on-chain, making it more secure and expensive) or validium (where transaction data is stored off-chain, making it far cheaper but less secure). This is important, as many applications will not require the security of on-chain data availability (rollup mode). In addition, it is likely that Polygon Hermez will be more expensive than other ZK-Rollups due to the complexity of implementing the EVM opcodes into ZK-Rollup. Again, this is speculation as Polygon Hermez remains a work in progress.

Thoughts On Polygon Ecosystem

Polygon Hermez demonstrates some interesting activity occurring in the Polygon ecosystem. While many will associate Polygon with Polygon PoS - the Ethereum sidechain - Polygon is in fact growing out a wider ecosystem of Ethereum-focused rollups.

The following graphic shows the wide scope of Polygon products being developed: Source: Polygon

These span sidechains, optimistic rollups, and ZK-Rollups. Polygon is building an ecosystem whereby these Polygon products can leverage the expertise of each other in building out the best possible scaling products for Ethereum.

Hermez is expected to go live on testnet this month (July 2022).

Key Takeaways

• The differing approaches to EVM compatibility/equivalence both come with their trade-offs. Compatibility at the language level enables a design that is more compatible with validity proof design. However, the bytecode-level approach is arguably safer, as it largely removes the additional complexity developers experience when deploying their applications on Layer-2.
• Both approaches are untested in practice, especially bytecode-level zkEVM. However, understanding these differences should be helpful in gauging which implementations could win out in practice.
• Polygon Hermez testnet launches in July 2022 and will be interesting to observe how this develops.
• Scroll remains in its infancy but is expected to launch testnet later this year and is an example of an exciting potential zkEVM.
• zkSync has been live on testnet for some time but is yet to launch mainnet. It does not incorporate the EVM at bytecode level, resulting in some claiming that it does not qualify as a zkEVM. It will be interesting to see what adoption it gets and whether applications can seamlessly deploy there.
• zkSync is expected to launch mainnet this year. The more complex zkEVM implementations by Scroll and Hermez will launch later and will likely take longer to scale up due to the additional complexity. If these can be deployed successfully and securely, they may be a key destination for high value NFTs and DeFi applications due to their EVM equivalence.
• Languages such as Cairo that are optimized for validity proofs may be better suited to developing new applications. However, it is a new language that needs to overcome some developer adoption challenges.