Original title: "A comparison of zkEVMs"
Original compilation: Kxp, BlockBeats
Original compilation: Kxp, BlockBeats
As the "zkEVM wars" heated up, there was a lot of public discussion about the merits of different zkEVMs. But there is also some misinformation, so we want to clarify some facts about Polygon zkEVM and how it compares to other projects.
As a Polygon employee, I am biased, but I will try to be relatively unbiased. I'm mostly focusing on Polygon's zkEVM and zkSync Era, since they're already in production use, and I don't know much about other zkEVM projects.
EVM Compatibility
EVM Compatibility
Polygon zkEVM directly executes EVM bytecode. According to Vitalik's classification, it is a type 3 zkEVM. Soon it will be type 2; currently we are missing four precompiles. Scroll is also working towards a Type 2 zkEVM.
In contrast, zkSync Era uses a different bytecode format by providing a compiler to support Solidity. This makes it a type 4 zkEVM: it supports Solidity, but not the EVM bytecode itself. Tools such as Hardhat cannot be used directly, although a plugin for zkSync is available.
performance
performance
Performance has always been a focus for Polygon, and our zkEVM is very efficient. Running our prover on CPU costs approximately $0.000084 per transaction.
secondary title
domain selection
After investigating several alternatives, we settled on the so-called Goldilocks field, a field of huge primes of order 2 2^64 - 2^32 + 1 . Its small size and beautiful binary structure lead to extremely fast field operations, with multiplication taking less than two cycles on a modern CPU.
zkSync takes a more traditional approach, using SNARKs based on the alt-bn 128 curve. The size of the underlying field is about 254 bits, and the field multiplication takes about 80 cycles on the CPU.
To get a feel for the impact of this huge difference, we can look at Celer's SHA 2 benchmark. There, our STARK prover is 5-50 times faster than elliptic curve based provers.
secondary title
Arithmetic
The difference doesn't stop there. Our zkEVM builds on STARKs, but with modern changes. We have a main STARK for the CPU (one row per cycle), and other STARKs for arithmetic, hashing, etc. These tables can be joined as we describe in RapidUp. This is similar to physical CPUs, which often have co-processors to speed up intensive operations like rendering, Crypto or ML inference.
Take Keccak for example. Since it is widely used in EVM applications, we designed a dedicated STARK for it, using some new tricks we document here. Designing such a custom arithmetization required a lot of work, but it paid off, allowing us to prove hundreds of Keccak permutations per second.
zkSync takes what I would call a more traditional approach. They use a PLONK-based prover, and while it supports custom gates, their zkEVM isn't used much; most calculations are performed using a generic gate called SelectorOptimizedWidth 4 MainGateWithDNext. It seems to be slightly more powerful than vanilla PLONK gates, but is still limited to simple operations like mul-adds.
safety
safety
Polygon takes security very seriously, and our zkEVM has undergone two independent audits: one by Spearbit and another by Hexens. Both reports are publicly viewable here. We also publish instructions for verifying deployments.
We do not know if zkSync's zkEVM has undergone any public audits. zkSync's website lists audits for bridge contracts, but not zkEVM itself.
first level title
L1 data
Polygon zkEVM publishes all transaction data to L1. There's been some confusion about this on Twitter, see Edu's article on gas fees for this. Currently, the average transaction size is about 120 bytes, so the Gas fee per transaction is about 120*16 = 1920 Gas.
zkSync publishes state differences. Malicious serializers may conceal transaction data, but zkSync believes that having the current state of the trie is sufficient for security. This seems controversial because transaction data is generally expected to be available, and some applications depend on it.
After looking at the corrected data, we can see that our zkEVM and zkSync have roughly the same gas fee per transaction. These numbers may change over time with the mix of transaction types happening on each chain, but as of today state differences don't save any gas; both systems send about 120 bytes per transaction to L1 .
Original link
IOS
Android