GoPlus Research: Deep into Eigenlayer, designing and building AVS

Original source: GoPlus

Background

From last year to today, EigenLayer has accumulated more than $10 billion in TVL as a core narrative in the Ethereum ecosystem. However, most people may simply regard it as a financial infrastructure, mainly because the most well-known feature of EigenLayer is its "Restaking" concept. This initial impression makes it easy for people to think that EigenLayer is just a platform that helps users get additional staking income. In fact, when we think deeply, a key question emerges: Why can re-staked ETH or LST (liquidity staking tokens) generate additional income? The answer to this question reveals the true nature of EigenLayer. I think EigenLayer is actually a revolutionary financial-driven cloud computing infrastructure. This definition may sound contradictory at first, but it precisely reflects the innovation of EigenLayer. Traditional cloud computing services, such as AWS or GCP, mainly rely on centralized resource allocation and management to provide computing power. EigenLayer has created a new cloud computing infrastructure model by cleverly combining financial incentives and distributed computing resources. This article will go 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 for the Ethereum ecosystem. For users, it enables users who hold Ethereum assets to not only earn interest through staking, but also use these deposit certificates to support other potential projects and earn additional rewards. This is the core concept of EigenLayer - Restaking. It is like a magical bridge that connects the strong security of Ethereum and all projects that require network consensus security. For developers, it is like a cloud computing platform that provides security, allowing them to focus on building decentralized services themselves 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 in the Eigenlayer ecosystem. AVS is simply a protocol, service or system that requires collateral to verify a "task". For example, if you want to build a decentralized price oracle network, in order to prevent the participating nodes of the oracle network from doing evil, you need to let these nodes pledge certain assets and set a consensus mechanism for each node when broadcasting and reporting prices. Then this scenario is very suitable for AVS. The AVS service itself undertakes the work of obtaining and reporting prices. At the same time, AVS also corresponds to its service management contract-Service Manager, which communicates with the Eigenlayer contract and contains status related to service functions, such as the operator running the service and the amount of deposit used to protect the service. According to Vyas Krishnan, Eigenlayer plays the role of "Convert crypto to cloud", so AVS is the cloud service we are familiar with in Web2, and it extends the pure on-chain computing capabilities of Crypto to off-chain cloud computing. So how does AVS work on the Eigenlayer network?

· First of all, as a project party who wants to use the Eigenlayer network, you need to develop your own AVS client and ServiceManager contract. The client itself is the service or system to be verified by the network. The client will be run by a large number of nodes participating in the network in the future, and the ServiceManager contract itself stipulates the conditions for nodes to participate in the network and the mechanism for rewards and punishments for the nodes themselves. For example: which tokens need to be pledged, the minimum number of tokens required for pledge, etc. At the same time, some specifications of the AVS ServiceManager contract must be followed, and some basic interfaces must be retained so that they can be indexed and communicated by the Eigenlayer main contract.

· The participating nodes of the network are called "Operators" in Eigenlayer. Operators are professional node operators who are mainly responsible for the actual operation and maintenance of network nodes. When they want to participate in a network, they need to meet the access conditions specified in the ServiceManager. As Operators, they can also be Stakers to stake their own nodes. So, how do ordinary users participate in the entire workflow process? Eigenlayer has designed a delegate function, which allows ordinary users to delegate their tokens to the selected Operator node, entrusting the node to obtain additional network benefits by running AVS.

· After completing the construction of AVS and the recruitment of nodes, the network's services can be opened to be consumed and used. The following figure is an official diagram of the call process of the entire AVS service.

As you can see, the Service Manager triggers the Operator's node to perform off-chain calculations through event events, and the operator returns the calculation results to the contract after signing with the private key, thereby completing a call. But in fact, the usage of AVS can be more flexible. First of all, triggering AVS does not necessarily have to be done through the Service Manager. Since the Operator nodes have already disclosed their IP and other gateway information when they were registered, they can directly call the service interface exposed by the gateway (authentication is required to prevent a large amount of Spam) to obtain the result. However, in this process, it is necessary to report the result and reach a consensus on the result through the aggregator, because the same call may be run by multiple nodes to improve the availability of the service. Finally, the Service Manager interacts with the Eigenlayer contract based on the reported results to complete the reward and punishment of the node.

