We all know that Ethereum blockchain needs a scale solution, and the most possible approach to scale up the network, currently we should believe in is the zero-knowledge technology, the most promising pathway to get there. However, the level of technological and algorithmic complexity is still a big barrier for projects on Ethereum. The conventional wisdom has been that the Ethereum network would need many years to develop Layer 2 scaling solutions that could give us both the scalability benefits of zk proofs and compatibility with the Ethereum Virtual Machine (EVM). The vision for a zk-EVM with complete EVM-equivalence is simple which will facilitate developers seamlessly deploying any Etehreum smart contract to a Layer 2 using zk proofs. Users and developers alike reaping the futuristic benefits of zk proofs, all while benefiting from the decentralization, security and familiarity of Ethereum. Any tooling or dApp on Ethereum used in exactly the same way on a zk-EVM. Increasingly, we are seeing that zk-EVM has become the key to scaling Ethereum.

When comparing the two scaling solutions of Optimistic and zk-rollups, Vitalik Buterin has opined that Optimistic Rollups will probably win in the short term for general purpose EVM calculations. But in the long term, zk-rollups will win in all scenarios with the improvement of zk-SNARK technology. The so-called ‘Improvements in zk-SNARK technology’ mainly refers to the success of zk-EVM.

Polygon (MATIC) is one of the most popular scaling solutions for smart contract developers on Ethereum network. In addition, to accelerate the mass adoption of crypto for personal sovereignty, zkSync will launch the first EVM compatible zk-rollups into production in early Fall 2022. Hence, there are many blockchain projects that are preparing to integrate zk technology. That shows that zk-EVM can become a phenomenon in the late of 2022.

I. What Is A ZK-EVM?

zk-EVM stands for zero-knowledge Ethereum Virtual Machine which means an EVM-compatible virtual machine that integrates zero-knowledge proof technology. Unlike regular virtual machines, a zk-EVM proves the correctness of program execution, including the validity of inputs and outputs used in the operation. In order to fully understand zk-EVM, we need to know what EVM is and what is zero-knowledge proof first.

Zero-Knowledge Proofs Technology

For ZKP, we already had an article detailed sharing in a very clear language. Different zk-EVM projects adopt different approaches to combining EVM execution with ZKP computation. Each type has unique traits and tradeoffs, which we will explore in a few next sections.

Ethereum Virtual Machine

The Ethereum Virtual Machine (EVM) is a powerful, sandboxed virtual stack embedded within each full Ethereum node, responsible for executing contract bytecode. Contracts are typically written in higher level languages, like Solidity, then compiled to EVM bytecode. This means that the machine code is completely isolated from the network, filesystem or any processes of the host computer. Every node in the Ethereum network runs an EVM instance which allows them to agree on executing the same instructions.

A virtual machine is “EVM-compatible” if it can run programs created to run in the EVM environment. The EVM is essential to the Ethereum protocol and is instrumental to the consensus engine of the Ethereum system structure. It allows everyone to execute code in a trustless approach in which the outcome of an execution can be guaranteed and fully deterministic executing smart contracts.

II. How Does A ZK-EVM Work?

At present, multiple teams are working on the research of zk-EVM, so to begin with, let’s take a look at the basic process of zk-EVM.

A zk-EVM is a virtual machine that transitions between states as a result of program operations. But the zk-EVM goes further by producing a proof to attest to the correctness of every part of the computation. Essentially, a zk-EVM uses a mechanism to prove that the execution steps (as described earlier) followed rules. The zk-EVM generates zero-knowledge proofs to verify various elements in each computation:

• Bytecode access: Was the appropriate program code loaded correctly, from the right address?
• Read-write operations: Did the program fetch the right values from stack/memory/storage before the computation? Did the program write the correct output values to the stack/memory/storage after completing execution?
• Computation: Were the opcodes executed correctly (i.e., one after the other, without skipping steps)?

Two Implementation Strategies

For zk-EVM, there are currently two main implementation strategies.

• Direct support for the existing set of EVM opcodes, which is fully compatible with the set of Solidity opcodes. Those using this solution include Hermez and the Ethereum Foundation zk-EVM.
• Maintaining Solidity compatibility by designing a new virtual machine that is zero-knowledge proof-friendly and adapting EVM development tools. This solution is mainly used by zkSync.

For the first strategy, since it fully supports the existing set of EVM opcodes and uses the same compiler as EVM, it is naturally fully compatible with the existing ecosystem and development tools, and also inherits the security model of Ethereum better. For the second strategy, it is not bound by the original set of EVM opcodes, so it is more flexible to compile the code into a more zero-knowledge proof-friendly set of opcodes. It is also free from the hard and heavy work required to be compatible with all of the original set of EVM opcodes. Overall, the first strategy is more compatible and safer, but with more work; the second strategy is more flexible and less work, but extra effort in adaptation is required.

III. Why Is A ZK-EVM Important?

There are several advantages of a fully functional zk-EVM.

