Check out ourEigenLayer Dashboard

EigenLayer: EigenDA and EigenLayer Data Availability Unboxed

Published:
Last updated:

EigenDA and the Importance of Data Availability

Although EigenLayer is an Ethereum protocol largely focused on restaking, the protocol has perhaps more potential uses than any other blockchain system in the industry.

This is because the network furnishes a pooled security model that represents a fully interoperable connectivity layer designed to support a large number of independent protocols and service-focused AVSs, ultimately underpinning a vast plethora of real-world applications. To learn more about EigenLayer’s various utilities, read our blog post that provides a detailed analysis of the platform’s uses.

To better comprehend EigenDA and its potential applications, it's important to understand that the ability for a distinct network type to provide data to another independent party (i.e., for a protocol, middleware system, independent rollup network, application etc.) is called Data Availability, or DA.

While Actively Validated Services (AVSs) atop EigenLayer do make use of restaking and other constructs to guarantee their efficiency and security, ultimately, different AVS middleware platforms need access to specific data types to operate. This ability to provide data is required to increase AVS efficiency to complement and scale blockchains like Ethereum and others.

This is where EigenDA comes in. More specifically, EigenDA is a specialized proprietary AVS (that recently became the first of many AVSs to launch on EigenLayer) built to provide hyperscale data services to all AVSs operating within the larger EigenLayer network.

In addition, EigenDA offers high throughput and derives economic security through Ethereum operators and restakers. In the bigger picture nonetheless, EigenDA is able to provide data for any platform, protocol, or network operating on EigenLayer (see the link to our use cases article above to learn more).

Provisioned via EigenDA and its related infrastructure, hyperscale data availability (DA) is of critical importance to achieving the operational efficiency of a vast interconnected network of Actively Validated Services (AVSs) and rollups that call EigenLayer home. (Image Credit: Intro to EigenDA: Hyperscale Data Availability for Rollups via the EigenLayer blog) Provisioned via EigenDA and its related infrastructure, hyperscale data availability (DA) is of critical importance to achieving the operational efficiency of a vast interconnected network of Actively Validated Services (AVSs) and rollups that call EigenLayer home. (Image Credit: Intro to EigenDA: Hyperscale Data Availability for Rollups via the EigenLayer blog)

That said, the main use for EigenDA is as a data availability service for L2 rollup networks. Generally, rollups are able to obtain data availability from a Layer 1 like Ethereum or via an independent Data Availability (DA) layer. The current model however, poses many issues related to scalability, decentralization, customizability, data security, and economic serviceability.

In general, EigenDA supplies all-important transaction data to rollups, ensuring that this required data is fully available to be used by the node validation systems on various L1, L2, and L3 networks. This design allows rollups to be able to share data with dApps operating on their network in a lightweight, fast, secure, permissionless, and decentralized manner.

Overall, validators encompassing Proof of Stake (PoS) blockchains like Ethereum must be able to verify all transactions within a proposed block. The presence of DA guarantees that all transaction data is readily available for all necessary network participants, including validators that must verify the next block in the correct sequential order.

Ethereum validators are generally required to download and store all transaction data on-chain. This makes sense because of the fact it allows all participants to be able to verify the existing state of the block by reviewing historical transaction data. The problem with this approach however, is that this model is not scalable. Case and point, as a larger number of transactions are amended and stored on the network over time, network performance is adversely affected, limiting overall efficiency in the process.

Therefore, EigenDA helps solve Ethereum’s scalability issues associated with congestion and high costs as the increasing number of transaction data requirements atop a plethora of network types grows (think L1s, various L2s, and other protocol types). EigenDA acts as a hyperscale rollup transaction storage platform that allows transactions to be stored prior to their computed state being finalized on a rollup bridge and being disseminated to their intended destinations.

EigenDA Design and Ethereum Ecosystem Considerations

