DA Nodes

In HyveDA, DA Nodes are responsible for storing and retrieving data sent to the network by Clients. These nodes adhere to protocol rules, ensuring data availability when operating correctly. Together, all nodes form the Data Availability Committee, which operates in a completely permissionless manner. Each DA Node is an operator that has staked ETH to its node, which is subject to slashing if the node becomes faulty or malicious.

In this document, we'll explore the architecture of a DA Node, how it receives and processes work, and how it can be slashed.

Architecture

The architecture of a DA Node, while heavily optimized, is not overly complex.

The first step for a DA Node is to receive shreds (discussed earlier in the client section) over a P2P network. Since not all DA nodes need to process all chunks of a blob, a deterministic method is used to properly assign chunks.

Assignment of work

At the start of each epoch, all nodes in the Data Availability Committee are shuffled. This process results in a list of nodes and their indices within the committee. Each DA Node stores only the shreds that have an index matching its own. By using a deterministic random function on-chain, we mitigate attack vectors associated with static lists. Additionally, there is no need to order the chunks beforehand, as each node knows which indices it should process and can verify the chunk's index.

Verification and Storage

The shred's index can be verified through its KZG commitment. Recall that the erasure-encoded chunks are generated by evaluating the polynomial at various points, each corresponding to a specific index (x_i) and evaluation (f(x_i)). The shred includes the KZG polynomial commitment, allowing us to verify that the polynomial's evaluation at index (i) results in the erasure-encoded chunk provided in the shred.

If the index matches the node's index and is accurate, the node proceeds to further verify the shred. This verification involves using the KZG Commitment and KZG Proof to confirm that the received erasure-encoded chunk is indeed part of the original blob, using an elliptic pairing function. The node also verifies the blob's KZG proof to ensure the blob is valid in its entirety. Additionally, the verification stage in the DA Nodes will check the signature.

After verification, the chunk and its metadata are stored in a simple key-value storage database. This step is crucial because HyveDA's slashing rules include conditions related to data retrieval. A retriever, which functions as a virtual node, can be used by the DA Node to retrieve data from the KV-store. This retriever can be individually scaled during network congestion but remains associated with the DA Node operator in the case of slashing events.

Since chunks do not affect each other, multiple verification and storage requests can be processed by the DA Node in parallel.

Attestation

After the shreds have been verified and stored, the DA Node creates a data availability attestation. Currently, the attestation is signed using the BLS12-381 signature scheme, allowing for easy aggregation. The attestation consists of the following data structure:

{
    "aggregation_bits": "Bitlist[MAX_DA_NODES_PER_COMMITTEE]",
    "data": "Bytes",
    "signature": "BLSSignature"
}

Broadcasting

The attestation must be aggregated with those from other DA Nodes to reach a quorum for each blob. This quorum ultimately confirms that the data was indeed available. To achieve this, the attestation is sent to the collector, which is currently a trusted entity that aggregates the signatures and combines them into a DAC Certificate.

Delegated Stake & Slashing

DA Nodes in HyveDA are operated by Operators registered on the Symbiotic restaking protocol. This means that HyveDA will utilize a NetworkMiddleware on Symbiotic and require DA Nodes to be registered on OperatorRegistry. Additionally, operators must have a stake delegated to them from a Vault. Since a single operator cannot attest to more than one index per blob, each individual node should have a unique operator assigned to it. At the genesis of HyveDA, only ETH will be allowed as a collateral token from multiple external vaults, along with a HyveDA vault deployed for permissionless operator participation.

More information regarding the on-chain architecture of HyveDA on Symbiotic will be shared soon.

The nodes are also subject to slashing conditions enforced by Symbiotic's sophisticated slashing modules. The exact rules for slashing can be found here.