Firstly, it allows for secure scalability. Ethereum’s throughput difficulties can be resolved using EVM-compatible zk-rollups without compromising network security. The constraints of the Ethereum consensus mechanism do not apply to zk-rollups. Thus, it leads to faster execution speeds. Secondly, zk-EVMs will reduce transaction costs. Since the veracity of state transitions is already ensured by validity proofs, ZK-rollups can afford to post less information to Ethereum. Moreover, zk-EVMs ensure faster finality and capital efficiency. Utilizing the network effects is the main motivation for creating EVM-compatible. The largest smart contract platform in the world, Ethereum offers a sizable ecosystem that benefits both developers and projects. Developers have access to a wealth of tooling, documentation, and code libraries that have been rigorously tested and verified. The network effects of Ethereum cannot be utilized by projects or development teams if a new zkVM is built that is incompatible with Ethereum’s infrastructure.

To figure out the role of zk-EVM, we need some background knowledge. Let’s start with Ethereum which is, in essence, a transaction-based state machine. In computer science, a state machine is a machine that transitions from an old state to a new state by reading a series of inputs. Starting from the genesis state, Ethereum transitioned through block after block of transactions to the current state of Ethereum. The state contained all account addresses and their mapped account states.

Among them, the EVM, or The Ethereum Virtual Machine, is responsible for processing transactions. The EVM operates as a stack machine, where the programmer writes code in a high-level language such as Solidity, which is then compiled into EVM bytecode that the EVM understands. The EVM performs standard stack operations as various EVM opcodes which eventually produces a new state. And now comes the problem. We know that the zk Rollup solution needs to generate zero-knowledge proofs for transactions on L2 and pass them back to L1 for verification. To generate zero-knowledge proofs, the processing of the transactions needs to conform to the zk circuit proof specification. And at the beginning of the EVM design, the designers did not consider supporting zero-knowledge proofs (it was 6 or 7 years ago, and zero-knowledge proofs were not on the minds of most people). Thus, we need zk-EVMS. Technically, the meaning of zk-EVM is: A virtual machine that runs on the zk Rollup network, is EVM-compatible and zero-knowledge proof friendly.

IV. Different Types Of ZK-EVMs In Comparison

Scroll (Fully Ethereum-Equivalent)

AppliedZKP is a project funded by the Ethereum Foundation to develop an EVM-compatible zk-rollups and a mechanism for generating validity proofs for Ethereum blocks. AppliedZKP’s innovation is the separation of computation from storage. It uses two types of validity proofs: state proofs and EVM proofs.

• State proofs: checks that operations touching storage, memory, and stack happened correctly. The proofs essentially verify the accuracy of read-write operation.
• EVM proofs: Checks that the computation called the accurate opcode at the right time. The EVM proofs verify the computation itself and also confirms that the state proof executed the right operation for each opcode.

The AppliedZKP zk-EVM uses a bus mapping to link the state proof and EVM proof. Also, both proofs must be verified before the Ethereum block is deemed valid. AppliedZKP zk-EVM is what we ultimately need to make the Ethereum layer 1 itself more scalable. This type is also ideal for rollups, because they allow rollups to re-use a lot of infrastructure. For example, Ethereum execution clients can be used to generate and process rollups blocks, or at least, they can be once withdrawals are implemented and that functionality can be re-used to support ETH being deposited into the rollups. So, tooling like block explorer, block production, etc. is very easy to reuse.

On the other hand, Ethereum was not originally designed around zk-friendliness, so there are many parts of the Ethereum protocol that take a large amount of computation to zk-prove. AppliedZKP zk-EVM aims to replicate Ethereum exactly, and so it has no way of mitigating these inefficiencies. At present, proofs for Ethereum blocks take many hours to produce and this can be mitigated either by clever engineering to massively parallelize the prover or in the longer term by zk-SNARK. The author recommends the audience to read through Vitalik’s article From Zero to Hero Guide to SNARKs.

Hermez zk-EVM (Fully EVM-Equivalent)

Hermez uses the first strategy, which translates the entire set of EVM opcodes into micro opcodes. It is well known that there are some variable EVM opcodes, such as CALL, EXP, CREATE, etc., which are inherently unfriendly to zk circuit proofs, and the logic of these opcodes can be expressed in a more friendly way using micro opcodes. The micro opcodes are executed in uVM, which uses a large number of cryptographic tools to achieve zk completion, and uses the Plookup algorithm to improve proof and verification efficiency.

Another highlight of the implementation of Hermez zk-EVM is that it uses two proof systems at the same time, specifically generating a STARK proof and then using PLONK or Groth16 to generate a proof of the STARK proof and verify it on L1, could say a proof of the proof. The reason for this is that while STARK is excellent, the proof size is large and the cost of verification on the chain is high, while Groth16 or PLONK has a smaller proof size and faster verification speed. This combination of the two, each with its strengths, is easy to think of as a scenario where asymmetric and symmetric encryption algorithms are used in combination.

Hermes zk-EVM makes changes to data structure that hold things like the Ethereum state. Fortunately, these are structures that the EVM itself cannot access directly, and so applications that work on Ethereum would almost always still work on a fully EVM-equivalent. However, it has improved but is still slow in terms of prover time. The slowness from having to prove the EVM, with all of the inefficiencies and zk-unfriendliness inherent to the EVM, still remains.

