Understanding the Bridge Architecture of Polygon zkEVM for Blockchain Interoperability

·

Blockchain interoperability refers to the ability of different blockchain networks, such as Chain A and Chain B, to interact and share data. As the blockchain ecosystem expands rapidly, the importance of interoperability has become a critical design consideration. Without it, networks risk isolation from the broader ecosystem, driving projects to develop robust interoperability solutions. Each solution involves different trade-offs and underlying technologies. This article explores the native interoperability solution provided by the Polygon team for the Polygon zkEVM L2 network.

A bridge serves as essential infrastructure, enabling asset migration and communication between L1 and L2 networks. From a user's perspective, a bridge allows assets to be transferred from Network A to Network B without altering the quantity or functionality of the asset. Bridges can also transmit data payloads—essentially cross-chain messages—between networks.

For L2 rollups like Polygon zkEVM, where L2 state transitions and transaction data availability are secured by L1 contracts, a properly designed L2 architecture can rely solely on contract logic to synchronize both ends of the bridge. This eliminates the need for trusted off-chain relayers to facilitate cross-network synchronization. It is important to note that this bridge solution requires specific design considerations at the L2 layer.

Core Concepts of the Bridge Interface

The bridging interface consists of bridge contracts deployed on both L1 and L2 networks, enabling users to:

  1. Bridge assets: Lock an asset in the "origin" network and mint a representative token upon claiming it via the bridge contract in the "destination" network.
  2. Reverse bridge assets: Burn the representative token in the destination network to unlock the original asset in the origin network.
  3. Establish cross-chain communication channels: Send data payloads bidirectionally between L1 and L2.

The Role of Exit Merkle Trees

The bridge incorporates a data structure known as the Global Exit Merkle Tree (GEMT). Each leaf in the GEMT represents the root of a specific network's Exit Merkle Tree (EMT). The GEMT contains only two leaf nodes: one for the L1 EMT root and another for the L2 EMT root.

The GEMT is a standard Merkle tree with a fixed two-leaf structure. In contrast, the EMT is an append-only sparse Merkle tree (SMT) with a fixed depth (designed as 32 in Polygon zkEVM). SMTs are widely used for their efficiency in on-chain operations.

Each leaf in a network's EMT represents an intent to bridge an asset (or its representative token) or send a message out of that network. A leaf is formed by taking the keccak256 hash of an ABI-encoded packed structure containing these parameters:

Once a leaf is added to an EMT, a new EMT root is computed, followed by a new GEMT root. The GEMT root is synchronized between networks, allowing for leaf inclusion proofs to be verified on the opposite network to complete bridge operations.

Contract Architecture Overview

Most bridge architectures use smart contracts on both networks. However, to synchronize the GEMT, part of the bridge logic must be integrated with the L2 state management architecture. Understanding this solution requires familiarity with the off-chain roles in L2 state management—such as the Sequencer and Aggregator—and the PolygonZkEVM.sol contract.

The bridge architecture also includes these key elements:

  1. PolygonZkEVMBridge.sol Contract: Serves as the bridging interface, allowing users to interact with the bridge for operations like bridgeAsset, bridgeMessage, claimAsset, and claimMessage. Each network has its own instance of this contract, which manages its respective EMT.

  2. PolygonZkEVMGlobalExitRoot.sol Contract: Manages the GEMT, acting as a historical repository for its roots. It:

    • Stores the GEMT.
    • Computes a new GEMT root whenever the PolygonZkEVM.sol contract updates a new EMT (effectively updating the L2 EMT).
    • Computes a new GEMT root whenever the L1 PolygonZkEVMBridge.sol contract updates a new EMT (updating the L1 EMT).

  3. PolygonZkEVMGlobalExitRootL2.sol Contract: A special contract for cross-network synchronization of GEMT and L2 EMT roots.

    • It contains storage slots for GEMT roots and the L2 EMT root.
    • Its特殊性 lies in the fact that the underlying zero-knowledge proving/verification system can directly access its storage slots. This ensures the validity of GEMTs synchronized from L1 to L2 (L1->L2) and the validity of L2 EMTs synchronized from L2 to L1 (L2->L1).

Bridging Data Flow Explained

The detailed bridge architecture and the interaction between networks for achieving bridge finality are illustrated in Figure 3. The process differs for the two bridge operation types.

Bridging from L1 to L2

The basic workflow for an L1->L2 bridge operation is:

  1. A user calls the bridgeAsset or bridgeMessage function on the L1 PolygonZkEVMBridge.sol contract. If the request is valid, the contract creates a new L1 EMT leaf based on the request's attributes, adds it to the EMT, and computes a new L1 EMT root.
  2. Within the same L1 transaction, the L1 bridge contract calls the L1 PolygonZkEVMGlobalExitRoot.sol contract to update the new L1 EMT root and compute a new GEMT root.
  3. The L2 Sequencer retrieves the new GEMT root from the L1 Global Exit Root contract.
  4. At the start of a transaction batch execution, the L2 Sequencer stores the new GEMT root in the special storage slots of the L2 PolygonZkEVMGlobalExitRootL2.sol contract, making it accessible to L2 users.
  5. To finalize the bridging process, the user must call the claimAsset or claimMessage function on the L2 PolygonZkEVMBridge.sol contract. They must provide a Merkle inclusion proof for the leaf previously added to the EMT.
  6. The L2 bridge contract retrieves the GEMT root from the L2 Global Exit Root contract and verifies the inclusion proof. If valid, the bridging process completes based on the asset type. If invalid, the transaction reverts.

Bridging from L2 to L1

