Search

Search for projects by name

Morph logoMorph

About

Morph is an EVM compatible rollup. It operates as an optimistic rollup with ZK fault proofs.


Value Locked
$17.82 M18.2%
Canonically Bridged
$17.37 M
Externally Bridged
$450.38 K
Natively Minted
$0.00

  • Tokens
  • Daily UOPS
    No data
  • 30D ops count
    No data

  • Stage
    Stage 0
  • Type
    Optimistic Rollup
  • Purpose
    Universal
  • Sequencer failureState validationData availabilityExit windowProposer failure

    About

    Morph is an EVM compatible rollup. It operates as an optimistic rollup with ZK fault proofs.


    Recategorisation

    179d
    10h
    23m
    04s

    The project will be classified as "Other" due to its specific risks that set it apart from the standard classifications.

    The project will move to Others because:

    There are less than 5 external actors that can submit challenges

    Consequence: projects without a sufficiently decentralized set of challengers rely on few entities to safely update the state. A small set of challengers can collude with the proposer to finalize an invalid state, which can cause loss of funds.

    Learn more about the recategorisation here.

    Value Locked
    Canonical
    External
    Native
    Risk summary
    Risk analysis
    Sequencer failureState validationData availabilityExit windowProposer failure

    Sequencer failure

    No mechanism

    There is no mechanism to have transactions be included if the sequencer is down or censoring.

    State validation

    Fraud proofs (1R, ZK)

    Fraud proofs allow actors watching the chain to prove that the state is incorrect. Single round proofs (1R) only require a single transaction to resolve. ZK proofs are used to prove the correctness of the state transition. The system currently operates with a single whitelisted challenger.

    Data availability

    Onchain

    All of the data needed for proof construction is published on Ethereum L1.

    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.

    Rollup stage
    MorphMorph is a
    Stage 0
    Optimistic Rollup.
    The requirement for available node software is under review

    Learn more about Rollup stages
    Please keep in mind that these stages do not reflect rollup security, this is an opinionated assessment of rollup maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.
    Technology

    Single round fault proof system

    Morph uses an one round fault proof system where whitelisted Challengers, if they find a faulty state root within the 2d challenge window, can post a 1 WEI bond and request a ZK proof of the state transition. After the challenge, during a 3d proving window, a ZK proof must be delivered, otherwise the state root is considered invalid and the root proposer bond, which is set currently to 1 ETH, is slashed. The zkEVM used is SP1 from Succinct. If the valid proof is delivered, the Challenger loses the challenge bond. The MorphAdminMSig can override any batch (both unfinalized and finalized), potentially preventing the ability to provide valid ZK proofs.

    • Funds can be stolen if whitelisted challenger does not post a challenge of an incorrect state root.

    • Funds can be lost if the owner overrides finalized batches.

    1. Rollup.sol - Etherscan source code, commitBatch(), challengeState(), proveState() functions

    Zero knowledge SNARK cryptography is used

    Despite their production use zkSNARKs are still new and experimental cryptography. Cryptography has made a lot of advancements in the recent years but all cryptographic solutions rely on time to prove their security. In addition zkSNARKs require a trusted setup to operate.

    • Funds can be stolen if the cryptography is broken or implemented incorrectly.

    All data required for proofs is published on chain

    All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.

    1. Rollup.sol - Etherscan source code commitBatch() and commitBatchWithBlobProof() functions
    Operator

    Morph uses decentralised sequencer network

    The system uses a decentralised sequencer/proposer network. At the moment all sequencers are run by Morph and - from the point of Ethereum - they don’t need to reach consensus on a block as any one of them can propose a block with an L2 state root on Ethereum. There is a plan to use tendermint with BLS signatures to verify consensus after Petra upgrade.

    • MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

    1. L1Staking.sol - Etherscan source code, verifySignature() function

    Users can't force any transaction

    There is no general mechanism to force the sequencer to include the transaction.

    • Users can be censored if the operator refuses to include their transactions.

    1. EnforcedTxGateway.sol - Etherscan source code
    2. Rollup.sol - proposer can indicate which messages were skipped
    Withdrawals

    Regular exit

    The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. The process of block finalization takes a challenge period of 2d to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

    • Funds can be frozen if the operator censors withdrawal transaction.

    1. L1ETHGateway.sol - Etherscan source code, finalizeWithdrawETH function
    Permissions

    The system uses the following set of permissioned addresses:

    Challenger MorphAdminMSig

    Challenger is an actor allowed to challenge or delete state roots proposed by a Proposer.

    Actors allowed to commit transaction batches and propose state roots

    MorphAdminMSig 0xB822…4377
    • A Gnosis Safe with 5 / 8 threshold.
    • Can act on behalf of ProxyAdmin.
    • A Challenger.
    • Can change the configuration of MorphRollup - can pause and unpause, override any batch, revert batch, update proof window, update challengers, modify verifiers.
    • Can change the configuration of EnforcedTxGateway - can pause and unpause.
    • Can upgrade the implementation of L1Staking, L1ETHGateway, L1MessageQueueWithGasPriceOracle, L1StandardERC20Gateway, L1GatewayRouter, MorphRollup, EnforcedTxGateway, L1CrossDomainMessenger (acting via ProxyAdmin).

    Those are the participants of the MorphAdminMSig.

    A Sequencer - Actors allowed to commit transaction batches and propose state roots.

    A Sequencer - Actors allowed to commit transaction batches and propose state roots.

    A Sequencer - Actors allowed to commit transaction batches and propose state roots.

    A Sequencer - Actors allowed to commit transaction batches and propose state roots.

    A Sequencer - Actors allowed to commit transaction batches and propose state roots.

    A Sequencer - Actors allowed to commit transaction batches and propose state roots.

    A Sequencer - Actors allowed to commit transaction batches and propose state roots.

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

    Contract keeping track of stakers which act as sequencers/proposes. It is responsible for stakers registering and withdrawals and for verifying BLS signatures of stakers (currently not implemented).

    Can be upgraded by:

    Upgrade delay: No delay

    Contract used to bridge ETH from L1 to L2.

    Can be upgraded by:

    Upgrade delay: No delay

    ProxyAdmin 0x3111…16A0

    Can be used to upgrade implementation of L1Staking, L1ETHGateway, L1MessageQueueWithGasPriceOracle, L1StandardERC20Gateway, L1GatewayRouter, MorphRollup, EnforcedTxGateway, L1CrossDomainMessenger.

    L1MessageQueueWithGasPriceOracle 0x3931…C1EFImplementation (Upgradable)Admin

    Contains the array of queued L1 -> L2 messages, either appended using the L1Messenger or the EnforcedTxGateway.

    Can be upgraded by:

    Upgrade delay: No delay

    Contract used to bridge ERC20 tokens from L1 to L2. It uses a fixed token list. This contract can store any token.

    Can be upgraded by:

    Upgrade delay: No delay

    ZkEvmVerifierV1 0x6dAe…069e

    Current SP1 verifier using Blobs for DA, used to prepare data for the PlonkVerifierV0.

    Main entry point for depositing ETH and ERC20 tokens, which are then forwarded to the correct gateway.

    Can be upgraded by:

    Upgrade delay: No delay

    The main contract of the Morph chain. Allows to post transaction data and state roots, implements challenge mechanism along with proofs. Sequencing and proposing are behind a whitelist.

    Can be upgraded by:

    Upgrade delay: No delay

    MultipleVersionRollupVerifier 0x87C1…DCF6

    Used to update the verifier and keep track of current and old versions.

    Contracts to force L1 -> L2 messages with the proper sender. Currently paused: true.

    Can be upgraded by:

    Upgrade delay: No delay

    Contract used to send L1 -> L2 and relay messages from L2. It allows to replay failed messages and to drop skipped messages. L1 -> L2 messages sent using this contract pay for L2 gas on L1 and will have the aliased address of this contract as the sender. This contract stores the following tokens: ETH.

    Can be upgraded by:

    Upgrade delay: No delay

    Whitelist 0xFFaf…6984

    Contract implementing a generic whitelist. Currently used to define the actor that can relay the L2 basefee on L1.

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