Similar to how the Internet protocol is modelled as a multi-layer stack, a blockchain protocol can be divided into several layers. - **Layer 0 (L0):** consists of hardware devices, protocols, connections, and other components that form the foundation of a blockchain ecosystem, Layer 0 acts as the infrastructure lying underneath the blockchain. -- **Layer 1 (L1):** carries out most of the tasks to maintain a blockchain network’s fundamental operations like consensus mechanisms, dispute resolution, programming languages, policies, etc. This layer represents the actual blockchain. +- **Layer 1 (L1):** carries out most of the tasks to maintain a blockchain network's fundamental operations like consensus mechanisms, dispute resolution, programming languages, policies, etc. This layer represents the actual blockchain. - **Layer 2 (L2):** is an extra layer sitting on top of layer-1. Layer 2 performs the majority of transactional validations and heavy computations that are meant to run on layer 1. Layer 2 relies on layer 1 for security, so it frequently exchanges data with layer 1. ## Scaling using rollups - layer 2 @@ -46,6 +47,7 @@ Similar to how the Internet protocol is modelled as a multi-layer stack, a block Scaling solutions refer to protocols that help solve the scalability problem of blockchain. A solution can be implemented on any layer of the blockchain, however, L0 and L1 are costly to modify as some changes might require a hard fork. Nowadays, the most widely adopted scaling solutions are implemented on L2 and many of them are rollups. Rollup is a class of L2 scaling solutions that bundles several off-chain transactions into one on-chain commitment, hence reducing the overall cost of the protocol as fewer computations are performed on L1. According to how rollups enforce Computational Integrity (CI), there are two main types of rollups: + - In **optimistic rollups**, L2 sequencers submit batches of transactions to the mainnet without verifying their validity. Instead of immediate verification, optimistic rollups provide a challenge period, lasting up to approximately seven days, during which network participants can dispute the validity of any transaction. - **Zero-knowledge (ZK) rollups** use advanced cryptographic techniques known as zero-knowledge proofs to validate transactions. This method allows the execution of transactions on L2 to be verified on L1 without a challenge period, significantly improving the user experience for cross-chain transactions between L1 and L2 compared to optimistic rollups. @@ -54,20 +56,23 @@ Rollup is a class of L2 scaling solutions that bundles several off-chain transac
-In this article, we focus on ZK rollups (zkEVM). First, we present the concept of zero-knowledge proof (ZKP) and how ZKP can improve the scalability of blockchain. Then, we provide an overview of zkevm. Finally, we summarize and compare some existing implementations of zkEVMs, evaluating their designs and performance. +In this article, we focus on ZK rollups (zkEVM). First, we present the concept of zero-knowledge proof (ZKP) and how ZKP can improve the scalability of blockchain. Then, we provide an overview of zkEVM. Finally, we summarize and compare some existing implementations of zkEVMs, evaluating their designs and performance. ## What is zero-knowledge proof? -Zero-knowledge proof is first devised in 1985 by Goldwasser, Micali, and Rackoff, as an interactive proof system (IP) is an interactive protocol that involves two parties: a prover and a verifier. These two parties will communicate back and forth multiple times for prover to convince verifier that a statement is true. Any interactive proof has the two following properties: +First devised in 1985 by [Goldwasser, Micali, and Rackoff](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf), an **interactive proof system (IP)** is an interactive protocol that involves two parties: a prover and a verifier. These two parties will communicate back and forth multiple times for prover to convince verifier that a statement is true. Any interactive proof has the two following properties: + - **Completeness:** If the statement is true, then an honest prover can convince the verifier with high probability. - **Soundness:** If the statement is false, then, for any prover, the verifier rejects the proof with high probability. If prover only sends one message to verifier, we say that the proof system they engaged in is non-interactive. One of the most employed cryptographic techniques to turn interactive proof systems into non-interactive protocols is Fiat-Shamir transformation. -In practice, the term "proof" is used interchangeably with "argument" and, most of the times, the latter is more accurate. Argument systems were introduced by Brassard, Chaum, and Crépeau in 1986. Compared to proof systems, the soundness property of argument systems is only required to hold against computationally bounded provers (provers with limited computing resources). According to this intuition, most modern computers are bounded, so arguments are considered "sound enough" in most cases. +In practice, the term "proof" is used interchangeably with "argument" and, most of the times, the latter is more accurate. **Argument systems** were introduced by [Brassard, Chaum, and Crépeau](https://crypto.cs.mcgill.ca/~crepeau/PDF/BCC88-jcss.pdf) in 1986. Compared to proof systems, the soundness property of argument systems is only required to hold against computationally bounded provers (provers with limited computing resources). According to this intuition, most modern computers are bounded, so arguments are considered "sound enough" in most cases. -A proof or argument system is considered zero-knowledge if the prover discloses nothing to the verifier other than the truthfulness of the statement being proved. A witness for a statement is a piece of information that allows you to efficiently verify that the statement is true. In a zero-knowledge proof system, prover can convince verifier that the existential statement holds while revealing absolutely no information about any of the witnesses. +A proof or argument system is considered **zero-knowledge** if the prover discloses nothing to the verifier other than the truthfulness of the statement being proved. With a zero-knowledge proof, a prover can prove that they know some hidden information. That secret information is, conceptually, a **witness**. In a zero-knowledge proof system, prover can perduade verifier that a statement holds while revealing any of the witnesses. One of the most well-known examples for zero-knowledge proof is the "Where's Waldo?" example. In this example, you want to convince your friend that you have found Waldo without disclosing his location in the picture. You can do so by using a board big enough to cover the entire picture when you show your friend the image of Waldo through a fixed peephole on that board. The witness, in this case, is the exact coordinates of Waldo. +
We are now examining two widely adopted and fully open-source zkEVMs: Polygon zkEVM and zkSync Era. We will begin by exploring the technical stack of each product, including their logical architecture, zero-knowledge components, and data availability (DA) solutions. Polygon zkEVM is primarily focused on optimizing fast proving times, aiming to expedite the verification process efficiently. In contrast, zkSync Era prioritizes data compression through its state diffs mechanism, which facilitates more economical on-chain settlement. -Furthermore, we will evaluate the EVM compatibility of both zkEVMs. Polygon zkEVM demonstrates high compatibility with EVM by directly interpreting EVM bytecode without the need for an intermediate representation. On the other hand, zkSync Era's instruction set differs significantly from EVM, preventing it from directly interpreting EVM bytecode like Polygon zkEVM. +Furthermore, we will evaluate the EVM compatibility of both zkEVMs. Polygon zkEVM demonstrates high compatibility with EVM through its ability to directly interpret EVM bytecode without the need for an intermediate representation. On the other hand, [zkSync Era's instruction set](https://matter-labs.github.io/eravm-spec/spec.html) differs significantly from that of EVM, preventing it from directly interpreting EVM bytecode like Polygon zkEVM. This comparison highlights the distinct approaches and technical considerations of each zkEVM in the context of their architecture, zero-knowledge features, data availability solutions, and compatibility with Ethereum's EVM. @@ -129,9 +134,9 @@ This comparison highlights the distinct approaches and technical considerations Polygon zkEVM is developed by [Polygon Labs](https://polygon.technology/). Polygon Labs has open-sourced two implementations of their CPU prover (written in [C++](https://github.com/0xPolygonHermez/zkevm-prover) and [Javascript](https://github.com/0xPolygonHermez/zkevm-proverjs)). -**Logic Part:** The logic part of Polygon zkEVM is divided into two parts: Polygon-VM and its ROM. Implementing logic part starts with a DSL called Polynomial Identity Language (PIL). This language is used to describe a uniprocessor VM. We refer to this machine as Polygon-VM. The firmware of Polygon-VM is written in a higher-level DSL called zero-knowledge Assembly (zkASM). The logic of EVM is contained within this firmware. Due to its immutability, the firmware is referred to as the read-only memory (ROM) of Polygon-VM. +**Logic Part:** The logic part of Polygon zkEVM is divided into two parts: Polygon-VM and its ROM. Implementing logic part starts with a DSL called [Polynomial Identity Language (PIL)](https://docs.polygon.technology/zkEVM/spec/pil/). This language is used to describe a uniprocessor VM. We refer to this machine as Polygon-VM. The firmware of Polygon-VM is written in a higher-level DSL called [zero-knowledge Assembly (zkASM)](https://docs.polygon.technology/zkEVM/spec/zkasm/). The logic of EVM is contained within this firmware. Due to its immutability, the firmware is referred to as the read-only memory (ROM) of Polygon-VM. -**Zero-knowledge Part:** Polygon zkEVM generates proofs of CI through a pipeline. In this pipeline, eSTARK [[8]](#8) is utilized to perform proof recursion, aggregation and composition while Groth16 [[1]](#1) or fflonk [[10]](#10) is employed for proof compression. +**Zero-knowledge Part:** Polygon zkEVM generates proofs of CI through a pipeline. In this pipeline, eSTARK [[8]](#8) is utilized to perform [proof recursion, aggregation and composition](https://docs.polygon.technology/zkEVM/architecture/zkprover/stark-recursion/composition-recursion-aggregation/) while Groth16 [[1]](#1) or fflonk [[10]](#10) is employed for proof compression. Because of the monolithic design of its ZK circuits, Polygon's prover is highly optimized to run on CPUs of a single powerful node.
- **DA Solution:** Instead of submitting detailed transaction data, zkSync focuses on posting state differentials ("state diffs") to L1. These diffs represent changes in the blockchain's state (account balance changes, storage updates, etc.), enabling zkSync to efficiently manage how data is stored and referenced: -- Instead of submitting detailed transaction data, zkSync focuses on posting state differentials (state diffs for short) to L1. These diffs represent changes in the blockchain's state (account balance changes, storage updates, etc.), enabling zkSync to efficiently manage how data is stored and referenced: +- Efficient use of storage slots: Changes to the same storage slots across multiple transactions can be grouped, reducing the amount of data that needs to be sent to L1 and thereby lowering gas costs. - Compression techniques: All data sent to L1, including state diffs, is compressed to further reduce costs. **EVM Compatibility:** zkSync Era is classified as a type-4 zkEVM, which means compatibility is actively traded for faster development. To make comparison easier, we will examine the same aspects as we did for Polygon zkEVM. @@ -186,16 +190,21 @@ Since EraVM's instruction set is mostly different from that of EVM, it cannot in
- Besides incompatibility at bytecode level, zkSync Era also deviates from EVM in many aspects such as fee model, computer architecture, built-in Account Abstraction, etc. Notably, some of these changes actually alter the behavior of execution layer. -### Performance benchmark +### Performance benchmarks + +We summarize the benchmarks to compare Polygon zkEVM and zkSync Era based on data from [[12]](#12). But ... before we start, here are the configurations of each prover: + + | | Git Commit | Hardware Configuration | Hourly Cost | + | -------- | -------- | -------- | -------- | + | Polygon zkEVM | d37e826 | r6i.metal (128 vCPUs, 1024GB RAM) | 8.06 USD | + | zkSync Era | 4794286 | g2-standard-32 (32 vCPUs, 1 NVIDIA L4 GPU, 128 GB RAM) | 1.87 USD | -We summarize the benchmark to compare Polygon zkEVM and zkSync Era based on data from [[12]](#12). **Prover time.** Polygon zkEVM maintains a proving time of either 190 or 200 seconds for each batch regardless of input size. In exchange for its outstandingly fast proof generation, Polygon zKEVM requires much more expensive hardware. On the other hand, the time spent on proof generation of zkSync Era extends with larger batch sizes. The proving time of zkSync Era increased from 400 to 1200 seconds when the batch size increased from 10 transactions to 200 transactions. -**Settlement costs.** The settlement costs This involve calling the L1 contract to commit to a specific batch, and submitting proofs and executing the verifier logic (e.g., SNARK verifier) for the committed batches. The settlement costs per batch of Polygon zkEVM are cheaper. However, its batch size is smaller, resulting in higher settlement costs per transaction overall. +**Settlement costs.** The settlement costs take into account calling the L1 contract to commit to a specific batch, submitting proofs and executing the verifier logic (e.g., SNARK verifier) for the committed batches. The settlement costs per batch of Polygon zkEVM are cheaper. However, its batch size is smaller, resulting in higher settlement costs per transaction overall. | Metrics | Polygon zkEVM | zkSync Era | | -------------------- | -------------- | ----------- | @@ -203,9 +212,9 @@ We summarize the benchmark to compare Polygon zkEVM and zkSync Era based on data | Median Batch Size | 27 | 3,895 | | Median Batch Size | 2,201 gas | 209 gas | -**Proof Compression.** The block’s proof from one proof system to another can be compressed to a smaller proof. This typically involves proving the verification of the aggregated proof in a cheaper (with regards to the verification cost) proof system (e.g., Groth16) so that the cost of settlement is lower. For Polygon zkEVM, the median time of proof compression is 311 seconds while the number for zkSync Era is 1,075 seconds. +**Proof Compression.** The block's proof from one proof system to another can be compressed to a smaller proof. This typically involves proving the verification of the aggregated proof in a cheaper (with regards to the verification cost) proof system (e.g., Groth16) so that the cost of settlement is lower. For Polygon zkEVM, the median time of proof compression is 311 seconds while the number for zkSync Era is 1,075 seconds. -**DA costs** One of the disadvantages of Polygon zkEVM is its high DA cost. The table below show the number of bytes used for DA for different payload types. The DA cost of Polygon zkEVM is 3-7 times higher than zkSync Era. +**DA costs.** One of the disadvantages of Polygon zkEVM is its high DA cost. The table below show the number of bytes used for DA for different payload types. The DA cost of Polygon zkEVM is 3-7 times higher than zkSync Era. | Payload Type | Polygon zkEVM | zkSync Era | | -------------------- | -------------- | ----------- | @@ -213,6 +222,20 @@ We summarize the benchmark to compare Polygon zkEVM and zkSync Era based on data | Contract Deployment | 84,369 | 17,087 | | ETH Transfer | 283,905 | 88,693 | + +### Polygon zkEVM vs zkSync Era: In Conclusion +To quickly sum up what we have learnt in this section, below is a table that captures the key takeaways from our analysis of Polygon zkEVM and zkSync Era. + +| | Polygon zkEVM | zkSync Era | +| -------------------- | -------------- | ----------- | +| Logic Part | Use PIL to define base constraint system (Polygon-VM) and zkASM to write EVM's logic (ROM) | Constraint system and a part of EVM's logic are contained in Rust ZK circuits while the rest of EVM is handled by Solidity/Yul smart contracts | +| Zero-knowledge Part | Proving architecture resembles a pipeline. Prover is resource-intesive and highly optimized for CPU and vertical scaling | Proving architecture resembles a tree. Prover can run on both CPU and GPU and can horizontally scale | +| DA Solution | All L2 transaction data is published on L1 | Only (compressed) state differentials (state diffs) are published on L1 | +| zkEVM Type | Type-2 zkEVM | Type-4 zkEVM | +| EVM Compatibility | Can directly interpret EVM bytecode | Ethereum smart contracts must be compiled to EraVM bytecode to be executed | +| Performance | Proving time remains constant regardless of input size. DA cost is significantly higher because of all transaction data is posted to L1 | Proving time increases as input size grows. DA cost is much lower thanks to the use of state diffs and data compression | + + ## References [1] Groth, Jens. "On the size of pairing-based non-interactive arguments." Advances in Cryptology–EUROCRYPT 2016: 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, May 8-12, 2016, Proceedings, Part II 35. Springer Berlin Heidelberg, 2016.