Using the Espresso Network as an OP Stack chain

OP stack integration with Espresso

Espresso is developing an integration with the OP Stack that allows OP Stack chains to easily integrate with Espresso. The first version of the integration enables Espresso confirmations for OP Stack chains. The integration will later be updated with functionality to enable new forms of sequencing (i.e., decentralized/shared sequencing) and support for Espresso DA.

When the initial version of the Espresso-OP Stack integration is production-ready, OP Stack chains will simply be able to download a Docker image that allows them to deploy onto Espresso (or ask their RaaS provider to do so on their behalf).

Integration overview

The Espresso-OP Stack integration involves ensuring that each batch processed by the rollup is consistent with HotShot-finalized blocks within its namespace. Note that the integration as described on this page is subject to change. Feedback is welcome!

To ensure that the batch has been finalized by HotShot, the following checks are performed:

1. Namespace validation: Ensure that the set of transactions in an OP batch corresponds to the correct namespace. Namespacing allows multiple chains to use Espresso’s fast confirmation layer simultaneously by associating each chain’s transactions with a unique namespace within HotShot blocks.

2. Espresso block Merkle proof check: Confirm that the OP batch maps to a valid HotShot block. Specifically, verify that the HotShot block associated with an OP batch is a valid leaf in the Merkle tree maintained by the light client contract, which stores the state of HotShot on L1.

High-level flow of integration

The flow is as follows:

1. A user submits either a deposit transaction to the L1 or an L2 transaction.

2. The rollup node (op-node, running in sequencer mode) fetches any deposit transactions from L1.

3. The rollup node constructs the payload attributes and sends them to op-geth, which executes them to create blocks.

4. The op-batcher, running in a TEE, queries the blocks and creates batches accordingly.

5. The batcher then submits these batches to HotShot for finalization via the submit API.
6. Periodically, the batcher also calls the availability API to check for finalized HotShot blocks containing these batches and performs batch consistency checks.
7. The batcher signs the transaction calldata that would be sent to the Batch Inbox contract.

8. In the integration, the Batch Inbox address is converted from an EOA to a contract containing only a fallback function. This fallback function receives all transactions sent to the contract and verifies the signature to ensure it originates from the trusted batcher:

No changes are required to the derivation or validation pipelines with this implementation. Only modifications to the batcher and Batch Inbox address, as detailed above, are needed.

This approach involves running an op-batcher in a TEE environment (such as Intel SGX). The batcher signs the transaction calldata. In case the TEE is broken, the batch poster can't impact the safety of the Orbit chain. It could, however, temporarily halt the chain's progress, thereby breaking liveness. Bridges relying on Espresso confirmations for faster settlement however need to trust the TEE as well in this integration. In a future update the dependency on TEEs will be removed entirely.