Demystifying Polygon’s ZK-EVM | Part 2

This article is part 2 of a series on Polygon’s ZK-EVM, please read part 1 here.

Table of contents

· Introduction
· Architecture of current ZK-EVM
· Implementation Model of Polygon Zk-EVM
· zkNode
· Trustless L2 State Management​
· Transaction life cycle
∘ Execution
∘ Transaction Batching
∘ Batch Sequencing
∘ Batch Aggregation
· Banana SDK Live on Polygon Zk-EVM Testnet
· Conclusion

Introduction

In our previous article, we provided an overview of Polygon’s ZK-EVM, exploring its role as a ZK-rollup and the fundamentals of ZK-Rollup technology in EVMs. In this article, we will shift our focus to the components and transaction journey within Polygon’s ZK-EVM. Join us as we delve deeper into the architecture, implementation model, and transaction life cycle of this cutting-edge solution.

Architecture of current ZK-EVM

So lets start with a 1000 ft view of the architecture of Polygon Zk-EVM. The major components of zkEVM are:

• Consensus Contract (PolygonZkEVM.sol)
• zkNode
• Synchroniser
• Sequencers & Aggregators
• RPC
• zkProver
• zkEVM Bridge

Implementation Model of Polygon Zk-EVM

The implementation model for Polygon ZK-EVM utilizes the Consensus Contract model, which leverages the existing Proof-of-Delegated (PoD) mechanism and allows for the permission-less participation of multiple coordinators in producing batches on Layer 2 (L2). The Consensus Contract, known as PolygonZkEVM.sol, employs a simplified technique that offers greater efficiency in addressing the challenges associated with PoD. This strategic implementation of contract-based consensus ensures that the network:

1. Maintains Permissionless Feature: The Consensus Contract allows for the permissionless participation of multiple coordinators, enabling the production of L2 batches in a decentralized manner.
2. Ensures High Efficiency: The chosen implementation technique focuses on efficiency, which is crucial for optimal network performance. By streamlining the consensus process, the network can achieve faster transaction processing and higher throughput.
3. Achieves Decentralization: The Consensus Contract model aims to maintain an acceptable degree of decentralization within the network. By allowing multiple coordinators to participate, it mitigates the risk of centralization and promotes a more robust and resilient ecosystem.
4. Enhances Security: One of the primary concerns in any consensus mechanism is protecting the network from malicious attacks. The Consensus Contract implementation incorporates measures to safeguard against such attacks, particularly from validators who may attempt to compromise the integrity of the network.
5. Balances Validation Effort and Network Value: The implementation model ensures a fair balance between the overall validation effort required and the value provided by the network. This equilibrium is crucial for incentivizing validators to actively participate in the consensus process.

ZK-Node

A zkNode is essential software for operating a zkEVM node. It acts as a client, enabling synchronization and governing the roles of participants (Sequencers or Aggregators). Participants in the Polygon zkEVM network have the flexibility to choose their preferred mode of participation:

• As a node to know the state of the network, or
• As a participant in the process of batch production in any of the two roles: Sequencer or Aggregator

Sequencer

A sequencer is a crucial component responsible for receiving, ordering, and generating batches of L2 transactions in the zkEVM network. It submits these batches to the storage slots of the Consensus contract as sequences.

By executing and broadcasting batches to L2 network nodes, the sequencer achieves fast finality and minimizes costs associated with high network usage, even before submitting them to L1. To fulfill its role, the Trusted Sequencer must operate a zkEVM node in Sequencer mode and possess an Ethereum account enforced by the Consensus Contract.

Aggregator

The Trusted Aggregator plays a critical role in the zkEVM network by computing the L2 State based on batches of L2 transactions executed by the Trusted Sequencer. Its primary responsibility is to take the L2 batches committed by the Trusted Sequencer and generate Zero-Knowledge proofs that attest to the computational integrity of these batches. This is achieved through a special off-chain EVM interpreter employed by the Aggregator.

