Author: GoPlus

Background

From last year to today, EigenLayer, as a core narrative in the Ethereum ecosystem, has accumulated more than 10 billion US dollars in TVL. 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-staking 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, on the other hand, 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 up 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 assumes the role of "Convert crypto to cloud", so AVS is the cloud service we are familiar with in Web2, and extends the ability of Crypto pure on-chain computing to off-chain cloud computing. So how does AVS work on the Eigenlayer network?

1. First of all, as a project party who wants to use the Eigenlayer network, it is necessary to develop its 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 rewarding and punishing the nodes themselves. For example: which tokens need to be pledged, the minimum number of tokens required to be pledged, etc. At the same time, it is also necessary to follow some specifications of the AVS ServiceManager contract and retain some basic interfaces for indexing and communication by the Eigenlayer main contract.

2. 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 an Operator, 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.

3. After completing the construction of AVS and the recruitment of nodes, the services of the network can be opened for consumption and use. The figure below is an official schematic diagram of the calling process of the entire AVS service.

It can be seen that the Service Manager triggers the Operator's node through the event event to perform off-chain calculations. The operator signs the calculation result with the private key and returns it to the contract, thus 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.

EigenLayer's core positioning

After talking about 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.

A platform that connects pledgers and developers

One ​​of the core positionings of EigenLayer is to serve as a platform that connects 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:

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

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

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

4. 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 architectures, 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 let nodes participate in the work of the network to obtain benefits by staking their own network tokens as collateral, and achieve the goal by making the nodes incur high costs of doing evil through **"Slash"**. 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 provided by EigenLayer highlights the concept of shared security, which is actually renting 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 ETH and re-pledged token prices, 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 transition to decentralization in this way, thereby improving the quality and transparency of the original services, and then taking out a part of the gains obtained from the service improvement to reward these shared security pledgers, entering a positive cycle.

Currently, EigenLayer has TVL assets worth nearly 12B US dollars, 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 corresponding Operator of the participating network, and is ultimately managed and maintained by the corresponding contract (ServiceManager) of AVS. Operators need 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 issues:

1. 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:

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

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

Node requirements: The service type determines the hardware and software requirements for the node. For example:

• Computation-intensive services require high-performance servers

• Storage-intensive services require large-capacity storage

• Financial services may require stricter security measures and higher penalties

• Content distribution services may pay more attention to tamper-proofing and availability

• Real-time on-chain risk control services require extremely low latency

• AI services require a lot of GPU computing performance

• • Define what behavior is considered "evil"

  • Set appropriate penalties that are both deterrent enough and not too severe to cause a decrease in node participation

  • Design fair and transparent judgment and enforcement mechanisms

3. The 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:

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

• The profit model and expected income of the service, or how to combine it with its own Tokenomics in the early stage of the project to give sufficient reward expectations through token inflation

• Operational costs, including infrastructure, maintenance, etc.

• The reward budget that can be allocated to nodes and stakers

4. What is the required network scale

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

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

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

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

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

AVS current ecology and new opportunities

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

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

1. DA

2. Decentralized Sequencer

3. Random number generation

4. ZK-Prover

5. Oracle service

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

• Lack of traditional general-purpose decentralized computing networks

• There are almost no AVSs that provide services directly to end users

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

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 and help EigenLayer expand to new application areas for end users. At present, the average daily call volume of GoPlus's security service 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 manner is also a new security paradigm in the development of Web3.