LogoLogo
  • INTRODUCTION
  • LEARN
    • Espresso in the Modular Stack
    • The Espresso Network
      • System Overview
      • Properties of HotShot
        • EspressoDA
          • How It Works
      • Interfaces
        • Espresso ↔ Rollup
        • Espresso ↔ L1
        • Rollup ↔ L1
      • Internal Functionality
        • Espresso Node
        • Light Client Contract
        • Fee Token Contract
        • Stake Table
          • How the Stake Table Contract Works
        • Smart Contract Upgradeability
    • Rollup Stacks
      • Integrating a ZK Rollup
        • ZK Rollup Architecture
        • Using Espresso
        • Summary of Changes
      • Integrating an Optimistic Rollup
        • Optimistic Rollup Architecture
        • Using Espresso
        • Summary of Changes
  • Guides
    • Using the Espresso Network
      • Integrating Arbitrum Orbit Chain
        • Quickstart with Arbitrum Nitro Rollups
        • Reading Confirmations from the Espresso Network
        • Arbitrum Nitro Integration Overview
          • Using TEE with Nitro
          • Arbitrum Nitro Trust & Liveness Dependencies
        • Migrating Arbitrum Orbit Chains to Espresso
          • Arbitrum Testnet
            • Nitro Testnet
            • Local Deployment (`docker compose`)
      • Using the Espresso Network as a Cartesi application
    • Running an Espresso Node
    • Running a Builder
    • Bridging with the Espresso Network
  • API Reference
    • Espresso API
      • Status API
      • Catchup API
      • Availability API
      • Node API
      • State API
      • Events API
      • Submit API
      • Earlier Versions
        • v0
          • Status API
          • Catchup API
          • Availability API
          • Node API
          • State API
          • Events API
          • Submit API
    • Builder API
  • Releases
    • Mainnet 1
      • Running a Mainnet 1 Node
      • Contracts
      • Rollup Migration Guide
    • Mainnet 0
      • Running a Mainnet 0 Node
      • Contracts
    • Testnets
      • Decaf Testnet Release
        • Running a Node
        • Contracts
      • Cappuccino Testnet Release
        • Running a Node
        • Deploying a Rollup on Cappuccino
        • Benchmarks
      • Gibraltar Testnet Release
        • Interacting with Gibraltar
        • Arbitrum Nitro integration
        • Deploying a Rollup on Gibraltar
      • Cortado Testnet Release
        • Interacting with Cortado
        • OP Stack Integration
          • Optimism Leader Election RFP
      • Doppio Testnet Release
        • Interacting with Doppio
        • Polygon zkEVM Stack Integration
        • Minimal Rollup Example
        • Benchmarks
      • Americano Testnet Release
  • Appendix
    • Interacting with L1
      • Trustless Sync
      • Fork Recovery
      • Bridging
    • Glossary of Key Terms
Powered by GitBook
On this page
  1. LEARN
  2. Rollup Stacks
  3. Integrating an Optimistic Rollup

Summary of Changes

PreviousUsing EspressoNextUsing the Espresso Network

Last updated 1 year ago

This section summarizes the changes from the that are required to integrate an optimistic rollup with Espresso. Though the changes are presented in terms of an abstracted architecture, if you can map this abstraction onto your specific optimistic rollup, you can derive a very concrete to-do list for integrating your rollup with Espresso.

  1. Modify JSON-RPC or analogous server to forward transactions from users to Espresso. Choose a numeric ID for your rollup and attach it to the forwarded transactions.

  2. Modify proposers and challengers to stream notifications of new blocks from either:

    • The streaming availability API

    • Events emitted by the sequencer contract

  3. Modify proposers and challengers to download full blocks, or rollup-specific subsets of blocks, from the sequencer availability API.

  4. Extend proposers and challengers to include, in the event of a challenge

    • The HotShot block commitment they are challenging

    • A completeness/inclusion proof for the transaction list they have executed relative to the block commitment

    • A Merkle proof showing the block commitment exists at the correct position in the Merkle tree maintained by the sequencer contract

  5. Modify the rollup contract to read block commitments from the sequencer contract instead of its own storage.

  6. Extend the rollup contract to verify the completness/inclusion proof and Merkle proof provided by proposer and challenger.

  7. (Optional) Extend the challenge protocol to encode a deterministic reordering of the transactions provided by Espresso.

generalized optimistic rollup architecture