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.
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.
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.
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.
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!
Let’s bring the world to Ethereum!
The final Polygon zkEVM testnet, which launched last year, has seen a surge of developers and users eager to experience the future of Ethereum scaling. The years-long technical achievements to get to this point have been enormous. Researchers working on zero-knowledge (ZK) to scale Ethereum have had to answer and address a bevy of design...
Last month, the second and final public testnet for Polygon zkEVM went live. Included in that rollout were meaningful improvements to the throughput, latency, and efficiency of the prover. In the first testnet, Polygon’s Hermez team, lead by Jordi Baylina, deliberately throttled performance to prioritize controlled testing of the soundness and correctness of the prover....
When the first Polygon zkEVM public testnet launched in October, the distant future of Ethereum scaling became a reality, today. Researchers at Polygon called for the community to join the testnet in the collaborative, built-in-public ethos that has defined Ethereum from the start. Developers can pour over the source code-available zero knowledge (ZK) proving system...