Espresso DA
Funds can be lost if
Espresso DA is a three-layer data availability (DA) solution based on the HotShot consensus.
There are no onchain assets at risk of being slashed in case of a data withholding attack. However, there is indirect economic security derived by the committee members being publicly known, and their reputation is at stake should they behave maliciously.
There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer.
The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment. There are 100 operators currently registered in the committee, but entry or exit of members is partially controlled by a centralized entity.
There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
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.
The HotShot Light Client is a data availability bridge using Zero-Knowledge proofs to verify Espresso HotShot data availability attestations on Ethereum.
The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment. There are 100 operators currently registered in the committee, but entry or exit of members is partially controlled by a centralized entity.
There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
Architecture
The Light Client contract serves as the DA bridge for the Espresso DA solution and is responsible for storing the HotShot consensus state on Ethereum.
When HotShot nodes reach consensus, they sign the updated HotShot state using Schnorr signatures, which indicate agreement with the state of the proposed block. These signatures are stored locally on the DA layer nodes.
A prover retrieves these signatures and generates a SNARK proof, which is sent to the LightClient contract’s newFinalizedState function. The LightClient contract verifies this proof using its verifyProof method, which accepts the proof and a set of public inputs, such as the blockHeight and the Merkle root of all sequenced blocks.
The proof should contain the HotShot state, the stake table information, and the list of Schnorr signatures from the HotShot nodes that formed a quorum and reached consensus on the state, and the new state is accepted only if the proof passes verification. Currently, attestations are relayed to the Light Client every 12 hours.
Funds can be lost if the DA bridge accepts an incorrect or malicious data commitment provided by 2/3 of validators.
Funds can be frozen if excluding L2-specific DA fallback - the permissioned relayers are unable to submit DA commitments to the Light Client contract.
The Committee has the following members:
The system consists of the following permissions on Ethereum:
Those are the participants of the EspressoMultisig.
Can change the configuration of HotShotLightClient - can call newFinalizedState() to prove the latest HotShot state.
The system consists of the following smart contracts on Ethereum:
The DA bridge contract that stores and verifies HotShot state commitments on Ethereum.
Upgrade delay: No delay
The current deployment carries some associated risks:
Funds can be lost if the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades.