When it comes to scaling Ethereum via rollups, zero-knowledge (ZK) rollups, and in particular the advent of EVM-compatible ZK-rollups (zkEVMs), are often considered the holy grail. Although we are not quite there yet in terms of development, various projects have recently turned up the heat in terms of innovation, making what once appeared years away seemingly within grasp. The race is now on to see which of these first movers can successfully implement a zkEVM at scale and gain the advantage in terms of early user adoption.

Setting the Stage

As an initial matter, note that this article does not serve as an introductory piece with respect to rollups. As a result, if you are not already familiar with the rollup landscape on Ethereum as well as the general advantages / disadvantages of using ZK-rollups in particular, I highly recommend reading this piece first which covers these basics in detail. I am sure Eli Ben-Sasson would prefer the use of “validity rollups” throughout this article instead of ZK-rollups, but we will stick with popular convention for now.

Keeping the above in mind, let us quickly remind ourselves why ZK-rollups are often looked on favorably in comparison to optimistic rollups. Although both forms of rollups offer huge improvements in terms of scalability and throughput, ZK-rollups provide an edge in terms of transaction finality (no challenge period) and security. For the latter, ZK-rollups are generally seen as more secure since they rely on trustless cryptographic mechanisms for security as opposed to relying on the honesty of other actors to submit fraud proofs. Of course, optimistic rollups have their particular benefits as well, such as not requiring complex calculations that are best performed on specialized machines to generate proofs (which has its costs), but these are the big-ticket items to note all else equal.

I want to stress “all else equal” because as of today, not everything else is equal. In particular, between the two forms of rollups, only optimistic rollups are generally EVM-compatible, which has contributed to optimistic rollups being more popular to date in terms of total value locked (TVL).

EVM-Compatibility and Equivalence Explained

I find the concept of the EVM and its various forms of compatibility to be one of the more overlooked and misunderstood topics in the space. The term is thrown around so often that you would think everyone understands the ins and outs, but this is most likely not the case. For an article focusing on zkEVMs, it is therefore imperative that we review the topic to ensure everyone has a strong grasp going in.

Keep in mind that public, general-purpose rollups all typically share a common goal — to onboard developers and users as quickly as possible in order to generate network effects in terms of adoption. This statement, in short, is what EVM-compatibility helps facilitate for new blockchain networks / rollups. Let’s explore how and why.

EVM (Ethereum Virtual Machine)

First off, what is EVM? EVM stands for Ethereum Virtual Machine, which is in essence a software platform.

At a high level, remember that with a blockchain, at any given time there can only be one canonical “state” (akin to a balance sheet). This state includes all of the blockchain’s accounts, balances, etc. at that particular moment. In the case of Ethereum, the EVM partly serves as a large database for holding all of this data.

However, the EVM also plays a more dynamic role. Ethereum’s state is not only a large data structure holding all accounts and balances, but also what is known as a machine state, which can change from block to block according to a pre-defined set of rules. These rules, as you may have guessed, are defined by the EVM — so any smart contracts wanting to perform transactions on Ethereum that are not written in compliance with the EVM will not be processed. Not only that, but as the Ethereum blockchain’s record transforms with each permitted transaction, the EVM continuously tracks and computes the new state of the network (therefore serving as both a gatekeeper and real-time registrar). Let’s look at an example here to help illustrate.

Assume you created a smart contract or decentralized application (dApp) on Ethereum. Like any standard smart contract, within this contract is a defined list of operations that are to be executed when certain conditions are met (e.g., given an input, the smart contract performs an output / function). To the extent this smart contract adheres to the current rules of the EVM, the EVM will help facilitate its execution leading to a new block and state on the Ethereum network (which the EVM computes). For the technically inclined, the EVM is helping facilitate execution by translating smart contract opcodes (short for operation codes, which are written in programming languages like Solidity) into bytecode so that instructions can be read and operations can be executed by the virtual machine.

Image Credit: Reddit blog post

The EVM can therefore almost be looked on as the lifeblood of Ethereum. By interpreting / executing smart contracts and computing the state of the Ethereum network from block to block in response to smart contract input data, it defines the rules for what can be processed and updates the state of the network in real time.

EVM-Compatibility

Now that we have a general understanding of what the Ethereum Virtual Machine (EVM) is, what does it next mean for a blockchain to be EVM-compatible?

Image Credit: GoCrypto Blog (Medium)

