Using the Espresso Network as an Arbitrum Orbit chain
Arbitrum integration with Espresso
Last updated
Arbitrum integration with Espresso
Last updated
Espresso is developing an integration with the Arbitrum Nitro tech stack that allows Arbitrum Orbit chains to easily integrate with Espresso. The first version of this integration enables Espresso confirmations for Orbit 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.
The first production release of the Espresso-Arbitrum Nitro integration is planned for January 2025, at which point Arbitrum Orbit 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).
This integration makes minimal changes to the Arbitrum Nitro stack, and ensures that each batch processed by the rollup is consistent with HotShot-finalized blocks within its namespace.
To ensure that the batch has been finalized by HotShot, the following checks are performed:
Namespace validation: Ensure that the set of transactions in a rollup's 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 rollup's batch maps to a valid HotShot block. Specifically, verify that the HotShot block associated with a rollup batch is a valid leaf in the Merkle tree maintained by the light client contract, which stores the state of HotShot on L1.
The sequencer calls WriteSequencerMsg on the transaction streamer.
The batcher fetches the message from the transaction streamer and submits the transaction to HotShot via the transaction streamer. Code for this is implemented in the batcher here.
The batcher then calls the query API to check if the transaction has been finalized by HotShot. This code can be found here.
Once the transaction is finalized, the batcher performs batch consistency checks.
The batcher computes the hashes of the blobs it intends to submit. (Note: Arbitrum uses blob transactions.) This enables the batcher to sign the combined hash of the blobs before sending the transaction, adding this signature to the transaction’s calldata.
The Sequencer Inbox contract is modified to verify the batcher’s signature on the blob hashes in this function. It will retrieve all blob hashes using the blobhash opcode, compute a combined hash of all blob hashes using Keccak256, and read the signature from the transaction’s calldata. Finally, it verifies the signature to confirm that it originated from the trusted batcher.
This approach involves running a Nitro node with only the batcher enabled, operating in a TEE environment (such as Intel SGX). The batcher will sign the combined hash of blob hashes and add 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 need to trust the TEE as well in this integration. In a future update, the dependency on TEEs will be removed entirely.
The code for the previous Arbitrum integration that ran on our past testnets is also available. Interested parties can read the instructions linked below to use the code related to this integration, though it should be stressed that this code is not production-ready.
The codebase of the old Arbitrum Nitro integration is not audited and not production-ready, and should be used at your own risk. For further instructions visit this webpage.
