GoPlus Research: In-depth Eigenlayer, Design and Build AVS

Background

From last year to today, EigenLayer has accumulated over $10 billion in TVL as a significant core narrative within the Ethereum ecosystem. However, most people may simply view it as a financial infrastructure, primarily because EigenLayer's most well-known feature is its "Restaking" concept. This initial impression can easily lead one to think that EigenLayer is merely a platform that helps users earn additional staking rewards. In reality, when we delve deeper, a key question arises: why can restaked ETH or LST (liquid staking tokens) generate additional returns? The answer to this question reveals the true nature of EigenLayer. I believe EigenLayer is actually a revolutionary, finance-driven cloud computing infrastructure. This definition may sound contradictory at first, but it precisely reflects EigenLayer's innovation. Traditional cloud computing services, such as AWS or GCP, primarily rely on centralized resource allocation and management to provide computing power. In contrast, EigenLayer creates a brand-new model of cloud computing infrastructure by cleverly combining financial incentive mechanisms with distributed computing resources. This article will delve into the principles and mechanisms of EigenLayer according to our understanding, and after months of development practice, we will also share some experiences and ideas on how to build your own decentralized network based on EigenLayer and how to design AVS.

What is EigenLayer?

First of all, EigenLayer is a revolutionary infrastructure within the Ethereum ecosystem. For users, it allows holders of Ethereum assets not only to earn interest through staking but also to use these deposit certificates to support other promising projects and earn additional rewards. This is the core idea of EigenLayer—Restaking. It acts like a magical bridge, connecting the robust security of Ethereum with all projects that require network consensus security. For developers, it serves as a cloud computing platform that provides security guarantees, allowing them to focus on building decentralized services without having to build complex consensus and security systems from scratch.

What is AVS and How Does It Work?

Based on EigenLayer, developers can build their own Actively Validated Service (AVS), which is also the most important concept within the EigenLayer ecosystem. Simply put, AVS is a protocol, service, or system that requires collateral to validate a "task." For example, if you want to build a decentralized price oracle network, to prevent malicious behavior from the participating nodes, you need to require these nodes to collateralize certain assets and set up a consensus mechanism for each node when broadcasting reported prices. This scenario is well-suited for AVS. The AVS service itself undertakes the tasks of obtaining and reporting prices, while AVS corresponds to its service management contract—Service Manager. This contract communicates with the EigenLayer contract and contains states related to service functionality, such as the operators running the service and the amount of collateral used to secure the service. According to Vyas Krishnan, EigenLayer plays the role of "Convert crypto to cloud," while AVS is akin to the cloud service we know from Web2, extending the capabilities of pure on-chain computation into off-chain cloud computing. So how does AVS specifically operate on the EigenLayer network?

1. First, as a project wanting to use the EigenLayer network, you need to develop your own AVS client and ServiceManager contract. The client itself is the service or system that the network needs to validate, and this client will be run by a large number of nodes participating in the network in the future. The ServiceManager contract specifies the conditions for nodes to participate in the network and the reward and punishment mechanisms for the nodes themselves, such as which tokens need to be staked, the minimum amount of tokens to be staked, etc. It must also adhere to certain specifications of the AVS ServiceManager contract, retaining some basic interfaces for indexing and communication with the EigenLayer main contract.
2. The participating nodes in the EigenLayer are referred to as "Operators." Operators are professional node operators responsible for the actual operation and maintenance of network nodes. When they want to participate in a network, they must meet the admission criteria specified in the ServiceManager. As Operators, they can also be Stakers staking to their own nodes. So how do ordinary users participate in the entire workflow? EigenLayer has designed a delegate function that allows ordinary users to delegate their tokens to selected Operator nodes, entrusting those nodes to earn additional network rewards by running AVS.
3. After completing the setup of AVS and recruiting nodes, the network's services can be opened for consumption and use. The following diagram is an illustration of the entire AVS service invocation process provided by the official source. It can be seen that the Service Manager triggers the Operator's node to perform off-chain computations through event events. The operator signs the computation results with a private key and returns them to the contract, thus completing a call. However, in practice, the use of AVS can be more flexible. First, triggering AVS does not necessarily have to go through the Service Manager. Since Operator nodes have already disclosed their IP and gateway information upon registration, they can directly call the service interface exposed by the gateway (authentication is required to prevent spam) to obtain results. However, in this process, results need to be reported, and consensus on the results must be achieved through an aggregator, as the same call may be run by multiple nodes to improve service availability. Ultimately, the Service Manager interacts with the EigenLayer contract based on the reported results to complete the reward and punishment actions for the nodes.

Core Positioning of EigenLayer