EVM-compatibility relates to how a particular blockchain’s smart contracts are written and deployed. If a blockchain is considered EVM-compatible, it means that its smart contracts are written in a manner that conforms with the EVM’s particular specifications and rules.

In way too simple of terms — if you essentially copy / paste code that is readable on the Ethereum network and deploy it on a different blockchain, if another blockchain is built to support and process this transposed smart contract / code it would be considered EVM-compatible. Why would another blockchain structure itself in accordance with these standards? The answer is that this ‘plug and play’ capability greatly expands the possibilities for emerging blockchains to attract developers to their ecosystem. Ethereum is the world’s most popular network — in order for other chains to potentially tap into its broad web of developers and applications, they must conform to what others are familiar with.

Consider the situation for non-EVM compatible chains. By building out entirely new standards and ecosystems, non-EVM compatible chains are granted the freedom to fundamentally change the Ethereum toolset and differentiate themselves in various ways (some for the better). However, it also makes it harder to attract developers into the new ecosystem, most of whom are probably already familiar with Ethereum. For example, if a blockchain is EVM-compatible, developers can quickly replicate and deploy existing dApps on Ethereum to this new chain, without having to re-write code or conduct costly and time-consuming smart contract audits. This luxury is not afforded to Ethereum developers who are porting to non-EVM compatible chains, which directly contributes to these other chains having lower project counts and market share.

EVM-compatibility has thus enabled numerous blockchains to become highly successful by reducing the barriers to entry for application developers to deploy smart contracts on these new chains. Examples of some popular EVM-compatible Layer 1s that you may be familiar with include Avalanche, BNB Smart Chain, and Fantom.

So, with all of the above in mind, are EVM-compatible blockchains essentially just Ethereum clones? Not quite. Although an EVM-compatible blockchain’s smart contracts are written in a manner that is compatible with the EVM, this does not otherwise require it to be identical to Ethereum in every respect — e.g., there may be differences in how the protocols are secured, the underlying technology, etc.

EVM-Equivalence

At this stage, what is known as “EVM-equivalence” should also be noted. In short, EVM-equivalence goes a step further than EVM-compatibility, and means that a blockchain’s smart contracts are written and deployed in complete alignment with EVM specifications.

Recall the ‘plug and play’ capability of EVM-compatible blockchains that was explained in the previous section. For EVM-equivalent chains, this truly is ‘plug and play’ — all code is in compliance with the Ethereum yellow paper (the formal definition of the protocol), and what is written on one EVM-compatible chain can be deployed exactly as it is on another such chain. This set up makes for even greater network effects when it comes to deploying existing smart contracts and dApps elsewhere.

In contrast, smart contracts written on EVM-compatible blockchains do not need to achieve exact EVM “equivalence” — minimal re-writing of the underlying code of smart contracts may occur. These deviations ultimately lead to a degree of fragmentation among EVM-compatible chains despite them still being relatively easy for Ethereum developers to replicate existing dApps on. For example, there may by five different blockchains, each of which are EVM-compatible, but yet still have slightly different codebases (making things more complicated than if each blockchain were EVM-equivalent).

Bringing It All Together

The primary benefit of having EVM-compatibility should now be clear — by reducing the barriers to entry for application developers to build on new chains, it makes it much easier to grow out these different ecosystems.

As noted earlier, of the two forms of rollups, only optimistic rollups are currently EVM-compatible. Given the complexity involved with zero-knowledge technology and proofs, Ethereum was not originally designed around ZK-friendliness, thus contributing to the delay in developing a general-purpose zkEVM at scale. However, innovation is knocking at the door — let’s now take a look at those leading the charge toward developing functional zkEVMs.

Projects Working Toward zkEVMs

The various projects listed in this section are by no means all-encompassing, but should provide a decent flavor for those actively innovating and building general-purpose zkEVMs. For each project listed, the current development status as well as the level of EVM-compatibility is highlighted for reference. As you read, I encourage you to take a deeper dive into any project that is of particular interest — news comes out almost weekly on the progress of many of these projects, and it is likely that by the time you read this article even further advancements have been made.

Polygon zkEVM

Development Status. Less than a month ago, Polygon announced the launch of the public testnet for Polygon zkEVM, which is the name given for their particular zkEVM project. This announcement comes after a string of activity by Polygon in an effort to shore up their zero-knowledge proof technology, including the acquisition of Mir Protocol and merger with Hermez Network. The testnet is currently in battle-test mode, and Polygon is encouraging users to deploy on the network and help find potential bugs.