In order to simultaneously provide this all-important data to so many protocols, networks, applications, and the like, EigenDA must be extremely advanced in technological terms. For this reason, EigenDA possesses the following characteristics:

  1. Hyperscalable: EigenDA write throughput scales linearly in relation to the number of operators on EigenLayer. This allows EigenDA to provide 10 MB/s of write throughput (5x higher than its nearest competitor). This means hypothetically, that n nodes (with n representing a fixed number) in a system, with C being considered as network bandwidth, that the system data rate should be nC/2. In addition, each node only downloads a very limited portion of the network’s total data and if any of the network’s nodes go offline or act maliciously, they are able to retrieve all originating data.
  2. Low-cost: Because each node is only downloading a portion of the data, the cost for data transfer and data use on EigenDA is extremely low. On most rollup systems, this means that the sequencer must utilize all appropriate data before it disperses it and sends it to the rollups via the DA layer. Consequently, atop EigenDA, the cost incurred to the entire DA layer should be only 2 times the cost of a single node downloading and storing it.
  3. Low-latency: Time to confirm data availability must be at native network efficiency, which is typically much smaller than block latency. Remember, the lower a system’s latency, the faster data is processed in most instances.
  4. Verifiable: As is customary with any computing network, cryptographic verifiability ensures the integrity of the entire system. Thus, on EigenLayer, light nodes with very little computational and network serviceability should be able to verify whether the DA layer is complying honestly or not.
  5. Customizable: EigenDA is built to allow applications to permissionlessly customize safety/liveness tradeoffs, token staking modalities, erasure code, and token-economic utility for fee payment on the DA layer.
  6. Decentralized: EigenDA is modeled after Danksharding, which is designed to scale Ethereuem-native DA well beyond EIP-4844. Using this model, EigenDA blob writes are registered upon Ethereum smart contracts, natively subjecting operators to specific slashing risks should they act maliciously.
  7. Secure: EigenDA is decentralized and constitutes hundreds of operators registered on EigenLayer. Each operator's delegated stake enforces an economic cost to misbehavior, meaning dishonest operators are slashed if they don't abide by the network's guidelines.
Although initially built to support the data availability needs of Ethereum rollups operating on EigenLayer, EigenDA furnishes accessibility to data availability for a plethora of AVSs of all shapes and sizes. That said, a month after EigenDA’s mainnet launch in April of this year, EigenDA opened accessibility for the final testing stages of rollup deployment prior to production-ready mainnet deployment. (Image Credit: Onboarding Rollups to EigenDA via the EigenLayer blog) Although initially built to support the data availability needs of Ethereum rollups operating on EigenLayer, EigenDA furnishes accessibility to data availability for a plethora of AVSs of all shapes and sizes. That said, a month after EigenDA’s mainnet launch in April of this year, EigenDA opened accessibility for the final testing stages of rollup deployment prior to production-ready mainnet deployment. (Image Credit: Onboarding Rollups to EigenDA via the EigenLayer blog)

According to Eigen Labs CEO Sreeram Kannan (read more on the founding of EigenLayer in our 3rd installment of this series), EigenDA is the first system to achieve the above characteristics, making it a leading-edge solution for the data availability needs of a wide range of applications and services.

Atop EigenDA, restakers are able to delegate stake to node operators performing validation tasks for EigenDA in exchange for service payments, while rollups can append data to EigenDA as a means to access reduced transaction costs, increased transaction throughput, and secure composability throughout the larger EigenLayer ecosystem. This allows the system to horizontally scale throughput and security in proportion to the amount or retaked assets and operators that have opted into servicing the protocol.

When the Eigen Labs team first chose to build EigenDA, it was critical to look at the overall larger picture and create a mental image of how the platform would contribute to the Ethereum ecosystem moving forward.

First, EigenDA was conceptualized to represent an innovative rollup DA solution that complements the Ethereum scaling endgame in a manner that allows security to be derived from, and value sent back to Ethereum stakers and validators, ensuring a synergistic and mutually beneficial relationship for all participants.

Secondly, the platform was built as a high throughput and low cost paradigm focused on realizing a plethora of new on-chain use cases. Case and point, as it relates to rollups specifically, EigenDA is built to provide a framework that provisions the expansion of applications across multiplayer gaming, video streaming, social networks, and much more, while using a flexible cost model that encompasses both variable and fixed fees.

