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:

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

The flow is as follows:

A user submits either a deposit transaction to the L1 or an L2 transaction.
The rollup node (op-node, running in sequencer mode) fetches any deposit transactions from L1.
The rollup node constructs the payload attributes and sends them to op-geth, which executes them to create blocks.
The op-batcher, running in a TEE, queries the blocks and creates batches accordingly.
The batcher then submits these batches to HotShot for finalization via the submit API.
Periodically, the batcher also calls the availability API to check for finalized HotShot blocks containing these batches and performs batch consistency checks.
The batcher computes the hashes of the blobs it intends to submit (Note: OP uses blob transactions), enabling it to sign the combined hash of the blobs before sending the transaction. This signature is added to the transaction’s calldata.
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, retrieves all blob hashes using the blobhash opcode, computes a combined hash of all blob hashes using Keccak256, and reads the signature from the transaction’s calldata. Finally, it verifies the signature to ensure it originates from the trusted batcher:
```
require(verifySignature(combinedHash, signature), "Invalid batcher signature.");
```

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 combined hash of blob hashes and adds this signature to the L1 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.

PreviousUsing the Espresso Network as a Cartesi application NextUsing the Espresso Network as a Polygon CDK chain

Last updated 1 month ago

Integration overview

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

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.

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.

The flow is as follows:

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

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

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

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

The batcher then submits these batches to HotShot for finalization via the submit API.

Periodically, the batcher also calls the availability API to check for finalized HotShot blocks containing these batches and performs batch consistency checks.

The batcher computes the hashes of the blobs it intends to submit (Note: OP uses blob transactions), enabling it to sign the combined hash of the blobs before sending the transaction. This signature is added to the transaction’s calldata.

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, retrieves all blob hashes using the blobhash opcode, computes a combined hash of all blob hashes using Keccak256, and reads the signature from the transaction’s calldata. Finally, it verifies the signature to ensure it originates from the trusted batcher:

require(verifySignature(combinedHash, signature), "Invalid batcher signature.");

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.