Cronos zkEVM logoCronos 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.


Value Locked
Canonically Bridged
$0.00
Externally Bridged
$0.00
Natively Minted
$0.00

  • Tokens
  • Daily TPS
    0.0611.10%
  • 30D tx count
    237.86 K

  • Type
    Validium
  • Purpose
    Universal
  • Sequencer failureState validationData availabilityExit windowProposer failure

    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.


    Activity
    Milestones & Incidents

    Alpha Mainnet Launch

    2024 Aug 15th

    Cronos zkEVM Launches Its Alpha Mainnet powered by ZKsync.

    Learn more
    Risk summary
    Risk analysis
    Sequencer failureState validationData availabilityExit windowProposer failure

    Sequencer failure

    Enqueue via L1

    Users can submit transactions to an L1 queue, but can’t force them. The sequencer cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencer censors or is down, it is so for everyone.

    State validation

    ZK proofs

    Data availability

    External

    Proof construction and state derivation rely fully on data that is NOT published on chain.

    Exit window

    None

    There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.

    Proposer failure

    Cannot withdraw

    Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.

    Technology

    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).

    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

    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.

    ZK Circuits

    ZK stack circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found here. The circuits are checked against tests that can be found here.

    • 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 tool. The system requires a trusted setup.

    Operator

    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.

    1. L1 - L2 interoperability - Developer's documentation
    Withdrawals

    Regular exit

    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.

    1. Withdrawing funds - ZKsync documentation

    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.

    Upgrades & Governance
    A diagram of the upgrades and governance
    A diagram of the upgrades and governance

    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.

    Permissions

    The system uses the following set of permissioned addresses:

    Matter Labs Multisig 0x4e49…7828

    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.

    CronosZkEVMAdmin 0x4e49…7828

    Can manage fees, apply predefined upgrades, censor bridge transactions and revert batches (Admin role in the CronosZkEvm contract).

    Used in:

    AdminMultisig 0x4c57…dFce

    This is a Gnosis Safe with 2 / 3 threshold. Inherits all permissions of the CronosZkEVMAdmin contract.

    AdminMultisig participants (3) 0xE9A0…64Fb0x5628…2ADa0xc7e3…11D8

    Those are the participants of the AdminMultisig.

    AdminEOA 0xfD7a…7339

    Inherits all permissions of the CronosZkEVMAdmin contract.

    Actors that are allowed to propose, execute and revert L2 batches on L1 through the ValidatorTimelock.

    Smart contracts
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    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.

    Can be upgraded by:

    Upgrade delay: No delay

    Proxy used in:

    Governance 0x0b62…3F61

    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.

    Can be upgraded by:

    Upgrade delay: No delay

    Proxy used in:

    CronosZkEVMAdmin 0x66eF…7cDC

    Intermediary governance contract that has the Admin (not upgradeability admin) role for the Cronos zkEVM diamond contract.

    ValidatorTimelock 0x5D8b…d06E

    Intermediary contract between the Validators and CronosZkEvm that delays block execution (ie. withdrawals and other L2 --> L1 messages).

    Proxy used in:

    Verifier 0x70F3…9604

    Implements ZK proof verification logic.

    Can be upgraded by:

    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.

    Can be upgraded by:

    Upgrade delay: No delay

    Proxy used in:

    Sits between the single shared bridge and the StateTransitionManager(s) and relays L1 <-> L2 messages from the shared bridge or other ZK stack chains to their respective destinations.

    Can be upgraded by:

    Upgrade delay: No delay

    Proxy used in:

    Defines shared L2 diamond contract creation and upgrade implementations and the verifier for the Hyperchain contracts connected to it.

    Can be upgraded by:

    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).

    Knowledge nuggets