EigenDA

EigenDA is a Data Availability (DA) service, implemented as an actively validated service (AVS) on EigenLayer, that provides secure and scalable DA for L2s on Ethereum.

What is DA?

In informal terms, DA is a guarantee that a given piece of data will be available to anyone who wishes to retrieve it.

A DA system accepts blobs of data (via some interface) and then makes them available to retrievers (through another interface).

Two important aspects of a DA system are

1. Security: The security of a DA system constitutes the set of conditions which are sufficient to ensure that all data blobs certified by the system as available are indeed available for honest retrievers to download.
2. Throughput: The throughput of a DA system is the rate at which the system is able to accept blobs of data, typically measured in bytes/second.

An EigenLayer AVS for DA

EigenDA is implemented as an actively validated service on EigenLayer, which is a restaking protocol for Ethereum.

Because of this, EigenDA makes use of the EigenLayer state, which is stored on Ethereum, for consensus about the state of operators and as a callback for consensus about the availability of data. This means that EigenDA can be simpler in implementation than many existing DA solutions: EigenDA doesn't need to build it's own chain or consensus protocol; it rides on the back of Ethereum.

A first of its kind, horizontally scalable DA solution

Among extant DA solutions, EigenDA takes an approach to scalability which is unique in that it yields true horizontal scalability: Every additional unit of capacity contributed by an operator can increase the total system capacity.

This property is achieved by using a Reed Solomon erasure encoding scheme to shard the blob data across the DA nodes. While other systems such as Celestia and Danksharding (planned) also make use of Reed Solomon encoding, they do so only for the purpose of supporting certain observability properties of Data Availability Sampling (DAS) by light nodes. On the other hand, all incentivized/full nodes of the system download, store, and serve the full system bandwidth.

Horizontal scalability provides the promise for the technological bottlenecks of DA capacity to continually track demand, which has enormous implications for Layer 2 ecosystems.

Security Model

EigenDA produces a DA attestation which asserts that a given blob or collection of blobs is available. Attestations are anchored to one or more "Quorums," each of which defines a set of EigenLayer stakers which underwrite the security of the attestation. Quorums should be considered as redundant: Each quorum linked to an attestation provides an independent guarantee of availability as if the other quorums did not exist.

Each attestation is characterized by safety and liveness tolerances:

• Liveness tolerance: Conditions under which the system will produce an availability attestation.
• Safety tolerance: Conditions under which an availability attestation implies that data is indeed available.

EigenDA defines two properties of each blob attestation which relate to its liveness and safety tolerance:

• Liveness threshold: The liveness threshold defines the minimum percentage of stake which an attacker must control in order to mount a liveness attack on the system.
• Safety threshold: The safety threshold defines the total percentage of stake which an attacker must control in order to mount a first-order safety attack on the system.

The term "first-order attack" alludes to the fact that exceeding the safety threshold may represent only a contingency rather than an actual safety failure due to the presence of recovery mechanisms that would apply during such a contingency. Discussion of such mechanisms is outside of the scope of the current documentation.

Safety thresholds can translate directly into cryptoeconomic safety properties for quorums consisting of tokens which experience toxicity in the event of publicly observable attacks by a large coalition of token holders. This and other discussions of cryptoeconomic security are also beyond the scope of this technical documentation. We restrict the discussion to illustrating how the protocol preserves the given safety and liveness thresholds.

EigenDA Protocol

Broken down into 2 main sections.

Core Services

EigenDA Protocol consists of a suite of services that allow for data to be securely stored and retrieved from the validators.

Contracts

System Architecture

Core Components

• DA nodes are the service providers of EigenDA, storing chunks of blob data for a predefined time period and serving these chunks upon request.
• The disperser is responsible for encoding blobs, distributing them to the DA nodes, and aggregating their digital signatures into a DA attestation. As the disperser is currently centralized, it is trusted for system liveness; the disperser will be decentralized over time.
• The disperser and the DA nodes both depend on the Ethereum L1 for shared state about the DA node registration and stake delegation. The L1 is also currently used to bridge DA attestations to L2 end-user applications such as rollup chains.

Essential flows

Dispersal. The is the flow by which data is made available and consists of the following steps:

1. The Disperser receives a collection of blobs, [encodes them], constructs a batch of encoded blobs and headers, and sends the sharded batch to the DA nodes.
2. The DA nodes validate their shares of the batch, and return an attestation consisting of a BLS signature of the batch header.
3. The disperser collects the attestations from the DA nodes and aggregates them into a single aggregate attestation.

Bridging. For a DA attestation to be consumed by the L2 end-user (e.g. a rollup), the it must be bridged to a chain from which the L2 can read. This might simply be the Ethereum L1 itself, but in many cases it is more economical to bridge directly into the L2 since this drastically decreases signature verification costs. For the time being all attestations are bridged to the L1 by the disperser.

Retrieval. Interested parties such as rollup challengers that want to obtain rollup blob data can retrieve a blob by downloading the encoded chunks from the DA nodes and decoding them. The blob lookup information contained in the request is obtained from the bridged attestation to the DA nodes.

Protocol Overview

For expositional purposes, we will divide the protocol into two conceptual layers:

• Attestation Layer: Modules to ensure that whenever a DA attestation is accepted by an end-user (e.g. a rollup), then the data is indeed available. More specifically, the attestation layer ensures that the system observes the safety and liveness tolerances defined in the Security Model section.
• Network Layer: The communications protocol which ensures that the liveness and safety of the protocol are robust against network-level events and threats.

Attestation Layer

The attest layer is responsible for ensuring that when the network-level assumptions and safety and liveness tolerances are observed, the system properly makes data available.

The primary responsibility of the attestation layer is to enable consensus about whether a given blob of data is fully within the custody of a set of honest nodes. (Here, what can be taken to be a set of honest nodes is defined by the system safety tolerance and the assurance that these honest nodes will be able to transmit the data to honest retrievers is handled by the network layer.) Since EigenDA is an EigenLayer AVS it does not need its own actual consensus protocol, but can instead piggy-back off of Ethereum's consensus. As a result, the attestation layer decomposes into two fairly straightforward pieces:

• Attestation Logic: The attestation logic allows us to answer the question of whether a given blob is available, given both a DA attestation and the validator state at the associated Ethereum block. The attestation logic can be understood as simply a function of these inputs which outputs yes or no, depending on whether these inputs imply that data is available. Naturally, this function is grounded upon assumptions about the behavior of honest nodes, which must perform certain validation actions as part of the attestation layer. The attestation logic further decomposes into two major modules:
  • Encoding: The encoding module defines a procedure for blobs to be encoded in such a way that their successful reconstruction can be guaranteed given a large enough collection of unique encoded chunks. The procedure also allows for the chunks to be trustlessly verified against a blob commitment so that the disperser cannot violate the protocol.
  • Assignment: The assignment module provides a deterministic mapping from validator state to an allocation of encoded chunks to DA nodes. The mapping is designed to uphold safety and liveness properties with minimal data-inefficiency.
• Bridging: Bridging describes how the attestation is bridged to the consumer protocol, such as that of the rollup. In principle, bridging can be performed in one of several different ways in order to optimize efficiency and composability. At the moment, only bridging via the Ethereum L1 is directly supported.