Thirdly, EigenDA was built as an infrastructure that protects the decentralization of EigenLayer’s larger network. Often in shared security systems like EigenLayer, if all node operators within the network are required to download and store all intersecting chains atop the platform, a proportionately small amount of node operators will be able to keep up with the continued growth, meaning the system has the risk of eventually becoming centralized.

EigenDA is built to eliminate this centralizing trend by achieving high-performance, while distributing work across a large number of participating nodes to ensure each operator is only required to accomplish a small amount of work in proportion to the larger network.

Lastly, EigenDA was developed as a proof point to provision the power of decentralized trust. This is accomplished by demonstrating that Ethereum validators and stakers alike are able to support crucial Ethereum infrastructure and Ethereum consensus, while also providing a system that allows AVSs (such as EigenDA) and AVS users (such as rollups using EigenDA) to succeed by developing new business and token models that are modular in nature atop the Ethereum trust network.

If you’d like to truly understand the overall value proposition of EigenLayer and why it's important, consider having a look at both our first and second blog posts in this series.

How Does EigenDA Work?

Essentially, the core insight of EigenDA is that the challenge of data availability doesn't necessitate independent consensus to solve. Therefore, as it relates to the development of a decentralized data store for Ethereum rollups, Ethereum is used for many aspects of coordination, while data storage is independently managed by EigenDA operators directly.

Of crucial importance, this approach allows EigenDA to scale in a linear manner. As it relates to a L1 blockchain, increasing throughput means either decreasing block times or increasing block size. Beyond a specific point, increases in scalability come at the expense of decentralization or security (i.e., the blockchain trilemma).

One way of solving this trilemma is via an emphasis on L2s, where data availability can be transferred off-chain in a manner that transaction data does not need to be dispersed to all nodes within the system. Rather, only DA metadata and accountability processes are processed off-chain, allowing DA to scale in relation to the bandwidth of the operator set.

The above illustration shows the flow of data between restakers, operators, EigenDA, and independent rollups. In sequential order, users restake ETH which is delegated to operators, operators then validate EigenDA, and finally, EigenDA provides data availability to sovereign rollups operating within the larger EigenLayer network. (Image Credit: Launch of the Stage 2 Testnet: EigenLayer & EigenDA via the EigenLayer blog) The above illustration shows the flow of data between restakers, operators, EigenDA, and independent rollups. In sequential order, users restake ETH which is delegated to operators, operators then validate EigenDA, and finally, EigenDA provides data availability to sovereign rollups operating within the larger EigenLayer network. (Image Credit: Launch of the Stage 2 Testnet: EigenLayer & EigenDA via the EigenLayer blog)

To function as intended, EigenDA utilizes three main components:

  • Operators - entities hosting node validation services atop the EigenLayer network
  • The Disperser - an API responsible for dispersing and retrieving blobs to and from the EigenDA network
  • Retrievers - a service that is responsible for querying, verifying, and retrieving data blobs on EigenDA

EigenDA operators are third-party service providers (holding delegate stake) registered on EigenLayer responsible for running EigenDA node software. More importantly, EigenDA operators are in charge of storing blobs (data storage units) accompanying valid storage requests.

Valid storage requests are requests where fees have been paid whereby the provided blob chunk is verified in conjunction with the associated KZG commitment and cryptographic proof. In the event of a successful verification, the operator retains the blob and signs a message via the KZG commitment and the chunk index in their possession and sends it back to the disperser.

As an interconnected group, EigenDA operators are jointly trusted, meaning that when a client (an AVS or independent protocol) writes a blob to EigenDA, they must choose the exact threshold stake that they’d like to store their blob within.

The EigenDA dispenser is a specialized API hosted by EigenLabs that allows for seamless connectivity between EigenDA operators, clients, and contracts.

The disperser is responsible for dispersing and retrieving blobs to and from the EigenDA network. More specifically, EigenDA clients produce dispersal requests to the disperser which Reed-Solomon encodes the blob, calculates the encoded blob's KZG commitment, and generates a KZG proof pertaining to each specific chunk.

