This update has improved the compatibility between Polygon zkEVM and Ethereum, bringing significant optimization to the efficiency of node execution and queries, and also expanding the possibilities of the Polygon CDK ecosystem.

Etrog Upgrade Overview

The upgrade of Polygon zkEVM to Etrog was completed in February 2024. This upgrade is the most significant one since the launch of Polygon zkEVM on the mainnet. It not only added support for several precompiled contracts in the underlying circuit, but also optimized the chain's packing and block generation mechanism. Additionally, it restructured the entire contract architecture, laying the foundation for the future development of the Polygon CDK ecosystem, as well as new features such as AggLayer and Unified Bridge. Overall, this update has enhanced the compatibility between Polygon zkEVM and Ethereum, greatly optimizing the efficiency of node execution and queries, and broadening the possibilities of the Polygon CDK ecosystem.

This article will delve into the technical details of this upgrade from the perspective of Polygon zkEVM contracts and node code, and comprehensively outline and complete the upgrade path from the early version of CDK Validium to the Etrog version based on the open-source Rollup upgrade solution.

Contract Refactoring

Before the Etrog upgrade, the Polygon zkEVM contracts mainly consisted of consensus contracts and bridge contracts.

Consensus Contracts

The consensus contracts record most of the information on the layer-two chain, including chain ID, version, basic information, real-time state information such as batch, and proof submission records. For Validium, the raw transaction data within the batch is not recorded in the consensus contract, but is saved by a committee contract within the DA node group off-chain. By combining this basic information and real-time state information, anyone can fully restore the state of a layer-two chain.

Bridge Contracts

On the other hand, the bridge contracts use a set of exit root state management to record all cross-chain states between layer-one and layer-two, and complete the asset flow between layer-one and layer-two through the Lock/Mint mode. The child nodes of the exit root are updated simultaneously by the bridge contract and the consensus contract, with the former maintaining the deposit transaction state from layer-one to layer-two, and the latter maintaining the withdrawal state from layer-two to layer-one through ZK proof submission.

The most significant change brought about by the Etrog upgrade at the contract level is the introduction of a multi-network solution, using a set of contracts to support multiple networks, rather than the original single layer-two network management and maintenance. It also relies on the newly introduced Unified Bridge to connect the asset interoperability between these layer-two networks, providing a better foundation for the overall ecosystem's future development.

Since the original contract structure does not support the deployment of multiple networks, the Etrog upgrade has refactored the overall contract structure:

1. Introduced the RollupManager contract to manage all layer-two network information;
2. Modified the structure of the bridge contract and GlobalExitRoot to maintain cross-chain states of all networks, ensuring interoperability of assets between different layer-two networks.

For detailed contract structure, please refer to

For the Polygon zkEVM layer-two networks running on versions below Etrog, these modifications have a strong disruptive impact on contract data. Therefore, the corresponding upgrade plan poses a significant challenge. Here, we will detail the specific upgrade plan behind the consensus contract and bridge contract separately.

Consensus Contracts

The most significant change in the consensus contract part of the Etrog upgrade is the introduction of a brand new RollupManager contract. Since most of the permission management and other contract operations in the new version are concentrated in the newly introduced RollupManager contract, the official upgrade plan for Polygon will update the implementation of the original Polygon zkEVM proxy to the RollupManager contract, and deploy a new subnetwork contract, PolygonZkEVMExistentEtrog, as the new consensus contract for the original network, writing the global information of the Rollup network into the initialization call of the new RollupManager contract. This PolygonZkEVMExistentEtrog, compared to the usual layer-two network contract PolygonZkEVMEtrog after the Etrog upgrade, implements an initializeUpgrade method for transitional logic during the upgrade process.

To ensure consistency in the slot of proxy contract variables after the upgrade, RollupManager inherits a LegacyZKEVMStateVariables contract specifically for storing old version variables. Furthermore, to ensure consistency of batch states before and after the upgrade, RollupManager also performs a series of operations during initialization, reassigning historical data to the new contract and generating a forcedBatch in layer-one according to the post-upgrade rules as a transitional batch for the Etrog upgrade.

Bridge Contracts

The Etrog upgrade provides the bridge contract with the functionality to customize gas tokens, and also modifies the generation scheme of globalExitRoot to ensure compatibility with the update of exit roots for multiple layer-two chains, enabling interoperability between multiple layer-two chains.

Node Update

On the node side, the Etrog upgrade mainly updated the sequencer and synchronizer modules, and also updated the contract ABI for interaction with the new version of contracts.

Sequencer Module

1. This upgrade modified the logic for block and batch packing. Before Etrog, each layer-two block only contained one transaction, and the block time and batch time were consistent. This design differed significantly from Ethereum's pattern, causing significant incompatibility for on-chain applications that rely on traversing transactions by block. Therefore, after the Etrog upgrade, the entire logic for packing layer-two blocks was adjusted to fixed-time block generation, and a single block could contain multiple transactions, addressing the compatibility issues in previous versions.
2. Synchronizer Module

