IOSG: 「4 つの質問」により、EigenLayer で AVS を構築する方法が理解できます

<img src="https://img.php.cn/upload/article/000/000/164/171159066812979.png" alt="IOSG: 「4 つの質問」により、EigenLayer で AVS を構築する方法が理解できます">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: 「4 つの質問」により、EigenLayer で AVS を構築する方法が理解できます">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）信任

イーサリアムバリデーターは、ステーキングを通じてイーサリアムへのコミットメントを行うことに加えて、EigenLayer にさらにステーキングする場合、AVS への信頼できるコミットメントを行うこともできます。これにより、提案者はイーサリアムのプロトコル レベルでの変更を必要とせずに、イーサリアム上で一部のサービス (MEV-Boost を介した部分ブロック オークションなど) を提供できるようになります。

たとえば、フォワード ブロック スペース オークションを使用すると、購入者は将来のブロック スペースを事前に確保できます。再ステーキングに参加するバリデーターは、ブロックスペースに対して信頼できるコミットメントを行うことができ、後で購入者のトランザクションを含めなかった場合、バリデーターは削減されます。

オラクルを構築していて、一定期間内に価格を提供する必要があるとします。または、L2 を実行していて、数分ごとに L2 データをイーサリアムに公開する必要があるとします。これらはすべて、前方ブロック スペース オークションの使用例です。

Q3: オペレーターが行う作業は軽量ですか?それとも重量ですか?

イーサリアムバリデーターの分散化を継承したい場合、AVS タスクは次のようにする必要があります。可能な限り軽量になるように設計されている必要があります。

タスクが大量のコンピューティング リソースを消費する場合、ソロ オペレーターはタスクを処理できない可能性があります。

Q4: スラッシュの条件は何ですか?

特定のサービスに再ステーキングすることにより、再ステークホルダーはスラッシュの可能性のあるリスクを受け入れます。このスラッシュ条件は AVS によって指定されます。

AVS として、チェーン上で検証可能、証明可能、客観的に起因するスラッシュ条件を設計する必要があります。たとえば、イーサリアムのブロックに二重署名し、ライト ノード クロスチェーン ブリッジ AVS のノードが別のチェーンからの無効なブロックに署名します。

スラッシュ条件が不適切に設計されていると、意見の相違が生じ、システム上のリスクにつながる可能性があります。

AVS は可観測性も確保し、サービス全体でリクエストと応答を監視、追跡、記録できるようにする必要があります。

数値化するにはどうすればよいですか?

AVS にはどの程度の信頼が必要ですか (資本の再ステーキング、さまざまな分散バリデーターの数、イーサリアムバリデーターの約束を果たすために必要なイーサリアムバリデーターの数)、またどのようにインセンティブを与えますか?

たとえば、クロスチェーン ブリッジの毎週の取引量が 1 億ドルで、1 億ドル相当のセキュリティをレンタルしている場合、ユーザーは安全であると信頼できます。バリデーターがシステムを破壊しようとしても、スラッシュ再配布を通じてユーザーを補償できるため、ユーザーは保護されます。

チェーン ブリッジ全体の TVL、借り換えされた ETH の量、オプトイン オペレーターの数、その他多くのパラメーターが今後も変化し、大幅に変動する可能性があることを考慮すると、AVS はセキュリティ予算を調整する何らかの方法が必要です。そしてバッファスペース。

AVS は、トークン総供給量の一部で経済的安全性を支払うことができます。

しかし、EigenLayer を使用するとトークン ユーティリティが侵害されることになりますか?

絶対にダメです。

EigenLayer はデュアル プレッジ (デュアル ステーキング) をサポートしています。これにより、ETH とネイティブ トークンの両方でネットワークを保護し、必要に応じて各トークンの比率を調整できます。ネットワークの初期段階では、ETH がより大きな割合を占める可能性があります。ネットワークが成熟するにつれて、ネイティブ トークンがより重要な役割を果たすことが必要になる場合があります。この場合、AVS はプロトコル ガバナンスを通じてネイティブ トークンの割合を増やすことができます。

さらに、AVS のセキュリティ ニーズが短期的に急速に増加した場合、たとえば、AVS オラクルが提供する DeFi プロトコルの TVL が急速に増加した場合でも、AVS は経済セキュリティを強化するために AigenLayer を使用できます。 。

この観点から見ると、EigenLayer は「回復力のある」セキュリティを提供するプログラム可能な信頼市場です。

どのような外部ツールを使用できますか?

注目すべき項目をいくつか紹介します。

EigenLayer のスリーパーティ市場では、オペレータは AVS ソフトウェアを正しくコーディングし、適切なスラッシュ条件を設定するために AVS 開発者に依存しています。ただし、AVS の多様性を考慮すると、各 AVS とオペレーターの間の対話ロジックが異なる可能性があり、それがまったく新しい分野を生み出します。偶発的なスラッシュ イベントを防ぐために、AVS はリリース前にコードベースを監査できます。さらに、EigenLayer には拒否権委員会があり、複数の署名を通じて誤ったスラッシュ決定を拒否することができます。

一方、Cubist は、EigenLabs と協力して、安全なハードウェアを活用し、カスタム ポリシーを使用してトランザクションに署名し、キー マネージャー内でメッセージを検証するオープンなアンチスラッシュ フレームワークを開発しています。たとえば、高さの異なる 2 つのブロック ヘッダーに同時に署名しても、キー マネージャー内のポリシー エンジンによって承認されることはありません。

リスク選好度の高い利害関係者/事業者は、より高い利益を得るために初期の AVS に参加することを望むかもしれません。この場合、Cubist の Anti-slasher が役立つ可能性があります。

EigenLayer が AVS による信頼ネットワークの構築に役立つことは多くの人が知っていますが、AVS は経済的セキュリティのためにいくら支払う必要があるのでしょうか?また、経済的攻撃からどのように防御するのでしょうか?

安全プロトコルは、AVS の経済的安全性の普遍的な標準尺度である安全率 (SF) を開発しました。 SF は汚職コストと汚職利益の概念に基づいています。

Anzen は、AVS が財務上のセキュリティに過剰な費用を支払うことなく、最低限のレベルの財務上のセキュリティを維持できるように支援します。

EigenLabs は、AVS のノード ソフトウェアのコーディングを支援するために、EigenSDK を開発しています。 SDK には、署名の集約、EigenLayer コントラクトとの対話ロジック、ネットワーキング、暗号化、およびイベント監視クライアント モジュールが含まれています。

一方、Othentic は AVS が製品をより迅速にリリースできるようにする開発ツールを構築しています。

参考文献:

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/

以上がIOSG: 「4 つの質問」により、EigenLayer で AVS を構築する方法が理解できますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。