Polygon zkEVM
Badges
About
Polygon zkEVM is a EVM-compatible ZK Rollup built by Polygon Labs.
Badges
About
Polygon zkEVM is a EVM-compatible ZK Rollup built by Polygon Labs.
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 10d Timelock for upgrades, forced transactions are disabled. Even if they were to be enabled, user withdrawals can be censored up to 15d.
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
No 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.
Regular exit
All main contracts and the verifier are upgradable by the 2 / 3 ProxyAdminOwner through a timelock that owns SharedProxyAdmin. Addresses of trusted sequencer, aggregator and operational parameters (like fees) on the PolygonRollupManager can be instantly set by the ProxyAdminOwner. Escrow contracts are upgradable by the EscrowsAdmin 5 / 10 multisig.
PolygonZkEVMTimelock is a modified version of TimelockController that disables delay in case of a manually enabled or triggered emergency state in the PolygonRollupManager. It otherwise has a 10d delay.
The process to upgrade the PolygonRollupManager-implementation and / or the verifier has two steps: 1) A newRollupType-transaction is added by the ProxyAdminOwner to the timelock, which in turn can call the addNewRollupType() function in the PolygonRollupManager. In a non-emergency state, this allows potential reviews of the new rollup type while it sits in the timelock. 2) After the delay period, the rollup implementation can be upgraded to the new rollup type by the ProxyAdminOwner calling the updateRollup()-function in the PolygonRollupManager directly.
The critical roles in the PolygonRollupManager can be changed through the timelock, while the trusted Aggregator role can be granted by the ProxyAdminOwner directly.
The 6 / 8 SecurityCouncil multisig can manually enable the emergency state in the PolygonRollupManager.
The system uses the following set of permissioned addresses:
Its sole purpose and ability is to submit transaction batches. In case they are unavailable users cannot rely on the force batch mechanism because it is currently disabled.
The trusted proposer (called Aggregator) provides ZK proofs for all the supported systems. In case they are unavailable a mechanism for users to submit proofs on their own exists, but is behind a 5d delay for proving and a 5d delay for finalizing state proven in this way. These delays can only be lowered except during the emergency state.
A Gnosis Safe with 6 / 8 threshold. The Security Council is a multisig that can be used to trigger the emergency state which pauses bridge functionality, restricts advancing system state and removes the upgradeability delay.
Used in:
Those are the participants of the SecurityCouncil.
Sole account allowed to submit forced transactions. If this address is the zero address, anyone can submit forced transactions.
Used in:
A Gnosis Safe with 2 / 3 threshold. Admin of the PolygonRollupManager contract, can set core system parameters like timeouts and aggregator as well as deactivate emergency state. They can also upgrade the PolygonZkEVMEtrog contracts, but are restricted by a 10d delay unless rollup is put in the Emergency State.
Used in:
Those are the participants of the RollupManagerAdminMultisig.
A Gnosis Safe with 5 / 10 threshold. Escrows Admin can instantly upgrade wstETH, DAI and USDC bridges.
Those are the participants of the EscrowsAdmin.
Admin of the PolygonZkEVMEtrog contract, can set core system parameters like timeouts, sequencer, activate forced transactions and update the DA mode. In the case on Polygon zkEVM, this is also the RollupManagerAdminMultisig.
Used in:
The system consists of the following smart contracts on the host chain (Ethereum):
The main contract of the Polygon zkEVM. Contains sequenced transaction batch hashes and forced transaction logic.
Upgrade delay: None
An autogenerated contract that verifies ZK proofs in the PolygonRollupManager system.
It defines the rules of the system including core system parameters, permissioned actors as well as emergency procedures. The emergency state can be activated either by the Security Council, by proving a soundness error or by presenting a sequenced batch that has not been aggregated before a 7d timeout. This contract receives L2 state roots as well as ZK proofs.
Upgrade delay: None
Proxy used in:
The escrow contract for user funds. It is mirrored on the L2 side and can be used to transfer both ERC20 assets and arbitrary messages. To transfer funds a user initiated transaction on both sides is required. This contract can store any token.
Upgrade delay: None
Proxy used in:
Contract upgrades have to go through a 10d timelock unless the Emergency State is activated. It can also add rollup types that can be used to upgrade verifier contracts of existing systems. It is controlled by the ProxyAdminOwner.
Implementation used in:
Value Locked 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 10d delay on code upgrades.
