In the dynamic world of blockchain technology, understanding the evolving landscape is crucial for stakeholders. Scalability on Ethereum is about to take a big step forward with EigenDA, a pioneering data availability layer set to be the first Actively Validated Service (AVS) launched on EigenLayer. This development is not just a technical leap but a strategic enhancement that could significantly impact how transactions and data are managed on Ethereum, particularly for rollups.

EigenDA offers a compelling solution to data availability that complements Ethereum’s existing infrastructure. Its launch promises to expand the capabilities of rollups, enhancing the scalability, efficiency, and privacy of transactions. This exploration delves into the core of EigenDA, demystifying its functionality and exploring its potential to shape the future of Ethereum.

What is EigenDA?

EigenDA is a decentralized data availability service, and the first Actively Validated Service (AVS) to be launched on EigenLayer in early Q2 2024. For more on EigenLayer check out our separate writeup EigenLayer: First Look.

Let’s start with the status quo before getting into EigenDA: What does it mean for rollups to use Ethereum as their data availability layer? 

Today users bridge their ETH to rollups. These rollups can be thought of as their own networks where users engage in all kinds of transactions (i.e., playing games, using DeFi applications, etc.) the same way they do on Ethereum. The rollups batch and post transaction information to Ethereum. These transactions are not replayed on the base layer of Ethereum, rather the information is available so that anyone wanting to recreate and verify the state transition on the rollup are able to (such as with specific software they can validate the state transitions on the rollup).

You can think of this as posting a receipt of sorts to Ethereum. This allows rollups to inherit some of the security characteristics of Ethereum but also allow much cheaper transactions. These savings come from batching transactions and data compression; in other words, the rollups minimize the amount of data they need to store on Ethereum as much as possible.

(Source)

EigenDA performs this function by essentially “storing the receipts” on Ethereum. Importantly, though, it greatly increases the amount of data available for rollups and relies on a different set of operators to verify the data. There is a significant amount of overlap between Danksharding and EigenDA. 

There are two more important differences between the two though. Danksharding is likely still at least two years away and EigenDA is likely to launch in the next few months while Danksharding will rely on Ethereum validators to confirm data availability (through data availability sampling), EigenDA relies on node operators.

How Will it Work?

Rollups send data blobs to the disperser; you can think of data blobs as similar to the “receipts” mentioned above. The disperser does much of the heavy lifting in terms of preparing the data blobs and providing proofs; EigenDA node operators are not responsible for running the disperser, this will likely be run either by EigenLayer or the users of EigenDA, i.e., the rollups. The node operators on EigenDA receive data chunks (think of these as pieces of the blob) and compare these against the KZG commitment and proofs. The node operator generates a signature and sends it to the disperser.

In more basic terms, the disperser takes the “receipt,” makes some modifications to it, divides it into pieces (i.e., chunks), and distributes them among the operators. The disperser also provides ‘guidance’ on how to verify the data (i.e., the KZG commitment) and a proof that the data is accurate. The node operator is able to use all of these pieces – the chunk, KZG commitment and the proof – to quickly verify the validity of the chunk and reflect that back to the disperser. For more details see here.

What Operators Should Know

Each Actively Validated Service (AVS) in the EigenLayer ecosystem should be treated as its own network in terms of diligence and operation. For more info on running an operator on EigenDA see here.

The top 200 node operators by delegated stake will be in the active set. Being below this threshold, or falling below it, means the operator will be outside of/removed from the active set and, therefore, not receiving rewards.

In addition to being in the top 200 by delegated stake, there are performance expectations of operators, which also depends on size. Failing to meet these performance requirements will result in being ejected from the active set.

*Percentage of active stake vs. total stake. This will be monitored by how much stake has signed the last batch.

(Source)

If an operator has been ejected it is possible to opt in again. Hardware requirements depend on the proportion of delegated stake each operator has:

(Source)

(source)

Node operators will be required to store data for two weeks. As a result of the supported throughput, the following storage is recommended:

(Source)

To get a sense of costs, readers can determine their hardware requirements and then review their preferred hardware providers’ site (as an example only, here is a reference).

How does this compare to running a validator on Ethereum? In terms of required hardware on Ethereum, the execution layer (EL) client and the consensus layer (CL) client make up the majority of resource use. Much depends on the clients chosen, but a decent starting point would be a machine with:

• Quad-core (i.e., 4 processors)
• 16 GB of RAM
• 2 TB of storage
• 100Mb/s download, 20Mb/s upload

Here are some references for various Ethereum clients and their associated hardware requirements: EL (geth, besu, erigon, nethermind), CL (Prysm, Lighthouse, Nimbus, Lodestar).

Beacon node requirements (EL + CL) are close to the middle node requirements on EigenDA (i.e., 0.2% of stake or less). Greater hardware resources are required when moving to the largest node size (i.e., 20% of stake) compared to running a Beacon Node.

Compared to the duties performed by a validator on Ethereum, node operators’ duties are much less varied, though it is expected that they will be more frequent (based on testnet experience, node operators will be required to confirm a chunk’s validity and send a signature to the disperser about every 60 seconds). 

As a comparison, validators on Ethereum make attestations once every 6.4 minutes on average; exceptionally, sync committee requires a validator to sign every 12 seconds, but these duties are rare – a group of 512 validators (of about 940,000 today) are chosen to participate in sync committee every ~27.3 hours.

In terms of operation, EigenDA does require access to a beacon node. There might be some flexibility in terms of whether you run a node specifically for EigenDA or use a public node/subscribe to a node service. It’s also worth bearing in mind that the EigenLayer operator CLI requires access to a beacon node as well. As a result, an operator sharing a beacon node between these two tasks, would (potentially) not require any additional resources to run EigenDA.

In spite of the requirement for a beacon node, EigenDA is effectively run on one piece of software. Running one piece of software versus three (such as in the case of an Ethereum validator) means that monitoring and troubleshooting burdens are less. See here for more details about monitoring EigenDA.

What Restakers Should Know

While not a lot is known about the risk/reward profile on EigenDA yet, it’s likely that there will be some penalty for failing to perform as expected (beyond being ejected from the active set as above). These penalties will be levied on the restakers – the staked ETH holders that have delegated this ETH to an operator.

Whenever a restaker is thinking about delegating to an operator, a thorough due diligence process must be undertaken. At a minimum a restaker should know: 

• an operator’s history running infrastructure on other networks and their track record – both in terms of performance but also slashing/penalty incidents. 
• what the operator’s AVS policy is – what criteria are used to add/remove AVSs; this is especially critical for public operators, where communication between the operator and the delegator (i.e., restaker) could be low or non-existent.
• the details on each AVS the operator is running or intends to run. This document serves as a minimum starting point, for instance.

Conclusion

In conclusion, the advent of EigenDA represents a significant milestone in the evolution of Ethereum’s ecosystem, offering a promising solution to the challenges of scalability and data availability. Both node operators and restakers must familiarize themselves with the nuances of EigenDA. 

Understanding its operational dynamics, hardware requirements, and the potential risks and rewards involved is crucial for making informed decisions. As EigenDA gears up for launch, its success will hinge on the collaborative efforts of the community—operators ensuring robust and efficient network performance, and restakers conducting diligent due diligence. Together, these efforts will fortify Ethereum’s infrastructure, paving the way for a more scalable, secure, and interconnected blockchain ecosystem.

The information herein is being provided to you for general informational purposes only. It is not intended to be, nor should it be relied upon as, legal, business, tax or investment advice. Figment undertakes no obligation to update the information herein.