The introduction of EVM-compatible ZK-rollups (zkEVMs), is frequently seen as the holy grail when it comes to scaling Ethereum via rollups. Even while we haven't yet reached that point in terms of progress, a number of recent initiatives have increased the heat in terms of innovation, making what formerly seemed years away seem within reach. It's now a contest to see which of these early adopters can successfully deploy a zkEVM at scale and gain the upper hand in user adoption. It should be noted right away that this essay is not intended to be an introduction to rollups. As a result, you could forehead discover the comparison between Optimistic Rollups and ZK-Rollups to understand these fundamentals in length in case you are unfamiliar with the rollup environment on Ethereum as well as the overall benefits/drawbacks of adopting ZK-rollups in particular.

The current situation

Let us quickly review the reasons why ZK-rollups are frequently preferred over-optimistic rollups while keeping the aforementioned in mind. ZK-rollups have an advantage in terms of transaction finality (no challenge period) and security despite the fact that both types of rollups give significant advantages in terms of scalability and throughput. When it comes to the latter, ZK-rollups are typically seen as being safer since they rely on trustless cryptographic procedures for security rather than depending on other actors' honesty to provide fraud-proof. Optimistic rollups do, of course, offer certain unique advantages, such as the ability to construct proofs without needing to execute complicated computations that are best done on expensive equipment, but these are the main points to keep in mind regardless of other factors.

Of the two forms of rollups, optimistic ones are now the more EVM compatible. Additionally, the TVL of optimistic rollups is higher.

What is EVM compatibility?

One of the more underappreciated and misunderstood concepts in the field is the idea of EVM and its different kinds of compatibility. The phrase is used so frequently that you would assume everyone knows what it means, yet this is probably not the case. Therefore, it is crucial that we go over the subject again to make sure everyone has a firm understanding before we talk about zkEVMs.

Remember that the common objective of public, general-purpose rollups is to enroll developers and users as rapidly as possible in order to produce network effects in terms of adoption. This is the main benefit of EVM compatibility for future blockchain networks and rollups. Let's investigate how and why.

EVM

To begin, what exactly is EVM? EVM is an abbreviation for Ethereum Virtual Machine, which is essentially a software platform.

Recall that with a blockchain, there can only be one canonical "state" at any given moment (similar to a balance sheet). This state includes all of the blockchain's accounts, balances, and so on at that time. In the case of Ethereum, the EVM also functions as a massive database to store all of this data.

The EVM, on the other hand, has a more active role. Ethereum's state is not just a massive data structure including all accounts and balances, but also a machine state, which may change from block to block based on a set of principles. As you might expect, the EVM defines these restrictions, therefore any smart contracts attempting to conduct transactions on Ethereum that are not designed in accordance with the EVM will be rejected. Furthermore, since the Ethereum blockchain's record evolves with each authorized transaction, the EVM continually tracks and computes the network's new state. Let's look at an example to see what that means.

Assume you constructed an Ethereum smart contract or decentralized application (dApp). This contract, like any other typical smart contract, contains a stated set of operations that are to be performed when specific criteria are satisfied (given an input, the smart contract executes an output/function). To the degree that this smart contract follows the present EVM regulations, the EVM will aid in its execution, resulting in a new block and status on the Ethereum chain (which the EVM computes). For the technically savvy, the EVM aids execution by transforming smart contract opcodes (stands for operation codes, which are expressed in programming languages such as Solidity) into bytecode, allowing commands to be read and functions to be performed by the virtual machine.

EVM compatibility

What does a blockchain being EVM-compatible entail now that we have a basic knowledge of what the Ethereum Virtual Machine (EVM) is?

How a certain blockchain's smart contracts are created and used is related to EVM compatibility. A blockchain is said to be EVM-compatible if its smart contracts are created in a way that complies with the EVM's unique requirements and guidelines.

In very simplistic words, if you effectively copy and paste code that is operable on the Ethereum network and launch it on another blockchain, that other blockchain would be deemed EVM-compatible if it was constructed to handle and execute the transposed smart contract or code. Why might a different blockchain organize itself using these guidelines? The ability to "plug and play" significantly widens the ways in which developing blockchains can entice developers to join their ecosystem, is the answer. Ethereum is the world’s most prominent network – in order for other chains to possibly connect to its extensive web of developers and apps, they must adhere to what others are acquainted with.

