Espresso DA

Architecture

ConsensusAn agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating nodes with consensus rules, rollups rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon.

Espresso uses the HotShot consensus protocol, a communication-efficient proof-of-stake system that is Byzantine Fault Tolerant (BFT). The validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set is permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants.: anyone can stake ESP tokens and the top 100 validators by total stake form the active consensus set, which is dynamically adjusted at epoch boundaries. Built on HotStuff-2, it achieves linear communication complexity using a pacemaker module to synchronize views and ensures safety and livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. as long as over two-thirds of the stake is controlled by honest nodes. Although validators are required to stake ESP to participate, there is currently no slashing mechanism in place for misbehaving nodes.

HotShot operates in a view-by-view manner, where each view designates a leader and an external builder. During a view, the consensus proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. finalizes a blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. with a certificate of availability by utilizing Espresso DA for data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium..

Data Availability Certificate

Once the proposer sends data to HotShot nodeA software client that participates in the network. 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 networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. (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 L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. Light ClientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. contract, which verifies the certificate and the HotShot state SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. 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 blobThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.’s inclusion in the Espresso DA HotShot chain.

Architecture

The TEE BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. leverages Trusted Execution Environments (TEEs) to provide hardware-based attestations for data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium.. 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 sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. provides soft-confirmations while simultaneously sending transactions to the Espresso NetworkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. for stronger BFT consensusAn agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating nodes with consensus rules, rollups rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon.-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 hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1. mechanism is enabled).

3. Batch Consistency Verification: Before posting to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., 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 blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. in the Merkle treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs. maintained by the light clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. contract

4. Signature Generation: The batcher computes blobThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. hashes and signs the combined hashA fixed-length fingerprint of variable-size input, produced by a hash function. 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 nodeA software client that participates in the network. 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 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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 livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. 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.