zkSync EVM (High-Level-Language Equivalent)

zkSync is an EVM-compatible zk-rollups developed by Matter Labs and powered by its own zk-EVM. Unlike Hermez and AppliedZKP, zkSync choose the second strategy. zkSync’s  is not a replica of EVM but is newly designed to run 99% of Solidity contracts and ensure that it works properly under a variety of conditions (including rollbacks and exceptions). At the same time, zkEVM can be used to efficiently generate zero-knowledge proofs in the circuit. zkSync EVM uses TinyRAM to implement the common set of opcodes, while opcodes that consume a lot of gas, such as SHA256 and keccak, will implement its circuit especially, and finally uses recursive aggregation technology to aggregate all proofs into one for improved efficiency.

zkSync has also developed two compiler front-ends for zk-EVM: Yul and Zinc. Yul is a micro Solidity representation that can be compiled into bytecode for different back-ends; Zinc is a language based on Rust for smart contracts and general purpose zero-knowledge proof circuits. This gives developers greater choice. Also, when building its compiler, zkSync chose LLVM, the most advanced compiler framework for producing industrial-grade products, to ensure that the compiler is sufficiently complete and has all the classic optimizations.

There is a lot of overhead that you can avoid by not zk-proving all the different parts of each EVM execution step, and starting from the higher-level code directly. Compiling from high-level languages directly really can greatly reduce costs and help decentralization by making it easier to be a prover. Nevertheless, a normal application written in Vyper or Solidity languages can be compiled down and it would “just work”, but there are some important ways in which very many applications are not normal. Such as contracts may not have the same addresses, or handwritten EVM bytecodes, loss of debugging infrastructure can’t be handled.

StarkNet

This is the approach StarkWare has taken with StarkNet, which is currently the most progressed general-purpose rollup. StarkNet runs a custom smart contract VM (Cairo VM), with its own low-level language (Cairo), both purposes built for smart contract rollups. This means StarkNet has no Ethereum compatibility out of the box — as we saw earlier, even opcode-level VM-level compatibility is a potential handbrake on rollup performance.

This approach to building a smart contract rollup is maintaining “Solidity-compatibility”: you’re not executing programs inside the EVM, nor maintaining compatibility with any other Ethereum interfaces, but Solidity developers will be able to write code which can be used on your rollup. You can therefore maintain a similar developer experience to Ethereum, without having to compromise the fundamental layer of your rollup — having your cake and eating it too. However, there are several additional tradeoffs to this approach. The first is that building your own VM is challenging — the Ethereum team has had more than half a decade to iron kinks out of the EVM, and is still frequently making upgrades and fixes. A more custom rollup will allow for better performance, but you will lose the benefit of the collective improvements made to the EVM by every other chain and rollup. Next, supporting Solidity via transpiler risks a potential loss of composability — if developers are writing contracts in both CAIRO and Solidity, there is a substantial chance that the tooling to support the interface between both will be brittle.

Possibly most importantly, the StarkNet team is currently not aiming for compatibility with other Ethereum components — they are rolling their own client APIs, javascript libraries and wallet system, which will force Ethereum-compatible tools to add StarkNet support manually. This is extremely challenging, but not impossible.

However, if they can do so successfully, the StarkWare team will look to replicate the first mover advantage of the EVM with the first smart contract VM optimized for zk-rollups.

V. Current State of ZK-EVMs

Given the detail required to understand the above, it’s no wonder we’ve invented a bunch of confusing language around Ethereum compatibility. In truth, no zk-rollup perfectly mirrors the behavior of the EVM in all circumstances — it’s all a matter of degree, and the detailed choices made by each team will end up mattering most when it comes to maintainability and performance, rather than compatibility alone.

It is crucial to understand that none of the above approaches are inherently superior. It's a categorisation, not a hierarchy. They all make different tradeoffs: easier to build, maintain and upgrade, more performant, more easily compatible with existing tools. Ultimately, the leading rollup will also be determined by better distribution and marketing, rather than pure technical capability.

VI. Some Thoughts On The Future Of ZK-EVMs

The mentioned types of zk-EVM are not unambiguously better or worse than others. Rather, there are different points on the tradeoff: lower equivalence types are more compatible with existing infrastructure but slower, and higher equivalence types are less compatible with existing infrastructure but faster. In general, it’s healthy for the environment that all of these types are being explored.

Personally, the author’s opinion is that everything comes to the AppliedZKP zk-EVM type, through a combination of improvements in zk-EVM and improvements to Ethereum itself to make it more zk-SNARK friendly. In such a future, we would have multiple zk-EVM implementations which could be used both for zk-rollups and to verify the Ethereum chain itself.

However, it’s going to take quite some time until we get to such a future. In the meantime, we are going to see a lot of innovation in the different paths to scaling Ethereum and Ethereum-based zk-rollups. With the Merge right around the corner, battle-tested application-specific rollups in production, and general purpose rollups hitting mainnet over the next year, the future of Ethereum scaling is right now. And final thought, with the plan of multiple zk-EVMs, the era of Ethereum dominance is finally upon us.