Polygon zkEVM Within Vitalik’s Framework: Gaining Clarity and Looking Ahead

The Ethereum community has recently seen a flurry of zkEVM (zero-knowledge Ethereum Virtual Machine) announcements, including the unveiling of Polygon zkEVM. Given how new these technologies are and how many different approaches are being tried, it comes as no surprise that there has also been a lively debate around key concepts and terminology. What is a zkEVM? What is EVM-equivalence? It can get confusing, since everyone has their own point of view and their own definitions.

Luckily for us, Ethereum co-creator Vitalik Buterin has taken it upon himself to offer up a taxonomy of zkEVMs. Vitalik’s recent blog post moves our community much closer to conceptual clarity about zkEVMs in general. He also helps us see where Polygon zkEVM sits as of now, and where it’s headed.

Vitalik’s zkEVM Landscape

We encourage everyone to read the actual post, which contains a lot of elaboration on how to distinguish between different types of zkEVMs. The key question for Vitalik is how close a given zkEVM is to Ethereum itself. The complementary question is what the trade-offs are and why projects choose different levels of compatibility.

Vitalik describes a spectrum of possible zkEVM approaches. They range from Type 1, which are fully Ethereum-equivalent and “[do] not change anything about Ethereum,” to Type 4, which avoid costly computational overhead “by not ZK-proving all the different parts of each EVM execution step, and starting from the higher-level code directly.” 

The post goes into extensive detail, but the upshot remains the same across the different types: similarity to Ethereum must be balanced against performance. The more similar a zkEVM is to Ethereum, the slower it tends to be to generate zero-knowledge proofs. 

How this helps the Ethereum community

Vitalik has done us several favors by laying out this taxonomy. First and most importantly, the Ethereum community now has a neutral conceptual framework for zkEVMs. We can use his system to pinpoint what aspects of a zkEVM are most relevant when comparing it to other projects. We can describe not only what the key properties of different projects are, but also why those differences exist. 

Vitalik also acknowledges that where projects are now is not necessarily where they will be in the future. ZK tech in general is an emerging, cutting-edge space, so it stands to reason that the various testnets and alpha versions of zkEVMs now coming online will evolve into a much different final form. As of now, every zkEVM is in some sense a work-in-progress. 

Locating Polygon zkEVM

Most importantly for our purposes at Polygon, Vitalik correctly identifies Polygon zkEVM as a project that is building towards being a Type 2 zkEVM. In his words, “Type 2 ZK-EVMs strive to be exactly EVM-equivalent, but not quite Ethereum-equivalent.” From a developer or user point of view, a Type 2 zkEVM would look and feel like Ethereum, but with some differences at the level of data structures: “The goal [of a Type 2 zkEVM] is to be fully compatible with existing applications, but make some minor modifications to Ethereum to make development easier and to make proof generation faster.”  This level of EVM-equivalence is where we’re headed.

For now, however, as Polygon zkEVM takes steps towards mainnet and works out various details of implementation, Vitalik classifies us as a Type 3. According to him, a Type 3 zkEVM is compatible with most existing programs, but “there will be some applications that would need to be rewritten either because they use pre-compiles that the Type 3 ZK-EVM removes or because of subtle dependencies on edge cases that the VMs treat differently.” Vitalik aptly describes Type 3 as “simply a transitional stage,” since current Type 3 projects want to become Type 2. We believe this is a fair description of Polygon zkEVM as it currently stands, and we look forward to meeting all the requirements of a Type 2.

Where we go from here

We continue to believe that building a Type 2 zkEVM is the best goal for serving the scaling needs of the Ethereum community. After all, Ethereum isn’t just a blockchain. It’s also a rich ecosystem of smart contracts, developer tools, and other community contributions. 

The best way to scale Ethereum is to maintain compatibility with this rich existing ecosystem, which is why Polygon zkEVM is pursuing the strong equivalence that Vitalik identifies as “Type 2.” We will stick to this roadmap and look forward to our rapidly approaching testnets.

As of now, Polygon zkEVM has open-sourced its code. It has already passed 60% of the Ethereum test vectors suite, which is used to establish EVM-equivalence. Polygon zkEVM’s zkProver is now able to process 500,000 gas within five minutes on a single CPU. 

This is where we are right now. We expect even better results in the near future as we build towards the best-in-class Type 2 zkEVM. Thanks to Vitalik for introducing clarity into this discourse!

Learn more about Polygon zkEVM, check out the source code on Github and tune into our blog for the latest from the Polygon ecosystem.

Let’s bring the world to Ethereum! 

Website | Twitter | Developer Twitter | Telegram | Reddit | Discord| Instagram | Facebook | LinkedIn