Why Polygon’s zkEVM is a Game Changer

The demand for scalable solutions for decentralized applications (dApps) on Ethereum has led to Polygon’s multifaceted approach, including developing Polygon zkEVM.

Polygon’s zkEVM uses zero-knowledge proofs to scale while ensuring compatibility with Ethereum’s virtual machine. A dedicated team is currently exploring the integration of zkEVM technology in the Proof-of-Stake (PoS) chain to minimize disruption for developers and users.

Polygon’s integration signifies a new phase in scaling efforts, with zkEVM promising performance enhancements while retaining EVM’s familiarity.

This comprehensive article delves into the intricacies of zkEVMs, exploring different types and their underlying trade-offs. After understanding these concepts clearly, we’ll explore Polygon zkEVM, a major player in this space. 

Read on to learn why Polygon zkEVM is hailed as the holy grail for Ethereum scaling.

What Is zkEVM?

zkEVM stands for zero-knowledge Ethereum Virtual Machine. It is a type of scaling solution that supports zero-knowledge-proof computations and Ethereum infrastructure for executing smart contract transitions.

Polygon zkEVM uses zero-knowledge proofs to reduce transaction fees and increase throughput while maintaining Ethereum L1’s security.

Ethereum’s popularity has led to network congestion and high transaction fees, threatening the growth and adoption of blockchain technology. Developers are exploring scaling solutions for Ethereum, including zero-knowledge Ethereum Virtual Machines (zkEVMs).

Several teams are racing to develop efficient and user-friendly zkEVMs. Understanding zkEVMs like Polygon’s is essential to navigating blockchain technology. We’ll explore how they work, Polygon’s advantages, and their potential impact on Ethereum’s scalability.

How Do Zero-Knowledge Proofs Work?

A zero-knowledge (ZK) proof is a method by which one party, referred to as a prover, demonstrates to another party, the verifier, that a specific statement is true without disclosing any additional information beyond the truth of the statement itself.

A ZK proof has three main steps: 

1. Commitment: in this phase, the prover and verifier agree on the parameters and cryptographic algorithms to be used. The prover generates a cryptographic commitment representing the verified statement without revealing its content.

2. Challenge: at this point, the verifier challenges the prover randomly, and the prover responds based on the committed statement.

3. Response: After receiving the response, the verifier compares it to the challenge and commitment to confirm its validity.

Zero-knowledge proofs are a cryptographic protocol used in zkEVMs like Polygon zkEVM for scaling benefits. They enable proof of information without revealing additional details.

In zkEVM, zero-knowledge proofs enable off-chain computations to prove their validity to the Ethereum mainnet without revealing every step, resulting in reduced fees, faster transactions, and a secured network thanks to zero-knowledge proofs.

Zero-knowledge proofs offer improved performance without compromising security, making them a key technology for Ethereum and dApps.

EVM Compatibility and Equivalence

When integrating Layer-2 solutions such as Polygon zkEVM with Ethereum, it is essential to consider two main factors: EVM Compatibility and EVM Equivalence.

• EVM Equivalence ensures seamless integration of any Ethereum mainnet application or protocol on EVM-equivalent Layer-2 networks. It’s ideal for replicating Ethereum’s mainnet functionalities on Layer-2 platforms.

• EVM Compatibility allows Ethereum-based applications to function but doesn’t guarantee complete adherence to EVM standards. While it supports most Ethereum functionalities, some adjustments may be necessary. This approach benefits apps that can accommodate slight variations to leverage specific features of Layer-2 networks.

Open graph

What Makes Building zkEVM Difficult?

Zero-knowledge Ethereum Virtual Machines (zkEVMs) are a significant development in blockchain technology, promising enhanced security and scalability for Ethereum. However, building an optimized zkEVM presents unique challenges due to inherent mismatches between EVM and zero-knowledge proof requirements.

Many talented teams are competing to be the first mover in zk-proofs technology, but there are significant hurdles to overcome. Ethereum’s EVM was not designed for the complex computations and cryptographic intricacies of zk-proofs, leading to critical obstacles:

• Special opcodes: The EVM has opcodes for smart contract actions, such as CALL and DELEGATECALL. These opcodes are incompatible with zk-proof systems and must be modified to work within a zero-knowledge-proof framework.

• Stack-based architecture: The EVM uses a stack-based architecture that follows the last in, first out (LIFO) principle, meaning that the last added data is removed first. This architecture is simpler than a registered-based model but harder to prove computation in.