“We invite the community to try out the testnet and help us improve it. Let’s deliver the first ever zkEVM together!” — Mihailo Bjelic, co-founder of Polygon

A mainnet launch is expected sometime in early 2023.

Level of EVM-Compatibility. Although Polygon is striving toward making its zkEVM fully EVM-equivalent, it is not quite there yet. In its current form, it is still better thought of as being EVM-compatible, as a few sacrifices to exact equivalence are being made. As of writing, despite supporting all EVM opcodes, the project’s Github code repository shows 97% coverage of Ethereum compatibility tests. In this regard, Polygon’s branding as an EVM-equivalent project actually faced some recent criticism, as the broader community picked up on the distinction between being fully (100%) EVM-equivalent versus not. That said, Polygon is expected to improve compatibility even further over time.

Image Credit: Polygon blog announcement

zkSync 2.0

Development Status. Similar to Polygon, zkZync (founded by Matter Labs) has had a lot of recent activity with respect to the launch of its zkEVM (called zkSync 2.0). Just a couple days ago on October 28, 2022, the project announced the release of its ‘Baby Alpha.’ This technically serves as the release of the zkEVM’s mainnet, although the platform does not yet support any external projects while the team continues to conduct stress tests to ensure everything is working correctly and performing as expected. With the launch, zkSync 2.0 becomes the first zkEVM solution to deploy on the main Ethereum network.

In Q4 2022, developers are expected to begin moving from the testnet to mainnet, but the system will still be closed to external users. Once all security checks receive clearance, the full alpha is expected out by end of year 2022. With more than 150 projects in the zkSync ecosystem launching simultaneously, the release of the full alpha will be quite the event. Popular dApps currently building on zkZync include Chainlink and Uniswap.

Image Credit: zkSync Twitter

Level of EVM-Compatibility. zkSync 2.0 is building toward EVM-compatibility (not equivalence), but in a way that is even less compatible than Polygon. Whereas Polygon achieves “opcode-level equivalency” by supporting all EVM opcodes with otherwise minimal re-writing of any code, zkSync 2.0 does not explicitly support certain EVM opcodes (see the documentation for more details). Although this deviation may allow for certain advantages like faster proof generation times or reduced costs, it results in more friction when it comes to naturally supporting Ethereum dApps and/or sharing EVM tooling given the lower overall compatibility.

Scroll

Development Status. Of the projects at EthCC 2022 that announced they were working toward general-purpose zkEVMs, Scroll was definitely the least known among Polygon and zkSync. However, the project should not be dismissed. Just a few weeks ago, it announced an upgrade to its pre-alpha testnet enabling smart contract deployment on the platform. This upgrade provides developers their first chance to interact with the infrastructure and experience contract deployment on the platform. Soon after this upgrade, Scroll is expected to roll out a more expansive alpha testnet that is open to all users without whitelisting, which will ultimately be followed by the release of their mainnet.

Level of EVM-Compatibility. Like Polygon zkEVM, Scroll is striving to be fully EVM-equivalent. This approach includes implementing every EVM opcode directly, which as discussed before has its benefits in terms of dApp migration and tooling support. However, also like Polygon, Scroll is not there yet in terms of supporting EVM-equivalence through the design they have chosen (which differs from Polygon structurally), although they intend to achieve equivalence in the future.

Image Credit: Scroll.io website

Taiko

Development Status. Not all projects developing zkEVMs are as far along or well-backed as the previous three mentioned. For example, of those mentioned so far, Taiko is on the earliest side by far in terms of development. The project shared their whitepaper for the first time only a couple weeks ago on October 7, 2022. Additionally, their latest community update includes various news with respect to team additions as well as core development (e.g., implementing opcodes, etc.). This project, as well as probably numerous others out there, is truly in the early innings.

Level of EVM-Compatibility. From their Twitter, Taiko is prioritizing EVM-equivalence over compatibility for their zvEVM (in contrast to projects like zkSync 2.0 which is making ZK-friendly optimizations). Like others striving for the same, they believe this creates the smoothest path for developers, users, and infrastructure providers when it comes to adoption.

Image Credit: Taiko Labs blog post

StarkNet

