Cronos zkEVM
Badges
About
Cronos zkEVM is a general-purpose Validium on Ethereum built on the ZK Stack, scaling the existing portfolio of Cronos apps and chains.
Badges
About
Cronos zkEVM is a general-purpose Validium on Ethereum built on the ZK Stack, scaling the existing portfolio of Cronos apps and chains.
Alpha Mainnet Launch
2024 Aug 15th
Cronos zkEVM Launches Its Alpha Mainnet powered by ZKsync.
Funds can be stolen if
Funds can be lost if
Users can be censored if
MEV can be extracted if
Sequencer failure
Enqueue via L1Data availability
ExternalProof construction and state derivation rely fully on data that is NOT published on chain.
Exit window
NoneThere is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Proposer failure
Cannot withdrawOnly the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
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.
Data is not stored on chain
The transaction data is not recorded on the Ethereum main chain.
Funds can be lost if the external data becomes unavailable (CRITICAL).
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.
ZK stack proof system Boojum can be found here and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found here.
The system has a centralized operator
The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can force any transaction via L1
If a user is censored by L2 Sequencer, they can try to force transaction via L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from L1 queue in an L2 block.
Users can be censored if the operator refuses to include their transactions.
Regular exit
Forced exit
If the user experiences censorship from the operator with regular exit they can submit their withdrawal requests directly on L1. The system is then obliged to service this request or halt all messages from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular exit.
The Matter Labs multisig (4 / 7) is able to instantly upgrade all contracts and manage all parameters and roles. This includes upgrading the shared contracts, the CronosZkEvm diamond and other ZK stack diamonds and their facets and censoring transactions or stealing locked funds. Most permissions are inherited by it being the indirect Owner of the StateTransitionManager (STM) and Governor (owner) of the Governance contract. A security council is currently not used.
The current deployment allows for a subset of the permissions currently held by the Matter Labs Multisig to be held by a ChainAdmin role.
This role can manage fees, apply predefined upgrades, censor bridge transactions, manage Validator addresses and revert batches. It cannot make arbitrary updates or access funds in the escrows. This Admin role is usually set to a ChainAdmin contract which is itself owned by the Matter Labs Multisig (Thus not affecting their full permissions).
Other roles include:
Validator: Proposes batches from L2 through the ValidatorTimelock, from where they can be proven and finally executed (by the Validator through the ExecutorFacet of the diamond) after a predefined delay (currently 21h). This allows for freezing the L2 chain and reverting batches within the delay if any suspicious activity was detected, but also delays finality. The ValidatorTimelock has the single Validator role in the Zk stack diamond contracts and can be set by the Matter Labs Multisig through the STM. The actual Validator actors can be added and removed by the ChainAdmin in the ValidatorTimelock contract.
Verifier: Verifies the zk proofs that were provided by a Validator. Can be changed by calling executeUpgrade() on the AdminFacet from the STM.
A Governance smart contract is used as the intermediary for most of the critical permissions of the Matter Labs Multisig. It includes logic for planning upgrades with parameters like transparency and/or a delay.
Currently the delay is optional and not used by the multisig.
The optional transparency may be used in the future to hide instant emergency upgrades by the Security Council or delay transparent (thus auditable) governance upgrades. The Governance smart contract has two roles, an Owner (Governor role in the picture, resolves to Matter Labs Multisig) role and a SecurityCouncil role.
The system uses the following set of permissioned addresses:
This is a Gnosis Safe with 4 / 7 threshold. This MultiSig is the current central Governor for upgradeability and configuration of all shared ZK stack contracts and each Hyperchain under it and can potentially steal all funds.
Used in:
Those are the participants of the Matter Labs Multisig.
Can manage fees, apply predefined upgrades, censor bridge transactions and revert batches (Admin role in the CronosZkEvm contract).
Used in:
This is a Gnosis Safe with 2 / 3 threshold. Inherits all permissions of the CronosZkEVMAdmin contract.
Those are the participants of the AdminMultisig.
Inherits all permissions of the CronosZkEVMAdmin contract.
The system consists of the following smart contracts on the host chain (Ethereum):
The main Rollup contract. The operator commits blocks and provides a ZK proof which is validated by the Verifier contract then processes transactions. During batch execution it processes L1 --> L2 and L2 --> L1 transactions.
Upgrade delay: No delay
Proxy used in:
Intermediary governance contract with two roles and a customizable delay. This delay is only mandatory for transactions scheduled by the Owner role and can be set by the SecurityCouncil role. The SecurityCouncil role can execute arbitrary upgrade transactions immediately. Currently the delay is set to 0s and the SecurityCouncil role is not used.
Upgrade delay: No delay
Proxy used in:
Intermediary governance contract that has the Admin (not upgradeability admin) role for the Cronos zkEVM diamond contract.
Intermediary contract between the Validators and CronosZkEvm that delays block execution (ie. withdrawals and other L2 --> L1 messages).
Proxy used in:
Implements ZK proof verification logic.
Upgrade delay: No delay
Proxy used in:
This bridge contract escrows all assets that are deposited to Cronos zkEVM and other chains in the Hyperchain Ecosystem.
Upgrade delay: No delay
Proxy used in:
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).
