The introduction of EigenLayer and the resulting Actively Validated Services (AVS’) create new design considerations and requirements specific to their native token systems. This article explores those design considerations by comparing EigenDA, a data availability AVS, with an external modular data availability solution, Celestia. This comparison aims to highlight the changes in token responsibilities between an AVS’ and their equivalent, independent solutions. Although both protocols are addressing the same problem, their architectures necessitate different requirements from their native tokens.

Introduction to EigenLayer

EigenLayer is a general-purpose marketplace for decentralized trust built on the largest programmable decentralized trust network, Ethereum. It unbundles the trust layer of Ethereum so components of the network can be reused for other purposes. In order for AVS’ to use the security strength already established in Ethereum’s network, stakers need to “restake” their staked ETH (or liquid staked ETH) , opting into additional slashing conditions unique to each AVS. In this sense, EigenLayer is a marketplace that leverages Ethereum’s validator network to enable its reuse for other protocols.

Source: EigenLayer whitepaper

The deceptively simple function of restaking unlocks efficiencies both for protocols currently within the Ethereum ecosystem and protocols outside the ecosystem:

i) Current Ethereum based applications that decide to outsource their security to Eigenlayer are now more economically efficient by integrating with the protocol and re-using the Ethereum capital stake to secure their dAPP/ network whilst also gaining higher throughput and scalability.

ii) Applications that were not economically viable within the bounds of the Ethereum network due to scalability restrictions, will now potentially be economically viable since security/trust of the system can be outsourced to the Ethereum “restakers”- gaining the security and decentralisation of Ethereum validators themselves. Some of these include: consensus protocols, data availability layers, virtual machines, keeper networks, oracle networks, bridges, threshold cryptography schemes, and trusted execution environments.

iii) Rollups built on EigenLayer have specific advantages. New virtual machines tailored to the roll up can be implemented whilst still using Ethereum trust guarantees. In addition, it inherits full safety and liveness attributes from Ethereum through Eigenlayer due to the full L1 state being locally available. The rollups facilitate easy building and deployment processes, streamlining the development and integration of applications. However, it’s worth noting that there is no “default” safe bridge to Ethereum, which might pose a challenge.

Source: How to build new VMs and rollups using eigenDA

EigenLayer introduces many advantages for applications and networks by gaining access to Ethereum’s security while removing constraints caused by its network congestion. However, in a crypto market where protocol tokens are a key tool for protocols to bootstrap and incentivise their own validator network and economic security layer, this begs the question: What is the role of protocol tokens within AVS’ built on top of EigenLayer?

This article compares an AVS (EigenDA) to its independent equivalent DA solution (Celestia) with the aim of building a framework to begin to decipher AVS specific token design requirements.

The Data Availability Problem on Ethereum

To illustrate the design differences for external network tokens vs Eigenlayer AVS tokens, we can examine two of the Ethereum data availability solutions both within and external to the Eigenlayer protocol.

The “data availability problem” in Ethereum refers to the challenge of proving that the records of transactional details exist and are available if needed, without actually downloading them. This is particularly relevant due to the growing number of “layer 2” networks. As the number of these networks increases, so does the amount of transactional data on mainnet which accelerates the mainnet DA congestion.

The four main solutions to the data availability problem currently being developed are:

• EIP 4844 (Proto-Danksharding)
  This is a proposed network update for Ethereum that aims to reduce transaction fees and increase throughput by introducing a new transaction type called a blob-carrying transaction, which holds large fixed-size blobs of data, providing a framework for future implementation of sharding on the Ethereum blockchain.
• Modular DA focused blockchains
  DA focussed blockchains like Celestia introduce a modular blockchain architecture, specializing in data availability. Celestia simplifies the deployment and maintenance of blockchains, and offers customization options in the aim of improving scalability for Web3 applications. It ensures data availability through a technology called data availability sampling, allowing users to verify large blocks. It enables anyone to power their own blockchain without having to bootstrap proprietary consensus and DA. Additionally, Celestia works with existing rollups, fostering a collaborative environment with interconnected chains, thereby creating value for the entire modular ecosystem.
• Layer 2 chains (rollups) \
  Layer 2 solutions such as Arbitrum, Optimism and zk rollups reduce the cost of data availability by processing transactions off-chain and posting compressed batches of these transactions to Ethereum. This method decreases congestion on the base layer and reduces fees. However, to ensure trust, the state change proposed must be independently verifiable, requiring the transaction data to be available.
