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
    • 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. Appendix

Interacting with L1

PreviousAmericano Testnet ReleaseNextTrustless Sync

Last updated 5 months ago

Espresso is intended primarily for use with rollups, and an essential feature of rollups is that they periodically send verified checkpoints of their state to some other blockchain, the layer 1. In the case of Espresso we have two types of checkpoints:

  • HotShot checkpoints record the history and state of HotShot. This includes commitments to all blocks that have been sequenced and the state that is needed to verify new blocks (such as the stake table) starting from the latest checkpoint. These checkpoints are recorded in the sequencer contract and shared by all applications using Espresso.

  • Rollup checkpoints record the state of individual rollups, such as the state of an EVM instance. Each rollup records its own checkpoints in its rollup contract. When recording a new checkpoint, the rollup contract will validate the checkpoint against the committed sequence of blocks by reading the historical sequence of block commitments from a corresponding HotShot checkpoint.

Many rollups will not only write their state to the L1, but will also allow information from the L1 to flow back into the rollup. In this case, the interaction with the rollup contract becomes a between the L1 and the rollup, allowing tokens and other information to be exchanged bidirectionally.

Espresso is interesting in that HotShot itself also allows this bidirectional flow of information to and from the L1, specifically regarding the stake table. This allows operations on the L1 to interact with the Espresso staking token, a crucial requirement for implementing restaking, which allows Espresso to share the security budget of the L1 and pass value generated by the sequencer back to L1 validators.

Since state updates are not only written to the L1 but also read back into the HotShot and rollup states, we will hereafter eschew the "checkpoint" terminology and instead refer to HotShot state updates and rollup state updates.

The following sections dive into the use cases for these state updates and explore some of the utility and security properties that L2s are able to derive from the L1 that they use for state updates.

bridge