Next, the disperser sends chunks, KZG commitments, and KZG proofs to operators, which are returned shortly thereafter with the required digital signatures. In succession, each of the previously sent signatures are aggregated by the disperser and uploaded to Ethereum as call data to the EigenDA contract (a necessary precondition that allows for the potentiality to slash operators for misbehavior).

Finally, the EigenDA retriever is a service that queries (searches for) EigenDA operators for blob chunks, verifies their legitimacy, then reconstructs the original blob for the user. As the primary source for this service, EigenDA hosts a retriever. However, client rollups are also able to host their own sequencer-connected retriever should they choose to.

EigenDA Data Flow and Rollup Integration

To better explain how how EigenDA integrates rollups into the platform, let’s look at the sequential flow of data within the system:

  1. First, the rollup sequencer sends a transaction batch (as a blob) to the EigenDA disperser sidecar.
  2. Then the EigenDA disperser sidecar erasure encodes the blob into separate chunks, generates a KZG commitment and cryptographic proofs for each chunk, disperses these chunks to EigenDA operators, then receives storage-certifying signatures in return.
  3. After fulfilling the signature aggregation process, the disperser registers the blob on-chain by sending the transaction to the EigenDA Manager contract comprising the aggregated signature and blog metadata.
  4. Next, the EigenDA Manager contract cryptographically verifies the aggregated signature via the EigenDA Registry contract, storing the result on-chain.
  5. After the blob has been stored off-chain and registered on-chain, the sequencer appends the EigenDA blob ID to its inbox contract within a transaction (with the blob ID being no more than 100 bytes in length)
  6. Finally, prior to accepting the blob ID into the rollup’s inbox, the inbox contract consults the EigenDA manager contract to determine if the blob is certified available. Provided it is, the blob ID is accepted into the inbox contract. Conversely, if it isn’t, the blob ID is discarded. If successful, the rollup receives the appropriate data it needs to enhance its independent rollup network.
The above diagram explains the data flow between EigenDA, the Ethereum blockchain, various EigenDA contracts, operators, rollup sequencer nodes, and the cryptographic signature creation and finalization process. (Image Credit: EigenDA Overview via EigenLayer docs) The above diagram explains the data flow between EigenDA, the Ethereum blockchain, various EigenDA contracts, operators, rollup sequencer nodes, and the cryptographic signature creation and finalization process. (Image Credit: EigenDA Overview via EigenLayer docs)

EigenDA’s Continued Evolution

Ethereum stakers provide the foundational user base of the EigenLayer and EigenDA platforms. By adopting EigenDA, rollups are able to align with these Ethereum stakeholders because of the fact they value censorship-resistance, decentralization, accessible open-source software, and permissionless, composable innovation.

Therefore, by creating a DA solution focused on equitable economics, high throughput, robust security, and full customizability, EigenDA represents a leading-edge solution to the continually changing data needs of rollups of all shapes and sizes. As Ethereum-focused L2s such as Arbitrum, Optimism, and others continue to grow and evolve over time, their data needs will expand exponentially.

This means L2 platforms will have a continuous requirement for secure, accessible, non-corruptible data that allows for the creation and usability of rollups built for a nearly endless number of uses.

While EigenDA is primarily used for rollups, the fact remains however, that EigenDA is able to support a vast number of AVSs, networks, and protocols of all shapes and sizes.

With this modular interoperable design, the larger EigenLayer network is built to support uses such as decentralized sequencing, fast finality, watcher and data relay networks, bridging, fair ordering, and artificial intelligence, along with threshold cryptography, threshold-FHE, MEV management, and much more.

As the first of many AVSs to operate on EigenLayer, EigenDA represents a highly advanced paradigm focused on serving the data needs of the continually evolving EigenLayer and Ethereum ecosystems. If EigenLayer’s almost overnight explosion to 20 billion in total value locked (TVL) is any indication, it seems inevitable this trend will continue for the foreseeable future.

Resources

Website

Blog

Whitepaper

Twitter

Documentation

LinkedIn

YouTube

Forum

GitHub

Discord