Think about the problem for chains that are not EVM compatible. Non-EVM-compliant chains are given the opportunity to radically alter the Ethereum toolkit and differentiate themselves in a variety of ways by establishing completely new standards and ecosystems (some for the better). However, since the majority of developers are undoubtedly already familiar with Ethereum, it also makes it more difficult to get them into the new environment. If a blockchain is EVM-compatible, for instance, developers may instantly duplicate and deploy current dApps on Ethereum to this blockchain network without having to rewrite code or do pricey and time-consuming smart contract reviews. This luxury is not available to Ethereum programmers who are migrating to non-EVM compatible chains, which has a direct impact on the lower project counts and market shares of these other chains.

By lowering the entry hurdles for application developers to install smart contracts on these new chains, EVM compatibility has therefore allowed a number of blockchains to become very successful. Examples of some well-known L1s that are EVM-compatible that you might be familiar with are BNB chain, Fantom, and Avalanche.

Given all of this, are EVM-compatible blockchains effectively simply Ethereum clones? Not exactly. Although smart contracts on an EVM-compatible blockchain are programmed in a way that is compatible with the EVM, this does not imply that it is similar to Ethereum in every way - for example, there may be variations in how the chains are secured, the core tech, and so on.

EVM equivalence

At this point, EVM equivalence should be mentioned as well. EVM-equivalence, in contrast to EVM compatibility, states that a blockchain's smart contracts are designed and implemented in perfect accordance with EVM requirements.

Consider the last section's discussion of the “plug and play” functionality of EVM-compatible blockchains. For EVM-equivalent chains, this is genuine "plug and play"- all code adheres to the Ethereum coding principles, and what is created on one EVM-compatible chain may be deployed precisely as it is on another. This configuration allows for even higher network effects when distributing current smart contracts and dApps everywhere.

Smart contracts developed on EVM-compatible blockchains, on the other hand, do not need to achieve precise EVM equivalence - little rewriting of smart contract source code may occur. These variations eventually lead to some fragmentation among EVM-compatible chains, despite the fact that they are still very straightforward for Ethereum developers to duplicate current dApps on. For example, there may be five separate blockchains that are all EVM-compatible but have somewhat different frameworks.

The main advantage of having EVM compatibility should now be obvious: it makes it much simpler to expand out these various ecosystems by lowering the entry barriers for app developers to develop on new chains.

As was already said, only optimistic rollups are currently compatible with the EVM of the two types of rollups. Given the intricacy of zero-knowledge technology, Ethereum was not initially built to be ZK-friendly, which hastened the creation of a general-purpose, scaleable zkEVM. However, advancement is at the door; let's now look at those who are pushing for the creation of effective zkEVMs.

zkEVM architecture

A proving circuit, a verifier contract, and an execution environment make up the zkEVM. Each component helps the zkEVM run programs, produce proofs, and check those proofs.

The environment for execution: the execution environment, as its name indicates, is where zkEVM programs (smart contracts) are run. The zkEVM's execution environment works similarly to the EVM in that it inputs a new (final) state after taking into account the starting state and the current transaction.

The proving circuit: the zero-knowledge proofs generated by the proving circuit serve to confirm the accuracy of the transactions calculated in the execution environment. The pre-state, transaction inputs and post-state data are used as inputs to complete the proof creation process. The prover then receives a clear demonstration of the validity of that specific state shift.

The verifier contract: a smart contract running on the layer 1 chain (Ethereum) receives validity proofs from the verifier contract ZK-rollups for verification. The verifier contract also receives the input (pre-states and transaction data) and output (final states). The verifier then performs calculations on the proof that has been supplied and verifies that the outputs that have been delivered were appropriately computed from the inputs.

Projects employing zkEVM

The projects included in this part are by no means complete, but they should offer a good taste for individuals who are interested in investing and constructing general-purpose zkEVMs. The current development state in addition to the level of EVM compatibility for each project mentioned is emphasized for reference.