After discussing AVS and introducing EigenLayer, I would like to summarize EigenLayer's three main core positions to help everyone better understand it and determine whether to use it.

A Platform Connecting Stakers and Developers

One of EigenLayer's core positions is as a platform connecting stakers and developers. This innovative model fundamentally changes the way decentralized networks are built and participated in, bringing unprecedented opportunities and conveniences to both parties. Before EigenLayer emerged, new decentralized networks faced significant cold start challenges:

1. High startup costs: Project parties needed to invest substantial funds and manpower to attract nodes to join the network.
2. Operational pressure: Maintaining an active node network requires ongoing operations and incentive measures.
3. High entry barriers for node participation: Potential node operators needed to purchase specific network tokens to participate, increasing their risks and costs.
4. Slow network effects: Due to a lack of participants, new networks struggled to quickly establish security and reliability.

EigenLayer cleverly addresses these issues through its innovative design. It allows stakers to use ETH or LST to provide node services for multiple networks simultaneously, significantly lowering the participation threshold. Project parties can quickly access an already existing large network of stakers, accelerating the cold start process. For node operators, they no longer need to purchase specific tokens for each participating network, reducing their risk exposure. By allowing stakers to earn rewards from multiple networks, EigenLayer creates a win-win ecosystem, achieving effective alignment of incentives. This innovative model not only simplifies the construction and participation process of decentralized networks but also provides a viable yield-generating scenario for most token holders.

From the current EigenLayer ecosystem, we can see that there are already a large number of well-backed operator nodes, including Coinbase Cloud, Figment, Google Cloud, Galaxy, Hashkey, and others. The participation of these institutions not only brings professionalism and reliability to the ecosystem but also greatly enhances the confidence of ordinary users. Delegators can choose these well-backed operators to delegate their assets, gaining professional node operation services while reducing risks. For developers, this convenience is self-evident; they can quickly build their own validator networks from scratch, reducing the costs of developing and maintaining consensus networks, leveraging already mature large-scale staking pools to achieve a high level of security, and focusing more on their own product and service innovations rather than reinventing the wheel of consensus infrastructure.

Shared Security Pool

The first major feature of EigenLayer mentioned above is its ability to connect stakers and developers, helping projects quickly find validating nodes for their services. So how can developers and project parties ensure the stability of these nodes and thus achieve the security of their own networks? This is one of the core problems EigenLayer solves and can be considered EigenLayer's biggest selling point.

First, we need to define what network security means. We all know that in traditional blockchain and decentralized network architectures, each network needs to independently build and maintain its own security and consensus system. In a distributed system, every node has the potential to act maliciously, so the network must be built on a zero-trust basis and must construct a rigorous consensus mechanism to prevent nodes from acting maliciously, thereby maintaining the stability and security of the network. Generally speaking, most networks choose to have nodes stake their network tokens as collateral to participate in the network's work and earn rewards, using "Slashing" to impose high costs on malicious behavior, thus achieving their goals. However, the costs themselves may not be stable; that is, if the collateral is the native tokens of these networks, then as the price fluctuates, the cost of malicious behavior for nodes also fluctuates. When the condition of "malicious gains exceeding collateral costs" is met, the network will fall into a security crisis. Such situations have occurred multiple times in history, and the prices of most network native tokens are indeed very easy to manipulate and unstable.

EigenLayer's solution emphasizes the concept of shared security, effectively renting out Ethereum's security in the form of rewards to these decentralized networks. By facilitating the staking of ETH/LST as collateral that determines the cost of malicious behavior, and due to the stability of ETH and restaked token prices, this network security is actually more trustworthy. This can also help a network quickly establish a stable and secure decentralized service network in its early stages, using its tokens as rewards to pay for the "security service fees" of the entire network. Similarly, it can help originally centralized services transition to decentralized ones, thereby improving the quality and transparency of existing services, and rewarding the shared security stakers with a portion of the gains obtained from the service improvements, entering a positive cycle.

Currently, EigenLayer has nearly $12 billion in TVL assets, equivalent to a massive shared security pool, sufficient to provide security services for various DA, Sequencers, oracles, and various decentralized networks.

Programmable Consensus

