# Astar zkEVM Markdown version of https://l2beat.com/layer2s/projects/astarzkevm ## Summary **Warning:** This project is archived and no longer maintained. - Gas token: ETH - Type: Other - Purpose: Universal - Host chain: Ethereum - Chain ID: 3776 ### Risks - Sequencer failure: No mechanism (sentiment: bad) - State validation: Validity proofs (ST, SN) (sentiment: good) - Data availability: External (DAC) (sentiment: bad) - Exit window: None (sentiment: bad) - Proposer failure: Cannot withdraw (sentiment: bad) ### About Astar zkEVM is a Validium that leverages Polygon's CDK and zero-knowledge cryptography to enable off-chain transactions while maintaining EVM equivalence. ## Milestones & Incidents - 2025-03-31: [Astar zkEVM sunsets](https://x.com/AstarNetwork/status/1906658995538194650). Astar Network has officially sunset. - 2024-03-06: [Astar zkEVM Launch](https://astar.network/blog/astars-zkevm-mainnet-is-live-86096). Astar Network launched Astar zkEVM, integrated with Polygon Agglayer. ## Risk summary ### Funds can be stolen if 1. 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. ### Funds can be lost if 2. the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly, 3. the proof system is implemented incorrectly. ### Funds can be frozen if 4. the sequencer refuses to include an exit transaction (CRITICAL). ### Users can be censored if 5. the operator refuses to include their transactions. ### MEV can be extracted if 6. the operator exploits their centralized position and frontruns user transactions. ## Risk analysis ### Sequencer failure No mechanism (sentiment: bad) 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. ### State validation Validity proofs (ST, SN) (sentiment: good) 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 External (DAC) (sentiment: bad) Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 3/5 that is tasked with protecting and supplying the data. ### Exit window None (sentiment: bad) There is no window for users to exit in case of an unwanted upgrade since the Security Council can remove the delay on upgrades. ### Proposer failure Cannot withdraw (sentiment: bad) Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen. ## Data availability Set of parties responsible for signing and attesting to the availability of data. ### Risk analysis #### Economic security None (sentiment: bad) There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known. #### Fraud detection None (sentiment: bad) There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer. #### Committee security 3/5 (sentiment: bad) The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability. #### Upgradeability No delay (sentiment: bad) There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed. #### Relayer failure No mechanism (sentiment: bad) The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity. ### Technology #### Architecture ![polygoncdk architecture](https://l2beat.com/images/da-layer-technology/polygoncdk/architecture.png#center) Polygon CDK validiums utilize a data availability solution that relies on a Data Availability Committee (DAC) to ensure data integrity and manage off-chain transaction data. This architecture comprises the following components: - **Operator**: A trusted entity that collects transactions, computes hash values for the transaction batch, and then requests and collects signatures from Committee members. - **Data Availability Committee (DAC)**: A group of nodes responsible for validating batch data against the hash values provided by the operator (sequencer), ensuring the data accurately represents the transactions. - **PolygonCommittee Contract**: Contract responsible for managing the data committee members list. Each DAC node independently validates the batch data, ensuring it matches the received hash values. Upon successful validation, DAC members store the hash values locally and generate signatures endorsing the batch's integrity. The sequencer collects these signatures and submits the transactions batch hash together with the aggregated signature on Ethereum. The PolygonCommittee contract is used during batch sequencing to verify that the signature posted by the sequencer was signed off by the DAC members stored in the contract. #### DA Bridge Architecture ![polygoncdk bridge architecture](https://l2beat.com/images/da-bridge-technology/polygoncdk/architectureL2.png#center) The DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge. The DA commitment consists of a data availability message provided as transaction input, made up of a byte array containing the signatures and all the addresses of the committee in ascending order. The sequencer distributes the data and collects signatures from Committee members offchain. Only the DA message is posted by the sequencer to the destination chain inbox (the DA bridge). A separate contract, the PolygonCommittee contract, is used to manage the committee members list and verify the signatures before accepting the DA commitment. **Risks** - Funds can be lost if a malicious committee signs a data availability attestation for an unavailable transaction batch. - Funds can be lost if the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades. **References** - [Polygon CDK Validium Documentation](https://docs.polygon.technology/cdk/architecture/cdk-validium/#data-availability-committee-dac) ## State derivation ### Node software Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation. ### Compression scheme No compression scheme is used. ### Genesis state The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json). ### Data format The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/tools/zkevm/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract. ## State validation 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. ### Prover Architecture Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark). ### ZK Circuits 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](https://github.com/0xPolygonHermez/zkevm-rom). **Risks** - Funds can be lost if the proof system is implemented incorrectly. ### Verification Keys Generation SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup. ### Pessimistic Proofs The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1). ### Validity proofs 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. **References** - [AgglayerManager.sol - source code, _verifyAndRewardBatches function](https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code) ## Upgrades & Governance The regular upgrade process for shared system contracts and L2-specific validium contracts 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 validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (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. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow. The PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager 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 rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. 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. ## Updates Shown as an interactive chart or widget on [the HTML page](https://l2beat.com/layer2s/projects/astarzkevm#updates). ## Operator ### The system has a centralized sequencer Only a trusted sequencer is allowed to submit transaction batches. **Risks** - 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). **References** - [Validium.sol - source code, onlyTrustedSequencer modifier](https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code) ### Users can't force any transaction There is no general mechanism to force the sequencer to include the transaction. **Risks** - Users can be censored if the operator refuses to include their transactions. **References** - [Validium.sol - source code, forceBatchAddress address](https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code) ## Withdrawals ### Regular messaging The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks. **References** - [AgglayerBridge.sol - source code, claimAsset function](https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code) ## Other considerations ### 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-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions. **Risks** - Funds can be lost if the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly. **References** - [Pessimistic Proof - Polygon Knowledge Layer](https://docs.polygon.technology/cdk/concepts/pessimistic-proofs) - [Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function](https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300) ## Permissions ### Ethereum #### Actors ##### PolygonAdminMultisig Addresses: [0x242daE44F5d8fb54B198D03a94dA45B5a4413e21](https://etherscan.io/address/0x242daE44F5d8fb54B198D03a94dA45B5a4413e21) A Multisig with 5/9 threshold. * Can upgrade **with 3d delay** * AgglayerGateway [via: Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin] * AgglayerBridge [via: Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin] * AgglayerManager [via: Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin] * AgglayerGER [via: Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin] * Can interact with AgglayerGateway * add new routes from proof selector to verifier / pessimisticVkey for pessimistic proofs **with 3d delay** [via: Timelock with 3d delay (no delay if in emergency state)] * add or update default aggchain verification keys (aggchainVkey) for any given selectors * change the aggchainSigners and threshold (a multisig used for permissioned state transitions) * freeze routes from proof selector to verifier / pessimisticVkey for pessimistic proofs * Can interact with AgglayerBridge * upgrade the implementation of wrapped tokens deployed by the bridge **with 3d delay** [via: Timelock with 3d delay (no delay if in emergency state)] * Can interact with AgglayerManager * deploy new projects that use predefined rollup types (implementations) and connect them or other Agglayer chains to the 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, migrate to pessimistic proofs and rollback batches, connect existing rollups to the PolygonRollupManager **with 3d delay** [via: Timelock with 3d delay (no delay if in emergency state)] * manage parameters like fees for all connected projects, set the trusted aggregator, stop the emergency state, update projects and obsolete rollup types * Can interact with Timelock * propose, cancel and execute transactions in the timelock, manage all access control roles and change the minimum delay **with 6d delay or with 3d delay** [via: Timelock with 3d delay (no delay if in emergency state) with 3d delay (no delay if in emergency state) - or - acting directly with 3d delay (no delay if in emergency state)] ##### AstarMultisig Addresses: [0xf98ee8c46baEa2B11e4f0450AD9D01861265F76E](https://etherscan.io/address/0xf98ee8c46baEa2B11e4f0450AD9D01861265F76E) A Multisig with 3/6 threshold. * Can upgrade **with no delay** * PolygonDataCommittee [via: ProxyAdmin] * Can interact with Validium * set core system parameters like the trusted sequencer and manage forced transactions/batches * sole address that can force batches * Can interact with PolygonDataCommittee * manage the members of the data availability committee and the threshold for valid commitments ##### AgglayerManager Addresses: [0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2](https://etherscan.io/address/0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2) The central shared managing contract for Polygon Agglayer chains. This contract coordinates chain deployments and proof validation. 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. * Can upgrade **with no delay** * Validium ##### PolygonSecurityCouncil Addresses: [0x37c58Dfa7BF0A165C5AAEdDf3e2EdB475ac6Dcb6](https://etherscan.io/address/0x37c58Dfa7BF0A165C5AAEdDf3e2EdB475ac6Dcb6) A Multisig with 6/8 threshold. * Can interact with AgglayerManager * 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 ##### PolygonCreateRollupMultisig Addresses: [0xC74eFc7fdb3BeC9c6930E91FFDF761b160dF79dB](https://etherscan.io/address/0xC74eFc7fdb3BeC9c6930E91FFDF761b160dF79dB) A Multisig with 3/5 threshold. * Can interact with AgglayerManager * deploy new projects that use predefined rollup types (implementations) and connect them or other Agglayer chains to the PolygonRollupManager ##### GnosisSafe Addresses: [0x6c4876Ecb5de33f76700f44d547C593065806dAC](https://etherscan.io/address/0x6c4876Ecb5de33f76700f44d547C593065806dAC) A Multisig with 1/3 threshold. Member of AstarMultisig. ##### EOA 1 Addresses: [0xA09F1c88C0194Da6b0a1c564CDBEcbF3AAd649E4](https://etherscan.io/address/0xA09F1c88C0194Da6b0a1c564CDBEcbF3AAd649E4) * Can interact with Validium * Allowed to commit transactions from the current layer to the host chain ##### EOA 2 Addresses: [0x20A53dCb196cD2bcc14Ece01F358f1C849aA51dE](https://etherscan.io/address/0x20A53dCb196cD2bcc14Ece01F358f1C849aA51dE) * Can interact with AgglayerManager * Permissioned to post new state roots and global exit roots accompanied by ZK proofs ## Smart contracts ### Ethereum #### Verifier Addresses: [0x0775e11309d75aA6b0967917fB0213C5673eDf81](https://etherscan.io/address/0x0775e11309d75aA6b0967917fB0213C5673eDf81#code) Verifies ZK proofs for state roots of this Layer 2 via the PolygonRollupManager. #### Validium Addresses: [0x1E163594e13030244DCAf4cDfC2cd0ba3206DA80](https://etherscan.io/address/0x1E163594e13030244DCAf4cDfC2cd0ba3206DA80#code), [0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C](https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code) (Implementation (Upgradable)), [0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2](https://etherscan.io/address/0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2#code) (Admin) The main system contract defining the Astar zkEVM Layer 2 logic. Entry point for sequencing batches. * Roles: * **admin**: AgglayerManager, AstarMultisig * **forceBatchAddress**: AstarMultisig * **trustedSequencer**: EOA 1 Can be upgraded by: AgglayerManager with no delay #### PolygonDataCommittee Addresses: [0x9CCD205052c732Ac1Df2cf7bf8aACC0E371eE0B0](https://etherscan.io/address/0x9CCD205052c732Ac1Df2cf7bf8aACC0E371eE0B0#code), [0xF4e87685e323818E0aE35dCdFc3B65106002E456](https://etherscan.io/address/0xF4e87685e323818E0aE35dCdFc3B65106002E456#code) (Implementation (Upgradable)), [0x1963D7b78e75A5eDfF9e5376E7A07A935Fb3d50d](https://etherscan.io/address/0x1963D7b78e75A5eDfF9e5376E7A07A935Fb3d50d#code) (Admin) Manages the members of the data availability committee (DAC) and the threshold for accepting commitments from them (Currently 5/3). * Roles: * **admin**: ProxyAdmin; ultimately AstarMultisig * **owner**: AstarMultisig Can be upgraded by: AstarMultisig with no delay #### AgglayerGateway Addresses: [0x046Bb8bb98Db4ceCbB2929542686B74b516274b3](https://etherscan.io/address/0x046Bb8bb98Db4ceCbB2929542686B74b516274b3#code), [0xD062B7f9fbB89bdA59262E77015C34a27Dc9aB49](https://etherscan.io/address/0xD062B7f9fbB89bdA59262E77015C34a27Dc9aB49#code) (Implementation (Upgradable)), [0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A](https://etherscan.io/address/0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A#code) (Admin) A verifier gateway for pessimistic proofs. Manages a map of chains and their verifier keys and is used to route proofs based on the first 4 bytes of proofBytes data in a proof submission. The SP1 verifier is used for all proofs. * Roles: * **addPpRoute**: Timelock; ultimately PolygonAdminMultisig * **admin**: SharedProxyAdmin; ultimately PolygonAdminMultisig * **aggchainDefaultVKey**: PolygonAdminMultisig * **alMultisig**: PolygonAdminMultisig * **freezePpRoute**: PolygonAdminMultisig Can be upgraded by: PolygonAdminMultisig with 3d delay #### AgglayerBridge Addresses: [0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe](https://etherscan.io/address/0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe#code), [0x66E0120e3c965552a89AcC37b03f762624baC5Ad](https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code) (Implementation (Upgradable)), [0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A](https://etherscan.io/address/0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A#code) (Admin) The shared bridge contract, escrowing user funds sent to Agglayer chains. It is usually mirrored on each chain and can be used to transfer both ERC20 assets and arbitrary messages. * Roles: * **admin**: SharedProxyAdmin; ultimately PolygonAdminMultisig * **proxiedTokensManager**: Timelock; ultimately PolygonAdminMultisig Can be upgraded by: PolygonAdminMultisig with 3d delay #### AgglayerGER Addresses: [0x580bda1e7A0CFAe92Fa7F6c20A3794F169CE3CFb](https://etherscan.io/address/0x580bda1e7A0CFAe92Fa7F6c20A3794F169CE3CFb#code), [0x7F1655d9d570167B2a3FfD1Ef809D3Fdd74427C5](https://etherscan.io/address/0x7F1655d9d570167B2a3FfD1Ef809D3Fdd74427C5#code) (Implementation (Upgradable)), [0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A](https://etherscan.io/address/0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A#code) (Admin) 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. * Roles: * **admin**: SharedProxyAdmin; ultimately PolygonAdminMultisig Can be upgraded by: PolygonAdminMultisig with 3d delay #### Timelock Addresses: [0xEf1462451C30Ea7aD8555386226059Fe837CA4EF](https://etherscan.io/address/0xEf1462451C30Ea7aD8555386226059Fe837CA4EF#code) A timelock with access control. In the case of an activated emergency state in the AgglayerManager, all transactions through this timelock are immediately executable. The current minimum delay is 3d. * Roles: * **timelockAdmin**: PolygonAdminMultisig (no delay if in emergency state), Timelock (no delay if in emergency state); ultimately PolygonAdminMultisig (no delay if in emergency state) #### ProxyAdmin Addresses: [0x1963D7b78e75A5eDfF9e5376E7A07A935Fb3d50d](https://etherscan.io/address/0x1963D7b78e75A5eDfF9e5376E7A07A935Fb3d50d#code) * Roles: * **owner**: AstarMultisig #### SP1Verifier Addresses: [0x0459d576A6223fEeA177Fb3DF53C9c77BF84C459](https://etherscan.io/address/0x0459d576A6223fEeA177Fb3DF53C9c77BF84C459#code) Verifier contract for SP1 proofs (v5.0.0). #### SharedProxyAdmin Addresses: [0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A](https://etherscan.io/address/0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A#code) * Roles: * **owner**: Timelock #### BridgeLib Addresses: [0x3622Fcf450ca40a340b7492Ae5F60E7c7Ea68aB3](https://etherscan.io/address/0x3622Fcf450ca40a340b7492Ae5F60E7c7Ea68aB3#code) Extension contract of the AgglayerBridge for asset metadata.. #### SP1Verifier Addresses: [0xc3c6dDDAc8829b233Dc6536Ec024775a57b0AF2A](https://etherscan.io/address/0xc3c6dDDAc8829b233Dc6536Ec024775a57b0AF2A#code) Verifier contract for SP1 proofs (v6.1.0). 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.