The desired behavior of the attestation logic can be formally described as follows (Ignore this if you're happy with the high level ideas): Let \(\alpha\) denote the safety threshold, i.e. the maximum proportion of adversarial stake that the system is able to tolerate. Likewise, let \(\beta\) represent the amount of stake that we require to be held by the signing operators in order to accept an attestation, i.e. one minus the liveness threshold. Also, let \(O\) denote the set of EigenDA operators.

We need to guarantee that any set of signing operators \(U_q \subseteq O\) such that

$$ \sum_{i \in U_q} S_i \ge \beta \sum_{i \in O}S_i$$

and any set of adversarial operators $U_a \subseteq U_q$ such

$$ \sum_{i \in U_a} S_i \le \alpha \sum_{i \in O}S_i$$

we can reconstruct the original data blob from the chunks held by \( U_q \setminus U_a \).

Encoding Module

The encoding module defines a procedure for blobs to be encoded in such a way that their successful reconstruction can be guaranteed given a large enough collection of unique encoded chunks. The procedure also allows for the chunks to be trustlessly verified against a blob commitment so that the disperser cannot violate the protocol.

Assignment Module

The assignment module is nothing more than a rule which takes in the Ethereum chain state and outputs an allocation of chunks to DA operators.

Signature verification and bridging

Bridging module

Network Layer

This section is under construction.

Encoding Module

The encoding module defines a procedure for blobs to be encoded in such a way that their successful reconstruction can be guaranteed given a large enough collection of unique encoded chunks. The procedure also allows for the chunks to be trustlessly verified against a blob commitment so that the disperser cannot violate the protocol.

One way to think of the encoding module is that it must satisfy the following security requirements:

1. Adversarial tolerance for DA nodes: We need to have tolerance to arbitrary adversarial behavior by any number of DA nodes up to some threshold. Note that while simple sharding approaches such as duplicating slices of the blob data have good tolerance to random node dropout, they have poor tolerance to worst-case adversarial behavior.
2. Adversarial tolerance for disperser: We do not want to put trust assumptions on the encoder or rely on fraud proofs to detect if an encoding is done incorrectly.

Trustless Encoding via KZG and Reed-Solomon

EigenDA uses a combination of Reed-Solomon (RS) erasure coding and KZG polynomial commitments to perform trustless encoding. In this section, we provide a high level overview of how the EigenDA encoding module works and how it achieves these properties.

Reed Solomon Encoding

Basic RS encoding is used to achieve the first requirement of Adversarial tolerance for DA nodes. This looks like the following:

1. The blob data is represented as a string of symbols, where each symbol is elements in a certain finite field. The number of symbols is called the BlobLength
2. These symbols are interpreted as the coefficients of a BlobLength-1 degree polynomial.
3. This polynomial is evaluated at NumChunks*ChunkLength distinct indices.
4. Chunks are constructed, where each chunk consists of the polynomial evaluations at ChunkLength distinct indices.

Notice that given any number of chunks $M$ such that $M \times$ChunkLength >= BlobLength, via polynomial interpolation it is possible to reconstruct the original polynomial, and therefore its coefficients which represent the original blob.

Validation via KZG

To address the requirement Adversarial tolerance for disperser using RS encoding alone requires fraud proofs: a challenger must download all of the encoded chunks and check that they lie on a polynomial corresponding to the blob commitment.

To avoid the need for fraud proofs, EigenDA follows the trail blazed by the Ethereum DA sharding roadmap in using KZG polynomial commitments.

Chunk Validation

Blobs sent to EigenDA are identified by their KZG commitment (which can be calculated by the disperser and easily validated by the rollup sequencer). When the disperser generates the encoded blob chunks, it also generates a collection of opening proofs which the DA nodes can use to trustlessly verify that their chunks fall on the blob polynomial at the correct indices (note: the indices are jointly derived by the disperser and DA nodes from the chain state using the logic in the Assignment module to ensure that the evaluation indices for each node are unique).

Blob Size Verification KZG commitments also can be used to verify the degree of the original polynomial, which in turn corresponds to the size of the original blob. Having a trustlessly verifiable upper bound on the size of the blob is necessary for DA nodes to verify the correctness of the chunk assignment defined by the assignment module.

The KZG commitment relies on a structured reference string (SRS) containing a generator point $G$ multiplied by all of the powers of some secret field element $\tau$, up to some maximum power $n$. This means that it is not possible to use this SRS to commit to a polynomial of degree greater than $n$. A consequence of this is that if $p(x)$ is a polynomial of degree greater than $m$, it will not be possible to commit to the polynomial $x^{n-m}p(x)$. A "valid" commitment to the polynomial $x^{n-m}p(x)$ thus constitutes a proof that the polynomial $p(x)$ is of degree less than or equal to $m$.

In practice, this looks like the following:

1. If the disperser wishes to claim that the polynomial $p(x)$ is of degree less than or equal to $m$, they must provide along with the commitment $C_1$ to $p$, a commitment $C_2$ to $q(x) = x^{n-m}p(x)$.
2. The verifier then performs the pairing check $e(C_1,[x^{n-m}]_2) = e(C_2,H)$, where $H$ is the G2 generator and $[x^{n-m}]_2$ is the $n-m$'th power of tau. This pairing will only evaluate correctly when $C_2$ was constructed as described above and $deg(p) <= m$.

Note: The blob length verification here allows for the blob length to be upper-bounded; it cannot be used to prove the exact blob length.

Prover Optimizations

EigenDA makes use of the results of Fast Amortized Kate Proofs, developed for Ethereum's sharding roadmap, to reduce the computational complexity for proof generation.

See the full discussion

Verifier Optimizations

Without any optimizations, the KZG verification complexity can lead to a computational bottleneck for the DA nodes. Fortunately, the Universal Verification Equation developed for Danksharding data availability sampling dramatically reduces the complexity. EigenDA has implemented this optimization to eliminate this bottleneck for the DA nodes.

Amortized KZG Prover Backend

It is important that the encoding and commitment tasks are able to be performed in seconds and that the dominating complexity of the computation is nearly linear in the degree of the polynomial. This is done using algorithms based on the Fast Fourier Transform (FFT).

This document describes how the KZG-FFT encoder backend implements the Encode(data [][]byte, params EncodingParams) (BlobCommitments, []*Chunk, error) interface, which 1) transforms the blob into a list of params.NumChunks Chunks, where each chunk is of length params.ChunkLength 2) produces the associated polynomial commitments and proofs.

We will also highlight the additional constraints on the Encoding interface which arise from the KZG-FFT encoder backend.

Deriving the polynomial coefficients and commitment

As described in the Encoding Module Specification, given a blob of data, we convert the blob to a polynomial $p(X) = \sum_{i=0}^{m-1} c_iX^i$ by simply slicing the data into a string of symbols, and interpreting this list of symbols as the tuple $(c_i)_{i=0}^{m-1}$.

In the case of the KZG-FFT encoder, the polynomial lives on the field associated with the BN254 elliptic curve, which as order [TODO: fill in order].

Given this polynomial representation, the KZG commitment can be calculated as in KZG polynomial commitments.

Polynomial Evaluation with the FFT

In order to use a Discrete Fourier Transform (DFT) to evaluate a polynomial, the indices of the polynomial evaluations which will make up the Chunks must be members of a cyclic group, which we will call $S$. A cyclic group is the group generated by taking all of the integer powers of some generator $v$, i.e., ${v^k | k \in \mathbb{Z} }$ (For this reason, the elements of a cyclic group $S$ of order $|S|=m$ will sometimes be referred to as the $|m|$’th roots of unity). Notice that since our polynomial lives on the BN254 field, the group $S$ must be a subgroup of that field (i.e. all of its elements must lie within that field).

Given a cyclic group $S$ of order $m$, we can evaluate a polynomial $p(X)$ of order $n$ at the indices contained in $S$ via the DFT,

$$ p_k = \sum_{i=1}^{n}c_i (v^k)^i $$

where $p_k$ gives the evaluation of the polynomial at $v^k \in S$. Letting $c$ denote the vector of polynomial coefficients and $p$ the vector of polynomial evaluations, we can use the shorthand $p = DFT[c]$. The inverse relation also holds, i.e., $c = DFT^{-1}[p]$.

To evaluate the DFT programmatically, we want $m = n$. Notice that we can achieve this when $m > n$ by simply padding $c$ with zeros to be of length $m$.

The use of the FFT can levy an additional requirement on the size of the group $S$. In our implementation, we require the size of $S$ to be a power of 2. For this, we can make use of the fact that the prime field associated with BN254 contains a subgroup of order $2^{28}$, which in turn contains subgroups of orders spanning every power of 2 less than $2^{28}$.

As the encoding interface calls for the construction of NumChunks Chunks of length ChunkLength, our application requires that $S$ be of size NumChunks*ChunkLength, which in turn must be a power of 2.

Amortized Multireveal Proof Generation with the FFT

The construction of the multireveal proofs can also be performed using a DFT (as in “Fast Amortized Kate Proofs”). Leaving the full details of this process to the referenced document, we describe here only 1) the index-assignment the scheme used by the amortized multiproof generation approach and 2) the constraints that this creates for the overall encoder interface.

Given the group $S$ corresponding to the indices of the polynomial evaluations and a cyclic group $C$ which is a subgroup of $S$, the cosets of $C$ in $S$ are given by

$$ s+C = {g+c : c \in C} \text{ for } s \in S. $$

Each coset $s+C$ has size $|C|$, and there are $|S|/|C|$ unique and disjoint cosets.

Given a polynomial $p(X)$ and the groups $S$ and $C$, the Amortized Kate Proofs approach generates $|S|/|C|$ different KZG multi-reveal proofs, where each proof is associated with the evaluation of $p(X)$ at the indices contained in a single coset $sC$ for $s \in S$. Because the Amortized Kate Proofs approach uses the FFT under the hood, $C$ itself must have an order which is a power of 2.

For the purposes of the KZG-FFT encoder, this means that we must choose $S$ to be of size NumChunks*ChunkLength and $C$ to be of size ChunkLength, each of which must be powers of 2.

Worked Example

As a simple illustrative example, suppose that AssignmentCoordinator provides the following parameters in order to meet the security requirements of a given blob:

• ChunkLength = 3
• NumChunks = 4

Supplied with these parameters, Encoder.ParamsFromMins will upgrade ChunkLength to the next highest power of 2, i.e., ChunkLength = 4, and leave NumChunks unchanged. The following figure illustrates how the indices will be assigned across the chunks in this scenario.

Assignment Module

The assignment module is essentially a rule which takes in the Ethereum chain state and outputs an allocation of chunks to DA operators. This can be generalized to a function that outputs a set of valid allocations.

A chunk assignment has the following parameters:

1. Indices: the chunk indices that will be assigned to each DA node. Some DA nodes receive more than one chunk.
2. ChunkLength: the length of each chunk (measured in number of symbols, as defined by the encoding module). We currently require all chunks to be of the same length, so this parameter is a scalar.

The assignment module is implemented by the AssignmentCoordinator interface.

Assignment Logic

The standard assignment coordinator implements a very simple logic for determining the number of chunks per node and the chunk length, which we describe here.

Chunk Length

Chunk lengths must be sufficiently small that operators with a small proportion of stake will be able to receive a quantity of data commensurate with their stake share. For each operator $i$, let $S_i$ signify the amount of stake held by that operator.

We require that the chunk size $C$ satisfy

$$ C \le \text{NextPowerOf2}\left(\frac{B}{\gamma}\max\left(\frac{\min_jS_j}{\sum_jS_j}, \frac{1}{M_\text{max}} \right) \right) $$

where $\gamma = \beta-\alpha$, with $\alpha$ and $\beta$ the adversary and quorum thresholds as defined in the Overview.

This means that as long as an operator has a stake share of at least $1/M_\text{max}$, then the encoded data that they will receive will be within a factor of 2 of their share of stake. Operators with less than $1/M_\text{max}$ of stake will receive no more than a $1/M_\text{max}$ of the encoded data. $M_\text{max}$ represents the maximum number of chunks that the disperser can be required to encode per blob. This limit is included because proving costs scale somewhat super-linearly with the number of chunks.