Polygon zkEVM

Status of Polygon zkEVM Development: Polygon revealed the opening of the open testnet for Polygon zkEVM, the moniker assigned to their specific zkEVM project, less than a month ago. This news follows Polygon's acquisition of Mir Protocol and merging with Hermez Network in an effort to strengthen their zero-knowledge proof technology. Polygon is asking users to operate on the network and help uncover any flaws while the testnet is in battle-test mode.

The mainnet is scheduled to become live in early 2023.

EVM compatibility level Polygon is working to make its zkEVM truly EVM-equivalent, but it is not quite there yet. As of this writing, the project's Github source repository displays 97% coverage of Ethereum compatibility tests despite supporting all EVM opcodes. In this sense, Polygon's positioning as an EVM-equivalent project has recently come under fire as the general public became aware of the difference between being completely (100%) EVM-equivalent and not. However, Polygon is anticipated to enhance compatibility even more in the future.

Zk EVM polygon

Source: Polygon blog

zkSync 2.0

Development status: Similar to Polygon, zkZync (created by Matter Labs) has been quite active lately in relation to the introduction of its zkEVM (called zkSync 2.0). The project just uncovered the release of its "Baby Alpha" on October 28, 2022. Although the platform does not currently accept any external applications while the team continues to do stress testing to make sure everything is operating properly and functioning as planned, this officially marks the release of the zkEVM's mainnet. zkSync 2.0 has been released, making it the first zkEVM product to be implemented on the main Ethereum network.

Developers are anticipated to start switching from the testnet to the mainnet in Q4 2022, although the system will still be inaccessible to outside users. The entire alpha is scheduled to be released by the end of 2022 when all security tests have been cleared. The complete alpha release will be a major event with the concurrent launch of more than 150 projects in the zkSync ecosystem. Chainlink and Uniswap are two well-known dApps that are presently being built on zkSync.

EVM compatibility level: While not equivalent, zkSync 2.0 is progressing in a fashion that is even less compatible with EVMs than Polygon. In contrast to Polygon, which supports all EVM opcodes while requiring little to no extra code rewriting, zkSync 2.0 does not explicitly support all EVM opcodes (you can read zkSync whitepaper for more details). Given the lower overall compatibility, this departure results in additional friction when it comes to organically support Ethereum dApps and/or sharing EVM technology, even if it may offer certain benefits like faster proof generation times or cheaper costs.

Zksync roadmap

Source: zkSync twitter

Scroll

Progress Status: The least well-known project among Polygon and zkSync at EthCC 2022 that declared they were working on general-purpose zkEVMs was Scroll. But the endeavor should not be abandoned. It just announced an update to its pre-alpha testnet that enables the development of smart contracts on the platform. Developers now have a chance to engage with the platform's infrastructure and learn about contract deployment thanks to this upgrade. Following the implementation of this upgrade, Scroll is anticipated to launch a larger alpha testnet that is accessible to all users without the usage of whitelists, which will ultimately be accompanied by the launch of their mainnet.

EVM compatibility level: Similar to Polygon zkEVM, Scroll aims to be entirely EVM-equivalent. This strategy entails explicitly implementing each EVM opcode, which, as was previously mentioned, offers advantages in terms of dApp migration and tools support. While Scroll intends to eventually attain equivalent, they are not there yet in terms of enabling EVM-equivalence through the architecture they have selected (which varies fundamentally from Polygon).

Taiko

Development Status: Not all zkEVM development projects are as advanced or supported as the aforementioned three. For instance, Taiko is by far the most primitive of those listed thus far in terms of development. The project just recently posted its whitepaper document for the first time on October 7, 2022. Additionally, their most recent community update has a variety of announcements on team additions and core progress (e.g., implementing opcodes, etc). This project is still very young, as are possibly a large number of others.

EVM compatibility level: According to their Twitter, Taiko is preferring EVM-equivalence for its zvEVM above compatibility (in contrast to projects such as zkSync 2.0 which is heading to ZK-friendly optimizations). They, along with others aiming for the same thing, think that this makes the adoption process as easy as possible for clients, developers, and infrastructure providers.

