Espresso DA

Architecture

Consensus

Currently only a fixed set of pre-registered operators can run a node. The Espresso Network will upgrade to proof-of-stake in a later release.

Espresso uses the HotShot consensus protocol, a communication-efficient proof-of-stake system that is Byzantine Fault Tolerant (BFT). The protocol is currently permissioned, with a fixed set of 100 nodes participating in consensus. Built on HotStuff-2, it achieves linear communication complexity using a pacemaker module to synchronize views and ensures safety and liveness as long as over two-thirds of the stake is controlled by honest nodes.

HotShot operates in a view-by-view manner, where each view designates a leader and an external builder. During a view, the consensus proposer finalizes a block with a certificate of availability by utilizing Espresso DA for data availability.

Data Availability Certificate

Once the proposer sends data to HotShot node operators, they initiate Espresso DA’s three layers of data availability:

• VID Layer: Disperses erasure-coded data to all nodes. VID layer nodes only store chunks of the data.
• DA Committee Layer: Uploads the data and commitment to a small DA committee. Every node in the committee stores the full data.
• CDN Layer: Uploads the full data to a content delivery network (CDN).

Once nodes receive and store the data, they return votes to the proposer. DAVotes are votes from committee nodes storing the full data, while QuorumVotes are votes from nodes storing erasure-coded shares of the data. A DA certificate consists of two components, the retrievability certificate and the optimistic DAC certificate:

• Retrievability Certificate: Formed when the DA leader collects 2/3 + 1 QuorumVotes.
• Optimistic DAC Certificate: Formed when the DA leader gathers 2/3 + 1 DAVotes from the DA committee. Currently, the committee size is 21 members, so the threshold is 15 signatures.

Once the DAC is formed, the DA leader stops broadcasting data to the nodes.

L2s Data Availability

The life cycle of L2 transactions begins with users submitting transactions to the Espresso DA mempool through an RPC endpoint, or directly to the block builder private mempool, including a namespace ID to indicate the target L2 rollup. A DA leader collects and disperses these transactions across Espresso DA’s layers to form a DA certificate. The leader then broadcasts a proposal with a vector commitment for the transactions to the HotShot consensus layer. The finalization of the block commitment in HotShot establishes data availability for the corresponding transactions. After block finalization in HotShot, the relayer propagates the commitment and quorum certificates to the L1 Light Client contract, which verifies the certificate and the HotShot state SNARK proof via the verifyProof function.

Users can retrieve data by querying any of Espresso DA’s layers, though the VID layer is slower due to the reconstruction of erasure-coded shares. L2s can also use a verifyInclusion function on an L1 light client smart contract to confirm a blob’s inclusion in the Espresso DA HotShot chain.

Architecture

The TEE Bridge leverages Trusted Execution Environments (TEEs) to provide hardware-based attestations for data availability. TEEs create secure, isolated environments where data availability proofs can be generated and verified with cryptographic guarantees.

Arbitrum Nitro Integration

The primary implementation runs the Arbitrum Nitro batch poster (batcher) inside a TEE environment, specifically Intel SGX. The integration process involves:

1. Transaction Flow: The sequencer provides soft-confirmations while simultaneously sending transactions to the Espresso Network for stronger BFT consensus-backed confirmations.

2. TEE Batch Poster: The batcher operates within the TEE and must honor Espresso Network confirmations. It cannot reorder transactions or equivocate, providing strong guarantees that transactions will be included and finalized (unless the escape hatch mechanism is enabled).

3. Batch Consistency Verification: Before posting to L1, the TEE batcher performs two critical checks:

   • Namespace Validation: Ensures transactions correspond to the correct Arbitrum Nitro/Orbit chain namespace
   • Merkle Proof Verification: Confirms the batch maps to a valid HotShot block in the Merkle tree maintained by the light client contract

4. Signature Generation: The batcher computes blob hashes and signs the combined hash along with calldata, including this signature in the L1 transaction for on-chain verification.

The TEE-based approach provides accountability for sequencers while maintaining the existing Arbitrum Nitro rollup design with minimal changes.

Security Considerations

TEE-based systems face unique security challenges that differ from traditional cryptographic approaches:

Remote Attestation: The bridge relies on Intel’s Attestation Service (IAS) to verify that TEE nodes are running legitimate software on genuine hardware with up-to-date security patches. This creates a dependency on Intel’s centralized infrastructure.

TCB Recovery: When new TEE vulnerabilities are discovered (such as AepicLeak or the WireTap attack), the system must implement Trusted Computing Base (TCB) recovery procedures to block compromised nodes from joining the network before Intel updates their attestation requirements. Research has shown that many applications fail to take appropriate action after TCB recovery announcements, often not implementing necessary security updates or node blocking mechanisms in a timely manner. Physical Hardware Attacks: Recent research has demonstrated that SGX attestation keys can be extracted through physical DRAM bus interposition attacks using relatively inexpensive equipment (under $1000). The WireTap attack shows how attackers can build devices to physically inspect memory traffic and exploit deterministic encryption in Intel’s Total Memory Encryption to recover SGX secret attestation keys. This allows attackers to forge SGX attestation quotes.

Key Management: The bridge uses on-chain key registration and verification rather than relying solely on TEE sealing mechanisms. TEE attestation keys are registered on-chain through verifier contracts that track valid MRENCLAVE hashes, MRSIGNER values, and authorized signers. This provides transparency and governance control over which TEE configurations are trusted, eliminating the “developer key backdoor” risk present in systems that rely purely on MRSIGNER-based sealing. However, initial key registration still requires Intel’s remote attestation to verify TEE authenticity. Governance and TCB Recovery: TEE-based bridges face unique governance challenges around TEE configuration management and vulnerability response. The on-chain verifier contracts allow governance to manage valid MRENCLAVE hashes and authorized signers, providing transparency and control over trusted TEE configurations. However, compromised TEE keys can sign false availability attestations during the time window before governance can detect and revoke them. When new TEE vulnerabilities are discovered, governance must coordinate extremely rapid responses to revoke compromised configurations before they can be exploited to attest to unavailable data.

Implementation Details

TEE Environment: The implementation uses Intel SGX with Gramine LibOS for stability and maturity. Remote Attestation is supported through RA-TLS certificates that embed SGX attestation reports, allowing anyone to verify the TEE’s integrity.

Escape Hatch Mechanism: The batch poster includes a liveness check mechanism that calls IsHotshotLive on the Light Client Contract before posting batches. Operators can configure two behaviors: (1) wait for HotShot to be live before posting, or (2) proceed without HotShot consistency checks if the network is unavailable, effectively bypassing Espresso consensus validation. This flexibility prevents the bridge from becoming permanently stuck while maintaining security when possible.