In the future, additional constraints on chunk length may be added; for instance, the chunk length may be set in order to maintain a fixed number of chunks per blob across all system states. Currently, the protocol does not mandate a specific value for the chunk length, but will accept the range satisfying the above constraint. The CalculateChunkLength function is provided as a convenience function that can be used to find a chunk length satisfying the protocol requirements.

Index Assignment

For each operator $i$, let $S_i$ signify the amount of stake held by that operator. We want for the number of chunks assigned to operator $i$ to satisfy

$$ \frac{\gamma m_i C}{B} \ge \frac{S_i}{\sum_j S_j} $$

Let

$$ m_i = \text{ceil}\left(\frac{B S_i}{C\gamma \sum_j S_j}\right)\tag{1} $$

Correctness Let's show that any sets $U_q$ and $U_a$ satisfying the constraints in the Consensus Layer Overview, the data held by the operators $U_q \setminus U_a$ will constitute an entire blob. The amount of data held by these operators is given by

$$ \sum_{i \in U_q \setminus U_a} m_i C $$

We have from (1) and from the definitions of $U_q$ and $U_a$ that

$$ \sum_{i \in U_q \setminus U_a} m_i C \ge =\frac{B}{\gamma}\sum_{i \in U_q \setminus U_a}\frac{S_i}{\sum_j S_j} = \frac{B}{\gamma}\frac{\sum_{i \in U_q} S_i - \sum_{i \in U_a} S_i}{\sum_jS_j} \ge B \frac{\beta-\alpha}{\gamma} = B \tag{2} $$

Since the unique data held by these operators exceeds the size of a blob, the encoding module ensures that the original blob can be reconstructed from this data.

Validation Actions

Validation with respect to assignments is performed at different layers of the protocol:

DA Nodes

When the DA node receives a StoreChunks request, it performs the following validation actions relative to each blob header:

• It uses the ValidateChunkLength to validate that the ChunkLength for the blob satisfies the above constraints.
• It uses GetOperatorAssignment to calculate the chunk indices for which it is responsible, and verifies that each of the chunks that it has received lies on the polynomial at these indices (see Encoding validation actions)

This step ensures that each honest node has received the blobs for which it is accountable.

Since the DA nodes will allow a range of ChunkLength values, as long as they satisfy the constraints of the protocol, it is necessary for there to be consensus on the ChunkLength that is in use for a particular blob and quorum. For this reason, the ChunkLength is included in the BlobQuorumParam which is hashed to create the merkle root contained in the BatchHeaderHash signed by the DA nodes.

Rollup Smart Contract

When the rollup confirms its blob against the EigenDA batch, it checks that the ConfirmationThreshold for the blob is greater than the AdversaryThreshold. This means that if the ChunkLength determined by the disperser is invalid, the batch cannot be confirmed as a sufficient number of nodes will not sign.

Signature verification and bridging

L1 Bridging

Bridging a DA attestation for a specific blob requires the following stages:

• Bridging the batch attestation. This involves checking the aggregate signature of the DA nodes for the batch, and tallying up the total amount of stake the signing nodes.
• Verifying the blob inclusion. Each batch contains a root of a Merkle tree whose leaves correspond to the blob headers contained in the batch. To verify blob inclusion, the associate Merkle proof must be supplied and evaluated. Furthermore, the specific quorum threshold requirement for the blob must be checked against the total amount of signing stake for the batch.

For the first stage, EigenDA makes use of the EigenLayer's default utilities for managing operator state, verifying aggregate BLS signatures, and checking the total stake held by the signing operators.

For the second stage, the EigenDA provides a utility contract with a verifyBlob method which rollups would typically integrate into their fraud proof pathway in the following manner:

1. The rollup sequencer posts all lookup data needed to verify a blob against a batch to the rollup inbox contract.
2. To initiate a fraud proof, the challenger must call the verifyBlob method with the supplied lookup data. If the blob does not verify correctly, the blob is considered invalid.

Reorg behavior (this section is outdated)

One aspect of the chain behavior of which the attestation protocol must be aware is that of chain reorganization. The following requirements relate to chain reorganizations:

1. Signed attestations should remain valid under reorgs so that a disperser never needs to resend the data and gather new signatures.
2. If an attestation is reorged out, a disperser should always be able to simply resubmit it after a specific waiting period.
3. Payloads constructed by a disperser and sent to DA nodes should never be rejected due to reorgs.

These requirements result in the following design choices:

• Chunk allotments should be based on registration state from a finalized block.
• If an attestation is reorged out and if the transaction containing the header of a batch is not present within BLOCK_STALE_MEASURE blocks since referenceBlockNumber and the block that is BLOCK_STALE_MEASURE blocks since referenceBlockNumber is finalized, then the disperser should again start a new dispersal with that blob of data. Otherwise, the disperser must not re-submit another transaction containing the header of a batch associated with the same blob of data.
• Payment payloads sent to DA nodes should only take into account finalized attestations.

The first and second decisions satisfy requirements 1 and 2. The three decisions together satisfy requirement 3.

Whenever the confirmBatch method of the ServiceManager.sol is called, the following checks are used to ensure that only finalized registration state is utilized:

• Stake staleness check. The referenceBlockNumber is verified to be within BLOCK_STALE_MEASURE blocks before the confirmation block.This is to make sure that batches using outdated stakes are not confirmed. It is assured that stakes from within BLOCK_STALE_MEASURE blocks before confirmation are valid by delaying removal of stakes by BLOCK_STALE_MEASURE + MAX_DURATION_BLOCKS.

EigenDA Managed Contracts

This page describe EigenDA contracts that are manage by EigenDA related actors (see the exact roles). For EigenDA-related contracts that are managed by rollups, see the rollup managed contracts page.

Middlewares Contracts

EigenDA Specific Contracts

The smart contracts can be found here.

EigenDACertVerifier

Contains a single function verifyDACertV2 which is used to verify certs. This function’s logic is described in the Cert Validation section.

EigenDAThreshold Registry

The EigenDAThresholdRegistry contains two sets of fundamental parameters:

/// @notice mapping of blob version id to the params of the blob version
mapping(uint16 => VersionedBlobParams) public versionedBlobParams;
struct VersionedBlobParams {
    uint32 maxNumOperators;
    uint32 numChunks;
    uint8 codingRate;
}

/// @notice Immutable security thresholds for quorums
SecurityThresholds public defaultSecurityThresholdsV2;
struct SecurityThresholds {
    uint8 confirmationThreshold;
    uint8 adversaryThreshold;
}

The securityThresholds are currently immutable. These are the same as the previously called liveness and safety thresholds:

• Confirmation Threshold (fka liveness threshold): minimum percentage of stake which an attacker must control in order to mount a liveness attack on the system.
• Adversary Threshold (fka safety threshold): total percentage of stake which an attacker must control in order to mount a first-order safety attack on the system.

Their values are

defaultSecurityThresholdsV2 = {
	confirmationThreshold = ??,
	adversaryThreshold = ??,
}

A new BlobParam version is very infrequently introduced by the EigenDA Foundation Governance, and rollups can choose which version they wish to use when dispersing a blob. Currently there is only version 0 defined, with parameters:

versionedBlobParams[0] = {
	maxNumOperators = ??,
	numChunks = 8192,
	codingRate = ??,
}

The five parameters are intricately related by this formula which is also verified onchain by the verifyBlobSecurityParams function:

$$ numChunks \cdot (1 - \frac{100}{\gamma * codingRate}) \geq maxNumOperators $$

where $\gamma$ = confirmationThreshold - adversaryThreshold

EigenDARelayRegistry

Contains EigenDA network registered Relays’ Ethereum address and DNS hostname or IP address. BlobCertificates contain relayKey(s), which can be transformed into that relay’s URL by calling relayKeyToUrl.

EigenDADisperserRegistry

Contains EigenDA network registered Dispersers’ Ethereum address. The EigenDA Network currently only supports a single Disperser, hosted by EigenLabs. The Disperser’s URL is currently static and unchanging, and can be found on our docs site in the Networks section.

Deployments

Governance Roles

Protocol Documentation

Table of Contents

• churner/churner.proto

  • ChurnReply

  • ChurnRequest

  • OperatorToChurn

  • SignatureWithSaltAndExpiry

  • Churner

• common/common.proto

  • BlobCommitment
  • G1Commitment

• common/v2/common_v2.proto

  • Batch
  • BatchHeader
  • BlobCertificate
  • BlobHeader
  • PaymentHeader

• disperser/disperser.proto

  • AuthenticatedReply

  • AuthenticatedRequest

  • AuthenticationData

  • BatchHeader

  • BatchMetadata

  • BlobAuthHeader

  • BlobHeader

  • BlobInfo

  • BlobQuorumParam

  • BlobStatusReply

  • BlobStatusRequest

  • BlobVerificationProof

  • DisperseBlobReply

  • DisperseBlobRequest

  • RetrieveBlobReply

  • RetrieveBlobRequest

  • BlobStatus

  • Disperser

• disperser/v2/disperser_v2.proto

  • Attestation

  • BlobCommitmentReply

  • BlobCommitmentRequest

  • BlobInclusionInfo

  • BlobStatusReply

  • BlobStatusRequest

  • DisperseBlobReply

  • DisperseBlobRequest

  • GetPaymentStateReply

  • GetPaymentStateRequest

  • PaymentGlobalParams

  • PeriodRecord

  • Reservation

  • SignedBatch

  • BlobStatus

  • Disperser

• node/node.proto

  • AttestBatchReply

  • AttestBatchRequest

  • BatchHeader

  • Blob

  • BlobHeader

  • BlobQuorumInfo

  • Bundle

  • G2Commitment

  • GetBlobHeaderReply

  • GetBlobHeaderRequest

  • MerkleProof

  • NodeInfoReply

  • NodeInfoRequest

  • RetrieveChunksReply

  • RetrieveChunksRequest

  • StoreBlobsReply

  • StoreBlobsRequest

  • StoreChunksReply

  • StoreChunksRequest

  • ChunkEncodingFormat

  • Dispersal

  • Retrieval

