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 a ZK Rollup

Summary of Changes

PreviousUsing EspressoNextIntegrating an Optimistic Rollup

Last updated 1 year ago

This section summarizes the changes from the that are required to integrate a ZK rollup with Espresso. Though the changes are presented in terms of an abstracted architecture, if you can map this abstraction onto your specific ZK 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 executor to stream notifications of new blocks from either:

    • The streaming availability API

    • Events emitted by the sequencer contract

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

  4. Change the interface of the state transition proof, replacing the rollup block or block commitment input with a HotShot block commitment.

  5. Extend the proof to encode a proof of completeness and inclusion of the rollup block relative to the block commitment. For a ZK proof system formalized the usual way, in terms of constraints on an arithmetic circuit, this means adding more wires and constraints so that the circuit checks the inclusion/completeness proof, which becomes a witness to the circuit. Once released, the Espresso SDK can help define these additional constraints.

  6. (Optional) Extend the proof to encode a deterministic reordering of the transactions provided by Espresso.

  7. Update the prover to generate the new type of proof.

  8. (If applicable) Update the on-chain proof verifier to check the new kind of proof. This generally involves replacing the preprocessed representation of the circuit. The contract will also need to accept a Merkle proof showing that the new block commitment input to the proof matches the corresponding block commitment in the Merkle tree maintained by the sequencer contract. Alternatively, the verification of this Merkle proof can be embedded in the circuit.

  9. (If applicable) Update off-chain proof verifiers (validators or light clients) in the analogous way.

generalized ZK-rollup architecture