The changes in Etrog are twofold. Firstly, it adapts to the events of the new version of contracts and the corresponding processing logic, including how to handle transitional batches, how to handle new batch/proof submission events, and info_tree update events. The other part involves a complete overhaul of the overall synchronization logic. In versions before Etrog, the synchronization logic was primarily serial. For permissionless nodes, they had to wait for layer-one data to be fully synchronized in batch order before continuing to synchronize pending data from the main node. This resulted in a delay between these nodes and the main node. The Etrog upgrade completely overhauled this part of the logic, splitting the synchronization tasks of layer-one and layer-two into their respective threads for management. This not only resolved the aforementioned delay issue but also accelerated the synchronization efficiency of layer-one data.

CDK Validium Upgrade for Lumoz

Regular zkEVM networks can complete the upgrade process using the open-source code from the official repository, but the official support for Validium's upgrade plan is not available. After research and development, the Lumoz team has completed the upgrade plan for Validium and successfully upgraded several test networks based on CDK Validium and the Merlin mainnet. This section will mainly introduce the specific upgrade path for Validium.

Code Implementation

Contract Aspect

The upgrade plan for Validium can be based on the changes in the official Rollup, implementing a PolygonValidiumExistentEtrog contract for use by the Validium consensus contract. This contract will be based on the original CDKValidium contract and, like zkEVMExistentEtrog, needs to implement an initializeUpgrade method to inherit historical data and generate an upgrade batch for node processing during the execution of upgrade transactions. Unlike zkEVM, the address of the new version of CDK Validium's DataCommittee will be maintained by the newly deployed PolygonValidiumExistentEtrog contract. Therefore, during the upgrade process, the original CDKDataCommittee's address needs to be reset to the dataAvailabilityProtocol variable.

Node Aspect

The official new version of Validium node code does not implement the handling logic for the event updateEtrogSequence, so it cannot be used directly. However, the processing flow of Rollup can still be used as a reference for implementation. Additionally, the code's dependency on contract ABI needs to be modified to adapt to the Validium contract interface, replacing the original Rollup contract interface.

Note that if choosing to skip Etrog and upgrade directly to a version above Eldberry, additional modifications are required due to the different batch data processing methods. During the contract upgrade process, the transitional forcedBatch generated by layer-one is still generated in the Etrog version's manner. Nodes cannot use the default Eldberry processor to handle this batch during processing and need to use the Etrog version's processor to avoid compatibility issues.

Upgrade Process

Before the upgrade, all new version contracts, including RollupManager, ValidiumExistentEtrog, GlobalExitRootV2, BridgeV2, etc., need to be deployed on both layer-one and layer-two networks. Specific instructions can be found in the official upgrade script, which involves replacing zkEVM-related contracts with Validium-related contracts. Once the relevant contracts are deployed, transaction data for upgrading the CDKValidium Proxy on layer-one can be pre-generated, and the new implementation of the initialize method can be called to perform the aforementioned data reassignment and transitional batch generation operations. Subsequently, the relevant permission addresses of the Timelock contract can schedule the upgrade transaction and wait for the Timelock contract's lock time. Similar operations need to be performed on layer-two to pre-generate the upgrade transaction data for the bridge contract and schedule the upgrade transaction in the layer-two Timelock contract.

Since the initialize logic of RollupManager needs to check whether the Proof is submitted to the latest version to ensure that the execution and proof of the batch before and after the upgrade are in the same version, some adjustments still need to be made to the trusted nodes after reaching the lock time. To minimize downtime during the upgrade, the StopSequencerOnBatchNum parameter in the sequencer service can be preset in advance to stop transaction packing after reaching that batch, allowing sufficient time for batch and corresponding proof submission. Additionally, since the new and old versions of Validium have made modifications to the pool_db migration file, the relevant records in the database 'supernets-0001.sql' need to be manually handled or processed in the node code to align with the database structure of the new version nodes.

Once the Proof is submitted to the latest version and the database is organized, the relevant permission addresses of the layer-one Timelock contract can call the execute method to execute the scheduled upgrade operation, update all configuration files, and simultaneously update all service versions of the trusted nodes. After the trusted nodes resume service and restart transaction packing, all permissionless nodes also need to update their configuration files and restart services using the new version of the code. The upgrade operation on layer-two can also be executed by calling the execute method after reaching the time set by the Timelock, completing the upgrade of the layer-two bridge contract.

As an important part of the Polygon CDK ecosystem, Lumoz has been paying close attention to every upgrade of Polygon CDK, conducting multiple research, development, and optimization efforts, and explaining the details behind the upgrade in a simple and understandable manner to the public. It is hoped that the early version of CDK Validium's upgrade path to the Etrog version can be comprehensively outlined and completed, effectively expanding the boundaries of the Polygon CDK and even the entire blockchain industry's development.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。