• Storage complexity: EVM’s storage mechanism uses Keccak hashing functions and a Merkle Patricia Trie, which can cause overhead issues in a zk-proof environment. Efficiently managing and optimizing storage for zk-proofs presents significant challenges.

• Proving costs: Generating zk-proofs in a non-compatible system is resource-intensive, time-consuming, and costly, requiring specialized software and expertise.

Types of zkEVMs

In his blog post, ‘The different types of ZK-EVMs,’ Vitalik Buterin introduces a classification system for zkEVMs based on their compatibility with EVM and circuit-proof approach. The system helps explore the details of different zkEVM implementations, each with unique strengths and trade-offs.

Open graph

Type 1 and Type 2 zkEVMs are both critical for Ethereum’s scalability. Some developers aim for perfect equivalence, while others prioritize a pragmatic balance for faster progress and broader adoption. Both approaches contribute to zkEVM development and push scalability and security limits within Ethereum.

Let’s explore the various types of zkEVMs and their unique characteristics.

Type 1: Fully Ethereum-Equivalent

Type 1 ZK-EVMs are fully Ethereum-equivalent and don’t modify any Ethereum components to facilitate proof generation. They don’t replace any in-consensus logic like hashes, state trees, transaction trees, or precompiles, no matter how peripheral.

Advantage — Perfect Compatibility

The goal is to have the ability to verify Ethereum blocks in their present state. This includes verifying the execution-layer side, covering all transaction execution, smart contract, and account logic. However, this does not include the beacon chain consensus logic.

Type 1 ZK-EVMs enhance the Ethereum Layer-1 scalability. In the long term, changes tested in Type 2 and Type 3 ZK-EVMs might be introduced into Ethereum but come with complexities.

Type 1 ZK-EVMs are ideal for rollups, as they allow infrastructure reuse. Ethereum execution clients can generate and process rollup blocks once withdrawals are implemented. This enables the easy reuse of tooling, such as block explorers and production.

Disadvantage — Prover Time

Ethereum’s protocol requires significant computation to ZK-prove due to its lack of ZK-friendliness. Type 1 replicates Ethereum exactly without mitigating these inefficiencies. Proofs for Ethereum blocks take hours to produce, but this can be improved by parallelizing the prover or using ZK-SNARK ASICs.

Type 2: Fully EVM-Equivalent

Type 2 ZK-EVMs aim to be exactly EVM-equivalent but not Ethereum-equivalent. They differ in external features, like the block structure and state tree, but maintain Ethereum’s internal structure.

The goal is to maintain app compatibility, facilitate Ethereum development, and accelerate proof generation.

Advantage — Perfect Equivalence at the VM Level

Type 2 ZK-EVMs modify Ethereum state data structures but cannot directly access them. Applications would still work on a Type 2 ZK_EVM rollup, but Ethereum execution clients would require modifications. EVM debugging tools and most other developer infrastructure would remain available.

Applications that verify Merkle proofs of historical Ethereum blocks may face incompatibility issues if ZK-EVM replaces Keccak with a different hash function. Therefore, it is not advisable to build applications in this way. Instead, Ethereum can add future-proof history access precompiles.

Disadvantage — Improved but Still Slow Prover Time

Type 2 ZK-EVMs are faster than Type 1 by simplifying Ethereum’s stack and using a different hash function like Poseidon. They modify the state tree to store the code hash and Keccak, eliminating the need to verify hashes when processing the EXTCODEHASH and EXTCODECOPY opcodes.

Although these modifications improve prover times, the inefficiencies and ZK-unfriendliness in the EVM still cause delays. For example, MLOAD can’t be interpreted as reading one chunk and may require reading two consecutive chunks, followed by bit operations to combine the results.

Type 2.5: EVM-Equivalent, Except for Gas Costs

One practical approach to improving worst-case prover times is to increase the gas costs of complex EVM operations, including precompiles, KECCAK opcode, and specific calling contract patterns or memory access.

Changing gas costs is less risky than more profound EVM changes, but it may reduce tooling compatibility and break some apps. Developers should avoid requiring more gas than a block can fit and never use hard-coded amounts of gas in calls.

Another way to manage resource constraints is to limit the times each operation can be called. It’s easier to implement in circuits but incompatible with EVM security assumptions.

Type 3: Almost EVM-Equivalent

Type 3 ZK-EVMs are almost EVM-equivalent but with a few modifications that aim to optimize prover times and simplify development.

Advantage — Easier to Build and Faster Prover Times

Type 3 ZK-EVMs may exclude complex features like precompiles and have minor differences in handling contract code, memory, or stack.

Disadvantage — More Incompatibility