• EigenDA
  EigenDA, developed by EigenLayer and based on the core technology of proto-danksharding, is a data availability (DA) layer for Ethereum that acts as middleware to ensure data is accessible for nodes. It operates by breaking up the calldata, which is a significant cost factor for rollups, into small chunks. This system uses zero knowledge proof concepts to allow each node to download only a small chunk of data, and even if half the nodes leave, the system remains unaffected, as the full data state can still be reconstructed.

EigenDA and Celestia specifically both provide the consensus and DA framework for modular components to build on top of them. However, there are key design differences that change the role of a native token in their respective ecosystems.

Celestia

Overview

Celestia is designed as a scale-out data availability-focused blockchain. It uses data availability proofs with erasure codes; a mathematical primitive that makes sharding secure. This allows the Celestia data availability layer to scale like sharded blockchains for block verification.

Source: Celestia

Celestia can be defined by two major components:

1. A native consensus mechanism: consisting of full nodes and light nodes in a highly scalable POS architecture.
   Light Nodes: Celestia light nodes use a block encoding scheme called Data Availability Sampling (DAS) that allows them to verify with high probability that the rest of the block has been published by only sampling a small random sample of block data. It works by having light nodes conduct multiple rounds of randomised sampling for small segments of block data. Once this process is repeated until the light node reaches a predetermined confidence interval, it will consider the block data available. Many light nodes doing this allows the system to prove consensus without downloading the entire blockchain and still retaining high levels of security.
   Full Nodes: If any full node detects something suspicious, they can notify light clients with a data availability fraud proof. In addition, the light clients don’t verify transaction data as Celestia only verifies consensus and DA.
   The light nodes play a fundamental role in the security and scalability of the network as a whole. As the number of light clients increases, the size of each block can also increase without compromising the security or decentralization of the network. This leads to more data throughput and more scaling.
2. Modular data availability layers: Celestia aims to help build a blockchain ecosystem with modular data availability layers and execution engines that can be integrated together. This is seen as the next generation of scalable blockchain architectures. It does this by reducing the problem of block verification to data availability verification, which can be done efficiently with sub-linear cost using data availability proofs. This leads to an interesting consequence: the more clients you have in the network, the greater the block size (and thus throughput) you can have securely.

Due to Celestia being a completely independent blockchain to Ethereum mainnet in order to provide a modular DA scalability solution, it requires its own infrastructure. This includes a distributed set of validators.

Eigen DA

Overview

To solve the DA problem mentioned above, the EigenLabs team has developed EigenDA. It is a middleware implementation that ensures that data is available for nodes to access. There are multiple DA layers, and re-stakers can opt into any layer they wish (by opting in they are responsible for ensuring that the data is valid). These restakers will then attest to the state of the data.

EigenDA has two main components to its architecture:

1. An Eigenlayer Consensus mechanism: ETH stakers can opt-in to validating the EigenDA network and accept EigenDA specific slashing conditions. These “Eigen pods” then function as POS validators that attest to the state of the network.
2. Data Availability Layers: EigenDA breaks up the calldata (the most dominant costs for rollups) into small chunks and performs erasure coding and KCG polynomial commitments (the basic core of zk proofs) on the chunks to facilitate a system where each node only downloads a small chunk of data and even if half the nodes leave, it won’t affect the system — they are still able to reconstruct the full data state. They can do this because erasure coding enables the full data state to be reconstructed even if some chunks are missing and the KCG proof ensures the chunk they received is the same as the chunk the node claimed.

Performance

Source: How to build new VMs and rollups using EigenDA

EigenDA is constructed upon the fundamental concepts of danksharding, which were originally developed by the Ethereum team, as the core technology. Because EigenDA is not burdened with the native constraints of Ethereum, it can process data at a multiple of 200x times that of mainnet. EigenDA is only able to do this because it doesn’t have to host its own consensus and security.

EigenDA Advantages

When building on EigenDA vs building traditional rollups with mainnet DA, there are a different set of challenges that must be solved for. Traditional rollups face challenges in competing with Layer 1 solutions (L1s). There are several reasons for this. Firstly, the primary cost factor for rollups is the DA component. Furthermore, the cost of DA becomes uncertain when rollups leverage the DA layer of L1s because they are sharing a common DA layer with other providers. Additionally, rollups incur upfront costs, whereas L1s have the advantage of having their costs paid in a token that they have native control over.

