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. Guides
  2. Using the Espresso Network

Using the Espresso Network as a Cartesi application

Cartesi integration with Espresso

PreviousLocal Deployment (`docker compose`)NextRunning an Espresso Node

Last updated 6 months ago

The team has built an integration that enables Cartesi applications to use Espresso for fast confirmations, low-cost DA, and decentralized sequencing. The integration is fully functional, but it is brand new and is still undergoing review, and should therefore be used with caution. Developers interested in deploying their own Cartesi application using Espresso should get in touch with the Cartesi team via their , where they can find a dedicated to the Espresso integration.

Integration overview

The integration enables Cartesi applications to configure their source of transactions to be their specific namespace in the Espresso Network.

Overview of a Cartesi application using Espresso

The integration is based on the concept that inputs to Cartesi dApps are of two fundamentally different natures:

  • L2 transactions: these refer to common interactions of users with the application, and refer to application-specific actions such as “swap token”, “post message”, “attack goblin”, etc.; these transactions do not require any direct information or logic from the base layer (i.e., the L1);

  • L1 -> L2 messages: these refer to information that is relayed from the base layer to the rollup application, such as informing about deposits done via the Portals, relaying the dApp’s address, ensuring base layer validation for a given input, etc.

This integration proposes that L2 transactions are to be processed “immediately” (i.e., as soon as they are sequenced), whereas L1 -> L2 messages are only processed when they are finalized on L1, meaning that they are processed “with a delay”.

Aside from that, from the application’s point of view, few things change:

  • Back-end: both L2 transactions and L1 -> L2 messages are received as regular inputs;

  • Front-end: L2 transactions are signed by the client and submitted to an L2 submission endpoint on the node, which will then forward them to Espresso; L1 -> L2 messages are submitted exactly in the same way as current regular Cartesi rollup inputs (i.e., as a transaction that eventually calls the InputBox contract’s addInput method).

Cartesi
Discord
channel