Search
K

How It Works

A step-by-step guide on the data availability process

Overview

The data availability process initiates with users submitting transactions to the Espresso Sequencer. Each view, a block proposer is selected within HotShot who bundles these transactions into a block. Rather than sending the full block data to other HotShot nodes, the block proposer only sends a commitment to the block for other nodes to vote on. All HotShot nodes also participate as storage nodes in the VID protocol and receive a small chunk representing their VID share of the respective block. The DA leader sends a DA proposal to the randomly sampled DA committee and all HotShot nodes. After receiving enough votes from the DA committee and the nodes in the network, the DA leader constructs a data availability certificate (DAC).
The DAC is composed of an optimistic DAC obtained from the DA committee and a retrievability certificate from the VID protocol. The optimistic DAC certifies that the proposed data is available to a quorum of the DA committee. The retrievability certificate in turn certifies that VID chunks are available to a quorum of nodes. The DAC design thus enables the best of both worlds, fast DA through DA committees, and robustness through VID. By combining the block commitment with the DAC, the Espresso Sequencer ensures that blocks will only finalized data is guaranteed to be available.
Exhibit A: DA and Rollup Architecture

Process Steps

Step 1: The DA leader begins a broadcast to ensure data is available for all nodes in the network that consists of:
  • Sending the DA proposal to the DA committee.
  • Sending the VID chunks to all replicas/nodes.
  • Gradually sending the DA proposal to all replicas/nodes. Broadcasting proceeds concurrently, prioritized by order of initialization.
A DA proposal will be rejected in either of the following cases:
  • The view number is earlier than the view corresponding to the latest valid quorum certificate (QC).
  • The proposal is not from the correct leader.
Step 2: Nodes receive the DA proposal (and/or VID share) and submit the data availability vote.
Anyone who receives and approves the DA proposal sends a strong DA vote to the DA leader, while anyone who only receives the VID share sends a normal DA vote.
Step 3: The DAC is formed.
The DAC is formed with the creation of the retrievability certificate and optimistic DAC certificate.
The retrievability certificate can be formed by:
  • The DA leader receives f + 1 strong votes, which may come from nodes on the committee or just regular nodes who happened to receive the DA proposal quickly enough. f = number of faulty nodes (nodes not performing correct function) in the entire network.
  • f + m normal votes, where m is the number of VID shares the block was split into.
The optimistic DAC can be formed in the following way:
1. The DA leader receives 2f + 1 strong votes from the DA committee (where, unlike above, f is the number faulty nodes in the committee, not in the entire network)
The DA leader stops broadcasting to the nodes after the DAC is formed, or when the quorum certificate from the next leader is received.
Step 4: The block commitment proposal is sent to replicas/nodes. The block commitment is a a cryptographic proof that a block is valid and has guaranteed DA.
The leader, once getting sufficient quorum votes for the previous view and the DAC is obtained, sends the commitment proposal. A block can only be applied to a chain if consensus on the commitment proposal is reached by HotShot consensus nodes. The leader also sends the QC to the next leader if one can be constructed.
Step 5: The HotShot nodes validate the commitment proposal.
The replicas/nodes validate the commitment proposal if either of the following set is received:
  • Commitment proposal and the DAC.
  • Commitment proposal and DA proposal, which is simply a block and the view number proposed
The node will send a quorum vote to the next consensus leader once the commitment proposal is validated. As long as over 2/3 of HotShot stake is honest, it is impossible for an adversary, even if bribing the DA committee, to forge a DAC. Utilizing the randomly elected DA committee alongside VID thus enables fast and secure DA.
Exhibit B: DA Process Overview

Implementation Options

We encourage L2s interested in working with the Espresso DA to reach out to us directly for customized integration options.
The Espresso DA is optimally implemented with the shared and decentralized Espresso sequencer. This is the recommended solution since the DA layer runs in an open and dynamic network with the interoperability benefits of shared sequencers.