Development Status. If you are unfamiliar with Starkware and what they are building with StarkNet, I recommend reading the overview provided in this article (see the “Starkware” section). Starkware is the pioneer when it comes to ZK-STARK technology, and as a result the team is very interesting to read up on generally. The StarkNet alpha was launched on Ethereum Mainnet in November 2021, and has seen over a hundred projects developing and starting to go live on the platform.

Level of EVM-Compatibility. StarkNet uses the Cairo programming language for its infrastructure and contracts (not Solidity), and left alone at that is not EVM-compatible. However, the team is actively creating ways to add compatibility. In particular, Nethermind’s Warp project is building a Solidity to Cairo “transpiler,” which enables Ethereum-based projects written in Solidity to translate their codebase into Cairo for purposes of deployment on StarkNet. The Warp plugin is still under development, but once refined and in effect, it will make StarkNet EVM-compatible in similar degree to zkSync 2.0.

Additionally, just a few days ago, the Starkware team introduced Kakarot (~sounds like Cairo), which is an EVM written in Cairo. Described as “a sort of ZK-EVM emulator,” Kakarot would be able to run Ethereum smart contracts on StarkNet, increasing EVM-compatibility to generally that of the current Polygon / Scroll level. Details are still minimal here, but as a die-hard DBZ fan, I’m here for the ‘over 9000’ references being made on their Twitter.

Image Credit: Dragon Ball Z

Keeping Track of Approaches

Keeping track of the rapid and evolving development of not only the projects listed here but also the countless others out there can be really difficult. Hopefully, now with the basics down, when you see references to these and other projects on Twitter or other blog posts in the future, retention will be a little easier.

A visual representation (as of August 2022) of the different approaches taken toward building a zkEVM by some of the projects highlighted in this article. Image Credit: Immutable X article.

Conclusion

As a recap, all public, general-purpose rollups have a vested interest in (i) migrating existing Ethereum dApps (and developers) to their ecosystem and (ii) being supported by EVM tooling (e.g., wallets, marketplaces, etc.). Each of these goals helps individual rollups greatly in terms of user adoption, and one of the simplest ways to achieve these goals is for a rollup to be EVM-compatible. For ZK-rollups in particular, which are regarded highly in comparison to optimistic rollups, this means creating a “zkEVM” — i.e., a general-purpose rollup that maintains compatibility with the common interfaces of the Ethereum ecosystem. Although the complexity surrounding zero-knowledge technology and proofs has prevented us from achieving proven zkEVMs to date, various projects (which were highlighted) are actively innovating and now on the edge of achieving what was once thought to be years away.

In the aftermath of Polygon, zkSync, and Scroll announcing at EthCC 2022 that they were making significant progress toward achieving functional ZK-EVMs, Vitalik Buterin published an article that highlighted several broad categories for classifying general-purpose rollups in terms of their compatibility with existing EVM infrastructure. Although a bit technical, I would definitely recommend the read, as the zkEVMs of numerous projects mentioned in this article are highlighted. For example, in Vitalik’s chart below, the zkEVMs that Polygon and Scroll are building are classified as ‘Type 3’ in their current form (although they are building toward Type 2), whereas zkSync and StarkNet (with the Warp plugin) are considered Type 4.

A taxonomy of different “types” of EVM equivalence. Image Credit: Vitalik Buterin blog post (“The different types of ZK-EVMs”)

A core takeaway from Vitalik’s article is that having a certain type or degree of EVM-compatibility does not necessarily mean that one project’s rollup is unambiguously better or worse than others. Rather, there are just different tradeoffs to consider — e.g., less compatible (lower Types in the taxonomy) rollups might make it harder to build out that particular ecosystem when it comes to attracting new developers, but at the same time deviations from existing EVM infrastructure might allow for faster proof generation times. This point is something to keep in mind when analyzing different projects moving forward. For example, if a proposed zkEVM is not seeking EVM-equivalence, what other benefits are there to justify the tradeoff? The ‘best’ approach or set up (if there is one) is not yet known, and it is healthy for the space that various projects are exploring different structures.

In fact, as the larger players continue to advance toward their respective mainnets and technology gradually improves, in the coming months and year ahead I anticipate countless more project (like Taiko) coming to market with their own approach. Given how nascent the technology is, a lot of white space exists for innovative projects to come in and make an entrance — it will be interesting to see how the landscape evolves and which winners emerge.