“Four Questions” Let You Understand How to Build AVS

Source: IOSG Ventures

Recently, using EigenLayer to build infrastructure projects has become very popular in the developer community.These projects are called Active Verification Services (AVS), refer 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 exactly do we build an AVS?

In order to set up the basic rules of AVS, you need to answer four main questions.

Q1: What defines a Task in your AVS?

In EigenLayer, the task is the smallest unit of work that Operator promises to serve AVS.These tasks may be associated with one or more confiscation conditions of the AVS.

Here are two sample tasks:

Hosting and providing “DataStore” in EigenDA
Release another blockchain’s status root for cross-chain bridge

EigenLayer provides a more detailed example in the following workflow.The task of this AVS is to calculate the square of a specific number.

Task Generator publishes tasks at fixed intervals.Each task specifies the number that needs to be calculated squared.It also includes the quorum and the threshold percentage of the quorum, which stipulates that each listed quorum requires at least a certain percentage of the Operator signature to pass this task.
The operator currently joined to AVS needs to read the task number from the task contract, calculate its square, sign the calculation results, and send the calculation results and signatures to the Aggregator.
Aggregator collects signatures from Operator and aggregates them.If any responses from the Operator pass the threshold percentage set by the Task Generator when publishing a task, the aggregator aggregates these responses and publishes them into the task contract.
During dispute resolution, anyone can raise a dispute.The DisputeResolution contract handles error responses for a specific operator.(Or the Operator did not respond within this time window)
If the dispute is finally verified and processed, the Operator will be frozen in the Registration contract, and the EigenLayer’s veto committee decides whether to veto the freeze request.

Q2: What kind of trust does your AVS want to inherit?

Source: EigenLayer, IOSG Ventures

EigenLayer provides three types of programmable trust.

Economic Trust

Economic trust depends on people’s confidence in pledged assets.If the profits brought by corruption are lower than the cost of corruption, economically rational actors will not attack.For example, if the cost of launching an attack on a cross-chain bridge is $1 billion but the profit is only $500 million, it is obviously irrational to conduct an attack from an economic perspective.

As a widely adopted crypto-economic primitive, confiscation can greatly increase the cost of corruption and thus strengthen economic security.

Decentralized trust

The essence of decentralized trust is to have a huge and widely distributed collection of validators, both virtually and geographically.To prevent collusion and Liveness Attack between individual nodes in AVS, it is best not to have a single service provider run all nodes.

On EigenLayer, different AVSs can customize their decentralization level.For example, they can set geolocation requirements for operators, or only allow individual operators to provide node services and provide more incentives accordingly to attract such operators.

Here is an example:

Shutter proposes a solution to prevent MEVs by using threshold encryption.The process involves a set 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.

Shutter can obtain a wider distribution of Kepers by using node operations services provided by EigenLayer.This approach not only reduces the risk of collusion between Keypers, but also enhances the security and resilience of the network.

Similarly, Lagrange’s Lagrange State Committee (LSC) consists of re-pledgeers.For each state proof, at least 2/3 of the committee members must sign a specific block header before a state proof is generated through SNARK.

Ethereum “Inclusion” Trust

In addition to making a commitment to Ethereum through staking, Ethereum validators can also make a trusted commitment to AVS if they are further restaking on EigenLayer.This allows the proposer to provide some services on Ethereum (for example, partial block auctions via MEV-Boost++) without making changes at Ethereum’s protocol level.

For example, forward block space auctions allow buyers to ensure that future block space is obtained in advance.Verifiers participating in restaking can make trusted commitments to the block space and will be confiscated if they do not include the buyer’s transactions later.

Suppose you are building an oracle, you may need to offer a price for a certain period of time.Or assuming you are running an L2, you may 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 as lightweight as possible.

If tasks consume a lot of computing resources, Solo Operator may not be able to handle them.

Q4: What are the slashing conditions?

By re-polating to a specific service, the re-polder accepts the possible risk of confiscation, and this confiscation condition will be specified by AVS.

As AVS, confiscation conditions that can be verified, proven, objectively attributable to the chain should be designed.For example, double signature of a block in Ethereum, and nodes in a light node cross-chain bridge AVS sign invalid blocks from another chain.

Improperly designed confiscation conditions may lead to disagreements, which in turn will lead to systemic risks.

AVS should also ensure observability, allowing for monitoring, tracking and logging of requests and responses across services.

How to quantify?

How much trust does your AVS require (resolution capital, the number of different distributed validators, and the number of Ethereum validators that need to fulfill the promise of Ethereum validators), and how will you incentivize it?

For example, if a cross-chain bridge has a weekly transaction volume of $100 million and rents $100 million worth of security, users can trust that they are safe.Even if the validator tries to destroy the system, the user is protected because they can compensate the user through confiscation reassignment.

Given that the TVL of the cross-chain bridge, the number of resolidated ETH, the number of operators opted in, and many other parameters will be constantly changing and potentially large fluctuations, 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 staking.This allows you to protect the network using both ETH and your native tokens and adjust the proportion of each token as needed.In the early stages of the network, ETH may account for a large proportion.As the network matures, you may want native tokens to play a more important role.In this case, AVS can increase the proportion of native tokens through protocol governance.

Furthermore, when AVS’s security demand grows rapidly in the short term, for example, when TVL of the DeFi protocol served by AVS oracles increases rapidly, AVS can still use EigenLayer to strengthen its economic security.

From this perspective, EigenLayer is a programmable trust market that provides “resilent” security.

What external tools can I use?

Here are some notable items.

In the tripartite market of EigenLayer, Operator relies on AVS developers to correctly encode AVS software and set reasonable confiscation conditions.However, given the diversity of AVS, the interaction logic between each AVS and Operator may be different, creating a whole new field.To prevent accidental confiscations, AVS can review the code base before release.In addition, EigenLayer has a veto committee that is able to veto incorrect confiscation decisions through multiple signatures.

Meanwhile, Cubist is working with EigenLabs to develop an open anti-fraud 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 simultaneously will never be approved by the policy engine in the key manager.

Reprivators/operators with higher risk appetite may want to participate in early AVS for higher returns.In this case, Cubist’s Anti-slasher might be useful.
Many people know that EigenLayer can help AVS build trust networks, but how much does AVS need to pay for economic security and how can it resist economic attacks?

Anzen Protocol developed the Security Factor (SF), a common standard measure of economic security for AVS.SF is based on the concept of corruption costs and corruption profits.

Anzen helps AVS maintain minimum economic security without overpaying economic security.
EigenLabs is developing the EigenSDK to help AVS write its node software code.The SDK includes signature aggregation, interactive logic with EigenLayer contracts, networking, cryptography, and event monitoring client modules.

Meanwhile, Othentic is building a development tool to help AVS release 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
https://docs.eigenlayer.xyz/eigenlayer/overview/