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
  • Prerequisites & Requirements (1-3 days*)
  • Run deployments (2-3 weeks)
  • Migration Flow (1-3 hours)
  • Support (0.5-1 hour per week)
  • FAQ
  1. Guides
  2. Using the Espresso Network
  3. Integrating Arbitrum Orbit Chain

Arbitrum Nitro Integration Overview

PreviousReading Confirmations from the Espresso NetworkNextUsing TEE with Nitro

Last updated 2 months ago

TL;DR - Chains and Rollup-as-a-Service (”RaaS”) providers can leverage the Espresso Network to provide users with faster, more secure confirmations on their transactions. The Espresso Network also provides chain operators with information about the state of their own chain and the states of other chains, all of which is important for improved UX and ultimately, cross-chain composability. This document outlines the steps for chains/RaaS to integrate with the Espresso Network.

Integration at a glance - Integrating with the Espresso Network requires minimal changes to Arbitrum Nitro's existing rollup design, and the key change is running the Arbitrum Nitro batch poster inside a Trusted Execution Environment (”TEE”). See for an explanation of this design and see for trust assumptions that partners should be aware of when integrating. Today, Espresso has developed software to run the batch poster using SGX in Microsoft Azure. We plan to release a version compatible with AWS Nitro (not to be confused with Arbitrum Nitro) by EOQ1’25.

Prerequisites & Requirements (1-3 days*)

*Assumes familiarity with TEEs. Teams may want to allocate up to 7 days to upskill and deploy this technology for the first time.

We will host a kick-off call to walk through your technical architecture, including what cloud providers you work with. In an effort to expedite the integration process, we ask that you please share with Espresso:

  1. A config file that we can work from. Note: This is only needed if Espresso is running the batch poster.

  2. Direct access to your RPC node (instead of through an intermediary). Note: This is only needed if Espresso is running the batch poster.

  3. Confirmation that you are able to run the TEE within your existing infrastructure. Note: Espresso is able to run it on your behalf; however we prefer to support you to run it using your own infrastructure.

  4. Confirmation of the integrating chain's current Arbitrum Nitro version.

  5. Other pre-requisites include understanding how a TEE operates, if you aren't already familiar:

    • Docs specific to AWS Nitro Enclaves:

    • Docs specific to SGX:

Run deployments (2-3 weeks)

We require that teams run a testnet and mainnet deployment; however chains and RaaS providers have the opportunity to also run internal devnet deployments beforehand (this is recommended if it's our first time working together). This process will allow us time to fix any issues and bugs that may occur during testing and will ultimately ensure a more seamless transition to mainnet. An illustrative integration timeline may look like this (see diagram below):

  • An internal deployment (3-4 days) is optional but is recommended for new architecture or a RaaS provider that has not previously integrated with Espresso.

  • A devnet deployment (3-7 days) is optional but is recommended for new architecture or a RaaS provider that has not previously integrated with Espresso.

  • A testnet deployment (5-7 days) is required, and we look to run a testnet for 5-7 days with no incidents before we consider deploying to mainnet.

  • A mainnet deployment would follow a successful testnet deployment.

Migration Flow (1-3 hours)

  1. Run the batch poster inside the TEE (e.g. AWS Nitro or SGX)

  2. Deploy the EspressoTEEVerifier contract

  3. Stop the batch poster node and copy the batch poster’s databases files to the TEE

  4. Perform the sequencer inbox migration

  5. New batch poster starts catching up messages and building up state

Support (0.5-1 hour per week)

  • Espresso engineers will support your chain and RaaS provider as you navigate the integration process through relevant devops services, async tech support, and calls to run through integration steps.

  • Espresso has a 24x7 support model and tracks the health and frequency of batch posting to ensure that there are no delays. If something isn't working, Espresso will automatically trigger an on-call procedure to investigate the incident. We recommend that our integrated chains also monitor these health metrics and have an incident management procedure.

FAQ

  1. How much does it cost a chain or RaaS provider to integrate with Espresso?

    1. Fees are paid by the builder of each block. Initially, in Mainnet 0.0/Decaf 0.0, Espresso will run a simple builder and cover fees. Fees will not be collected from rollups using Espresso or their users. There will be no third party builders during Mainnet 0.0/Decaf 0.0.

  2. What is Espresso’s latency for blocks? How long does it take blocks to reach finality?

    1. Espresso confirmations are faster than waiting for Ethereum finality, which takes 12-15 minutes. Using Espresso, the current latency for blocks is 2-9s (1-3s with transactions, 8s with no transactions) with HotShot finality reached after 3 consecutive blocks, typically in 6-20s (slower when blocks are empty). There are future roadmap improvements to decrease latency and time to finality (including an adjustment to finalize after 2 consecutive blocks, rather than 3, which should result in a 20-30% reduction in latency).

  3. What is Espresso’s throughput per second?

OR

(note this links to Taiko’s docs, as Taiko currently uses SGX)

During some recent heavy load testing, we achieved ~100 TPS with small transactions (~200 bytes each). We currently have a 1MB limit on the block size, which performed well under the same load testing. We plan to use our Proof of Stake upgrade in March 2025 to significantly improve network throughput and latency with (i) an increase to the block limit, and (ii) adding erasure coding via .

Review Hello Enclaves sample application
Install AWS Nitro on Linux
Install AWS Nitro on Windows
Guide to determine which hardware/cloud providers support SGX
Guide to enable a prover using SGX
Verifiable Information Dispersal
here
here
See here for the technical integration diagram