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

Espresso in the Modular Stack

How Espresso can optionally be used for data availability and sequencing

PreviousINTRODUCTIONNextThe Espresso Network

Last updated 6 months ago

The Espresso Network has been designed with modularity in mind. We have seen that developers are best able to innovate when they have flexibility around designing their stack.

Espresso offers several benefits for chain operators and their developers to choose from:

  • Confirmations: All chains that leverage Espresso benefit from fast, reliable —replacing the need for users, bridges, and beyond to depend on preconfirmations that come from centralized sequencers.

  • Data availability: All chains using Espresso also benefit from highly efficient offered by the Espresso Network. However, many of the chains that are using Espresso also choose to leverage another form of DA, such as EigenDA, Celestia, Avail, or Ethereum itself. We have designed Espresso to respect and to be additively compatible with these choices.

  • Decentralized sequencing: Chains integrating Espresso may additionally use it as a decentralized sequencing layer, leveraging the network to determine the order of transactions on the chain. However, this is not required: chains that use their own sovereign sequencers to determine transaction ordering can still benefit from Espresso’s confirmations.

A few examples of how Ethereum rollups can use the Espresso network include:

  • A standard rollup or validium that uses the L1 or an alternative data availability solution, leverages its own centralized sequencer, and settles to Ethereum may leverage Espresso for confirmations.

  • A based rollup that uses Ethereum for DA, relies on the Ethereum proposer for sequencing, and looks to the L1 for settlement may also use Espresso for fast, reliable confirmations.

  • A validium that leverages its own centralized sequencer can use Espresso for data availability and also for more robust confirmations than the preconfirmations that its sequencer could offer.

  • A rollup or validium that wants to decentralize its sequencing without using the L1 proposer may use the Espresso leader as its sequencer for any given round and use Espresso for confirmations – while using its own choice of data availability.

  • A rollup that uses Espresso for DA, sequencing, and confirmations is what we like to call a caffeinated chain.

While we only cover Ethereum rollups here, this also applies to sovereign rollups and beyond.

confirmations
data availability