Source: IOSG Ventures
Using EigenLayer to build infrastructure projects has become very popular in the developer community recently. These projects are called Active Verification Services (AVS), referring to any system that requires its own distributed verification semantics for verification. These systems can include DA layers, new VMs, oracles, bridges, and more.
Source: EigenLayer, IOSG
But how do we build an AVS?
In order to set the ground rules for AVS, you need to answer four main questions.
Q1: What defines a Task in your AVS?
In EigenLayer, the task is an Operator promise The smallest unit of work that provides services to AVS. These tasks may be associated with one or more slashing conditions of AVS.
The following are two example tasks:
EigenLayer in the following workflow A more detailed example is provided. The task of this AVS is to calculate the square of a specific number.
- < p>Task Generator publishes tasks at fixed intervals. Each task specifies the number to be squared. It also includes quorums and quorum threshold percentages, stipulating that each listed quorum requires at least a certain percentage of Operator signatures to pass this task.
The Operator currently joining AVS needs to read the task number from the task contract, calculate its square, sign the calculation result, and send the calculation result and signature to the Aggregator.
Aggregator collects signatures from Operators and aggregates them. If any response from the Operator passes the threshold percentage set by the Task Generator when publishing the task, the aggregator aggregates these responses and publishes them to the task contract.
During dispute resolution, anyone can file a dispute. The DisputeResolution contract handles error responses from a specific Operator. (Or the Operator does not respond within this time window)
If the dispute is finally verified and handled, the Operator will be frozen in the Registration contract and will be determined by the veto committee of EigenLayer Decide whether to deny the freeze request.
Q2: What kind of trust does your AVS want to inherit?
Source: EigenLayer, IOSG Ventures
EigenLayer provides three programmable trusts.
Economic Trust relies on People’s confidence in pledged assets. If the profits from corruption are lower than the costs of corruption, economically rational actors will not attack. For example, if the cost of an attack on a cross-chain bridge is $1 billion, but the profit is only $500 million, it is clearly irrational from an economic perspective to conduct the attack.
As a widely adopted cryptoeconomic primitive, confiscation can greatly increase the cost of corruption, thus strengthening economic security.
Decentralized The essence of centralized trust is to have a large and widely distributed set of validators, both virtually and geographically. To prevent collusion and Liveness Attacks between nodes in AVS, it is best not to have a single service provider run all nodes.
On EigenLayer, different AVS can customize their degree of decentralization. For example, they can set geographical location requirements for operators, or only allow individual operators to provide node services, and accordingly provide more incentives to attract such operators.
The following is an example:
Shutter proposed a A solution to prevent MEV by using threshold encryption. The process involves a group of nodes, called Keypers, who participate in computing a shared set of public and private keys through Distributed Key Generation (DKG). These nodes are elected by the governance of Shutter DAO.
Obviously, DKG relies on the assumption of an honest majority.
By leveraging the node operation services provided by EigenLayer, Shutter can obtain a wider distribution of Kepers. This approach not only reduces the risk of collusion between Keypers, but also enhances the security and resiliency of the network.
Similarly, Lagrange’s Lagrange State Committee (LSC) is composed of re-pledgers. For each proof of state, at least 2/3 of the committee members must sign a specific block header before a proof of state is generated via SNARK.
Ethereum "Inclusion" trust
In addition to making commitments to Ethereum through staking, Ethereum validators can also make credible commitments to AVS if they further pledge on EigenLayer. This allows proposers to provide some services on Ethereum (e.g. partial block auctions via MEV-Boost++) without requiring changes at the protocol level of Ethereum.
For example, forward block space auctions allow buyers to secure future block space in advance. Validators participating in the re-staking can make a credible commitment to the block space, and if they later do not include the buyer's transaction, they will be slashed.
Suppose you are building an oracle and you may need to provide prices within a certain time period. Or let's say you're running an L2, and you might need to publish L2 data to Ethereum every few minutes. These are all use cases for forward block space auctions.
Q3: Is the work to be done by the operator lightweight or heavyweight?
If you want to inherit the decentralization of Ethereum validators, AVS tasks should be designed to be as lightweight as possible.
If tasks consume significant computing resources, the Solo Operator may not be able to process them.
Q4: What are the slashing conditions?
By re-staking to a specific service, the re-stakeholder accepts the possible risk of slashing, And this slashing condition will be specified by AVS.
As AVS, slashing conditions should be designed that are verifiable, provable, and objectively attributable on the chain. For example, double signing a block in Ethereum, and a node in a light node cross-chain bridge AVS signing an invalid block from another chain.
Improperly designed slashing conditions may lead to disagreements and thus systemic risks.
AVS should also ensure observability, allowing requests and responses to be monitored, tracked, and logged across services.
How to quantify?
How much trust your AVS requires (re-staking capital, number of different distributed validators, and number of Ethereum validators needed to fulfill the Ethereum validator commitment), and what you will How to motivate it?
For example, if a cross-chain bridge has $100 million in weekly transaction volume and leases $100 million worth of security, users can trust that they are safe. Even if validators try to break the system, users are protected because they can compensate users through slashing redistributions.
Given that the TVL of cross-chain bridges, the amount of ETH remortgaged, the number of Operators opted in, and many other parameters will continue to change and may fluctuate significantly, AVS needs some way to adjust its security budget and buffer space.
AVS can pay for economic security with a portion of its total token supply.
But, do I compromise my token utility by using EigenLayer?
Absolutely not!
EigenLayer supports dual pledge (Dual Staking). This allows you to secure the network with both ETH and your native token, adjusting the ratio of each token as needed. In the early stages of the network, ETH may account for a larger proportion. As the network matures, you may want the native token to play a more prominent role. In this case, AVS can increase the proportion of native tokens through protocol governance.
In addition, when the security needs of AVS increase rapidly in the short term, for example, when the TVL of the DeFi protocol served by the AVS oracle increases rapidly, AVS can still use EigenLayer to strengthen its economic security.
From this perspective, EigenLayer is a programmable trust market that provides "resilient" security.
What external tools can I use?
Here are some noteworthy items.
In EigenLayer's three-party market, Operators rely on AVS developers to correctly code AVS software and set reasonable slashing conditions. However, considering the diversity of AVS, the interaction logic between each AVS and Operator may be different, which creates a whole new field. To prevent accidental slashing events, AVS can audit the codebase prior to release. In addition, EigenLayer has a veto committee that can veto incorrect slashing decisions through multi-signatures.
Meanwhile, Cubist is working with EigenLabs to develop an open anti-slashing framework that leverages secure hardware and uses custom policies to sign transactions and verify messages within the key manager. For example, signing two block headers of different heights at the same time will never be approved by the policy engine within the key manager.
Restakers/Operators with a higher risk appetite may wish to participate in early AVS to obtain higher returns. In this case, Cubist's Anti-slasher may be useful.
Many people know that EigenLayer can help AVS build a trust network, but how much does AVS need to pay for economic security, and how does it defend against economic attacks?
Anzen Protocol developed the Safety Factor (SF), a universal standard measure of the economic safety of AVS. SF is based on the concepts of corruption costs and corruption profits.
Anzen helps AVS maintain a minimum level of financial security without overpaying for financial security.
EigenLabs is developing EigenSDK to help AVS code its node software. The SDK includes signature aggregation, interaction logic with EigenLayer contracts, networking, cryptography, and event monitoring client modules.
Meanwhile, Othentic is building a development tool to help AVS ship products faster.
References:
https://medium.com/@lagrangelabs/state-committees-on-eigenlayer-via-lagrange-7752f1916db4
https://www.blog.eigenlayer.xyz/ycie/
https://www.blog.eigenlayer.xyz/ eigenlayer-universe-15-unicorn-ideas/
https://github.com/Layr-Labs
< /li>https://docs.eigenlayer.xyz/eigenlayer/overview/