The Consensus Contract validates these Zero-Knowledge proofs, ensuring that the zkEVM inherits the security of L1. Before committing new L2 State roots to the Consensus Contract, verification of the proofs is required. A verified proof serves as irrefutable evidence that a specific sequence of batches led to a particular L2 State.

Consensys Contract

The PolygonZkEVM.sol contract serves as the Consensus Contract utilized by both the Trusted Sequencer and the Trusted Aggregator for their interactions with L1. The Trusted Sequencer has the ability to commit batch sequences to L1 and store them in the PolygonZkEVM.sol contract, establishing a historical repository of sequences.

Additionally, the PolygonZkEVM.sol contract facilitates the public verification of transitions from one L2 State root to the next by the Aggregator. This is achieved through the Consensus Contract’s validation of the Aggregator’s ZK-proofs, which provide evidence of the correct execution of transaction batches.

Trustless L2 State Management

Overview of L2 and L1 interaction

The Trusted Sequencer generates batches that are shared with L2 network nodes via a broadcasting channel to achieve fast finality of L2 transactions. Each node independently computes the resulting L2 State by executing the batches locally. Now the trusted sequencer needs to commit these transactions from L1 to L2 so that this cannot be changed and later on used by Aggregators to produce a zero-knowledge proof. Once the Trusted Sequencer commits the batch sequences fetched from L1, L2 network nodes execute them again, eliminating the need for trust. And yeah you read it right, the L2 nodes fetch the committed transaction from L1 nodes after sequencer has committed to them and re-execute them so that they don’t have to trust it.

The off-chain execution is later verified on-chain through a Zero-Knowledge proof, and the resulting L2 State root is committed. As the zkEVM protocol advances, L2 state roots are directly synchronized from L1 by L2 network nodes. The L2 State has three stages, corresponding to different ways L2 nodes update their state, depending on the format of the batch data.

Three states of L2 nodes

There are three methods through which L2 nodes can receive batch data:

1. Trusted State: Directly from the Trusted Sequencer before the batches are committed to L1, the update is solely informed by the information (i.e., Batches containing ordered transactions) received directly from the Trusted Sequencer. This occurs prior to any data availability on L1, resulting in the Trusted State of L2.
2. Virtual State: Straight from L1 after the batches have been sequenced, L2 nodes receive updates based on information retrieved from the L1 network. This happens after the batches have been sequenced and data has become available on L1. This state is referred to as the Virtual State of L2.
3. Consolidated State: Only after the correctness of execution has been proven by the Aggregator and verified by the PolygonZkEVM.sol contract, L2 nodes receive updates that include verified zero-knowledge proofs of computational integrity. Following the successful verification of the Zero-Knowledge proof on L1, L2 nodes synchronize their local L2 State root with the one committed in L1 by the Trusted Aggregator. This results in the Consolidated State of L2.

Three states of L2

It is important to note that L2 nodes receive the three batch data formats in the chronological order mentioned above.

Transaction life cycle

In the Polygon zkEVM network, transactions follow a defined life cycle. Users create transactions in their wallets and sign them with their private keys. These signed transactions are then sent to the Trusted Sequencer’s node through the JSON-RPC interface.

The transactions are stored in the pending transactions pool, where they await the Sequencer’s decision for execution or discard. The communication between users and the zkEVM occurs via JSON-RPC, which ensures compatibility with Ethereum RPC. This compatibility enables EVM-compatible applications, including wallet software, to seamlessly interact with the zkEVM network, providing a familiar experience for Ethereum network users.

Execution

As stated earlier, now the trusted Sequencer reads transactions from the pool and decides whether to discard them or order and execute them. Transactions that have been executed are added to a transaction batch, and the Sequencer’s local L2 State is updated.

Once a transaction is added to the L2 State, it is broadcasted to all other zkEVM nodes via a broadcast service. It is worth noting that by relying on the Trusted Sequencer, we can achieve fast transaction finality (faster than in L1). However, the resulting L2 State will be in a trusted state until the batch is committed in the Consensus Contract.

Transaction Batching

The Trusted Sequencer must batch the transactions using the following BatchData struct specified in the PolygonZkEVM.sol contract:

