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. Guides
  2. Using the Espresso Network

Integrating Arbitrum Orbit Chain

Arbitrum integration with Espresso

PreviousUsing the Espresso NetworkNextQuickstart with Arbitrum Nitro Rollups

Last updated 3 months ago

Espresso has developed an integration with the Arbitrum Nitro tech stack that allows chains to easily integrate with Espresso. The first version of this integration enables Espresso confirmations for Orbit chains. The integration will later be updated with functionality to enable enhanced cross-chain interoperability, new forms of sequencing (i.e., decentralized/shared sequencing), and support for Espresso DA.

The first production release of the Espresso-Arbitrum Nitro integration is planned for January 2025, at which point Arbitrum Orbit chains will simply be able to download a Docker image that allows them to deploy onto Espresso (or ask their RaaS provider to do so on their behalf).

If you just want to see the steps for getting up and running, you can .

Integration overview

This integration makes minimal changes to the Arbitrum Nitro stack, and ensures that each batch processed by the rollup is consistent with HotShot-finalized blocks within its namespace.

To ensure that the batch has been finalized by HotShot, the following checks are performed:

  1. Namespace validation: Ensure that the set of transactions in a rollup's batch corresponds to the correct namespace. Namespacing allows multiple chains to use Espresso’s fast confirmation layer simultaneously by associating each chain’s transactions with a unique namespace within HotShot blocks.

  2. Espresso block Merkle proof check: Confirm that the rollup's batch maps to a valid HotShot block. Specifically, verify that the HotShot block associated with a rollup batch is a valid leaf in the Merkle tree maintained by the light client contract, which stores the state of HotShot on L1.

  1. The sequencer calls WriteSequencerMsg on the transaction streamer.

  2. The batcher fetches the message from the transaction streamer and submits the transaction to HotShot via the transaction streamer.

  3. The batcher then calls the query API to check if the transaction has been finalized by HotShot.

  4. Once the transaction is finalized, the batcher performs batch consistency checks.

  5. The batcher signs the transaction calldata that would be sent to the Sequencer Inbox contract.

  6. The Sequencer Inbox contract is modified to verify the batcher’s signature.

This approach involves running a Nitro node with only the batcher enabled, operating in a TEE environment (such as Intel SGX). The batcher will sign the transaction calldata. In case the TEE is broken, the batch poster can't impact the safety of the Orbit chain. It could, however, temporarily halt the chain's progress, thereby breaking liveness. Bridges relying on Espresso confirmations for faster settlement need to trust the TEE as well in this integration. In a future update, the dependency on TEEs will be removed entirely.

Arbitrum Orbit
skip to the guide
High-level flow of integration