Following the launch of Polygon zkEVM Mainnet Beta, the claim of whether or not Polygon zkEVM was EVM-equivalent was suddenly in question. Since the first public testnet of Polygon zkEVM, EVM-equivalence has been a central part of Polygon Labs’ messaging for this breakthrough protocol.
But is Polygon zkEVM an EVM-equivalent rollup? Yes.*
We’ll get back to that asterisk in a moment.
Borrowing from Polygon Zero co-founder Brendan Farmer’s recent Twitter thread, let’s take a good-faith look at those concerns—who gets to define EVM-equivalence and what does it mean?
Who Gets to Define It?
Because there’s no central authority in emerging technology—much less a technology built around the careful dance of consensus—everyone has a say.
And by everyone, we mean those people working in blockchain and, importantly, the people building the implementations of these protocols. So the definition of EVM-equivalence follows how these groups use the term EVM-equivalence.
Usage → meaning. Nothing new.
The term zkEVM is fairly new, coined as the technology it’s describing is just now emerging. Add to that the academic and marketplace incentives at stake. That’s a good thing for users. Debate in the public square? Also good for users.
Defining EVM-equivalence is a collective act, weighted towards those people in the space, but not centralized to any single entity.
What Does It Mean?
Okay, so what does EVM-equivalence mean? To put it another way, what is this characteristic’s underlying functionality? It refers to a zkEVM that executes EVM bytecode directly. It means that there is no interface—in the form of a recompiler or LLVM—between the zkEVM and the EVM.
Is this true for Polygon zkEVM? Yes.
So why not refer to Polygon zkEVM as a bytecode-compatible ZK rollup? Well, it’s a mouthful and Tweets can only be so long. But mostly, it doesn’t do a good job of describing the practical implications for devs. Sometimes, as terms become more precise, they actually lose meaning.
Some ZK rollups may prefer this phrasing. But that’s a stylistic decision, like capitalizing the word internet, not a substantive one.
Standardization Comes Later
At the moment, there aren’t even standardized ways of discussing performance in ZK rollups. Differences in hardware and differences in design—and a few black boxes 👀—mean that metrics like tps and proof-generation time aren’t yet apples to apples.
There is meaningful research—with contributions from some of Polygon Miden’s team— to standardize how performance is measured.
But for the moment, this is the frontier.
*About that Asterisk
According to Vitalik Buterin, EVM-equivalence is also about two additional characteristics:
- Support for all of the EVM's opcodes
- Identical gas pricing as the EVM
- Support for all of the EVM's precompiled smart contracts
Does Polygon zkEVM support all of the EVM’s opcodes? Yes.
Is gas pricing the same? Yes.
Does it support all of the EVM’s precompiled smart contracts? It will. There are nine precompiled smart contracts. Polygon zkEVM supports five of them, and the other four are expected soon. These precompiled smart contracts are important, but not meaningful to the dev UX of the network.
Does Vitalik’s definition of EVM-equivalence leave room for a range of variance between the EVM and the rollup’s implementation of the EVM? Also yes.
For the latest, be sure to check the Polygon blog and tune in to the social channels for everything in the Polygon ecosystem. And if you’re interested in (or perplexed by) Zero Knowledge, follow the dedicated ZK handle for Polygon, @0xPolygon, and head over to the ZK forum.
Website | Twitter | Developer Twitter | Telegram | Reddit | Discord | Instagram | Facebook | LinkedIn