The basic workflow for an L2->L1 bridge operation is:

  1. A user calls the bridgeAsset or bridgeMessage function on the L2 PolygonZkEVMBridge.sol contract. If valid, the contract creates a new L2 EMT leaf, adds it to the EMT, and computes a new L2 EMT root.
  2. Within the same L2 transaction, the L2 bridge contract calls the L2 PolygonZkEVMGlobalExitRootL2.sol contract to update the new L2 EMT root and compute a new GEMT root.
  3. The L2 Aggregator generates a computational integrity zero-knowledge proof (ZKP) for the sequence of batches that includes this L2 bridge transaction. This execution yields the new L2 EMT from the L2 state.
  4. The Aggregator submits the new L2 EMT and the corresponding ZKP to the L1 PolygonZkEVM.sol contract.
  5. The L1 contract verifies the ZKP. If valid, it calls the L1 PolygonZkEVMGlobalExitRoot.sol contract to update the new L2 EMT root and compute a new GEMT root.
  6. To finalize the bridging process, the user must call the claimAsset or claimMessage function on the L1 PolygonZkEVMBridge.sol contract, providing a Merkle inclusion proof for the leaf.
  7. The L1 bridge contract retrieves the GEMT root and verifies the proof. If valid, the process completes; if not, the transaction reverts.

Deep Dive into the Bridge Contract

The PolygonZkEVMBridge.sol contract is the user-facing bridging interface on each network. It contains the necessary storage slots to maintain each network's EMT and the functions for user interaction.

The contract currently offers two bridging functions (bridgeAsset, bridgeMessage) and two claiming functions (claimAsset, claimMessage). A key feature is that L2 accounts may not have ether for gas fees. Therefore, the L2 transaction claiming an asset or message from L1 can be gas-sponsored by the Polygon zkEVM protocol.

The bridgeAsset Function

This function transfers assets to another network. Its parameters include the destination network ID, recipient address, amount, token address, and optional permit data for ERC-20 allowances. The execution flow varies based on the asset type being bridged:

After processing, the function emits a BridgeEvent, adds the new leaf to the EMT, and calls the GEMT contract to update the root.

The bridgeMessage Function

This function transfers messages to another network. Its parameters are similar to bridgeAsset but include a metadata parameter for the message payload. The key differences are:

The claimAsset Function

This function claims assets bridged from another network. The user must provide parameters describing the leaf and a Merkle inclusion proof (smtProof). The function verifies the proof's validity against a stored GEMT root and checks a nullifier bitmap (claimedBitMap) to prevent replay attacks.

The claiming process also has three possible flows:

The claimMessage Function

This function claims messages from other networks. Its parameters and initial verification process are identical to claimAsset. Upon successful verification, the function calls the recipient address:

destinationAddress.call{value: amount}(abi.encodeCall(IBridgeMessageReceiver.onMessageReceived, (originAddress, originNetwork, metadata)));

This transfers any accompanying ether and delivers the message payload. If the recipient is an Externally Owned Account (EOA), it can receive the ether but cannot process the message payload.

Managing Global Exit Roots

The L1 PolygonZkEVMGlobalExitRoot.sol contract calculates and stores every new GEMT root in a map (globalExitRootMap) to ensure future verifiability of leaves. Its updateExitRoot function can be called by:

The L2 PolygonZkEVMGlobalExitRootL2.sol contract is a "special" contract on L2. The Aggregator's zkEVM node software can directly access its lastRollupExitRoot storage slot, which holds the L2 EMT root. This root is then submitted with the L2 state transition proof to the L1 contract, enabling the entire system to stay synchronized.

Frequently Asked Questions

What is blockchain interoperability?
Blockchain interoperability is the capability of different blockchain networks to communicate, share data, and transfer assets between each other seamlessly. It prevents networks from becoming isolated islands and enables a more connected and efficient ecosystem.

How does the Polygon zkEVM bridge ensure security?
The bridge leverages zero-knowledge proofs and Merkle tree structures to secure transactions. Asset transfers and messages are represented as leaves in an Exit Merkle Tree, and their inclusion must be proven against a Global Exit Root that is synchronised and secured between the L1 and L2 networks, minimizing trust assumptions.

What are the main types of assets that can be bridged?
The system supports three asset types: the native ether currency, standard ERC-20 tokens originating from the same network, and representative (wrapped) ERC-20 tokens that stand for assets originating from another connected network.

Can I send messages along with assets using the bridge?
Yes, the bridgeMessage function allows you to send arbitrary data payloads (messages) to another network. You can also send ether alongside a message, which will be transferred to the recipient address upon claiming the message on the destination chain.

What is the purpose of the Global Exit Merkle Tree (GEMT)?
The GEMT acts as a single, shared root of trust between the L1 and L2 networks. It contains the roots of each network's Exit Merkle Tree (EMT), allowing users to prove on one network that a specific bridge action (represented by a leaf) was legitimately initiated on the other network.

Who pays for the gas fees when claiming assets on L2?
A notable feature is that the L2 transaction for claiming assets or messages that originated from L1 can have its gas fees sponsored by the Polygon zkEVM protocol itself. This improves the user experience by removing the need for users to initially fund their L2 wallet with gas money. 👉 Explore more strategies for managing gas fees

Conclusion

The Polygon zkEVM bridge architecture presents a sophisticated and secure approach to achieving blockchain interoperability. By deeply integrating with the L2's zero-knowledge proof system and utilizing a Merkle tree-based structure for proofs, it enables trust-minimized asset and data transfers between L1 and L2. The design carefully handles different asset types, prevents replay attacks, and even offers gas sponsorship for a smoother user experience. This native interoperability solution is a fundamental component in connecting the Polygon zkEVM network to the wider blockchain ecosystem.