Search
Search for projects by name or address
Astar zkEVM
Badges
About
Astar zkEVM is a Validium that leverages Polygon's CDK and zero-knowledge cryptography to enable off-chain transactions while maintaining EVM equivalence.
Tokens breakdown
Badges
About
Astar zkEVM is a Validium that leverages Polygon's CDK and zero-knowledge cryptography to enable off-chain transactions while maintaining EVM equivalence.
Why is the project listed in others?
Consequence: projects without a sufficiently decentralized data availability committee rely on few entities to safely attest data availability on Ethereum. A small set of entities can collude with the proposer to finalize an unavailable state, which can cause loss of funds.
Learn more about the recategorisation here.
Astar zkEVM sunsets
2025 Mar 31st
Astar NetworkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. has officially sunset.
Astar zkEVM Launch
2024 Mar 6th
Astar NetworkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. launched Astar zkEVM, integrated with Polygon Agglayer.
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 sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. 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 setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits..
Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC)A set of members whose task is attesting and ensuring that the data is available for the public. An onchain DAC verifier checks that a threshold of signatures from the DAC members is reached before considering a data commitment as available and therefore valid to be used in the system. with a threshold of 3/5 that is tasked with protecting and supplying the data.
Even though there is a 3d Timelock for non-emergency upgrades, there are no forced transactions and thus no way to exit during operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. censorship or downtime.
There is no window for users to exit in case of an unwanted upgrade since the Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. can remove the delay on upgrades.
Only the whitelisted proposers can publish state rootsA cryptographic hash succinctly representing a state using a Merkle tree. on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., so in the event of failure the withdrawals are frozen.
Set of parties responsible for signing and attesting to the availability of data.
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.
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 layerAn infrastructure that is used to make publish data so that it's available to the public. They take the form of Data Availability Committees (DACs) or blockchains. Not to confuse with the layer responsible with ordering, since ordering and DA can be separated..
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 bridgeSystem that verifies that data has been made available. It takes the form of a smart contract verifying a consensus or, if the data is verified directly by either downloading the full data or sampling, of an enshrined bridge. and it is reliant on the assumption of an honest sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs., creating significant risks to data integrity and availability.
There is no delay in the upgradeabilityThe ability for rollup smart contracts and parameters used in a rollup to be updated by holders of an admin key. Upgradeability represents a vector of risk for users, and should be decentralized and combined with time delays for greater security guarantees. of the bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridgeSystem that verifies that data has been made available. It takes the form of a smart contract verifying a consensus or, if the data is verified directly by either downloading the full data or sampling, of an enshrined bridge. does not have a Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. 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.
Architecture
Polygon CDK validiums utilize a data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. solution that relies on a Data Availability Committee (DAC)A set of members whose task is attesting and ensuring that the data is available for the public. An onchain DAC verifier checks that a threshold of signatures from the DAC members is reached before considering a data commitment as available and therefore valid to be used in the system. to ensure data integrity and manage off-chain transaction data. This architecture comprises the following components:
- OperatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.: A trusted entity that collects transactions, computes hashA fixed-length fingerprint of variable-size input, produced by a hash function. 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 (sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs.), ensuring the data accurately represents the transactions.
- PolygonCommittee Contract: Contract responsible for managing the data committee members list.
Each DAC nodeA software client that participates in the network. 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 BridgeSystem that verifies that data has been made available. It takes the form of a smart contract verifying a consensus or, if the data is verified directly by either downloading the full data or sampling, of an enshrined bridge. Architecture
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.
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.
No compression scheme is used.
The genesis state, whose corresponding root is accessible as Batch 0 root in the _legacyBatchNumToStateRoot variable of AgglayerManager, is available here.
The trusted sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. batches transactions according to the specifications documented here. Only /signed hashes of batches are posted to the ValidiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption. contract.
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 systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. PIL-STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. 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.
SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. verification keys can be generated and checked against the Ethereum verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract using this guide. The system requires a trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits..
The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. are using the SP1 zkVM by Succinct.
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.
The regular upgrade process for shared system contracts and L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.-specific validiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption. 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 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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 bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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 (proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. and proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract.) 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 sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs., manage forced batches and set the data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. 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.
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
2025 July 14, 12:44 UTC6changesDiscovery rerun on the same block number with only config-related changes.
Discovery rerun on the same block number with only config-related changes.
New and verified contracts
| + | Status: CREATED |
| contract Verifier (0x0775e11309d75aA6b0967917fB0213C5673eDf81) | |
| +++ description: Verifies ZK proofs for state roots of this Layer 2 via the PolygonRollupManager. | |
| + | Status: CREATED |
| contract ProxyAdmin (0x1963D7b78e75A5eDfF9e5376E7A07A935Fb3d50d) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Validium (0x1E163594e13030244DCAf4cDfC2cd0ba3206DA80) | |
| +++ description: The main system contract defining the Astar zkEVM Layer 2 logic. Entry point for sequencing batches. | |
| + | Status: CREATED |
| contract GnosisSafe (0x6c4876Ecb5de33f76700f44d547C593065806dAC) | |
| +++ description: None | |
| + | Status: CREATED |
| contract PolygonDataCommittee (0x9CCD205052c732Ac1Df2cf7bf8aACC0E371eE0B0) | |
| +++ description: Manages the members of the data availability committee (DAC) and the threshold for accepting commitments from them (Currently 5/3). | |
| + | Status: CREATED |
| contract AstarMultisig (0xf98ee8c46baEa2B11e4f0450AD9D01861265F76E) | |
| +++ description: None | |
2024 June 28, 07:20 UTC13changesChange sequencer address and URL. DAC committee members changed. Chain was offline for this update/maintenance for 40 minutes.
Change sequencer address and URL. DAC committee members changed. Chain was offline for this update/maintenance for 40 minutes.
| contract AstarValidiumEtrog (0x1E163594e13030244DCAf4cDfC2cd0ba3206DA80) { | |
| +++ description: None | |
| values.trustedSequencer: | |
| - | "0xD49CD5f9776A54fAe89B68205F6Af69586F98203" |
| + | "0xA09F1c88C0194Da6b0a1c564CDBEcbF3AAd649E4" |
| values.trustedSequencerURL: | |
| - | "https://rpc.astar-zkevm.gelato.digital" |
| + | "https://rpc-zkevm.astar.network" |
| } | |
| contract AstarValidiumDAC (0x9CCD205052c732Ac1Df2cf7bf8aACC0E371eE0B0) { | |
| +++ description: None | |
| values.committeeHash: | |
| - | "0xf3b713b9d34dd6c8f99950e7f622937def5d1044471824b807c8b9dbedf75d2f" |
| + | "0x9a0c18a0211f34e9126b78961894fb03edbdcb7e314a5affed3f8365315e3aff" |
| values.members.4.1: | |
| - | "0xF54b295a221B5d3510D03d9B16E23BA151da012A" |
| + | "0xC4ad70e848f36925FcbDfb252f5e258D06647320" |
| values.members.4.0: | |
| - | "http://cdk-validium-dac-1-prod-6d3f0-port1.cdk-validium-deployment-6d3f0.svc.cluster.local:8444" |
| + | "https://dac0-zkevm.astar.network" |
| values.members.3.1: | |
| - | "0xCFb77B6abb27e04cE0DB347cCCd5544f51A98CBc" |
| + | "0xB4d094b4216F1BEb8bAeD995092A05182fD4bEf0" |
| values.members.3.0: | |
| - | "http://cdk-validium-dac-2-prod-6d3f0-port1.cdk-validium-deployment-6d3f0.svc.cluster.local:8444" |
| + | "https://dac4-zkevm.astar.network" |
| values.members.2.1: | |
| - | "0x8FB3cb4777EE1c2C35C48aC69a650026d18aFF08" |
| + | "0x68B62E4C9E69cd637c61f19Fb64976D466De1d58" |
| values.members.2.0: | |
| - | "http://cdk-validium-dac-3-prod-6d3f0-port1.cdk-validium-deployment-6d3f0.svc.cluster.local:8444" |
| + | "https://dac2-zkevm.astar.network" |
| values.members.1.1: | |
| - | "0x37f0B74e0Fc72aDAAb1Fd39Ec6d779F596866aB8" |
| + | "0x361Ed4c21Ad3f9B28eeE1e1894854cE7E39b2dB1" |
| values.members.1.0: | |
| - | "http://cdk-validium-dac-4-prod-6d3f0-port1.cdk-validium-deployment-6d3f0.svc.cluster.local:8444" |
| + | "https://dac3-zkevm.astar.network" |
| values.members.0.1: | |
| - | "0x08EbBdFf8cB6d1336515A89641e899bc8ce91F2C" |
| + | "0x19DdD9d655B993D6B2e2437bfBA0378B777d7470" |
| values.members.0.0: | |
| - | "http://cdk-validium-dac-5-prod-6d3f0-port1.cdk-validium-deployment-6d3f0.svc.cluster.local:8444" |
| + | "https://dac1-zkevm.astar.network" |
| } | |
2024 April 10, 10:20 UTCHigh severity9changesMigration of rollup contract Etrog and added related verifier. Rollup contract changes: - added timestamp range to check on sequenced batched, batches with timestamp outside range will be invalidated by circuit. - added possibility to migrate data availability protocol.
Migration of rollup contract Etrog and added related verifier. Rollup contract changes:
- added timestamp range to check on sequenced batched, batches with timestamp outside range will be invalidated by circuit.
- added possibility to migrate data availability protocol.
| - | Status: DELETED |
| contract FflonkVerifier (0x1C3A3da552b8662CD69538356b1E7c2E9CC1EBD8) | |
| +++ description: None | |
| contract AstarValidiumEtrog (0x1E163594e13030244DCAf4cDfC2cd0ba3206DA80) { | |
| +++ description: None | |
| upgradeability.implementation: | |
| - | "0x9cf80f7eB1C76ec5AE7A88b417e373449b73ac30" |
| + | "0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C" |
| implementations.0: | |
| - | "0x9cf80f7eB1C76ec5AE7A88b417e373449b73ac30" |
| + | "0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C" |
| values.TIMESTAMP_RANGE: | |
| + | 36 |
| derivedName: | |
| - | "PolygonValidiumEtrog" |
| + | "PolygonValidiumStorageMigration" |
| } | |
| contract PolygonRollupManager (0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2) { | |
| +++ description: None | |
| +++ description: Contains important info such as the etrog and verifier address, the rollup type and chain id | |
| +++ type: CODE_CHANGE | |
| +++ severity: HIGH | |
| values.rollupData.4: | |
| - | 1 |
| + | 4 |
| +++ description: Contains important info such as the etrog and verifier address, the rollup type and chain id | |
| +++ type: CODE_CHANGE | |
| +++ severity: HIGH | |
| values.rollupData.3: | |
| - | 7 |
| + | 9 |
| +++ description: Contains important info such as the etrog and verifier address, the rollup type and chain id | |
| +++ type: CODE_CHANGE | |
| +++ severity: HIGH | |
| values.rollupData.2: | |
| - | "0x1C3A3da552b8662CD69538356b1E7c2E9CC1EBD8" |
| + | "0x0775e11309d75aA6b0967917fB0213C5673eDf81" |
| } | |
| + | Status: CREATED |
| contract AstarVerifier (0x0775e11309d75aA6b0967917fB0213C5673eDf81) | |
| +++ description: None | |
2024 April 02, 11:19 UTC15changesProvide description of changes. This section will be preserved.
Provide description of changes. This section will be preserved.
| contract POL (0x455e53CBB86018Ac2B8092FdCd39d8444aFFC3F6) { | |
| +++ description: None | |
| values.lastMint: | |
| - | 1710310247 |
| + | 1711986143 |
| values.totalSupply: | |
| - | "10113921492245423640000000000" |
| + | "10129821158641559310000000000" |
| } | |
| contract PolygonRollupManager (0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2) { | |
| +++ description: None | |
| values.rollupCount: | |
| - | 2 |
| + | 3 |
| values.rollupsData.2: | |
| + | ["0x2B0ee28D4D51bC9aDde5E58E295873F61F4a0507","0x0775e11309d75aA6b0967917fB0213C5673eDf81"] |
| values.rollupTypeCount: | |
| - | 3 |
| + | 4 |
| values.rollupTypes.3: | |
| + | ["0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C","0x0775e11309d75aA6b0967917fB0213C5673eDf81"] |
| } | |
| contract PolygonZkEVMGlobalExitRootV2 (0x580bda1e7A0CFAe92Fa7F6c20A3794F169CE3CFb) { | |
| +++ description: None | |
| values.depositCount: | |
| - | 5902 |
| + | 6983 |
| values.getLastGlobalExitRoot: | |
| - | "0x9ca5a604c186e1ea5b4b1c98cef0172948cfdd3922e6d696432af039f2029ee4" |
| + | "0xc095e5994a0b9fd52ea40b40a773ef3501d71b6714aaa9f317da893d00a4a232" |
| values.getRoot: | |
| - | "0x8cc1015a052135594ecf5f93b9714a5fa9693df8723d30d54681edc0452ada70" |
| + | "0xfa45b3fc78774ebaab9c348497cd3179c1b985b3d5acd9f7943ef5249df28026" |
| values.lastMainnetExitRoot: | |
| - | "0xf497f247b8a83a6ef28ab1344cb4ceda601beadc8b8e750b9e94c60c692c90a6" |
| + | "0xb660abe75b32c4549f002831954229d9bca2088cbba3e11ed323d658d3405195" |
| values.lastRollupExitRoot: | |
| - | "0x3f422c6785e945568024d0ebffa974e7332ecb1abb878478ff7bb8d453408bf2" |
| + | "0xbe9fd8ca76197d4a5e1a89029ce2a23b17702c9c061ac9e1d5653d6de3cdd87e" |
| } | |
| + | Status: CREATED |
| contract PolygonDataCommittee (0x05652Ec92366F3C2255991a265c499E01Ba58e6a) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ProxyAdmin (0x1e37EA18e9515db29b3E94A00eD31484A3130204) | |
| +++ description: None | |
| + | Status: CREATED |
| contract PolygonValidiumStorageMigration (0x2B0ee28D4D51bC9aDde5E58E295873F61F4a0507) | |
| +++ description: None | |
| + | Status: CREATED |
| contract OKBImplementation (0x75231F58b43240C9718Dd58B4967c5114342a86c) | |
| +++ description: None | |
2024 March 25, 09:12 UTC4changesA bug on Polygon zkEVM was fixed, unrelated to Astar zkEVM.
A bug on Polygon zkEVM was fixed, unrelated to Astar zkEVM.
| contract RollupManagerAdminMultisig (0x242daE44F5d8fb54B198D03a94dA45B5a4413e21) { | |
| +++ description: None | |
| values.nonce: | |
| - | 19 |
| + | 27 |
| } | |
| contract PolygonRollupManager (0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2) { | |
| +++ description: None | |
| values.accessControl.UPDATE_ROLLUP.members.1: | |
| + | "0x242daE44F5d8fb54B198D03a94dA45B5a4413e21" |
| values.lastDeactivatedEmergencyStateTimestamp: | |
| - | 0 |
| + | 1711323791 |
| values.rollupTypeCount: | |
| - | 2 |
| + | 3 |
| } | |
The system has a centralized sequencer
Only a trusted sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. is allowed to submit transaction batches.
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
There is no general mechanism to force the sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. to include the transaction.
Users can be censored if the operator refuses to include their transactions.
Regular messaging
The user initiates L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. messages by submitting a regular transaction on this chain. When the blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks.
Shared bridge and Pessimistic Proofs
Polygon Agglayer uses a shared bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrow for Rollups, Validiums and external chains that opt in to participate in interoperabilityRefers to the capability of different blockchain networks to communicate and share data. It enables the transfer of assets and information between blockchains, facilitating functionality and collaboration between blockchain ecosystems.. 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 zkVMA special type of zk proving system that proves the correctness of state transitions of a virtual machine. Computation is represented by a program in a specific instruction language, it can have private and public inputs and public outputs. Most of zkVMs are STARKs. by Succinct, even projects without a full proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.
Funds can be lost if the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly.
Ethereum
Actors:
A Multisig with 5/9 threshold.
- Can upgrade with 3d delay
- AgglayerGateway Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin
- AgglayerBridge Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin
- AgglayerManager Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin
- AgglayerGER Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin
- Can interact with AgglayerGateway
- add new routes from proof selector to verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. / pessimisticVkey for pessimistic proofs with 3d delay 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 bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. with 3d delay Timelock with 3d delay (no delay if in emergency state)
- Can interact with AgglayerManager
- deploy new projects that use predefined rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 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 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)
Participants (9):
0xEB5E…EA720xAb35…235E0xf02B…D4B20xdFEd…56Da0xffbf…32380xeD44…dB370x516e…46B70x2161…d4170x8B9F…782BA Multisig with 3/6 threshold.
- Can upgrade with no delay
- PolygonDataCommittee ProxyAdmin
- Can interact with ValidiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption.
- set core system parameters like the trusted sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. and manage forced transactions/batches
- sole address that can force batches
- Can interact with PolygonDataCommittee
- manage the members of the data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. committee and the threshold for valid commitments
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
- ValidiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption.
A Multisig with 6/8 threshold.
- Can interact with AgglayerManager
- activate the emergency state in the PolygonRollupManager and in the shared bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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…1C28A Multisig with 3/5 threshold.
- Can interact with AgglayerManager
- deploy new projects that use predefined rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. types (implementations) and connect them or other Agglayer chains to the PolygonRollupManager
A Multisig with 1/3 threshold. Member of AstarMultisig.
- Can interact with ValidiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption.
- Allowed to commit transactions from the current layer to the host chain
- Can interact with AgglayerManager
- Permissioned to post new state rootsA cryptographic hash succinctly representing a state using a Merkle tree. and global exit roots accompanied by ZK proofs
Ethereum
Verifies ZK proofs for state rootsA cryptographic hash succinctly representing a state using a Merkle tree. of this Layer 2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. via the PolygonRollupManager.
The main system contract defining the Astar zkEVM Layer 2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. logic. Entry point for sequencing batches.
- Roles:
- admin: AgglayerManager, AstarMultisig
- forceBatchAddress: AstarMultisig
- trustedSequencer: EOA 1
Manages the members of the data availability committee (DAC)A set of members whose task is attesting and ensuring that the data is available for the public. An onchain DAC verifier checks that a threshold of signatures from the DAC members is reached before considering a data commitment as available and therefore valid to be used in the system. and the threshold for accepting commitments from them (Currently 5/3).
- Roles:
- admin: ProxyAdmin; ultimately AstarMultisig
- owner: AstarMultisig
A verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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
The shared bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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
All supported tokens in this escrow are included in the value secured calculation.
A merkle treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs. storage contract aggregating state rootsA cryptographic hash succinctly representing a state using a Merkle tree. of each participating Layer 2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups., 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 interoperabilityRefers to the capability of different blockchain networks to communicate and share data. It enables the transfer of assets and information between blockchains, facilitating functionality and collaboration between blockchain ecosystems..
- Roles:
- admin: SharedProxyAdmin; ultimately PolygonAdminMultisig
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)
- Roles:
- owner: AstarMultisig
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v5.0.0).
Extension contract of the AgglayerBridge for asset metadata…
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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.