The Type 3 ZK-EVM aims to be compatible with most applications, requiring only minimal rewriting. However, some apps may need significant rewrites due to removed precompiles or different handling of edge cases by other VMs.

Type 4: High-Level Language Equivalent

A Type 4 system uses high-level smart contract source code compiled into ZK-SNARK-friendly languages.

Advantage — Fast Prover Times

To reduce overhead in EVM execution, start from the higher-level code directly and consider compiling from high-level languages for easy proving.

Disadvantage — More Incompatibility

Although Vyper and Solidity applications can be compiled, they may not be compatible in the following ways:

• Type 4 systems may have contract addresses different from the EVM due to CREATE2 dependencies. This can cause issues for applications that rely on not-yet-deployed contracts, ERC-4337 wallets, or EIP-2470 singletons.

• Handwritten EVM bytecode is an efficient programming language used in some applications. Type 4 systems may not support it, but limited EVM bytecode support can be implemented without becoming a full-on Type 3 ZK-EVM.

• Debugging infrastructure on EVM bytecode cannot be carried over, but traditional high-level or intermediate languages like LLVM offer greater access to debugging infrastructure.

Polygon zkEVM

On March 27, 2023, the launch of Polygon zkEVM’s mainnet marked a pivotal moment in Ethereum’s scaling. As the first open-source zkEVM, it promised significant performance improvements and a seamless transition for developers and users.

Polygon zkEVM is committed to open-source development and continuous improvement. The Dragonfruit upgrade optimized performance and enhanced developer tools. The Etrog upgrade introduced precompiled smart contract support, bringing Polygon zkEVM closer to achieving Type 2 ZK-EVM status.

Polygon is working on a new upgrade called ‘Type 1 Prover,’ which aims to improve computations while maintaining EVM equivalence. This proposal aims to reduce prover costs and set a new standard for ZK-EVM technology.

Polygon zkEVM scales Ethereum using zkEVM technology, offering seamless development and new opportunities for dApps.

Polygon’s zkEVM Competitors

zkEVMs have spurred creative solutions to scale Ethereum, including Polygon zkEVM, Scroll, Taiko, Linea, zkSync, and StarkNet. Each brings unique strengths, promoting a competitive environment that drives innovation.

Polygon zkEVM:

• Open-source development is prioritized, encouraging community involvement and transparency, which can lead to faster evolution and broader adoption.

• The platform aims for full compatibility with the Ethereum Virtual Machine (EVM), easing the migration process for existing dApps and developers.

• Upgrades such as Etrog and the proposed Type 1 Prover are evidence of the platform’s ongoing innovation and commitment to enhanced performance and efficiency.

• Polygon zkEVM offers extensive developer tooling and resources to facilitate smooth integration and empower builders to leverage their existing Ethereum expertise, thereby accelerating dApp development on the platform.

Competitors:

• Scroll: This project utilizes optimistic rollup technology to achieve high throughput and fast finality for transactions.

• Taiko: Built on StarkWare’s technology, Taiko aims to balance scalability and security.

• Linea: This project focuses on high performance and decentralization, using its own custom Proof-of-Stake consensus mechanism.

• zkSync: Another EVM-compatible option, zkSync provides user-friendly experience and supports various Ethereum developer tools.

• StarkNet: This project focuses on general-purpose computation and provides a flexible and powerful platform for diverse applications.

Choosing a zkEVM solution depends on individual needs. Polygon zkEVM offers a user-friendly and developer-friendly environment with a focus on innovation.

Future Prospects

There are currently two public networks in the Polygon ecosystem: Polygon PoS and Polygon zkEVM rollup. After the Polygon 2.0 upgrade, both networks will use the latest zkEVM technology, one as a rollup and the other as a validium. The Polygon team believes that both networks can coexist and work together to complement each other.

The Polygon zkEVM rollup provides the highest level of security, but it may come with higher fees and limited throughput. It perfectly suits applications that handle high-value transactions where security is a top priority, such as high-value DeFi applications.

The upgraded Polygon PoS (zkEVM validium) would provide a highly scalable and cost-effective solution for applications with high transaction volumes. It would be an excellent fit for use cases like Web3 gaming and social and micro DeFi requiring low transaction fees.

The Takeaway

Polygon zkEVM is a significant development in Ethereum scaling. It combines open-source development, full EVM equivalence, and a developer-friendly approach, making it an ideal solution for dApp developers and users.

As the zkEVM landscape evolves, Polygon zkEVM aims to continuously improve and seamlessly integrate, positioning itself as a major player in scaling Ethereum.