• relay/relay.proto

  • ChunkRequest

  • ChunkRequestByIndex

  • ChunkRequestByRange

  • GetBlobReply

  • GetBlobRequest

  • GetChunksReply

  • GetChunksRequest

  • Relay

• retriever/retriever.proto

  • BlobReply

  • BlobRequest

  • Retriever

• retriever/v2/retriever_v2.proto

  • BlobReply

  • BlobRequest

  • Retriever

• validator/node_v2.proto

  • GetChunksReply

  • GetChunksRequest

  • GetNodeInfoReply

  • GetNodeInfoRequest

  • StoreChunksReply

  • StoreChunksRequest

  • ChunkEncodingFormat

  • Dispersal

  • Retrieval

• Scalar Value Types

Top

churner/churner.proto

ChurnReply

For example, if the ChurnRequest specifies quorums 0 and 1 where quorum 0 is full and quorum 1 has available space, the ChurnReply will contain two OperatorToChurn objects with the respective quorums. OperatorToChurn for quorum 0 will contain the operator to churn out and OperatorToChurn for quorum 1 will contain empty operator (zero address) and pubkey. The smart contract should only churn out the operators for quorum 0 because quorum 1 has available space without having any operators churned. Note: it's possible an operator gets churned out just for one or more quorums (rather than entirely churned out for all quorums). |

ChurnRequest

OperatorToChurn

This describes an operator to churn out for a quorum.

SignatureWithSaltAndExpiry

Churner

