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.
The section shows the operating costs that L2s pay to Ethereum.
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
Sequencer failure
No mechanismThere 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.
State validation
ZK proofs (ST, SN)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.
Data availability
OnchainAll of the data needed for proof construction is published on Ethereum L1. Unlike most ZK rollups transactions are posted instead of state diffs.
Exit window
NoneEven though there is a 3d Timelock for upgrades, forced transactions are disabled.
Proposer failure
Cannot withdrawOnly the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
Polygon zkEVM is a Validity proofs ensure state correctness
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.
Zero knowledge STARK and SNARK cryptography is used
Despite their production use zkSTARKs and zkSNARKs proof systems are still relatively new, complex and they rely on the proper implementation of the polynomial constraints used to check validity of the Execution Trace. In addition zkSNARKs require a trusted setup to operate.
Funds can be lost if the proof system is implemented incorrectly.
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 yet.
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 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 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.
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 5 / 10 threshold.
- Can upgrade the implementation of daiBridge, usdcBridge, wstETHBridge.
- A Multisig with 2 / 3 threshold.
- Can act on behalf of PolygonZkEVMTimelock if there is no emergency state, in which case there is 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 PolygonZkEVMTimelock with 3d delay if there is no emergency state, in which case there is 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 PolygonZkEVMTimelock - propose, cancel and execute transactions in the timelock, manage all access control roles - acting via PolygonZkEVMTimelock with 3d delay if there is no emergency state, in which case there is no delay.
- Is allowed to interact with PolygonZkEVMTimelock - propose, cancel and execute transactions in the timelock, manage all access control roles.
- Can upgrade the implementation of PolygonZkEVMBridgeV2, PolygonRollupManager, PolygonZkEVMGlobalExitRootV2 - acting via SharedProxyAdmin, PolygonZkEVMTimelock with 3d delay if there is no emergency state, in which case there is 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:
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.
Can be used to upgrade implementation of PolygonZkEVMBridgeV2, PolygonRollupManager, PolygonZkEVMGlobalExitRootV2.
Implementation used in:
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 PolygonZkEVMTimelock if there is no emergency state, in which case there is 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 PolygonZkEVMTimelock - propose, cancel and execute transactions in the timelock, manage all access control roles.
Implementation 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.
