IOSG: "Four Questions" let you understand how to build AVS on EigenLayer

<img src="https://img.php.cn/upload/article/000/000/164/171159066812979.png" alt="IOSG: Four Questions let you understand how to build AVS on EigenLayer">Source: EigenLayer, IOSG

最近，使用 EigenLayer 来构建基础设施项目在开发者社区中已经变得非常流行。这些项目被称为主动验证服务（AVS），指的是任何需要自己的分布式验证语义以进行验证的系统。这些系统可以包括 DA 层、新的 VM、预言机、桥等等。

但是我们到底如何构建一个 AVS？

为了设置 AVS 的基本规则，您需要回答四个主要问题。

Q1: What defines a Task in your AVS?

在 EigenLayer 中，任务是 Operator 承诺为 AVS 提供服务的最小工作单位。这些任务可能与AVS 的一个或多个罚没条件相关联。

以下是两个示例任务：

• 在 EigenDA 的中托管和提供 “DataStore”
• 为跨链桥发布另一个区块链的状态根

EigenLayer 在以下工作流程中提供了一个更详细的示例。这个 AVS 的任务是计算特定数字的平方。

Task Generator 以固定时间间隔发布任务。每个任务指定了需要计算平方的数字。它还包括法定人数和法定人数的阈值百分比，规定每个列出的法定人数至少需要一定比例的 Operator 签名才能通过此任务。

当前加入 AVS 的 Operator 需要从任务合约中读取任务编号，计算其平方，对计算结果进行签名，并将计算结果和签名发送给 Aggregator。

Aggregator 收集来自 Operator 的签名并进行聚合。如果任何来自 Operator 的响应通过 了 Task Generator 在发布任务时设置的阈值百分比，聚合器将这些响应聚合起来并发布到任务合约中。

在争议解决期间，任何人都可以提出争议。DisputeResolution 合约会处理特定 Operator 的错误响应。（或者该 Operator 在这个时间窗口内没有做出响应）

如果争议被最终验证并处理， Operator 将被冻结在 Registration 合约中，由 EigenLayer 的否决委员决定是否否决冻结请求。

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

<img src="https://img.php.cn/upload/article/000/000/164/171159066870472.png" alt="IOSG: Four Questions let you understand how to build AVS on EigenLayer">Source: EigenLayer, IOSG Ventures

EigenLayer 提供了三种可编程信任。

经济信任

经济信任依赖于人们对质押资产的信心。如果腐败带来的利润低于腐败成本，经济上理性的行为者就不会发起攻击。例如，如果对跨链桥发起攻击的成本为 10 亿美元，但利润仅为 5 亿美元，则从经济上来看，进行攻击是显然不理性的。

作为广泛采用的加密经济学原语，罚没可以大大提高腐败成本，从而强化经济安全。

去中心化信任

去中心化信任的本质是拥有一个庞大且广泛分布的验证者集合，无论是在虚拟上还是在地理上。为了防止在 AVS 中各个节点之间发生串通和 Liveness Attack，最好不要让单一服务提供商运行所有节点。

在 EigenLayer 上，不同的 AVS 可以定制它们的去中心化程度。例如，它们可以为 Operator 设置地理位置要求，或者只允许个人 Operator 提供节点服务，并相应地提供更多的激励来吸引这类Operator。

以下是一个示例：

Shutter 提出了一种通过使用阈值加密来防止 MEV 的解决方案。该过程涉及一组节点，称为Keypers，他们通过分布式密钥生成（DKG）参与计算一组共享的公钥和私钥。这些节点由Shutter DAO 的治理选举产生。

显然，DKG 依赖于诚实多数的假设。

通过借助 EigenLayer 提供的节点运营服务，Shutter 可以获得更广泛的 Kepers 分布。这种方法不仅降低了 Keypers 之间串通的风险，还增强了网络的安全性和弹性。

同样，Lagrange 的 Lagrange State Committee（LSC）由再质押者组成。对于每个状态证明，至少有 2/3 的委员会成员必须签署一个特定的区块头，之后才通过 SNARK 生成一个状态证明。

以太坊“包含”（Inclusion）信任

In addition to making commitments to Ethereum through staking, Ethereum validators can also make credible commitments to AVS if they further stake 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 period of time. 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, we should design slashing conditions 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, which may lead to 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 will your AVS require (re-staking capital, different distributed validator numbers, and the number of Ethereum validators needed to fulfill the Ethereum validator promise), 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 validators try to break the system, users are protected because they can compensate users through slashing redistributions.

Given that the TVL across chain bridges, the amount of ETH remortgaged, the number of Operators opting 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.

Re-stakeholders/Operators with a higher risk appetite may wish to participate in early AVS for 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 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/

The above is the detailed content of IOSG: "Four Questions" let you understand how to build AVS on EigenLayer. For more information, please follow other related articles on the PHP Chinese website!