Core Positioning of EigenLayer

After introducing AVS and EigenLayer, I would like to summarize the three main core positioning of EigenLayer to help you better understand it and decide whether to use it.

Platform for connecting pledgers and developers

One of the core positionings of EigenLayer is as a platform for connecting pledgers and developers. This innovative model has completely changed the way decentralized networks are built and participated in, bringing unprecedented opportunities and convenience to both parties. Before the emergence of EigenLayer, new decentralized networks faced huge cold start challenges:

· High startup costs:Project parties need to invest a lot of money and manpower to attract nodes to join the network.

· Operational pressure:Maintaining an active node network requires continuous operations and incentives.

· High threshold for node participation: Potential node operators need to purchase tokens of a specific network to participate, increasing their risks and costs.

· Slow network effect: Due to the small number of participants, it is difficult for new networks to quickly establish security and reliability.

EigenLayer cleverly solves these problems through its innovative design. It allows stakers to use ETH or LST to provide node services for multiple networks at the same time, greatly reducing the threshold for participation. Project parties can quickly access an already existing large network of stakers to accelerate the cold start process. For node operators, they no longer need to purchase specific tokens for each participating network, which reduces risk exposure. By allowing stakers to receive rewards from multiple networks, EigenLayer creates a win-win ecosystem for all parties and achieves effective alignment of incentives. This innovative model not only simplifies the process of building and participating in decentralized networks, but also provides an effective interest-earning scenario for most token holders.

From the current EigenLayer ecosystem, we can find that there are already a large number of operator nodes with very good endorsements, including Coinbase Cloud, Figment, Google Cloud, Galaxy, Hashkey, etc. 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 operators with strong backgrounds to entrust their assets, which not only obtains professional node operation services but also reduces risks. For developers, such convenience is self-evident. They can quickly build their own validator network from scratch, reduce the cost of developing and maintaining consensus networks, and use mature large-scale staking pools to obtain a relatively high level of security, focusing more on their own product and service innovations, rather than reinventing the wheel of consensus infrastructure.

Shared Security Pool

As mentioned above, the first major feature of EigenLayer is that it can connect pledgers and developers, helping projects quickly find validator nodes for services. So for developers and project parties, how to ensure the stability of these nodes and thus achieve the security of their own networks? This is one of the core problems solved by EigenLayer, and it can also be said to be the biggest selling point of EigenLayer.

Here we must first define what is so-called network security. We all know that in traditional blockchain and decentralized network architecture, each network needs to independently build and maintain its own security and consensus system. Because in a distributed system, every node has the possibility of doing evil, so the network must be built on a zero-trust basis, and a careful consensus mechanism needs to be built to prevent nodes from doing evil in order to maintain the stability and security of the network. Generally speaking, most networks will choose to allow nodes to participate in the work of the network by staking their own network tokens as collateral to obtain benefits, and through "Slash", nodes will incur high costs for doing evil, thereby achieving their goals. However, the cost itself may not be stable. That is to say, if the collateral itself is the native token of these networks, then with the fluctuation of prices, the cost of nodes doing evil is also constantly fluctuating. When the condition of "the benefits of doing evil are greater than the cost of collateral" is met, the network will also fall into a security crisis. This situation has happened many times in history, and the prices of most network native tokens are indeed very easy to manipulate and unstable.

The solution given by EigenLayer highlights the concept of shared security, which actually rents out the security of Ethereum to these decentralized networks in the form of income. By matching mortgagees, nodes and various projects, the collateral that determines the cost of doing evil becomes ETH/LST. Due to the stability of the price of ETH and re-pledged tokens, such network security is actually more trustworthy. This can also help a network quickly establish a stable and secure decentralized service network in the early stage, and use its own tokens as income to pay the "security service fee" of the entire network. Similarly, it can also help the originally centralized services to transition to decentralization in this way, thereby improving the quality and transparency of the original services, and then taking out a portion of the gains from the service improvement to reward these shared security pledgers, entering a positive cycle.

Currently, EigenLayer has TVL assets worth nearly $12 billion, which is equivalent to a huge shared security pool, enough to provide various DAs, sequencers, oracles and various decentralized network security services.

Programmable Consensus

