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
  • VID Layer
  • DA Committee Layer
  • CDN Layer
  1. LEARN
  2. The Espresso Network
  3. Properties of HotShot

EspressoDA

PreviousProperties of HotShotNextHow It Works

Last updated 4 months ago

For a detailed technical overview of EspressoDA, see .

Data availability is the requirement that all transaction data included in blocks is available to every node participating in consensus before a decision can be reached. Because the amount of data can be quite large, requiring each node to download and verify the data before reaching consensus presents a fundamental bottleneck in the throughput of consensus protocols (i.e., the ).

EspressoDA resolves this bottleneck while ensuring data availability via a three-layer system we've designed to balance performance and security:

  • VID Layer: Stores erasure-coded data chunks across all nodes.

  • DA Committee Layer: A small committee stores the full data and guarantees efficient recovery of data.

  • CDN Layer: Uploads full data for retrieval efficiency.

VID Layer

EspressoDA eliminates the need for each storage node to download all block data by using (VID), a technique that encodes block data into erasure-coded chunks, which are disseminated among s in a way that recoverability is ensured. Nodes only need to store their chunk rather than the entire block. This method is more efficient than data availability sampling (DAS) as it limits unnecessary redundancies.

By using VID, EspressoDA guarantees a block will only be finalized if data is verified to be available.

DA Committee Layer

A small DA committee, selected from the network's nodes, receives the entire data blob and allows for very fast data retrievability, with the VID protocol acting as a fallback in case the DA committee fails to make data available.

EspressoDA ensures data is made available for rollups (optimistically by the DA committee, and guaranteed through VID) without incurring the high costs of posting transactions to the Ethereum L1 (though rollups may still choose to do so). It also avoids centralized DA solutions, which allow the DA operators to freeze the rollup and censor its users.

CDN Layer

We provide EspressoDA with web2-level performance by using a content delivery network (CDN) to quickly share a block’s data to many different nodes. It can massively accelerate data dissemination. from our Cappuccino testnet show a data dissemination of around 5.7 MB/s with 100 nodes. The CDN can also help with efficient recovery of subsets of the data, such as single transactions.

Importantly, the CDN is not trusted for security and thus doesn’t present a single point of failure. EspressoDA works perfectly fine without the CDN, which is only helpful for accelerating the DA and can easily be replaced or removed.

EspressoDA: Our Three-Layered DA Solution
data availability problem
Verifiable Information Dispersal
Benchmarks