Starknet

Development Status: We advise reading the summary provided in the Starknet whitepaper if you are not familiar with Starkware and what they are doing with StarkNet. Given that Starkware invented ZK-STARK technology, reading about the company, in general, is quite intriguing. In November 2021, the StarkNet alpha opened on Ethereum Mainnet, and since then, more than a hundred applications have been developed and beginning to go live on the platform.

EVM compatibility level: StarkNet's infrastructure and contracts are written in Cairo rather than Solidity, making them incompatible with EVM if left alone. The crew is working hard to enhance compatibility, nevertheless. A Solidity to Cairo "transpiler" is being developed in particular by Nethermind's Warp project, allowing Solidity-based Ethereum projects to convert their codebase into Cairo in order to be deployed on StarkNet. While still in development, the Warp plugin will make StarkNet EVM compatible to a similar extent as zkSync 2.0 once it is finished and put into use.

In addition, the Starkware team just unveiled Kakarot, an EVM written in Cairo (sounds like Cairo). Kakarot, which has been referred to as "kind of a ZK-EVM emulator," would be able to execute Ethereum smart contracts on StarkNet, bringing the degree of EVM compatibility up to roughly the same as that of the present Polygon / Scroll level.

It may be quite challenging to stay on top of the projects listed here as well as the numerous more that are out there since they evolve quickly and constantly. Now that the fundamentals have been covered, maybe retention will be a little bit simpler when you see references to these and other projects in the future on Twitter or in other blog entries.

Starknet roadmap

Source: Starknet

A trade-off race

Following the announcement by Polygon, zkSync, and Scroll at EthCC 2022 that they had made significant advancements toward creating functional ZK-EVMs, Vitalik Buterin wrote an article outlining several broad categories for categorizing general-purpose rollups in terms of their compatibility with current EVM infrastructure. Although a little technical, the piece is worth reading since it highlights the zkEVMs of many of the projects that are listed. For instance, the zkEVMs that Polygon and Scroll are developing are categorized as "Type 3" in their present state (even if they are working toward Type 2) in Vitalik's chart below, but zkSync and StarkNet (with the Warp plugin) are regarded as Type 4.

A key lesson from Vitalik's post is that having a given level or kind of EVM compatibility does not always imply that a project's rollup is unquestionably superior to or inferior to that of other projects. Instead, there are simply different tradeoffs to take into account. For instance, fewer compatible rollups (lower Types in the taxonomy) may make it more difficult to recruit new developers to that ecosystem, while departures from the current EVM architecture may enable quicker proof generation times. Moving ahead, it is important to keep this idea in mind while you evaluate various projects. What additional advantages are there, for instance, if a proposed zkEVM is not aiming for EVM-equivalence, to justify the tradeoff?

In fact, we expect numerous additional projects (like Taiko) to enter the market with their own strategies in the months and years to come as the bigger companies continue to move toward their own mainnet and technology constantly advances. There is a lot of room for fresh ideas to enter the market given how young the technology is; it will be interesting to observe how the environment changes and which companies succeed.

Different types of EVM equivalence

Source: Vitalik blog

Conclusion

To summarize, all public, general-purpose rollups have a strong interest in transferring current Ethereum dApps (and developers) to their ecosystem and having EVM tools support them (e.g., wallets, marketplaces, etc). Each of these objectives tremendously benefits individual rollups in terms of user engagement, and one of the simplest ways to achieve these objectives is for a rollup to be EVM-compatible. This implies constructing a zkEVM - a general-purpose rollup that preserves compatibility with the Ethereum ecosystem's common interfaces - for ZK-rollups in particular, which are viewed favorably in contrast to optimistic rollups.

Despite the fact that the intricacy of zero-knowledge technology and proofs has kept us from creating proven zkEVMs to date, numerous projects (which were featured) are actively developing and are now on the verge of attaining what was once considered to be years away.

Disclaimer:
This article is intended for and only to be used for reference purposes only. No such information provided constitutes advice or a recommendation that any investment or trading strategy is suitable for any specific name.

ZK-EVMs: The holy grails for Ethereum scaling