Security Model
Introduction
EigenDA is a high-throughput, decentralized data availability (DA) layer built on EigenLayer, designed to ensure that any data confirmed as available by the protocol can be reliably retrieved by clients. The system distinguishes between two core failure modes:
- Safety failure: The DA layer issues a valid availability certificate, but users are unable to retrieve the corresponding data.
- Liveness failure: Data that should be available—i.e., properly paid for and within system throughput bounds—is not served to users.
EigenDA mitigates these risks through a BFT security model backed by restaked collateral. Operators participating in the DA layer are delegated stake via EigenLayer, including ETH, EIGEN, and customized tokens.
Additionally, EIGEN slashing introduces strong accountability: in the event of a safety failure, stake can be slashed, penalizing operators who sign availability attestations for data they do not actually serve. Extra economic alignment is also provided by token toxicity.
On this page, we present a technical analysis of EigenDA's security guarantees. We use the terms validator and operator interchangiblity in this document.
Cryptographic Primitives
The encoding module is used for extending a blob of data into a set of encoded chunks which can be used to reconstruct the blob. The correctness of the encoding is proven by the proving module. The encoding and proving module needs to satisfy two main properties:
- Any collection of unique, encoded chunks of a sufficient size can be used to reconstruct the original unencoded blob.
- Each chunk can be paired with an opening proof which can be used to verify that the chunk was properly derived from a blob corresponding to a particular commitment.
To achieve these properties, the module provides the following primitives:
EncodeAndProve
. Extends a blob of data into a set of encoded chunks. Also produces opening proofs and blob commitments.Verify
. Verifies a chunk against a blob commitment using an opening proof.Decode
. Reconstructs the original blob given a sufficiently sized collection of encoded chunks.
EigenDA implements the encoding module using Reed Solomon encoding, together with KZG polynomial commitments and opening proofs. More details about the encoding and proving module can be found in the code spec.
Quorums and Security Models
In EigenDA, there are three different kinds of quorums where different assets (restaked-ETH, EIGEN and customized tokens of roll-ups) are delegated to the operators. Different quorums provide different security guarantees. All three kinds of quorums must simultaneously fail for a safety attack to be successfully executed, providing multi-layered security assurance.
The three security models in EigenDA, along with their corresponding quorums, are outlined below:
- BFT security: ETH, EIGEN and Custom Quorum
- Cryptoeconomic security: EIGEN Quorum
- Token Toxicity: Custom Quorum
We begin by giving an overview of each security model and how it contributes to EigenDA’s overall resilience: BFT security ensures both safety and liveness of the system as long as the share of stake or voting power held by malicious validators stays below a certain threshold. Cryptoeconomic security goes a step further—if an attacker misbehaves, they not only need to control a significant amount of stake, but they also risk losing it through slashing. This makes attacks financially unappealing. Token toxicity adds another layer of incentive alignment. When validators misbehave, the native token may drop in value, leading to losses for token holders who delegated their stake to those validators. This dynamic encourages stakeholders to carefully choose trustworthy operators.
In the rest of this page, we provide a detailed analysis of how the three kinds of security are satisfied.
BFT Security Model
The BFT security model ensures system safety and liveness as long as the stake delegated to malicious validators remains below a predefined threshold. We begin by analyzing the reconstruction guarantee of our chunk assignment algorithm, and then proceed to prove the BFT security of EigenDA.
Chunk Assignment Algorithm
In this section, we describe how the encoded chunks are allocated to each validator based on their stake, and prove the reconstruction property of the assignment.
Parameters
The allocation of data among the EigenDA validators is governed by chunk assignment logic which takes as input a set of BlobParameters
which are linked to the blob Version
by a mapping in the EigenDAServiceManager
contract. The BlobParameters
consist of:
NumChunks
- The number of encoded chunks that will be generated for each blob (must be a power of 2).CodingRate
- The total size of the encoded chunks divided by the size of the original blob (must be a power of two). Note that for representational purposes, this is the inverse of the standard coding rate used in coding theory.MaxNumOperators
- The maximum number of operators which can be supported by the blobVersion
.
The chunk assignment logic provides the following primitives:
GetChunkAssignments
. Given a blob version and the state of the validators, generates a mapping from each chunk index to a validator.VerifySecurityParameters
. Validates whether a given set of security parameters is valid with respect to a blob version.
For the purposes of modeling, we let denote the number of chunks which the assignment logic maps to an operator . We also denote the NumChunks
defined by the blob version as , the CodingRate
as , and the MaxNumOperators
as . Any set of unique chunks can be used to recover the blob. We let , which is the number of chunks assigned to validator , divided by the number of chunks needed to recover the blob. We also denote as the percentage of quorum stake which is assigned to the validator . The minimum percentage of the total stake that a group of validators must collectively hold in order to possess enough chunks to recover the blob is denoted by . The key terminology is summarized below for reference:
Term | Symbol | Description |
---|---|---|
Max Validator Count | The maximum number of validator nodes participating in the system (currently ) | |
Validator Set | Set of all the validators. is the total number of validator nodes participating in the system. | |
Total Chunks | The total number of chunks after encoding (currently ) | |
Coding Rate | The total number of chunks after encoding / total number of chunks before encoding (currently ) | |
Percentage of blob per validator | , the percentage of chunks required to reconstruct the blob assigned to validator in a quorum | |
Num of Chunks Assigned | The number of chunks assigned to validator in a quorum | |
Validator Stake | The stake proportion of validator in a quorum (, and ) | |
Reconstruction Threshold | The minimum percentage of total stake required for a group of validators to successfully reconstruct the blob |
Properties for a Single Quorum
We start by describing the chunk assignment logic and the properties we aim to satisfy within a single quorum. For each quorum, the assignment algorithm is designed to satisfy the following properties:
- Non-overlapping assignment: .
- Reconstruction: If a blob passes
VerifySecurityParameters
, then for any set of validators such that