Alternatively, the EigenDA solution presents a different approach. It offers a solution with significantly low costs as there are next to no capital costs involved in network bootstrapping, and only a fraction of the full data state needs to be downloaded. Moreover, EigenDA makes it possible to reserve DA in advance if there will be a known high DA requirement for an application or network. A long-term DA reservation provides cost certainty. In this solution, it is also possible to pay DA fees using the native token, given that the EigenLayer validators accept it. This enables better financial management and control over incentives, including the ability to address inflationary concerns.

EigenDA vs Celestia Token Considerations

Although EigenDA and Celestia propose solutions to the same problem, their architecture and design is quite different in implementation and they therefore have different requirements of a native token.

Celestia

Celestia provides a DA and consensus base for modular execution and settlement environments to use its infrastructure. It’s a POS system with some innovations around novel Data Availability Sampling (DAS) technology that enables its light nodes to prove consensus without downloading the entire blockchain and retaining security. Despite this, it still requires staked capital and fees in the form of a native token.

This token will most likely function similarly to POS tokens we are familiar with such as Ethereum. They have a fee burn mechanism similar to EIP-1559, so that burned fees will offset new token issuance as the network gains adoption. The token will also likely be used for governance in making large changes to the network and used in reaching consensus around community decisions.

EigenDA

EigenDA leverages the capital stake of Ethereum stakers to reuse the shared security for its own purposes and so it mitigates a lot of the capital issue that Celestia experiences. However, this also removes the necessity of a native token for the core functionality of a traditional POS platform. Despite this, there are some potential avenues where an EigenDA token adds a lot of value:

1. EigenLayer must have attributable, objective slashing conditions to avoid “overloading Ethereum’s consensus” as Vitalik Buterin states, this means that social consensus specific to EigenDA must be covered by something outside of the Ethereum capital stake. This creates the opportunity for an EigenDA token that enables network specific social consensus.
2. Payment token: If EigenLayer validators accept it, the native token can be used as a DA payment token. This will enable a higher level of financial management over incentives and reduce inflationary concerns. It could also be used in DA reservation in either a set price or auction style mechanism that enables applications to have DA certainty for high traffic periods.
3. If EigenDA token is used for social consensus, the EigenDA token could be implemented as a dual staking system for “dual quorum”, as mentioned in the most recent EigenDA article, if stakers were happy to receive the native token as reward.
4. For a network of EigenLayer AVS’, shared security and attributable assurances provide the best of both worlds in terms of security. AVS’ built on EigenLayer need a shared coordination layer to track capital stake to each application and network. This is so if staked capital is slashed, there is a process to track which applications have been affected. Issuing insurance bonds to specific applications and services on Eigenlayer then becomes possible, unlocking both benefits. Then if slashing occurs, the AVS can guarantee a certain amount of return from the slashed bonds. One consideration however is that Insurance bonds must remain less than than total ETH stake capital value to avoid unhealthy debt. There is a potential to integrate the native token into the maintenance of those insurance bonds.
5. EigenDA enables the compounding of yield for Ethereum stakers. This creates a risk of concentration on liquid staking token re-stakers, as they are able to get high yield with a lower barrier to entry. To maintain a healthy balance of solo staking re-stakers it might be worth considering incentivising “solo-staking” users specifically.

Conclusion

Both Celestia and EigenDA present scalable advances for modular DA performance, approaching the challenge in different ways. The token design for each platform must account for these structural differences. Celestia has made advances with DAS technology which enables its light nodes to scale the blockchain much more efficiently, however it is still a POS blockchain that requires a POS token for fees and staking rewards. EigenDA won’t have the necessity for native POS infrastructure and so won’t require a standard POS token. Instead, it faces unique utility challenges such as isolated native social consensus and attributable slashing insurance as well as opportunities around DA reservation and native payment tokens. AVS’ present new opportunities as well as new challenges that should be considered in their token design. As the number of AVS’ grow and their specialties increase, Vending Machine is excited to explore and contribute to token designs that most effectively integrate into their unique ecosystems.

Token Design Disclaimer

These considerations do not constitute a token design. To design a full token system is an extensive process that must include understanding the network participants, the protocol network objective and then using the token system as a tool to orient user behaviour toward said desired objective. Testing, simulating and optimising must then be done before a token design can be produced. These considerations are simply meant to outline structural and design differences between the two DA solutions that may affect a token system.

Disclaimer：

1. This article is reprinted from [Vending Machine]. All copyrights belong to the original author [Jean-Luc]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.