ZkEVM explained: examining future of zk rollups

ZkEVM explained

Over the past couple of years, rollups have emerged as one of the most promising solutions to the scalability problem that Layer 1 networks have faced pretty much since the inception of blockchain technology.  

As we’ve already discussed on these pages, there are two types of rollups – optimistic rollups and zero-knowledge rollups (zk rollups). The latter, in particular, has received some high profiled endorsements, including from the creator of Ethereum himself, Vitalik Buterin, who has said that zk rollups will outperform their optimistic counterparts in the long term. That said, optimistic rollups have so far shown that they are more ready for primetime, having taken an early lead by powering two of today’s mоst promising Layer 2 scaling platforms – Optimism and Arbitrum. So why is that?

Well, while zk rollups have many desirable properties, they also have one significant drawback – they do not have native support for the Ethereum Virtual Machine (EVM), meaning that they cannot execute smart contracts. This a pretty significant limitation for an Ethereum-based technology since smart contracts are at the heart of dApp development on the platform.

Fortunately, we are already close to solving the issue, with several projects working on implementing the Ethereum Virtual Machine. The new tech is known as zkEVM and is expected to unlock the full potential of zero-knowledge rollups.

What is zkEVM?

A ‘zero-knowledge Ethereum Virtual Machine’, or zkEVM for short, is, essentially, an implementation of the EVM that is tailored to the specifications of a particular zk rollup network. In other words, a zkEVM is designed to support both zero knowledge generation and smart contract execution. Ultimately, the goal is to ensure that zk rollups can process any transactions that occur on mainnet Ethereum and can support L1 Ethereum dApps, though, as we’ll see below, currently some projects are choosing to prioritize performance over compatibility with the existing Ethereum infrastructure. 

Types of zkEVM

While the main goal of all zkEVM implementations is the same, there are different approaches based on what each projects chooses to prioritize compatibility with Ethereum or speed. 


There’s a very good reason for zkEVM implementations to pursue compatibility with Ethereum – it practically ensures that rollup developers can reuse a lot of existing infrastructure and tooling which allows for smooth development. 

The main drawback of this approach is that by emulating Ethereum so closely, thеse types of zkEVMs inevitably inherit the limitations that stem from the protocol’s design. Specifically, Ethereum was never designed with native support for zk-rollups in mind, so generating zero knowledge proofs requires a lot of calculation and takes a lot of time. Naturally, zkEVMs that prioritize compatibility with Ethereum do not make significant changes to mitigate those limitations.

This is not to say that there are no changes whatsoever, as there are different ways to pursue that compatibility. Some zkEVMs aim for full Ethereum equivalency and do not change any part of the system. Others target perfect EVM equivalency, meaning that they implement the Ethereum Virtual Machine as is, but make some modifications to some data structures like those responsible for storing Ethereum state. These changes result in some slight improvements in proof generation times and are subtle enough to allow most Ethereum apps to run on a zkEVM rollup with only slight modifications.

There’s another way to improve prover time without significantly compromising compatibility. The approach calls for increasing the gas price for operations that are particularly difficult to zk-prove, incentivizing optimization. Vitalik Buterin refers to such zkEVMs as Type 2.5.


On the other hand are  the zkEVMs that make concerted efforts to optimize for shorter prover times (proof generation times). Here we also have room for different approaches. On the one hand we have projects that still value compatibility, but are willing to sacrifice the complete EVM equivalency in exchange for faster prover times. To that end they remove operations like precompiles, which  are difficult to zk-proove. Naturally, this results in a greater EVM incompatibility compared to the types we already mentioned. While the goal here is to allow for most Ethereum apps to work with minor changes, this is not always possible, especially when the apps in question use precompiles or other removed operations.

Finally, some zKEVM teams take optimization to another level, taking smart contract code written in Solidity or another language and compiling it to a zkSNARK friendly language. This approach offers significant advantages in terms of prover time optimization and cost efficiency. However, zkEVM systems of that type are even more incompatible with Ethereum, which can lead to significant complications that developers should always keep in mind.

Notable ZkEVM projects

Over the past few months several zkEVM projects have been gaining more and more traction. Here are the most promising projects in this field.


The biggest scaling solution on the market last year demonstrated its ambitions to conquer the rollup space as it acquired one of the most promising ZK rollup projects – Hermez. Since then, the Hermez project has been rebranded to Polygon zkEVM, signaling Polygon’s sharpened focus on building its own zkEVM implementation.

According to the classification proposed by Buterin, Polygon zkEVM is a type 3 zkEVM implementation. As we mentioned above, type 3 zkEVMs are almost EVM-equivalent, but make some changes in order to improve performance. That said, Polygon’s plans are for the project to eventually have a type 2 (EVM-equivalent) zkEVM implementation.

Some notable changes introduced by Polygon zkEVM include changes to supported opcodes, partial support of precompiled contracts and the addition of zk-counters. According to Polygon, the changes have no impact on the developer experience and the zkEVM supports popular libraries such as Web3.js and Ethers.js, gas optimization techniques and seamless contract deployment.

At the same time, Polygon zkEVM is being designed with a strong focus on performance, with fast network finality and low transaction fees. The consensus mechanism used by the network plays a key role in making this possible. Polygon zkEVM uses a Proof of Efficiency (PoE) mechanism, which is highly efficient and protects against malicious attacks. In addition, Polygon uses proprietary for fast zk-proof generation, which utilizes recursive STARKs for scalability.

Another important part of the network is the zkEVM Bridge, which is designed to connect Polygon zkEVM to the Ethereum mainnet, as well as any Layer 2 networks built on Ethereum.

The Polygon zkEVM network is currently in beta.

ZkSync Era

ZkSync Era is another prominent name in the zkEVM space. This is a ‘type 4’ implementation, which makes notable changes to the EVM, aiming to optimize performance. Still, according to the zkSync team, Era can handle most EVM contracts.

Some of the changes include: a number of removed or modified opcodes; different behavior of the CREATE and CREATE2 opcodes, which can result in smart contacts having different addresses compared to the EVM; a different gas model and more.

Here we also have a focus on performance, with an aim at achieving  fast prover and verifier times. Era uses zk-SNARKs, which have considerably smaller proof sizes than their STARK counterparts.


The Scroll network is one of several ‘Type 1’ zkEVM projects, which target full Ethereum equivalency. To that end, Scroll uses the most popular Ethereum client, GETH, which makes it fully compatible with Layer 1 dApps. As we mentioned above, however, the price for this compatibility is slower prover times.

Nevertheless, Scroll uses cutting-edge technology for ZKP generation. The network relies on Halo 2 – a Plonk-based system for scalable proof generation developed by the Zcash team.

The Scroll network is currently in its Phase 3, having recently launched an alpha testnet on the Ethereum public testnet Goerli. Phase 4 involves launching the Scroll mainnet.


The projects listed above are just  some of the players involved with zkEVM technology. Others like Taiko and StarkNet are also doing impressive work in the space, contributing to the growing excitement and interest in the tech. The impressive progress made by zkEVM researchers in the span of just over a year is one of the reasons why many Web3 observers believe that zk-rollups are the future of Ethereum scalability. Whether that would be the case remains to be seen, but so far the signs have been extremely promising.

If you want to pursue a career at a world-class Web3 development company, LimeChain is the place for you! Check out our Careers page to find the perfect role for you!