Polygon Employee Statement: Differences Between Polygon zkEVM and zkSync zkEVM

Original Title: "A comparison of zkEVMs"

Author: Daniel Lubarov

Compiled by: Kxp, BlockBeats

As the "zkEVM wars" heat up, public discussions have highlighted many advantages of different zkEVMs. However, there is also some misinformation, so we want to clarify some facts about Polygon zkEVM and how it compares to other projects.

As an employee of Polygon, I have biases, but I will do my best to remain fair in the comparison. I will primarily focus on Polygon's zkEVM and zkSync Era, as they are already in production, and I am less familiar with other zkEVM projects.

zkSync's zkEVM and prover consist of over 100k lines of code. I will do my best to provide an accurate summary, and if there are any inaccuracies, please let me know, and I will correct them.

EVM Compatibility

Polygon zkEVM directly executes EVM bytecode. According to Vitalik's classification, it is a type 3 zkEVM. Soon it will become 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 and supports Solidity by providing a compiler. This makes it a type 4 zkEVM: it supports Solidity but does not support EVM bytecode itself. Tools like Hardhat cannot be used directly, although zkSync's plugins can be utilized.

zkSync believes their zkVM is more future-proof, meaning it can better integrate with languages beyond Solidity. However, their VM seems to inherit many performance characteristics from the EVM, such as its 256-bit word size. zkVMs like Miden may be more future-proof as they are designed for general-purpose computation rather than focusing on Solidity.

Performance

Performance has always been a focus for Polygon, and our zkEVM is highly efficient. The cost of running our prover on a CPU is about $0.000084 per transaction.

While we have not found any working benchmarks for zkSync's zkEVM, we suspect there is a significant performance gap due to our very different ZK technology choices.

Field Selection

After researching several alternatives, we chose the so-called Goldilocks field, a degree-2 large prime field 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 modern CPUs.

zkSync has taken a more traditional approach, using a SNARK based on the alt-bn128 curve. The size of the base field is about 254 bits, and field multiplication takes about 80 cycles on a CPU.

To feel the impact of this significant difference, we can look at Celer's SHA2 benchmarks. There, our STARK prover is 5-50 times faster than the elliptic curve-based prover.

The advantage of alt-bn128 is that it is natively supported by the EVM, making it simpler to submit proofs to Ethereum. At Polygon, we "wrap" the final aggregated proof with an alt-bn128 fflonk proof. While our approach requires more work, we believe it is worth it for the incredible performance gains.

Arithmetic

The differences do not stop there. Our zkEVM is built on STARKs but with modern variations. We have a main STARK for CPU (one line per cycle) and others for arithmetic, hashing, etc. These tables can connect, as we describe in RapidUp. This is similar to physical CPUs, which often have coprocessors to accelerate rendering, crypto, or ML inference.

Take Keccak as an example. Since it is widely used in EVM applications, we designed a dedicated STARK for it, employing some new techniques we document here. Designing such custom arithmetic requires significant effort, but it pays off, allowing us to prove hundreds of Keccak permutations per second.

zkSync has taken what I would call a more traditional approach. They use a PLONK-based prover, and while it supports custom gates, their zkEVM does not utilize much of it; most computations are done using a generic gate called SelectorOptimizedWidth4MainGateWithDNext. It seems slightly more powerful than vanilla PLONK gates but is still limited to simple operations like mul-adds.

Notably, zkSync uses lookup parameters (like us), which is a more modern technique that helps improve efficiency for things like Keccak. However, without custom arithmetic, the efficiency of 256-bit math, Keccak, etc., suffers significantly.

Security

Polygon places a high priority on security, and our zkEVM has undergone two independent audits: one by Spearbit and another by Hexens. Both reports are publicly available here. We have also published instructions for verifying deployments.

We do not know if zkSync's zkEVM has undergone any public audits. zkSync's website lists audits for bridging contracts but not for the zkEVM itself.

Aside from audits, both projects have various "safety nets" to provide backup security layers, but this is a deep topic that I will not elaborate on here.

L1 Data

Polygon zkEVM publishes all transaction data to L1. There has been some confusion about this on Twitter; for gas fees related to this, please refer to Edu's article. Currently, the average transaction size is about 120 bytes, so the gas fee per transaction is approximately 120*16=1920 Gas.

zkSync, on the other hand, publishes state differences. A malicious sequencer could hide transaction data, but zkSync believes that having the current state trie is sufficient to ensure security. This seems contentious, as it is generally expected that transaction data is available, and certain applications rely on this.

After reviewing the corrected data, we can see that the gas fees per transaction for our zkEVM and zkSync are essentially the same. These numbers may vary over time with the mix of transaction types occurring on each chain, but as of today, state differences have not saved any gas fees; both systems send about 120 bytes of transaction data to L1.

We plan to make some optimizations here, but not by using state differences. The transactions themselves can be compressed to reduce gas fees while still ensuring the availability of transaction data. Stay tuned!