Polygon zkEVM
Badges
About
Polygon zkEVM is an EVM-compatible ZK Rollup built by Polygon Labs.
Badges
About
Polygon zkEVM is an EVM-compatible ZK Rollup built by Polygon Labs.
2024 May 03 — 2025 May 03
2024 May 04 — 2025 May 03
The section shows the operating costs that L2s pay to Ethereum.
2024 May 04 — 2025 May 03
Polygon zkEVM Etrog upgrade
2024 Feb 13th
Polygon zkEVM is upgraded to the Polygon Etrog version.
Funds can be stolen if
Funds can be lost if
Funds can be frozen if
Users can be censored if
MEV can be extracted if
There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.
STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.
All of the data needed for proof construction is published on Ethereum L1. Unlike most ZK rollups transactions are posted instead of state diffs.
Even though there is a 3d Timelock for upgrades, forced transactions are disabled.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
Polygon zkEVM is a All transaction data is recorded on chain
All executed transactions are submitted to an on chain smart contract. The execution of the rollup is based entirely on the submitted transactions, so anyone monitoring the contract can know the correct state of the rollup chain.
EthereumNo compression scheme is used.
The genesis state, whose corresponding root is accessible as Batch 0 root in the _legacyBatchNumToStateRoot variable of PolygonRollupManager, is available here.
Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
Polygon zkEVM proof system PIL-STARK can be found here.
Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found here.
Funds can be lost if the proof system is implemented incorrectly.
SNARK verification keys can be generated and checked against the Ethereum verifier contract using this guide. The system requires a trusted setup.
The pessimistic proofs that are used to prove correct accounting in the shared bridge are using the SP1 zkVM by Succinct.
The system has a centralized sequencer
Only a trusted sequencer is allowed to submit transaction batches. A mechanism for users to submit their own batches is currently disabled.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Funds can be frozen if the sequencer refuses to include an exit transaction (CRITICAL).
Users can't force any transaction
The mechanism for allowing users to submit their own transactions is currently disabled.
Users can be censored if the operator refuses to include their transactions.
Shared bridge and Pessimistic Proofs
Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them ‘Pessimistic Proofs’) are used by external chains (‘cdk-sovereign’). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum are able to share the bridge with the zkEVM Agglayer projects.
Funds can be lost if the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly.
The regular upgrade process for all system contracts (shared and L2-specific) starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific rollup- or validium contract requires first adding a new rollupType through the Timelock and the RollupManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it.
The PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the PolygonRollupManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.
Furthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rolupTypes and manage operational parameters and fees in the PolygonRollupManager directly. The local admin of a specific Layer 2 can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.
Ethereum
Roles:
Allowed to commit transactions from the current layer to the host chain.
Permissioned to post new state roots and global exit roots accompanied by ZK proofs.
Actors:
- A Multisig with 2/3 threshold.
- Can act on behalf of Timelock if there is no emergency state, in which case there would be no delay with 3d delay.
- Is allowed to interact with PolygonRollupManager - deploy new projects that use predefined rollup types (implementations) and connect them to the PolygonRollupManager.
- Is allowed to interact with PolygonRollupManager - manage all access control roles, add new rollup types (which are implementation contracts that can then be upgraded to by connected projects), update any connected projects to new rollup types and rollback batches, connect existing rollups to the PolygonRollupManager - acting via Timelock with 3d delay if there is no emergency state, in which case there would be no delay.
- Is allowed to interact with PolygonRollupManager - manage parameters like fees for all connected projects, set the trusted aggregator, stop the emergency state, update projects and obsolete rollup types.
- Is allowed to interact with Timelock - propose, cancel and execute transactions in the timelock, manage all access control roles and change the minimum delay if there is no emergency state, in which case there would be no delay with 3d delay - acting via Timelock with 3d delay if there is no emergency state, in which case there would be no delay.
- Is allowed to interact with Timelock - propose, cancel and execute transactions in the timelock, manage all access control roles and change the minimum delay if there is no emergency state, in which case there would be no delay with 3d delay.
- Can upgrade the implementation of PolygonSharedBridge, PolygonRollupManager, PolygonGlobalExitRootV2 - acting via SharedProxyAdmin, Timelock with 3d delay if there is no emergency state, in which case there would be no delay.
Used in:
- A Multisig with 6/8 threshold.
- Is allowed to interact with PolygonRollupManager - activate the emergency state in the PolygonRollupManager and in the shared bridge immediately, effectively pausing all projects connected to them and making system contracts instantly upgradable.
Participants (8):
0xFe45…2e4b0xaF46…261D0xBDc2…FEFf0x4c16…88910x3ab9…D6220x49c1…0E860x9F7d…86A00x2188…1C28Used in:
- A Multisig with 3/8 threshold.
- Is allowed to interact with PolygonRollupManager - deploy new projects that use predefined rollup types (implementations) and connect them to the PolygonRollupManager.
Participants (8):
0x3038…D3b50xa439…AE310xD947…fCFC0xCE27…AaAc0x0B84…Ca770x0185…22A60x7316…44960xC8aa…39e9Used in:
- A Multisig with 5/10 threshold.
- Can upgrade the implementation of daiBridge, usdcBridge, wstETHBridge.
Ethereum
The main system contract defining the polygon zkEVM Layer 2 logic. Entry point for sequencing batches.
Verifies ZK proofs for state roots of this Layer 2 via the PolygonRollupManager.
The central shared managing contract for Layer 2s on the Polygon AggLayer. This contract receives L2 state roots as well as ZK proofs. All connected Layer 2s can be globally paused by activating the ‘Emergency State’. This can be done by the PolygonSecurityCouncil or by anyone after 1 week of inactive verifiers.
Proxy used in:
A merkle tree storage contract aggregating state roots of each participating Layer 2, thus creating a single global merkle root representing the global state of the AggLayer, the ‘global exit root’. The global exit root is synchronized to all connected Layer 2s to help with their interoperability.
Proxy used in:
- A timelock with access control. In the case of an activated emergency state in the PolygonRollupManager, all transactions through this timelock are immediately executable. The current minimum delay is 3d.
- Can act on behalf of SharedProxyAdmin.
- Can act on behalf of Timelock if there is no emergency state, in which case there would be no delay with 3d delay.
- Can be used to interact with PolygonRollupManager - manage all access control roles, add new rollup types (which are implementation contracts that can then be upgraded to by connected projects), update any connected projects to new rollup types and rollback batches, connect existing rollups to the PolygonRollupManager.
- Can be used to interact with Timelock - propose, cancel and execute transactions in the timelock, manage all access control roles and change the minimum delay if there is no emergency state, in which case there would be no delay with 3d delay.
Proxy used in:
Can be used to upgrade implementation of PolygonSharedBridge, PolygonRollupManager, PolygonGlobalExitRootV2.
Proxy used in:
Value Secured is calculated based on these smart contracts and tokens:
Proxy used in:
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is a 3d delay on code upgrades unless upgrade is initiated by the PolygonSecurityCouncil in which case there is no delay.