The third core advantage of EigenLayer is its ability for programmable consensus. Here, we first need to introduce the concept of AVS, which stands for Actively Validated Services. AVS refers to any service that requires its own distributed system for validation, such as Sequencers, DA, oracle networks, and various decentralized network services. AVS is operated by the corresponding Operators in the network and is ultimately managed and maintained for consensus by the corresponding contract (ServiceManager). Operators need to register through this contract, and rewards and punishments will also be triggered by this contract, so it can be said that this contract serves as the consensus gateway for AVS. When developers write contracts, they can flexibly define their AVS validation rules and requirements, node admission rules, slashing rules, etc., and even configure the staked tokens flexibly. EigenLayer's programmable consensus capability provides developers with unprecedented flexibility and innovation space. Through this feature, developers can dynamically adjust consensus parameters based on the development stage and needs of the network, ensuring that the network maintains optimal performance and security in different scenarios. This adaptability allows projects to optimize their operational mechanisms at any time to respond to the ever-changing market environment and user demands.

Design Ideas and Principles for AVS

Before designing their own AVS, I believe most developers need to clarify the following questions:

1. The service needs and types provided by the project itself

Understanding the type of service provided by the project is the foundation for designing AVS, as it directly affects:

Necessity: Is the computation something that cannot be executed by the on-chain VM or is too costly? If it can be completed by an on-chain contract, then the necessity of using AVS should be considered.

Validation Logic: Different services require different validation methods. For example:

• Oracle services may need to verify the consistency of multiple data sources.
• DA services need to verify data storage and retrieval.
• On-chain risk control requires simulating and reviewing transactions, necessitating real-time efficiency and accuracy.

Performance Requirements: The type of service determines the requirements for speed and throughput. For example:

• Real-time on-chain risk control services require extremely low latency.
• AI services require substantial GPU computational performance.

Security Model: Different services face different security threats, affecting the design of punishment mechanisms. For example:

• Financial services may require stricter security measures and higher penalties.
• Content distribution services may focus more on tamper resistance and availability.

Node Requirements: The type of service determines the hardware and software requirements for nodes. For example:

• Compute-intensive services require high-performance servers.
• Storage-intensive services require large-capacity storage.

2. How to punish malicious nodes

This question directly relates to the security and reliability of AVS. Developers need to design an effective punishment mechanism to maintain the security and stability of the network. This includes:

• Defining what behaviors are considered "malicious."
• Setting appropriate punishment levels that are deterrent enough without being so harsh that they reduce node participation.
• Designing a fair and transparent determination and execution mechanism.

A reasonable punishment mechanism can effectively reduce the motivation for nodes to act maliciously, ensuring the long-term healthy operation of the network.

3. The profitability of the service itself and the budget for paying for "shared security"

This question involves the economic sustainability of AVS. Developers need to assess:

• The service's profit model and expected revenue, or how to combine it with their own tokenomics in the early stages of the project to provide sufficient reward expectations through token inflation.
• Operating costs, including infrastructure, maintenance, etc.
• The reward budget that can be allocated to nodes and stakers.

A reasonable economic model can ensure that AVS can attract and retain enough nodes and stakers while maintaining the sustainable development of the project.

4. What scale of network is needed

The scale of the network directly affects the performance, decentralization level, and security of AVS:

• A smaller network may be easier to manage but may sacrifice some degree of decentralization.
• A larger network may provide higher security but may increase complexity and costs.

Developers need to find the best balance based on service needs and resource constraints.

Current AVS Ecosystem and New Opportunities

Although EigenLayer is still in its early stages, we believe there are numerous opportunities and potential within this ecosystem. First, based on our observations, the current AVS in the ecosystem mainly focuses on the following areas:

1. DA
2. Decentralized Sequencer
3. Random Number Generation
4. ZK-Prover
5. Oracle Services

These services primarily target developers, providing critical support for blockchain infrastructure. However, we notice some significant gaps in the current ecosystem:

• A lack of traditional general-purpose decentralized computing networks.
• Almost no AVS directly providing services to end users.

We believe that a large number of application-oriented AVS can bring more possibilities to the ecosystem. These application-oriented AVS can directly serve end users, thereby expanding EigenLayer's influence and practicality. GoPlus, as a provider of user security services, is leveraging EigenLayer's infrastructure to build an AVS focused on user security. This AVS will provide comprehensive security protection services for cryptocurrency users, including but not limited to:

1. Wallet address risk assessment
2. Anti-phishing and anti-fraud protection
3. Token risk assessment
4. Decentralized real-time on-chain firewall

By building AVS on EigenLayer, GoPlus will provide decentralized, transparent, and reliable security services. This initiative not only enhances the credibility of the service but also attracts more participants through incentive mechanisms. GoPlus's AVS will offer better protection for users while helping EigenLayer expand into new application areas aimed at end users. Currently, GoPlus's security services have an average daily call volume of up to 21 million, so after completing the AVS upgrade, GoPlus AVS is expected to become the largest application-oriented use case within the ecosystem. Providing security services in a decentralized manner also represents a new security paradigm in the development of Web3.