AltLayer Documentation
  • 👋Welcome
    • Overview
  • Restaked Rollups
    • VITAL for Decentralised Verification
      • Tier-1 Finality
      • Tier-2 Finality
      • Tier-3 Finality
    • MACH for Faster Finality
      • Interoperability via MACH
    • SQUAD for Decentralised Sequencing
    • Staking of dApp Token
  • Wizard
    • Introduction
    • Technical overview
    • Create AVS
    • Manage AVS
    • Operator management
    • Hosted operator API (BLS based)
    • Custom AVS specification
      • Constructor specification requirements
      • Import Externally-Deployed AVS
    • Report bug or submit a feature request
  • Autonome
    • Deploy AI Agent
    • Autonome API guide
    • Uploading your own agent framework
    • Twitter/X login troubleshooting guide
  • ♾️AltLayer-Facilitated Actively Validated Services
    • Overview
    • AltLayer MACH AVS
      • Operator Guide
      • User Delegation Guide
    • Cyber MACH AVS for Cyber L2
      • Operator Guide
      • User Delegation Guide
    • DODOchain MACH AVS for DODO Chain
      • Operator Guide
      • User Delegation Guide
    • Fast Finality Layer for Soneium
      • Operator Guide
      • User Delegation Guide
    • Xterio MACH AVS for Xterio Chain
      • Operator Guide
      • User Delegation Guide
  • Upgrade Guide
  • 🥩ALT Restaking
    • Staking Info & Parameters
    • Restake ALT
    • Delegating reALT
    • Check and Claim Staking Rewards
    • Unstake ALT
    • Migration from Xterio (Legacy) ALT Pool to Xterio Restaked ALT Pool
    • Testnet reALT faucet
  • Rollup-as-a-Service
    • What is Rollup-as-a-Service (RaaS)?
    • AltLayer's RaaS Offering
    • RaaS Onboarding Guide
      • Optimism Rollup FAQ
      • Arbitrum Rollup FAQ
    • AltLayer Ecosystem
    • Clients in the Spotlight
    • Pricing Model
  • External Integrations
    • Account Abstraction using Biconomy
    • Enabling permissionless interoperability on AltLayer Rollup with Hyperlane
      • Deplying Hyperlane Warp Routes for ERC20 Token Bridging
      • Running Off-chain Agents
      • Setting up the bridging UI
    • Cross-chain Interoperability using Celer
      • Fungible Token Bridging
      • Non-fungible Token Bridging
      • Generic Message Passing
      • cBridge SDK
  • AltLayer's In-House Rollup Stack in Depth
    • How does AltLayer's in-house rollup stack work?
    • Decentralized Sequencer Set
    • Security via Fraud Proof
  • Rollup Types
    • Flash Layer Rollups
      • Example Use cases
        • NFT Mint Events
        • Games
        • Event Ticketing
    • Persistent Rollups
  • Core Features of AltLayer's In-House Rollup Stack
    • Modular
    • Elastic
    • Multi-VM Support
    • Fraud Proofs
    • Decentralized Sequencers
    • Tiered-Finality
  • FlashLayer Showcase
    • AltLayer's POAP NFTs Collection Mint
      • Performance Test in the Wild
    • Dark Forest Community Round
    • Oh Ottie! NFT Collection Mint
    • Dark Forest Community Round for Jump Crypto's Pit Event
    • Ottie 2048
    • Other demos
      • Fraud Proof Demo
      • Flash Layer Demo
      • Rollup Launchpad Demo
      • FlashGPT Demo
  • Implementation Status
    • Roadmap
    • Development Status
  • Community & Support
    • Community
    • Support
Powered by GitBook
On this page
  1. Restaked Rollups

MACH for Faster Finality

PreviousTier-3 FinalityNextInteroperability via MACH

Last updated 1 year ago

To address the slow finality of rollups, we present MACH: a fast finality layer for Ethereum rollups with the following key desiderata:

  1. Fast confirmation for rollup transactions

  2. Crypto-economic security so as to handle any malicious network participants

  3. Support both ZK as well as optimistic rollups

  4. Generic enough to support different proof systems and runtimes

In order to guarantee finality, MACH as a network needs to verify the validity of a rollup state to ensure that the rollup operators have followed the state transition function correctly. To this end, MACH supports three state validity modes.

Pessimistic Mode

In the pessimistic mode, each transaction is considered by default invalid, and hence needs to be replayed. As a result, the rollup operator feeds transaction data directly to the MACH network which in turn re-executes the transaction and reaches consensus on the validity of the proposed state by the rollup operator.

While this operational mode is the simplest of all, one of its major downsides is that it is not very efficient as MACH practically operates as a network of full nodes for the rollup. And this results in beefy node requirements.

A future work is to build stateless clients that require a smaller state footprint to operate a node for the rollup.

Optimistic Mode

In this mode, the rollup operator asserts a state claim on MACH, stating that the execution of a specific block of transactions leads to a particular state commitment. Any node in the MACH network can then challenge the claim and prove that the new state is not valid by engaging with the rollup operator in a bisection protocol. This is the classical Optimistic Mode as shown in the diagram below.

This setup assumes the existence of at least one honest node in the MACH network and network nodes are mostly in observation mode.

Validity Proof Mode

In this mode, the MACH network acts as a decentralised verifier network for validity proofs. The rollup operator such as a sequencer will commit to a newly set of transactions, the resulting state, together with the validity proof on MACH. The MACH network will then verify and reach consensus on the validity of the proof.

Despite the explicit usage of validity proofs, this mode can also work well with optimistic rollups. With optimistic rollups, any designated prover with the right incentive (outside of MACH), can generate a proof of validity and submit it to the MACH network which in turn verifies and reaches consensus on the validity of the proof.

Note that for ZK rollups, the prover can generate and submit proofs more frequently on MACH than it does on Ethereum and it is important they do so for faster finality. Moreover, this does not need to happen at the expense of more proving work: Instead of waiting to create a single batch proof, the prover can create proofs in real time and send it to MACH and use recursion to aggregate them into a batch proof later that can go to Ethereum. As long as the incremental proofs are distributed right away to MACH, the transactions will experience fast finality.

Note that the bisection protocol is triggered only when a challenger believes the state commitment is not valid. Alternatively, one could also replace the bisection protocol by This is explained in the diagram below.

on-demand ZK proofs, where the ZK proof is only generated if there is a challenge.