Search for projects by name
Morph is an EVM compatible rollup. It operates as an optimistic rollup with ZK fault proofs.
Morph is an EVM compatible rollup. It operates as an optimistic rollup with ZK fault proofs.
There is no mechanism to have transactions be included if the sequencer is down or censoring.
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.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
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.
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 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.
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.
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.
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.
Challenger is an actor allowed to challenge or delete state roots proposed by a Proposer.
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.
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).
Upgrade delay: No delay
Upgrade delay: No delay
Can be used to upgrade implementation of L1Staking, L1ETHGateway, L1MessageQueueWithGasPriceOracle, L1StandardERC20Gateway, L1GatewayRouter, MorphRollup, EnforcedTxGateway, L1CrossDomainMessenger.
Main entry point for depositing ETH and ERC20 tokens, which are then forwarded to the correct gateway.
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.
Upgrade delay: No delay
Used to update the verifier and keep track of current and old versions.
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.
Upgrade delay: No delay
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).