The Churner is a service that handles churn requests from new operators trying to join the EigenDA network. When the EigenDA network reaches the maximum number of operators, any new operator trying to join will have to make a churn request to this Churner, which acts as the sole decision maker to decide whether this new operator could join, and if so, which existing operator will be churned out (so the max number of operators won't be exceeded). The max number of operators, as well as the rules to make churn decisions, are defined onchain, see details in OperatorSetParam at: https://github.com/Layr-Labs/eigenlayer-middleware/blob/master/src/interfaces/IBLSRegistryCoordinatorWithIndices.sol#L24.

Top

common/common.proto

BlobCommitment

BlobCommitment represents commitment of a specific blob, containing its KZG commitment, degree proof, the actual degree, and data length in number of symbols.

G1Commitment

A KZG commitment

Top

common/v2/common_v2.proto

Batch

Batch is a batch of blob certificates

BatchHeader

BatchHeader is the header of a batch of blobs

BlobCertificate

BlobCertificate contains a full description of a blob and how it is dispersed. Part of the certificate is provided by the blob submitter (i.e. the blob header), and part is provided by the disperser (i.e. the relays). Validator nodes eventually sign the blob certificate once they are in custody of the required chunks (note that the signature is indirect; validators sign the hash of a Batch, which contains the blob certificate).

BlobHeader

BlobHeader contains the information describing a blob and the way it is to be dispersed.

On-demand dispersal is currently limited to using a subset of the following quorums: - 0: ETH - 1: EIGEN

Reserved-bandwidth dispersal is free to use multiple quorums, however those must be reserved ahead of time. The quorum_numbers specified here must be a subset of the ones allowed by the on-chain reservation. Check the allowed quorum numbers by looking up reservation struct: https://github.com/Layr-Labs/eigenda/blob/1430d56258b4e814b388e497320fd76354bfb478/contracts/src/interfaces/IPaymentVault.sol#L10 | | commitment | common.BlobCommitment | | commitment is the KZG commitment to the blob | | payment_header | PaymentHeader | | payment_header contains payment information for the blob |

PaymentHeader

PaymentHeader contains payment information for a blob. At least one of reservation_period or cumulative_payment must be set, and reservation_period is always considered before cumulative_payment. If reservation_period is set but not valid, the server will reject the request and not proceed with dispersal. If reservation_period is not set and cumulative_payment is set but not valid, the server will reject the request and not proceed with dispersal. Once the server has accepted the payment header, a client cannot cancel or rollback the payment. Every dispersal request will be charged by a multiple of minNumSymbols field defined by the payment vault contract. If the request blob size is smaller or not a multiple of minNumSymbols, the server will charge the user for the next multiple of minNumSymbols (https://github.com/Layr-Labs/eigenda/blob/1430d56258b4e814b388e497320fd76354bfb478/contracts/src/payments/PaymentVaultStorage.sol#L9).

Example Usage Flow: 1. The user sets up a reservation with the EigenDA team, including throughput (symbolsPerSecond), startTimestamp, endTimestamp, and reservationPeriodInterval. 2. When sending a dispersal request at time t, the client fill in the timestamp field with t. 3. The disperser take timestamp t and checks the reservation period and the user's bandwidth capacity: - If the reservation is active (t >= startTimestamp and t < endTimestamp). - After rounding up to the nearest multiple of minNumSymbols defined by the payment vault contract, the user still has enough bandwidth capacity (hasn’t exceeded symbolsPerSecond * reservationPeriodInterval). - The request is ratelimited against the current reservation period, and calculated as reservation_period = floor(t / reservationPeriodInterval) * reservationPeriodInterval. the request's reservation period must either be the disperser server's current reservation period or the previous reservation period. 4. Server always go ahead with recording the received request in the current reservation period, and then categorize the scenarios - If the remaining bandwidth is sufficient for the request, the dispersal request proceeds. - If the remaining bandwidth is not enough for the request, server fills up the current bin and overflowing the extra to a future bin. - If the bandwidth has already been exhausted, the request is rejected. 5. Once the dispersal request signature has been verified, the server will not roll back the payment or the usage records. Users should be aware of this when planning their usage. The dispersal client written by EigenDA team takes account of this. 6. When the reservation ends or usage is exhausted, the client must wait for the next reservation period or switch to on-demand. | | cumulative_payment | bytes | | Cumulative payment is the total amount of tokens paid by the requesting account, including the current request. This value is serialized as an uint256 and parsed as a big integer, and must match the user’s on-chain deposit limits as well as the recorded payments for all previous requests. Because it is a cumulative (not incremental) total, requests can arrive out of order and still unambiguously declare how much of the on-chain deposit can be deducted.

Example Decision Flow: 1. In the set up phase, the user must deposit tokens into the EigenDA PaymentVault contract. The payment vault contract specifies the minimum number of symbols charged per dispersal, the pricing per symbol, and the maximum global rate for on-demand dispersals. The user should calculate the amount of tokens they would like to deposit based on their usage. The first time a user make a request, server will immediate read the contract for the on-chain balance. When user runs out of on-chain balance, the server will reject the request and not proceed with dispersal. When a user top up on-chain, the server will only refresh every few minutes for the top-up to take effect. 2. The disperser client accounts how many tokens they’ve already paid (previousCumPmt). 3. They should calculate the payment by rounding up blob size to the nearest multiple of minNumSymbols defined by the payment vault contract, and calculate the incremental amount of tokens needed for the current request needs based on protocol defined pricing. 4. They take the sum of previousCumPmt + new incremental payment and place it in the “cumulative_payment” field. 5. The disperser checks this new cumulative total against on-chain deposits and prior records (largest previous payment and smallest later payment if exists). 6. If the payment number is valid, the request is confirmed and disperser proceeds with dispersal; otherwise it’s rejected. |

Top

disperser/disperser.proto

AuthenticatedReply

AuthenticatedRequest

AuthenticationData

AuthenticationData contains the signature of the BlobAuthHeader.

BatchHeader

BatchMetadata

BlobAuthHeader

BlobAuthHeader contains information about the blob for the client to verify and sign.

• Once payments are enabled, the BlobAuthHeader will contain the KZG commitment to the blob, which the client will verify and sign. Having the client verify the KZG commitment instead of calculating it avoids the need for the client to have the KZG structured reference string (SRS), which can be large. The signed KZG commitment prevents the disperser from sending a different blob to the DA Nodes than the one the client sent.
• In the meantime, the BlobAuthHeader contains a simple challenge parameter is used to prevent replay attacks in the event that a signature is leaked.

BlobHeader

BlobInfo

BlobInfo contains information needed to confirm the blob against the EigenDA contracts

BlobQuorumParam

BlobStatusReply

BlobStatusRequest

BlobStatusRequest is used to query the status of a blob.

BlobVerificationProof

DisperseBlobReply

Once a request is accepted, a unique request ID is generated. request_id = string(blob_key) = (hash(blob), hash(metadata)) where metadata contains a requestedAt timestamp and the requested quorum numbers and their adversarial thresholds. BlobKey definition: https://github.com/Layr-Labs/eigenda/blob/6b02bf966afa2b9bf2385db8dd01f66f17334e17/disperser/disperser.go#L87 BlobKey computation: https://github.com/Layr-Labs/eigenda/blob/6b02bf966afa2b9bf2385db8dd01f66f17334e17/disperser/common/blobstore/shared_storage.go#L83-L84

Different DisperseBlobRequests have different IDs, including two identical DisperseBlobRequests sent at different times. Clients should thus store this ID and use it to query the processing status of the request via the GetBlobStatus API. |

DisperseBlobRequest

RetrieveBlobReply

RetrieveBlobReply contains the retrieved blob data

RetrieveBlobRequest

RetrieveBlobRequest contains parameters to retrieve the blob.

BlobStatus

BlobStatus represents the status of a blob. The status of a blob is updated as the blob is processed by the disperser. The status of a blob can be queried by the client using the GetBlobStatus API. Intermediate states are states that the blob can be in while being processed, and it can be updated to a different state:

• PROCESSING
• DISPERSING
• CONFIRMED Terminal states are states that will not be updated to a different state:
• FAILED
• FINALIZED
• INSUFFICIENT_SIGNATURES

Disperser

Disperser defines the public APIs for dispersing blobs.

If DisperseBlob returns the following error codes: INVALID_ARGUMENT (400): request is invalid for a reason specified in the error msg. RESOURCE_EXHAUSTED (429): request is rate limited for the quorum specified in the error msg. user should retry after the specified duration. INTERNAL (500): serious error, user should NOT retry. | | DisperseBlobAuthenticated | AuthenticatedRequest stream | AuthenticatedReply stream | DisperseBlobAuthenticated is similar to DisperseBlob, except that it requires the client to authenticate itself via the AuthenticationData message. The protocol is as follows: 1. The client sends a DisperseBlobAuthenticated request with the DisperseBlobRequest message 2. The Disperser sends back a BlobAuthHeader message containing information for the client to verify and sign. 3. The client verifies the BlobAuthHeader and sends back the signed BlobAuthHeader in an AuthenticationData message. 4. The Disperser verifies the signature and returns a DisperseBlobReply message. | | GetBlobStatus | BlobStatusRequest | BlobStatusReply | This API is meant to be polled for the blob status. | | RetrieveBlob | RetrieveBlobRequest | RetrieveBlobReply | This retrieves the requested blob from the Disperser's backend. This is a more efficient way to retrieve blobs than directly retrieving from the DA Nodes (see detail about this approach in api/proto/retriever/retriever.proto). The blob should have been initially dispersed via this Disperser service for this API to work. |

Top

disperser/v2/disperser_v2.proto

Attestation

BlobCommitmentReply

The result of a BlobCommitmentRequest().

BlobCommitmentRequest

The input for a BlobCommitmentRequest(). This can be used to construct a BlobHeader.commitment.

BlobInclusionInfo

BlobInclusionInfo is the information needed to verify the inclusion of a blob in a batch.

BlobStatusReply

BlobStatusReply is the reply to a BlobStatusRequest.

BlobStatusRequest

BlobStatusRequest is used to query the status of a blob.

DisperseBlobReply

A reply to a DisperseBlob request.

The blob_key is the keccak hash of the rlp serialization of the BlobHeader, as computed here: https://github.com/Layr-Labs/eigenda/blob/0f14d1c90b86d29c30ff7e92cbadf2762c47f402/core/v2/serialization.go#L30 The blob_key must thus be unique for every request, even if the same blob is being dispersed. Meaning the blob_header must be different for each request.

Note that attempting to disperse a blob with the same blob key as a previously dispersed blob may cause the disperser to reject the blob (DisperseBlob() RPC will return an error). |

DisperseBlobRequest

A request to disperse a blob.

The size of this byte array may be any size as long as it does not exceed the maximum length of 16MiB. While the data being dispersed is only required to be greater than 0 bytes, the blob size charged against the payment method will be rounded up to the nearest multiple of minNumSymbols defined by the payment vault contract (https://github.com/Layr-Labs/eigenda/blob/1430d56258b4e814b388e497320fd76354bfb478/contracts/src/payments/PaymentVaultStorage.sol#L9).

Every 32 bytes of data is interpreted as an integer in big endian format where the lower address has more significant bits. The integer must stay in the valid range to be interpreted as a field element on the bn254 curve. The valid range is 0 <= x < 21888242871839275222246405745257275088548364400416034343698204186575808495617. If any one of the 32 bytes elements is outside the range, the whole request is deemed as invalid, and rejected. | | blob_header | common.v2.BlobHeader | | The header contains metadata about the blob.

This header can be thought of as an "eigenDA tx", in that it plays a purpose similar to an eth_tx to disperse a 4844 blob. Note that a call to DisperseBlob requires the blob and the blobHeader, which is similar to how dispersing a blob to ethereum requires sending a tx whose data contains the hash of the kzg commit of the blob, which is dispersed separately. | | signature | bytes | | signature over keccak hash of the blob_header that can be verified by blob_header.payment_header.account_id |

GetPaymentStateReply

GetPaymentStateReply contains the payment state of an account.

GetPaymentStateRequest

GetPaymentStateRequest contains parameters to query the payment state of an account.

PaymentGlobalParams

Global constant parameters defined by the payment vault.

PeriodRecord

PeriodRecord is the usage record of an account in a bin. The API should return the active bin record and the subsequent two records that contains potential overflows.

Reservation

Reservation parameters of an account, used to determine the rate limit for the account.

SignedBatch

SignedBatch is a batch of blobs with a signature.

BlobStatus

BlobStatus represents the status of a blob. The status of a blob is updated as the blob is processed by the disperser. The status of a blob can be queried by the client using the GetBlobStatus API. Intermediate states are states that the blob can be in while being processed, and it can be updated to a different state:

• QUEUED
• ENCODED
• GATHERING_SIGNATURES Terminal states are states that will not be updated to a different state:
• UNKNOWN
• COMPLETE
• FAILED

This status is functionally equivalent to FAILED, but is used to indicate that the failure is due to an unanticipated bug. | | QUEUED | 1 | QUEUED means that the blob has been queued by the disperser for processing. The DisperseBlob API is asynchronous, meaning that after request validation, but before any processing, the blob is stored in a queue of some sort, and a response immediately returned to the client. | | ENCODED | 2 | ENCODED means that the blob has been Reed-Solomon encoded into chunks and is ready to be dispersed to DA Nodes. | | GATHERING_SIGNATURES | 3 | GATHERING_SIGNATURES means that the blob chunks are currently actively being transmitted to validators, and in doing so requesting that the validators sign to acknowledge receipt of the blob. Requests that timeout or receive errors are resubmitted to DA nodes for some period of time set by the disperser, after which the BlobStatus becomes COMPLETE. | | COMPLETE | 4 | COMPLETE means the blob has been dispersed to DA nodes, and the GATHERING_SIGNATURES period of time has completed. This status does not guarantee any signer percentage, so a client should check that the signature has met its required threshold, and resubmit a new blob dispersal request if not. | | FAILED | 5 | FAILED means that the blob has failed permanently. Note that this is a terminal state, and in order to retry the blob, the client must submit the blob again (blob key is required to be unique). |

Disperser

Disperser defines the public APIs for dispersing blobs.

Top

node/node.proto

AttestBatchReply

AttestBatchRequest

BatchHeader

BatchHeader (see core/data.go#BatchHeader)

Blob

In EigenDA, the original blob to disperse is encoded as a polynomial via taking taking different point evaluations (i.e. erasure coding). These points are split into disjoint subsets which are assigned to different operator nodes in the EigenDA network. The data in this message is a subset of these points that are assigned to a single operator node.

BlobHeader

BlobQuorumInfo

See BlobQuorumParam as defined in api/proto/disperser/disperser.proto

Bundle

A Bundle is the collection of chunks associated with a single blob, for a single operator and a single quorum.

G2Commitment

GetBlobHeaderReply

GetBlobHeaderRequest

See RetrieveChunksRequest for documentation of each parameter of GetBlobHeaderRequest.

MerkleProof

NodeInfoReply

Node info reply

NodeInfoRequest

Node info request

RetrieveChunksReply

RetrieveChunksRequest

StoreBlobsReply

StoreBlobsRequest

StoreChunksReply

StoreChunksRequest

ChunkEncodingFormat

This describes how the chunks returned in RetrieveChunksReply are encoded. Used to facilitate the decoding of chunks.

Dispersal

Retrieval

Top

relay/relay.proto

ChunkRequest

A request for chunks within a specific blob. Requests are fulfilled in all-or-nothing fashion. If any of the requested chunks are not found or are unable to be fetched, the entire request will fail.

ChunkRequestByIndex

A request for chunks within a specific blob. Each chunk is requested individually by its index.

ChunkRequestByRange

A request for chunks within a specific blob. Each chunk is requested a range of indices.

GetBlobReply

The reply to a GetBlobs request.

GetBlobRequest

A request to fetch one or more blobs.

GetChunksReply

The reply to a GetChunks request.

GetChunksRequest

Request chunks from blobs stored by this relay.

The following describes the schema for computing the hash of this request This algorithm is implemented in golang using relay.auth.HashGetChunksRequest().

All integers are encoded as unsigned 4 byte big endian values.

Perform a keccak256 hash on the following data in the following order: 1. the length of the operator ID in bytes 2. the operator id 3. the number of chunk requests 4. for each chunk request: a. if the chunk request is a request by index: i. a one byte ASCII representation of the character "i" (aka Ox69) ii. the length blob key in bytes iii. the blob key iv. the start index v. the end index b. if the chunk request is a request by range: i. a one byte ASCII representation of the character "r" (aka Ox72) ii. the length of the blob key in bytes iii. the blob key iv. each requested chunk index, in order 5. the timestamp (seconds since the Unix epoch encoded as a 4 byte big endian value) |

Relay

Relay is a service that provides access to public relay functionality.

Top

retriever/retriever.proto

BlobReply

BlobRequest

Retriever

The Retriever is a service for retrieving chunks corresponding to a blob from the EigenDA operator nodes and reconstructing the original blob from the chunks. This is a client-side library that the users are supposed to operationalize.

Note: Users generally have two ways to retrieve a blob from EigenDA:

1. Retrieve from the Disperser that the user initially used for dispersal: the API is Disperser.RetrieveBlob() as defined in api/proto/disperser/disperser.proto
2. Retrieve directly from the EigenDA Nodes, which is supported by this Retriever.

The Disperser.RetrieveBlob() (the 1st approach) is generally faster and cheaper as the Disperser manages the blobs that it has processed, whereas the Retriever.RetrieveBlob() (the 2nd approach here) removes the need to trust the Disperser, with the downside of worse cost and performance.

Top

retriever/v2/retriever_v2.proto

BlobReply

A reply to a RetrieveBlob() request.

BlobRequest

A request to retrieve a blob from the EigenDA Nodes via RetrieveBlob().

Retriever

The Retriever is a service for retrieving chunks corresponding to a blob from the EigenDA operator nodes and reconstructing the original blob from the chunks. This is a client-side library that the users are supposed to operationalize.

Note: Users generally have two ways to retrieve a blob from EigenDA V2:

1. Retrieve from the relay that the blob is assigned to: the API is Relay.GetBlob() as defined in api/proto/relay/relay.proto
2. Retrieve directly from the EigenDA Nodes, which is supported by this Retriever.

The Relay.GetBlob() (the 1st approach) is generally faster and cheaper as the relay manages the blobs that it has processed, whereas the Retriever.RetrieveBlob() (the 2nd approach here) removes the need to trust the relay, with the downside of worse cost and performance.

Top

validator/node_v2.proto

GetChunksReply

The response to the GetChunks() RPC.

GetChunksRequest

The parameter for the GetChunks() RPC.

GetNodeInfoReply

Node info reply

GetNodeInfoRequest

The parameter for the GetNodeInfo() RPC.

StoreChunksReply

StoreChunksReply is the message type used to respond to a StoreChunks() RPC.

StoreChunksRequest

Request that the Node store a batch of chunks.

Algorithm for computing the hash is as follows. All integer values are serialized in big-endian order (unsigned). A reference implementation (golang) can be found at https://github.com/Layr-Labs/eigenda/blob/master/disperser/auth/request_signing.go

1. digest len(batch.BatchHeader.BatchRoot) (4 bytes, unsigned big endian) 2. digest batch.BatchHeader.BatchRoot 3. digest batch.BatchHeader.ReferenceBlockNumber (8 bytes, unsigned big endian) 4. digest len(batch.BlobCertificates) (4 bytes, unsigned big endian) 5. for each certificate in batch.BlobCertificates: a. digest certificate.BlobHeader.Version (4 bytes, unsigned big endian) b. digest len(certificate.BlobHeader.QuorumNumbers) (4 bytes, unsigned big endian) c. for each quorum_number in certificate.BlobHeader.QuorumNumbers: i. digest quorum_number (4 bytes, unsigned big endian) d. digest len(certificate.BlobHeader.Commitment.Commitment) (4 bytes, unsigned big endian) e. digest certificate.BlobHeader.Commitment.Commitment f digest len(certificate.BlobHeader.Commitment.LengthCommitment) (4 bytes, unsigned big endian) g. digest certificate.BlobHeader.Commitment.LengthCommitment h. digest len(certificate.BlobHeader.Commitment.LengthProof) (4 bytes, unsigned big endian) i. digest certificate.BlobHeader.Commitment.LengthProof j. digest certificate.BlobHeader.Commitment.Length (4 bytes, unsigned big endian) k. digest len(certificate.BlobHeader.PaymentHeader.AccountId) (4 bytes, unsigned big endian) l. digest certificate.BlobHeader.PaymentHeader.AccountId m. digest certificate.BlobHeader.PaymentHeader.Timestamp (4 bytes, signed big endian) n digest len(certificate.BlobHeader.PaymentHeader.CumulativePayment) (4 bytes, unsigned big endian) o. digest certificate.BlobHeader.PaymentHeader.CumulativePayment p digest len(certificate.BlobHeader.Signature) (4 bytes, unsigned big endian) q. digest certificate.BlobHeader.Signature r. digest len(certificate.Relays) (4 bytes, unsigned big endian) s. for each relay in certificate.Relays: i. digest relay (4 bytes, unsigned big endian) 6. digest disperserID (4 bytes, unsigned big endian) 7. digest timestamp (4 bytes, unsigned big endian)

Note that this signature is not included in the hash for obvious reasons. |

ChunkEncodingFormat

This describes how the chunks returned in GetChunksReply are encoded. Used to facilitate the decoding of chunks.

[KZG proof: 32 bytes] [Coeff 1: 32 bytes] [Coeff 2: 32 bytes] ... [Coeff n: 32 bytes]

The KZG proof is a point on G1 and is serialized with bn254.G1Affine.Bytes(). The coefficients are field elements in bn254 and serialized with fr.Element.Marshal().

References: - bn254.G1Affine: github.com/consensys/gnark-crypto/ecc/bn254 - fr.Element: github.com/consensys/gnark-crypto/ecc/bn254/fr

Golang serialization and deserialization can be found in: - Frame.SerializeGnark() - Frame.DeserializeGnark() Package: github.com/Layr-Labs/eigenda/encoding |

Dispersal

Dispersal is utilized to disperse chunk data.

Retrieval

Retrieval is utilized to retrieve chunk data.

Scalar Value Types

Protocol Documentation

Table of Contents

• churner/churner.proto

  • ChurnReply

  • ChurnRequest

  • OperatorToChurn

  • SignatureWithSaltAndExpiry

  • Churner

• Scalar Value Types

Top

churner/churner.proto

ChurnReply

For example, if the ChurnRequest specifies quorums 0 and 1 where quorum 0 is full and quorum 1 has available space, the ChurnReply will contain two OperatorToChurn objects with the respective quorums. OperatorToChurn for quorum 0 will contain the operator to churn out and OperatorToChurn for quorum 1 will contain empty operator (zero address) and pubkey. The smart contract should only churn out the operators for quorum 0 because quorum 1 has available space without having any operators churned. Note: it's possible an operator gets churned out just for one or more quorums (rather than entirely churned out for all quorums). |

ChurnRequest

OperatorToChurn

This describes an operator to churn out for a quorum.

SignatureWithSaltAndExpiry

Churner

The Churner is a service that handles churn requests from new operators trying to join the EigenDA network. When the EigenDA network reaches the maximum number of operators, any new operator trying to join will have to make a churn request to this Churner, which acts as the sole decision maker to decide whether this new operator could join, and if so, which existing operator will be churned out (so the max number of operators won't be exceeded). The max number of operators, as well as the rules to make churn decisions, are defined onchain, see details in OperatorSetParam at: https://github.com/Layr-Labs/eigenlayer-middleware/blob/master/src/interfaces/IBLSRegistryCoordinatorWithIndices.sol#L24.

Scalar Value Types

Protocol Documentation

Table of Contents

• common/common.proto

  • BlobCommitment
  • G1Commitment

• Scalar Value Types

Top

common/common.proto

BlobCommitment

BlobCommitment represents commitment of a specific blob, containing its KZG commitment, degree proof, the actual degree, and data length in number of symbols.

G1Commitment

A KZG commitment

Scalar Value Types

Protocol Documentation

Table of Contents

• common/v2/common_v2.proto

  • Batch
  • BatchHeader
  • BlobCertificate
  • BlobHeader
  • PaymentHeader

• Scalar Value Types

Top

common/v2/common_v2.proto

Batch

Batch is a batch of blob certificates

BatchHeader

BatchHeader is the header of a batch of blobs

BlobCertificate

BlobCertificate contains a full description of a blob and how it is dispersed. Part of the certificate is provided by the blob submitter (i.e. the blob header), and part is provided by the disperser (i.e. the relays). Validator nodes eventually sign the blob certificate once they are in custody of the required chunks (note that the signature is indirect; validators sign the hash of a Batch, which contains the blob certificate).

BlobHeader

BlobHeader contains the information describing a blob and the way it is to be dispersed.

On-demand dispersal is currently limited to using a subset of the following quorums: - 0: ETH - 1: EIGEN

Reserved-bandwidth dispersal is free to use multiple quorums, however those must be reserved ahead of time. The quorum_numbers specified here must be a subset of the ones allowed by the on-chain reservation. Check the allowed quorum numbers by looking up reservation struct: https://github.com/Layr-Labs/eigenda/blob/1430d56258b4e814b388e497320fd76354bfb478/contracts/src/interfaces/IPaymentVault.sol#L10 | | commitment | common.BlobCommitment | | commitment is the KZG commitment to the blob | | payment_header | PaymentHeader | | payment_header contains payment information for the blob |

PaymentHeader

PaymentHeader contains payment information for a blob. At least one of reservation_period or cumulative_payment must be set, and reservation_period is always considered before cumulative_payment. If reservation_period is set but not valid, the server will reject the request and not proceed with dispersal. If reservation_period is not set and cumulative_payment is set but not valid, the server will reject the request and not proceed with dispersal. Once the server has accepted the payment header, a client cannot cancel or rollback the payment. Every dispersal request will be charged by a multiple of minNumSymbols field defined by the payment vault contract. If the request blob size is smaller or not a multiple of minNumSymbols, the server will charge the user for the next multiple of minNumSymbols (https://github.com/Layr-Labs/eigenda/blob/1430d56258b4e814b388e497320fd76354bfb478/contracts/src/payments/PaymentVaultStorage.sol#L9).

Example Usage Flow: 1. The user sets up a reservation with the EigenDA team, including throughput (symbolsPerSecond), startTimestamp, endTimestamp, and reservationPeriodInterval. 2. When sending a dispersal request at time t, the client fill in the timestamp field with t. 3. The disperser take timestamp t and checks the reservation period and the user's bandwidth capacity: - If the reservation is active (t >= startTimestamp and t < endTimestamp). - After rounding up to the nearest multiple of minNumSymbols defined by the payment vault contract, the user still has enough bandwidth capacity (hasn’t exceeded symbolsPerSecond * reservationPeriodInterval). - The request is ratelimited against the current reservation period, and calculated as reservation_period = floor(t / reservationPeriodInterval) * reservationPeriodInterval. the request's reservation period must either be the disperser server's current reservation period or the previous reservation period. 4. Server always go ahead with recording the received request in the current reservation period, and then categorize the scenarios - If the remaining bandwidth is sufficient for the request, the dispersal request proceeds. - If the remaining bandwidth is not enough for the request, server fills up the current bin and overflowing the extra to a future bin. - If the bandwidth has already been exhausted, the request is rejected. 5. Once the dispersal request signature has been verified, the server will not roll back the payment or the usage records. Users should be aware of this when planning their usage. The dispersal client written by EigenDA team takes account of this. 6. When the reservation ends or usage is exhausted, the client must wait for the next reservation period or switch to on-demand. | | cumulative_payment | bytes | | Cumulative payment is the total amount of tokens paid by the requesting account, including the current request. This value is serialized as an uint256 and parsed as a big integer, and must match the user’s on-chain deposit limits as well as the recorded payments for all previous requests. Because it is a cumulative (not incremental) total, requests can arrive out of order and still unambiguously declare how much of the on-chain deposit can be deducted.

Example Decision Flow: 1. In the set up phase, the user must deposit tokens into the EigenDA PaymentVault contract. The payment vault contract specifies the minimum number of symbols charged per dispersal, the pricing per symbol, and the maximum global rate for on-demand dispersals. The user should calculate the amount of tokens they would like to deposit based on their usage. The first time a user make a request, server will immediate read the contract for the on-chain balance. When user runs out of on-chain balance, the server will reject the request and not proceed with dispersal. When a user top up on-chain, the server will only refresh every few minutes for the top-up to take effect. 2. The disperser client accounts how many tokens they’ve already paid (previousCumPmt). 3. They should calculate the payment by rounding up blob size to the nearest multiple of minNumSymbols defined by the payment vault contract, and calculate the incremental amount of tokens needed for the current request needs based on protocol defined pricing. 4. They take the sum of previousCumPmt + new incremental payment and place it in the “cumulative_payment” field. 5. The disperser checks this new cumulative total against on-chain deposits and prior records (largest previous payment and smallest later payment if exists). 6. If the payment number is valid, the request is confirmed and disperser proceeds with dispersal; otherwise it’s rejected. |

Scalar Value Types

Protocol Documentation

Table of Contents

• disperser/disperser.proto

  • AuthenticatedReply

  • AuthenticatedRequest

  • AuthenticationData

  • BatchHeader

  • BatchMetadata

  • BlobAuthHeader

  • BlobHeader

  • BlobInfo

  • BlobQuorumParam

  • BlobStatusReply

  • BlobStatusRequest

  • BlobVerificationProof

  • DisperseBlobReply

  • DisperseBlobRequest

  • RetrieveBlobReply

  • RetrieveBlobRequest

  • BlobStatus

  • Disperser

• Scalar Value Types

Top

disperser/disperser.proto

AuthenticatedReply

AuthenticatedRequest

AuthenticationData

AuthenticationData contains the signature of the BlobAuthHeader.

BatchHeader

BatchMetadata

BlobAuthHeader

BlobAuthHeader contains information about the blob for the client to verify and sign.

• Once payments are enabled, the BlobAuthHeader will contain the KZG commitment to the blob, which the client will verify and sign. Having the client verify the KZG commitment instead of calculating it avoids the need for the client to have the KZG structured reference string (SRS), which can be large. The signed KZG commitment prevents the disperser from sending a different blob to the DA Nodes than the one the client sent.
• In the meantime, the BlobAuthHeader contains a simple challenge parameter is used to prevent replay attacks in the event that a signature is leaked.

BlobHeader

BlobInfo

BlobInfo contains information needed to confirm the blob against the EigenDA contracts

BlobQuorumParam

BlobStatusReply

BlobStatusRequest

BlobStatusRequest is used to query the status of a blob.

BlobVerificationProof

DisperseBlobReply

Once a request is accepted, a unique request ID is generated. request_id = string(blob_key) = (hash(blob), hash(metadata)) where metadata contains a requestedAt timestamp and the requested quorum numbers and their adversarial thresholds. BlobKey definition: https://github.com/Layr-Labs/eigenda/blob/6b02bf966afa2b9bf2385db8dd01f66f17334e17/disperser/disperser.go#L87 BlobKey computation: https://github.com/Layr-Labs/eigenda/blob/6b02bf966afa2b9bf2385db8dd01f66f17334e17/disperser/common/blobstore/shared_storage.go#L83-L84

Different DisperseBlobRequests have different IDs, including two identical DisperseBlobRequests sent at different times. Clients should thus store this ID and use it to query the processing status of the request via the GetBlobStatus API. |

DisperseBlobRequest

RetrieveBlobReply

RetrieveBlobReply contains the retrieved blob data

RetrieveBlobRequest

RetrieveBlobRequest contains parameters to retrieve the blob.

BlobStatus

BlobStatus represents the status of a blob. The status of a blob is updated as the blob is processed by the disperser. The status of a blob can be queried by the client using the GetBlobStatus API. Intermediate states are states that the blob can be in while being processed, and it can be updated to a different state:

• PROCESSING
• DISPERSING
• CONFIRMED Terminal states are states that will not be updated to a different state:
• FAILED
• FINALIZED
• INSUFFICIENT_SIGNATURES

Disperser

Disperser defines the public APIs for dispersing blobs.

If DisperseBlob returns the following error codes: INVALID_ARGUMENT (400): request is invalid for a reason specified in the error msg. RESOURCE_EXHAUSTED (429): request is rate limited for the quorum specified in the error msg. user should retry after the specified duration. INTERNAL (500): serious error, user should NOT retry. | | DisperseBlobAuthenticated | AuthenticatedRequest stream | AuthenticatedReply stream | DisperseBlobAuthenticated is similar to DisperseBlob, except that it requires the client to authenticate itself via the AuthenticationData message. The protocol is as follows: 1. The client sends a DisperseBlobAuthenticated request with the DisperseBlobRequest message 2. The Disperser sends back a BlobAuthHeader message containing information for the client to verify and sign. 3. The client verifies the BlobAuthHeader and sends back the signed BlobAuthHeader in an AuthenticationData message. 4. The Disperser verifies the signature and returns a DisperseBlobReply message. | | GetBlobStatus | BlobStatusRequest | BlobStatusReply | This API is meant to be polled for the blob status. | | RetrieveBlob | RetrieveBlobRequest | RetrieveBlobReply | This retrieves the requested blob from the Disperser's backend. This is a more efficient way to retrieve blobs than directly retrieving from the DA Nodes (see detail about this approach in api/proto/retriever/retriever.proto). The blob should have been initially dispersed via this Disperser service for this API to work. |

Scalar Value Types

Protocol Documentation

Table of Contents

• disperser/v2/disperser_v2.proto

  • Attestation

  • BlobCommitmentReply

  • BlobCommitmentRequest

  • BlobInclusionInfo

  • BlobStatusReply

  • BlobStatusRequest

  • DisperseBlobReply

  • DisperseBlobRequest

  • GetPaymentStateReply

  • GetPaymentStateRequest

  • PaymentGlobalParams

  • PeriodRecord

  • Reservation

  • SignedBatch

  • BlobStatus

  • Disperser

• Scalar Value Types

Top

disperser/v2/disperser_v2.proto

Attestation

BlobCommitmentReply

The result of a BlobCommitmentRequest().

BlobCommitmentRequest

The input for a BlobCommitmentRequest(). This can be used to construct a BlobHeader.commitment.

BlobInclusionInfo

BlobInclusionInfo is the information needed to verify the inclusion of a blob in a batch.

BlobStatusReply

BlobStatusReply is the reply to a BlobStatusRequest.

BlobStatusRequest

BlobStatusRequest is used to query the status of a blob.

DisperseBlobReply

A reply to a DisperseBlob request.

The blob_key is the keccak hash of the rlp serialization of the BlobHeader, as computed here: https://github.com/Layr-Labs/eigenda/blob/0f14d1c90b86d29c30ff7e92cbadf2762c47f402/core/v2/serialization.go#L30 The blob_key must thus be unique for every request, even if the same blob is being dispersed. Meaning the blob_header must be different for each request.

Note that attempting to disperse a blob with the same blob key as a previously dispersed blob may cause the disperser to reject the blob (DisperseBlob() RPC will return an error). |

DisperseBlobRequest

A request to disperse a blob.

The size of this byte array may be any size as long as it does not exceed the maximum length of 16MiB. While the data being dispersed is only required to be greater than 0 bytes, the blob size charged against the payment method will be rounded up to the nearest multiple of minNumSymbols defined by the payment vault contract (https://github.com/Layr-Labs/eigenda/blob/1430d56258b4e814b388e497320fd76354bfb478/contracts/src/payments/PaymentVaultStorage.sol#L9).

Every 32 bytes of data is interpreted as an integer in big endian format where the lower address has more significant bits. The integer must stay in the valid range to be interpreted as a field element on the bn254 curve. The valid range is 0 <= x < 21888242871839275222246405745257275088548364400416034343698204186575808495617. If any one of the 32 bytes elements is outside the range, the whole request is deemed as invalid, and rejected. | | blob_header | common.v2.BlobHeader | | The header contains metadata about the blob.

This header can be thought of as an "eigenDA tx", in that it plays a purpose similar to an eth_tx to disperse a 4844 blob. Note that a call to DisperseBlob requires the blob and the blobHeader, which is similar to how dispersing a blob to ethereum requires sending a tx whose data contains the hash of the kzg commit of the blob, which is dispersed separately. | | signature | bytes | | signature over keccak hash of the blob_header that can be verified by blob_header.payment_header.account_id |

GetPaymentStateReply

GetPaymentStateReply contains the payment state of an account.

GetPaymentStateRequest

GetPaymentStateRequest contains parameters to query the payment state of an account.

PaymentGlobalParams

Global constant parameters defined by the payment vault.

PeriodRecord

PeriodRecord is the usage record of an account in a bin. The API should return the active bin record and the subsequent two records that contains potential overflows.

Reservation

Reservation parameters of an account, used to determine the rate limit for the account.

SignedBatch

SignedBatch is a batch of blobs with a signature.

BlobStatus

BlobStatus represents the status of a blob. The status of a blob is updated as the blob is processed by the disperser. The status of a blob can be queried by the client using the GetBlobStatus API. Intermediate states are states that the blob can be in while being processed, and it can be updated to a different state:

• QUEUED
• ENCODED
• GATHERING_SIGNATURES Terminal states are states that will not be updated to a different state:
• UNKNOWN
• COMPLETE
• FAILED

This status is functionally equivalent to FAILED, but is used to indicate that the failure is due to an unanticipated bug. | | QUEUED | 1 | QUEUED means that the blob has been queued by the disperser for processing. The DisperseBlob API is asynchronous, meaning that after request validation, but before any processing, the blob is stored in a queue of some sort, and a response immediately returned to the client. | | ENCODED | 2 | ENCODED means that the blob has been Reed-Solomon encoded into chunks and is ready to be dispersed to DA Nodes. | | GATHERING_SIGNATURES | 3 | GATHERING_SIGNATURES means that the blob chunks are currently actively being transmitted to validators, and in doing so requesting that the validators sign to acknowledge receipt of the blob. Requests that timeout or receive errors are resubmitted to DA nodes for some period of time set by the disperser, after which the BlobStatus becomes COMPLETE. | | COMPLETE | 4 | COMPLETE means the blob has been dispersed to DA nodes, and the GATHERING_SIGNATURES period of time has completed. This status does not guarantee any signer percentage, so a client should check that the signature has met its required threshold, and resubmit a new blob dispersal request if not. | | FAILED | 5 | FAILED means that the blob has failed permanently. Note that this is a terminal state, and in order to retry the blob, the client must submit the blob again (blob key is required to be unique). |

Disperser

Disperser defines the public APIs for dispersing blobs.

Scalar Value Types

Protocol Documentation

Table of Contents

• node/node.proto

  • AttestBatchReply

  • AttestBatchRequest

  • BatchHeader

  • Blob

  • BlobHeader

  • BlobQuorumInfo

  • Bundle

  • G2Commitment

  • GetBlobHeaderReply

  • GetBlobHeaderRequest

  • MerkleProof

  • NodeInfoReply

  • NodeInfoRequest

  • RetrieveChunksReply

  • RetrieveChunksRequest

  • StoreBlobsReply

  • StoreBlobsRequest

  • StoreChunksReply

  • StoreChunksRequest

  • ChunkEncodingFormat

  • Dispersal

  • Retrieval

• Scalar Value Types

Top

node/node.proto

AttestBatchReply

AttestBatchRequest

BatchHeader

BatchHeader (see core/data.go#BatchHeader)

Blob

In EigenDA, the original blob to disperse is encoded as a polynomial via taking taking different point evaluations (i.e. erasure coding). These points are split into disjoint subsets which are assigned to different operator nodes in the EigenDA network. The data in this message is a subset of these points that are assigned to a single operator node.

BlobHeader

BlobQuorumInfo

See BlobQuorumParam as defined in api/proto/disperser/disperser.proto

Bundle

A Bundle is the collection of chunks associated with a single blob, for a single operator and a single quorum.

G2Commitment

GetBlobHeaderReply

GetBlobHeaderRequest

See RetrieveChunksRequest for documentation of each parameter of GetBlobHeaderRequest.

MerkleProof

NodeInfoReply

Node info reply

NodeInfoRequest

Node info request

RetrieveChunksReply

RetrieveChunksRequest

StoreBlobsReply

StoreBlobsRequest

StoreChunksReply

StoreChunksRequest

ChunkEncodingFormat

This describes how the chunks returned in RetrieveChunksReply are encoded. Used to facilitate the decoding of chunks.

Dispersal

Retrieval

Scalar Value Types

Protocol Documentation

Table of Contents

• validator/node_v2.proto

  • GetChunksReply

  • GetChunksRequest

  • GetNodeInfoReply

  • GetNodeInfoRequest

  • StoreChunksReply

  • StoreChunksRequest

  • ChunkEncodingFormat

  • Dispersal

  • Retrieval

• Scalar Value Types

Top

validator/node_v2.proto

GetChunksReply

The response to the GetChunks() RPC.

GetChunksRequest

The parameter for the GetChunks() RPC.

GetNodeInfoReply

Node info reply

GetNodeInfoRequest

The parameter for the GetNodeInfo() RPC.

StoreChunksReply

StoreChunksReply is the message type used to respond to a StoreChunks() RPC.

StoreChunksRequest

Request that the Node store a batch of chunks.

Algorithm for computing the hash is as follows. All integer values are serialized in big-endian order (unsigned). A reference implementation (golang) can be found at https://github.com/Layr-Labs/eigenda/blob/master/disperser/auth/request_signing.go

1. digest len(batch.BatchHeader.BatchRoot) (4 bytes, unsigned big endian) 2. digest batch.BatchHeader.BatchRoot 3. digest batch.BatchHeader.ReferenceBlockNumber (8 bytes, unsigned big endian) 4. digest len(batch.BlobCertificates) (4 bytes, unsigned big endian) 5. for each certificate in batch.BlobCertificates: a. digest certificate.BlobHeader.Version (4 bytes, unsigned big endian) b. digest len(certificate.BlobHeader.QuorumNumbers) (4 bytes, unsigned big endian) c. for each quorum_number in certificate.BlobHeader.QuorumNumbers: i. digest quorum_number (4 bytes, unsigned big endian) d. digest len(certificate.BlobHeader.Commitment.Commitment) (4 bytes, unsigned big endian) e. digest certificate.BlobHeader.Commitment.Commitment f digest len(certificate.BlobHeader.Commitment.LengthCommitment) (4 bytes, unsigned big endian) g. digest certificate.BlobHeader.Commitment.LengthCommitment h. digest len(certificate.BlobHeader.Commitment.LengthProof) (4 bytes, unsigned big endian) i. digest certificate.BlobHeader.Commitment.LengthProof j. digest certificate.BlobHeader.Commitment.Length (4 bytes, unsigned big endian) k. digest len(certificate.BlobHeader.PaymentHeader.AccountId) (4 bytes, unsigned big endian) l. digest certificate.BlobHeader.PaymentHeader.AccountId m. digest certificate.BlobHeader.PaymentHeader.Timestamp (4 bytes, signed big endian) n digest len(certificate.BlobHeader.PaymentHeader.CumulativePayment) (4 bytes, unsigned big endian) o. digest certificate.BlobHeader.PaymentHeader.CumulativePayment p digest len(certificate.BlobHeader.Signature) (4 bytes, unsigned big endian) q. digest certificate.BlobHeader.Signature r. digest len(certificate.Relays) (4 bytes, unsigned big endian) s. for each relay in certificate.Relays: i. digest relay (4 bytes, unsigned big endian) 6. digest disperserID (4 bytes, unsigned big endian) 7. digest timestamp (4 bytes, unsigned big endian)

Note that this signature is not included in the hash for obvious reasons. |

ChunkEncodingFormat

This describes how the chunks returned in GetChunksReply are encoded. Used to facilitate the decoding of chunks.

[KZG proof: 32 bytes] [Coeff 1: 32 bytes] [Coeff 2: 32 bytes] ... [Coeff n: 32 bytes]

The KZG proof is a point on G1 and is serialized with bn254.G1Affine.Bytes(). The coefficients are field elements in bn254 and serialized with fr.Element.Marshal().

References: - bn254.G1Affine: github.com/consensys/gnark-crypto/ecc/bn254 - fr.Element: github.com/consensys/gnark-crypto/ecc/bn254/fr

Golang serialization and deserialization can be found in: - Frame.SerializeGnark() - Frame.DeserializeGnark() Package: github.com/Layr-Labs/eigenda/encoding |

Dispersal

Dispersal is utilized to disperse chunk data.

Retrieval

Retrieval is utilized to retrieve chunk data.

Scalar Value Types

Protocol Documentation

Table of Contents

• relay/relay.proto

  • ChunkRequest

  • ChunkRequestByIndex

  • ChunkRequestByRange

  • GetBlobReply

  • GetBlobRequest

  • GetChunksReply

  • GetChunksRequest

  • Relay

• Scalar Value Types

Top

relay/relay.proto

ChunkRequest

A request for chunks within a specific blob. Requests are fulfilled in all-or-nothing fashion. If any of the requested chunks are not found or are unable to be fetched, the entire request will fail.

ChunkRequestByIndex

A request for chunks within a specific blob. Each chunk is requested individually by its index.

ChunkRequestByRange

A request for chunks within a specific blob. Each chunk is requested a range of indices.

GetBlobReply

The reply to a GetBlobs request.

GetBlobRequest

A request to fetch one or more blobs.

GetChunksReply

The reply to a GetChunks request.

GetChunksRequest

Request chunks from blobs stored by this relay.

The following describes the schema for computing the hash of this request This algorithm is implemented in golang using relay.auth.HashGetChunksRequest().

All integers are encoded as unsigned 4 byte big endian values.

Perform a keccak256 hash on the following data in the following order: 1. the length of the operator ID in bytes 2. the operator id 3. the number of chunk requests 4. for each chunk request: a. if the chunk request is a request by index: i. a one byte ASCII representation of the character "i" (aka Ox69) ii. the length blob key in bytes iii. the blob key iv. the start index v. the end index b. if the chunk request is a request by range: i. a one byte ASCII representation of the character "r" (aka Ox72) ii. the length of the blob key in bytes iii. the blob key iv. each requested chunk index, in order 5. the timestamp (seconds since the Unix epoch encoded as a 4 byte big endian value) |

Relay

Relay is a service that provides access to public relay functionality.

Scalar Value Types

Protocol Documentation

Table of Contents

• retriever/retriever.proto

  • BlobReply

  • BlobRequest

  • Retriever

• Scalar Value Types