Original author: GoPlus
background
From last year to today, EigenLayer, as a core narrative in the Ethereum ecosystem, has accumulated more than $10 billion 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-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 brand 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. After several 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 allows 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 cloud computing under the chain. So how does AVS work on the Eigenlayer network?
First of all, as a project party that 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.
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 entry requirements 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 that 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 networks services can be opened for consumption and use. The following figure is an official diagram of the entire AVS service calling process.
As you can see, Service Manager triggers the Operators node to perform off-chain calculations through event events. The operator returns the calculation results to the contract after signing with a private key, 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 Service Manager. Since 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 results. However, in this process, it is necessary to report the results and reach a consensus on the results through the aggregator, because the same call may be run by multiple nodes to improve the availability of the service. Finally, Service Manager interacts with the Eigenlayer contract based on the reported results to complete the reward and punishment of the node.
The 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.
A platform that connects stakers and developers
One of the core positionings of EigenLayer is as a platform connecting stakers 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 owners 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 network-specific tokens to participate, increasing their risks and costs.
Slow network effects: It is difficult for new networks to quickly establish security and reliability due to the small number of participants.
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 a large existing network of stakers and 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 the consensus network, and use the mature large-scale staking pool to obtain a relatively high level of security, focusing more on their own product and service innovation, 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 stakers and developers, helping projects quickly find validator nodes for services. So for developers and project owners, how can they ensure the stability of these nodes and thus achieve the security of their own networks? This is one of the core problems that EigenLayer solves, and it can also be said to be the biggest selling point of EigenLayer.
First of all, we need to 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**, the nodes will incur high costs for doing evil, thereby achieving the purpose. 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 to rent out the security of Ethereum to these decentralized networks in the form of income. By matching pledgers, 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 stages, using its own tokens as income to pay for the security service fees 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 portion of the income from 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, sufficient 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). 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. EigenLayers 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 respond to changing market conditions and user needs.
AVS design ideas and principles
Before designing their own AVS, I think most developers need to think about the following questions:
1. The service requirements and types provided by the project itself
Understanding the types of services provided by a project is fundamental to designing an AVS because it directly affects:
Necessity: Is the calculation itself impossible to perform with the on-chain VM or is too costly? If the verification can be completed with 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 require storage and retrieval of authentication data
On-chain risk control requires simulation and review of transactions, which requires real-time efficiency and accuracy
Performance requirements: The service type determines the speed and throughput requirements. For example:
Real-time on-chain risk control services require extremely low latency
AI services require a lot of GPU computing power
Security model: Different services face different security threats, which affects the design of the penalty mechanism. For example:
Financial services may require tighter security measures and higher penalties
Content distribution services may focus more on tamper-proofing and availability
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 storage capacities
2. How to punish malicious nodes
This issue is directly related to the security and reliability of AVS. Developers need to design an effective penalty mechanism to maintain the security and stability of the network. This includes:
Define what behavior is considered evil
Set appropriate penalties to deter the node from participating in the project.
Design fair and transparent judgment and enforcement mechanisms
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 for shared security
This question concerns the economic sustainability of AVS. Developers need to evaluate:
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 provide sufficient reward expectations through token inflation
Operating costs, including infrastructure, maintenance, etc.
Rewards budget available for allocation 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 network size is needed?
The network size directly affects the performance, decentralization and security of AVS:
Smaller networks may be more manageable, but may sacrifice some decentralization
Larger networks may provide greater 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 can I design a good and highly engaging 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 ecosystem. First, according to our observation,
At present, AVS in the 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
There are almost no AVSs that provide services directly 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 EigenLayers 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. GoPluss AVS will provide better protection for users, while helping EigenLayer expand into new application areas for end users. Currently, GoPluss security service has an average daily call volume of 21 million times. Therefore, after completing the AVS upgrade, GoPlus AVS is expected to become the largest application use case in the ecosystem. Providing security services in a decentralized manner is also a new security paradigm in the development of Web3.