struct BatchData {
  bytes transactions;
  bytes32 globalExitRoot;
  uint64 timestamp;
  uint64 minForcedTimestamp;
}

1. Batch transactions in the Polygon zkEVM network are encoded using the RLP standard, with concatenated signature values.
2. The GlobalExitRoot represents the root of the Bridge’s Global Exit Merkle Tree, synchronized in the L2 State for asset transportation.
3. Each batch has a timestamp, ensuring ordering and synchronization with L1 blocks, with specific constraints to maintain consistency.
4. The minForcedTimestamp parameter is used for forced batches, countering censorship in the network.

Batch Sequencing

In the Polygon zkEVM network, batches undergo sequencing and validation before being incorporated into the L2 Virtual State. The Trusted Sequencer utilizes the sequencedBatches mapping in the L1 PolygonZkEVM.sol contract to add a batch to the sequence. To be eligible for sequencing, batches must be included in the array of batches. The Trusted Sequencer interacts with the PolygonZkEVM.sol Contract, which utilizes the sequenceBatches mapping, accepting an array of batches as input for sequencing.

Batch Validity & L2 State Integrity in the Polygon zkEVM network is ensured through a series of criteria. The sequencedBatches function verifies the validity of each batch by checking the presence of a valid globalExitRoot, ensuring the transactions byte array length is within the specified limit, and maintaining the chronological order of batches. If any batch is found to be invalid, the entire sequence is discarded. The sequencing process utilizes the lastBatchSequenced variable as a batch counter and employs a hashing mechanism to maintain the cryptographic integrity of the batch chain. The digest of each batch is computed using accumulated hashes of previously sequenced batches.

Batch Aggregation

In the Polygon zkEVM network, the Trusted Aggregator plays a crucial role in aggregating the sequences of previously committed batches by the Trusted Sequencer. This aggregation process aims to achieve the final stage of the L2 State, known as the Consolidated State. By adding the resulting L2 State root to the batchNumToStateRoot mapping in the ‘PolygonZkEVM.sol’ contract, the Aggregator creates a storage structure that holds all the consolidated L2 State roots, indexed by the last batch index of each aggregated sequence. This step ensures the integrity and organization of the network’s consolidated L2 State.

Banana SDK Live on Polygon Zk-EVM Testnet

We are excited to announce that Banana SDK is now live on the Polygon ZK-EVM testnet. With Banana, onboarding new users to the Polygon ZK-EVM network has never been easier. In just under a minute, users can create their wallets without the hassle of managing private keys. The security of user keys is ensured by storing them securely within the user’s hardware, offering a security experience that is 100 times better than passwords and existing EOAs.

How is this possible, you ask? Banana utilizes passkeys, allowing users to create wallets using their face ID or touch ID. This innovative approach simplifies web3 adoption to such an extent that you won’t even realize how easy it is to use. By combining the high transaction throughput and low gas fees of Polygon’s ZK-EVM with Banana’s user-friendly onboarding process, we are one step closer to achieving mass adoption of web3. Experience the power of Banana SDK on the Polygon ZK-EVM testnet and witness the seamless integration of web3 into your everyday transactions.

Conclusion

Thank you for reading the post, we hope you enjoyed it. We covered the basics of the components of Polygon’s ZK-EVM i.e. Sequencers, Aggregators and ZK-EVM contract, how they interact with each other and what is the journey of a transaction when it leaves the wallet. Talking about wallets, Banana SDK is live on polygon ZK-EVM and providing the seamless user ondoarding expierence to this powerful technology. Here is a link where you can read more about it. Please post your comments down below we would love to hear them out! Thanks

Banana SDK is a smart contract wallet infrastructure that leverages account abstraction to facilitate secure and user-friendly onboarding for applications. It is currently operational on Polygon’s ZK-EVM, Polygon, Astar, Gnosis chain and Optimism. For more information on Banana SDK, please visit our official website.

Get in touch

Twitter | Discord | Telegram | LinkedIn | Github | Email