Partnered With:

Comparison between Polygon's zkEVM and zkSync.

Read this article in 9 Minutes

Polygon employees conduct comprehensive comparison between Polygon zkEVM and zkSync Era.

Original Title: "A comparison of zkEVMs"

Original Author: Daniel Lubarov

Original Translation: Kxp, BlockBeats

With the escalation of the "zkEVM war", the public has discussed many advantages of different zkEVMs. However, there is also some incorrect information, so we want to clarify some facts about Polygon zkEVM and its comparison with other projects.

As an employee of Polygon, I am biased, but I will try to remain impartial. My main focus is on Polygon's zkEVM and zkSync Era, as they are already in production use, and I am not very familiar with other zkEVM projects.

zkSync's zkEVM and proof system consist of over 100k lines of code. I will do my best to provide an accurate summary, and please let me know if there are any inaccuracies that need to be corrected.

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 developing type 2 zkEVM.

Compared to that, 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 not EVM bytecode itself. Tools like Hardhat cannot be used directly, although plugins for zkSync can be used.

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

Performance

(Note: This content cannot be translated as it only contains HTML tags and a non-translatable character.)

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

Although we have not found any benchmarks for zkEVM of zkSync, we suspect that there is a significant performance gap due to our very different ZK technology choices.

Domain Selection

After researching multiple alternative solutions, we have chosen the so-called Goldilocks field, a second-order prime field of 2^64 - 2^32 + 1. Its small size and beautiful binary structure result in extremely fast field operations, with multiplication taking less than two cycles on modern CPUs.

zkSync uses a more traditional approach, utilizing SNARKs based on the alt-bn128 curve. The size of the base field is approximately 254 bits, and field multiplication requires around 80 cycles on a CPU.

In order to feel the impact of this huge difference, we can take a look at Celer's SHA2 benchmark test. 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 EVM, making it easier to submit proofs to Ethereum. At Polygon, we wrap the final aggregated proof with alt-bn128's fflonk proof. Although our method requires more work, we believe it is worth it for the incredible performance gains.

Arithmeticization

The difference is not only this. Our zkEVM is built on top of STARKs, but with modern changes. We have a main STARK for the CPU (one row per cycle), and others for arithmetic, hashing, and so on. These tables can be connected, just as we described in RapidUp. This is similar to a physical CPU, which often has coprocessors to accelerate intensive operations such as rendering, crypto, or ML inference.

Take Keccak as an example. As it is widely used in EVM applications, we have designed a dedicated STARK for it, using some new techniques that we have recorded here. Designing such a custom arithmetic requires a lot of work, but it pays off, allowing us to prove hundreds of Keccak permutations per second.

zkSync uses what I call a more traditional approach. They use a PLONK-based prover, although it supports custom gates, their zkEVM doesn't use much of it; most computations are done using a universal gate called SelectorOptimizedWidth4MainGateWithDNext. It seems to be slightly more powerful than vanilla PLONK gates, but still limited to simple operations like mul-adds.

It is worth praising that zkSync uses lookup parameters (like us), which is a more modern technology that can help improve efficiency for algorithms like Keccak. However, without custom arithmetic, efficiency for 256-bit mathematics, Keccak, and so on will be greatly reduced.

Security

Polygon places great emphasis on security. Our zkEVM has undergone two independent audits: one conducted by Spearbit and the other by Hexens. Both reports can be viewed publicly here. We have also released instructions for verifying deployments.

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

除了审计外，两个项目都有各种「安全备胎」，以提供备用的安全层，但这是一个很深的话题，我在这里不会详细介绍。

Translation:

Except for auditing, both projects have various "security spare tires" to provide backup security layers, but this is a deep topic that I won't go into detail here.

L1 Data

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

zkSync has different views on state differences. Malicious serializers may conceal transaction data, but zkSync believes that having the current state trie is sufficient to ensure security. This seems controversial as transaction data is typically expected to be available and some applications rely on it.

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

We plan to perform some optimizations here, but without using state differences. The transaction itself can be compressed to reduce gas costs while still ensuring the availability of transaction data. Stay tuned!