The third core advantage of EigenLayer is its programmable consensus capability. Here we first need to introduce the concept of AVS. AVS stands for Actively Validated Services. AVS refers to any service that requires its own distributed system for verification, such as Sequencer, DA, oracle network and various decentralized network services. AVS is operated by the Operator corresponding to the participating network, and is ultimately managed and maintained by the contract corresponding to AVS (ServiceManager). Operator needs to register through the contract entry, and rewards and penalties will also be triggered by the contract. Therefore, it can be said that the contract serves as the consensus gateway of AVS. When developers write contracts, they can flexibly define their own AVS verification rules and requirements, node admission rules, Slash rules, etc., and even flexibly configure the staked tokens. EigenLayer's programmable consensus capability provides developers with unprecedented flexibility and innovation space. Through this feature, developers can dynamically adjust consensus parameters according to the development stage and needs of the network to ensure that the network can maintain optimal performance and security in different scenarios. This adaptability allows the project to optimize its operating mechanism at any time to cope with the ever-changing market environment and user needs.

AVS design ideas and principles

Before designing your own AVS, I think most developers need to think clearly about the following questions:

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

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

Necessity:Whether the calculation itself is impossible to execute by the VM on the chain or the cost is too high. If the verification can be completed by the on-chain contract, then the necessity of using AVS can be considered

Verification logic:Different services require different verification methods. For example:

 · Oracle services may need to verify the consistency of multiple data sources

 · DA services need to verify the storage and retrieval of data

 · On-chain risk control requires simulation and review of transactions, requiring 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 a lot of GPU computing performance

Security model:Different services face different security threats, which affects the design of the penalty mechanism. For example:

· Financial services may require stricter security measures and higher penalties

· Content distribution services may focus more on anti-tampering and availability

Node requirements:The type of service determines the hardware and software requirements for the node. Such as:

· Computation-intensive services require high-performance servers

· Storage-intensive services require large-capacity storage

2. How to punish malicious nodes

This issue is directly related 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:

 · Define what behavior is considered "evil"

 · Set appropriate punishment intensity, which should be deterrent enough but not too severe to cause a decrease in node participation

 · Design a fair and transparent judgment and execution mechanism

A reasonable punishment mechanism can effectively reduce the motivation of nodes to do evil and ensure the long-term healthy operation of the network.

3. Profitability of the service itself and the budget that can be paid to "shared security"

This issue involves the economic sustainability of AVS. Developers need to evaluate:

 · The profit model and expected income of the service, or how to combine it with their own Tokenomics in the early stage of the project to give enough 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. How big a network scale is needed

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

 · Smaller networks may be easier to manage, but may sacrifice some decentralization

 · Larger networks may provide higher security, but may increase complexity and cost

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

Only by clearly considering these issues, I think it is possible to design a good and highly engaged AVS, and avoid major problems that may arise due to insufficient thinking in the later stage.

AVS Current Ecosystem and New Opportunities

Although EigenLayer is still in its early stages, we believe that there are a lot of opportunities and potential in the ecosystem. First of all, according to our observation,

AVS in the current ecosystem is mainly concentrated in the following areas:

· DA

· Decentralized Sequencer

· Random Number Generation

· ZK-Prover

· Oracle Service

These services are mainly for developers and provide key support for blockchain infrastructure. However, we have noticed some significant gaps in the current ecosystem:

· Lack of traditional general-purpose decentralized computing networks

· Almost no AVS that directly provides services to end users

We believe that a large number of application-based AVS can bring more possibilities to the ecosystem. These application-based AVS can directly serve end users, thereby expanding the influence and practicality of EigenLayer. As a provider of user security services, GoPlus is using 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:

· Wallet address risk assessment

· Anti-phishing and anti-fraud protection

· Token risk assessment

· Decentralized real-time on-chain firewall

GoPlus will provide decentralized, transparent and reliable security services by building AVS on EigenLayer. This move not only improves the credibility of the service, but also attracts more participants through incentive mechanisms. GoPlus's AVS will provide better protection for users, while helping EigenLayer expand into new application areas for end users. At present, the average daily call volume of GoPlus's security services is as high as 21 million times. Therefore, after completing the AVS upgrade, GoPlus AVS is expected to become the largest application use case in the ecosystem. And providing security services in a decentralized way is also a new security paradigm in the development of Web3.

This article is from a contribution and does not represent the views of BlockBeats