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. The Espresso Network
  3. Internal Functionality

Espresso Node

PreviousInternal FunctionalityNextLight Client Contract

Last updated 5 months ago

An Espresso node is a participant in the HotShot consensus protocol which also makes available some services to support L2 clients. The Espresso node is L2 agnostic: it does not provide services specifically tailored to any particular L2. It merely exposes all available information about HotShot and the log of blocks which have been sequenced. Any L2 may query this information and interpret the blocks according to its own execution rules in order to implement a prover, executor, RPC service, etc.

The main internal components of the Espresso node and their respective functions are:

  • HotShot node: The component which actually runs consensus and communicates with other nodes.

  • HotShot query service: The query service maintains a database containing the history and current state of HotShot, including all committed blocks and QCs, consensus-specific data like view numbers and stake tables, and status information like validator uptime. It populates this data using events provided by the HotShot validator and provides a REST API for querying the data. There is also a WebSockets-based API which allows clients to subscribe to notifications when new blocks and QCs are produced. The query service does not provide any L2-specific information. The contents of the blocks it provides are the generic transactions that HotShot itself understands.

  • : The Espresso node also provides an interface allowing clients to submit transactions to the HotShot mempool. It takes as input a transaction serialized into bytes and an L2 identifier, and it wraps these into HotShot's generic transaction type.

Submit API
Internal components of an Espresso node and their possible usage by various participants in an L2