Astar zkEVM Launch
2024 Mar 6th
Astar Network launched Astar zkEVM, integrated with Polygon AggLayer.
zkSNARKS are zero knowledge proofs that ensure state correctness, but require trusted setup.
Proof construction relies fully on data that is NOT published on chain. There exists a Data Availability Committee (DAC) with a threshold of 3/5 that is tasked with protecting and supplying the data.
Even 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.
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.
If the Proposer fails, users can leverage the source available prover to submit proofs to the L1 bridge. There is 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.
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.
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.
The transaction data is not recorded on the Ethereum main chain. Transaction data is stored off-chain and only the hashes are posted on-chain by the Sequencer, after being signed by the DAC members.
Funds can be lost if the external data becomes unavailable (CRITICAL).
Node software can be found here.
No compression scheme yet.
The genesis state, whose corresponding root is accessible as Batch 0 root in the getRollupBatchNumToStateRoot
method of PolygonRollupManager, is available here.
The trusted sequencer request signatures from DAC members off-chain, and posts hashed batches with signatures to the AstarValidiumEtrog contract.
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).
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 user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is proven the funds become available for withdrawal on L1. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.
Admin of the AstarValidiumEtrog rollup, can set core system parameters like timeouts, sequencer, activate forced transactions and update the DA mode.
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.
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. This is a Gnosis Safe with 6 / 8 threshold.
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.
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 AstarValidiumEtrog contracts, but are restricted by a 10d delay unless rollup is put in the Emergency State. This is a Gnosis Safe with 2 / 3 threshold.
Those are the participants of the RollupManagerAdminMultisig.
Validium committee contract that allows the admin to setup the members of the committee and stores the required amount of signatures threshold.
Can be upgraded by: ProxyAdminOwner
Upgrade delay: None
The main contract of the Astar zkEVM. Contains sequenced transaction batch hashes and forced transaction logic.
Can be upgraded by: RollupManagerAdminMultisig
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.
Can be upgraded by: RollupManagerAdminMultisig
Upgrade delay: None
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.
Can be upgraded by: RollupManagerAdminMultisig
Upgrade delay: None
Synchronizes deposit and withdraw merkle trees across L1 and the L2s. The global root from this contract is injected into the L2 contracts.
Can be upgraded by: RollupManagerAdminMultisig
Upgrade delay: None
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.
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.