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
  • Background
  • Using Espresso confirmations
  • Sending data to Espresso
  • Fetching data from Espresso
  • Receiving notification about finalized Espresso blocks
  • Fetching transactions confirmed by Espresso
  • Verifying Espresso consensus
  • Arbitrum Nitro integration example
  1. Guides

Using the Espresso Network

Guides for applications, such as rollups and bridges, to use the Global Confirmation Layer.

PreviousSummary of ChangesNextIntegrating Arbitrum Orbit Chain

Last updated 5 months ago

Background

The Espresso Network is a shared source of truth that provides strong confirmations on transaction ordering and data across chains. The confirmations provided by HotShot are additive, meaning that rollups can keep giving their users pre-confirmations using their own existing sequencer. It’s up to the end user whether to trust the centralized sequencer or wait a few seconds more for the stronger confirmation provided by Espresso. For more details see the

Using Espresso confirmations

Using the Espresso Network primarily relies on three ingredients:

  • Data is sent to Espresso

  • Data is fetched from Espresso after confirmation

  • HotShot consensus is verified in the chain's state transition function (STF)

We recommend running an Espresso node and using its query service. This is the easiest way to ensure that all data received is validated. For convenience you can also connect to the API services of Espresso’s nodes and use the Docker image for local testing.

Sending data to Espresso

Espresso does not interpret the data submitted to the network. As a result, chains are free to encode their data however they wish when sending it to Espresso. Chains are expected to choose an integer namespace ID akin to the EVM chain ID. Note that anyone can submit transactions with any namespace ID. If transactions from third parties are undesired those must be filtered out.

An Espresso transaction consists of a .

The Espresso transactions can be sent to the of sequencer nodes, or to a . Builders may support private mempools if gossiping of transactions through the public mempool is not desired.

Fetching data from Espresso

The blocks finalized by Espresso are divided by namespace. Transactions with a certain namespace ID will be found in the corresponding namespace in the block. For a basic integration, the rollup will only consider the Espresso transactions in its own namespace.

Receiving notification about finalized Espresso blocks

Rollups can receive notifications from the Espresso query service API or the sequencer contract on the L1. The interval at which the finalized state is proved in the sequencer contract (hours) is orders of magnitudes slower than the Espresso block time (seconds). To acquire confirmations, notifications about newly finalized blocks must be obtained via the Espresso query service API directly.

Fetching transactions confirmed by Espresso

Verifying Espresso consensus

The rollup state transition function must ensure that the rollup transactions are confirmed by Espresso before executing them.

The two main additions to the rollup STF are that the STF must verify that:

  1. the transactions are exactly the transactions in the rollup’s namespace confirmed as part of the finalized Espresso block, and

  2. the Espresso block is part of the canonical Espresso chain.

For the second check, the STF needs to verify the Espresso block Merkle proof and compare that against the proven block Merkle tree commitment in the Espresso light client contract on the L1.

The STF must also ensure that no transactions finalized by Espresso are skipped or applied twice.

Arbitrum Nitro integration example

Espresso's integration with the Arbitrum Nitro stack provides an illustration of how Espresso consensus can be verified in an application's STF.

Confirmed transaction data can be obtained from the Espresso DA layer. The query service of Espresso nodes provides a variety of to fetch finalized blocks, namespaces, and transactions.

The first check involves verifying Espresso DA's Savoiardi VID proof. To learn more about our VID scheme refer to our or Appendix A of the .

If the architecture of the rollup mandates that all data is available on a specific DA layer, the integration needs to ensure the necessary data is submitted to that DA layer. In the Espresso-Arbitrum Nitro integration, a (sometimes called Attestation) contains the namespace and block Merkle proofs necessary for validation of Espresso consensus. The justification is submitted to the Nitro parent chain so that it can be used as part of the STF to derive the state of the child chain.

The Espresso-specific validation for the Arbitrum Nitro STF is performed in the replay binary . It calls out to the Rust code to and to .

In the Arbitrum Nitro “Arbitrator” smart contract, added to the Host IO contract are used to read and validate the HotShot/Espresso commitment from the sequencer contract. Due to Nitro’s stateless STF, the integration also adds the corresponding Host IO functionality to supply this external piece of data to the STF when validator and staker nodes execute them locally.

system overview docs. .
espresso-dev-node
namespace ID and payload bytes
submit endpoint
builder
API endpoints
DA documentation
Espresso Paper
Justification
here
verify a namespace
verify the Espresso block Merkle proof
two additional functions