"Four Questions" to Understand How to Build AVS

Forward the Original Title‘IOSG Weekly Brief｜“四问”让你了解如何构建 AVS #218’

Q1: What defines a Task in your AVS?

In EigenLayer, a task is the smallest unit of work for which an Operator commits to providing services for the AVS. These tasks may be associated with one or more penalization conditions of the AVS.

Here are two example tasks:

• Hosting and providing “DataStore” within EigenDA
• Publishing the state root of another blockchain for a cross-chain bridge

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

• The Task Generator periodically releases tasks, each specifying a number to be squared. It also includes a list of quorums and a percentage threshold for each quorum, stipulating that a certain percentage of Operator signatures from each listed quorum is required to pass the task.
• Operators, currently part of AVS, must read the task number from the task contract, calculate its square, sign the calculated result, and send both the result and signature to the Aggregator.
• The Aggregator collects signatures from Operators and aggregates them. If any responses from Operators pass the threshold percentage set by the Task Generator at the time of task issuance, the aggregator aggregates these responses and publishes them to the task contract.
• During a dispute resolution period, anyone can raise a dispute. The DisputeResolution contract handles incorrect responses from specific Operators (or lack of response within this time window).
• If the dispute is ultimately verified and addressed, the Operator will be frozen in the Registration contract, with the EigenLayer’s veto committee deciding whether to veto the freeze request.

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

Source: EigenLayer, IOSG Ventures

EigenLayer offers three types of programmable trust:

Economic Trust

Economic trust relies on the confidence in staked assets. If the profit from corruption is less than the cost of corruption, economically rational actors would not launch attacks. For instance, if the cost to attack a cross-chain bridge is $1 billion, but the profit is only $500 million, then economically, it would be irrational to attack.

As a widely adopted cryptographic economic primitive, slashing can significantly increase the cost of corruption, thereby strengthening economic security.

Decentralized Trust

The essence of decentralized trust is having a large and widely distributed set of validators, both virtually and geographically. To prevent collusion and Liveness Attacks among nodes in the AVS, it’s best not to let a single service provider run all nodes.

On EigenLayer, different AVS can customize their level of decentralization. For example, they can set geographic location requirements for Operators or allow only individual Operators to provide node services, providing more incentives to attract such Operators.

Here’s an example:

Shutter has proposed a solution to prevent MEV (Miner Extractable Value) using threshold encryption. This process involves a group of nodes called Keypers, who participate in computing a set of shared public and private keys through Distributed Key Generation (DKG). These nodes are elected by the governance of the Shutter DAO.

Clearly, DKG relies on the assumption of an honest majority.

By leveraging node operation services provided by EigenLayer, Shutter can achieve a wider distribution of Keypers. This method not only reduces the risk of collusion among Keypers but also enhances the network’s security and resilience.

Similarly, Lagrange’s Lagrange State Committee (LSC) is composed of restakers. 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 credible commitment to the Adversarial Validity Service (AVS) by further staking on EigenLayer. This enables proposers to offer certain services on Ethereum, such as partial block auctions through MEV-Boost++, without requiring changes at the Ethereum protocol level.

For instance, forward block space auctions allow buyers to secure future block space in advance. Validators participating in re-staking can make credible commitments to block space. If they later fail to include the buyer’s transactions, they will be penalized.

Suppose you are building an oracle; you may need to provide prices over a certain period. Or, suppose you are running a Layer 2 (L2) solution; you might need to post L2 data to Ethereum every few minutes. These are use cases for forward block space auctions.

Q3: Is the work to be done by the operator lightweight or heavyweight?

To inherit the decentralization of Ethereum validators, the tasks for AVS should be designed to be as lightweight as possible. If the tasks consume a lot of computing resources, Solo Operators may not be able to handle them.

Q4: What are the slashing conditions?

By re-staking to a specific service, the re-stakers accept the potential risk of penalties, and these slashing conditions will be specified by AVS. As AVS, it should design slashing conditions that can be verified on-chain, provable, and objectively attributable. For example, signing a block twice in Ethereum, and a node in a light node cross-chain bridge AVS signing an invalid block from another chain. Poorly designed slashing conditions may lead to disputes, thereby posing systemic risks. AVS should also ensure observability, allowing cross-service monitoring, tracking, and recording of requests and responses.

How to quantify?

How much trust does your AVS require (in terms of re-staked capital, the number of different distributed validators, and the number of Ethereum validators needed to fulfill Ethereum validator commitments), and how will you incentivize it?

For example, if a cross-chain bridge has a weekly transaction volume of $100 million and rents security worth $100 million, users can trust that they are safe. Even if validators attempt to compromise the system, users are protected because they can be compensated through the forfeiture and redistribution to users.

Given that the TVL of cross-chain bridges, the amount of ETH re-staked, the number of operators who opt-in, and many other parameters will constantly change and may experience significant fluctuations, the 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, which allows you to protect the network using both ETH and your native tokens simultaneously, adjusting the ratio of each token as needed. In the early stages of the network, ETH might constitute a larger proportion. As the network matures, you might want to play a more significant role with your native tokens. In such cases, AVS can increase the proportion of native tokens through protocol governance.

Furthermore, when AVS’s security needs grow rapidly in the short term, for example, when the Total Value Locked (TVL) of DeFi protocols serviced by AVS oracles increases rapidly, AVS can still fortify its economic security using EigenLayer.

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

What external tools can I use?

Here are some notable projects.

• In EigenLayer’s tripartite market, Operators rely on AVS developers to correctly code AVS software and set reasonable forfeiture conditions. However, given the diversity of AVS, the interaction logic between each AVS and Operators may differ, creating a whole new domain. To prevent accidental forfeiture events, AVS can audit the codebase before release. Additionally, EigenLayer has a veto committee that can veto incorrect forfeiture decisions through multi-signature.
• Meanwhile, Cubist is working with EigenLabs to develop an open anti-forfeiture framework, utilizing secure hardware and using custom strategies to sign transactions and verify messages within the key manager. For example, a policy engine within the key manager would never approve signing two block headers at different heights simultaneously.
• Higher-risk restakers/Operators may wish to participate in early AVS for higher returns. In this case, Cubist’s Anti-slasher may be useful.
• Many know that EigenLayer can help AVS establish trust networks, but how much does AVS need to pay for economic security, and how can it defend against economic attacks?
• Anzen Protocol has developed a Security Factor (SF), a generic standard metric for measuring the economic security of AVS. SF is based on the concepts of corruption cost and corruption profit.
• Anzen helps AVS maintain the minimum level of economic security without overpaying for economic security.
• EigenLabs is developing EigenSDK to help AVS write their node software code. The SDK includes modules for signature aggregation, interaction logic with EigenLayer contracts, networking, cryptography, and event monitoring clients.
• Meanwhile, Othentic is building a development tool to help AVS release products faster.

Disclaimer：

1. This article is reprinted from [IOSG Ventures]. Forward the Original Title‘IOSG Weekly Brief｜“四问”让你了解如何构建 AVS #218’.All copyrights belong to the original author [IOSG Ventures]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.