著者: GoPlus

背景

昨年から今日に至るまで、EigenLayerはイーサリアムエコシステムの最も広く認知されたコアナラティブの1つとなっています。EigenLayerはイーサリアムエコシステムの中核的な物語として100億ドル以上のTVLを集めましたが、EigenLayerの最も広く知られた特徴が「Restaking」（再レバレッジ）の概念であることから、ほとんどの人は単に金融インフラとして見ているかもしれません。この最初の印象から、EigenLayerは単にユーザーがプレッジで追加収入を得るのを助けるプラットフォームだと思われがちだ。実際、より深く考えてみると、重要な疑問が浮かび上がってきます：なぜリペッジされたETHやLST（流動性誓約トークン）が追加収益を生むのか？この疑問に対する答えが、EigenLayerの本質を明らかにします。私は、EigenLayerは実際には革命的な金融主導のクラウドコンピューティング・インフラストラクチャだと考えています。この定義は一見矛盾しているように聞こえるかもしれませんが、EigenLayerが革新的であることを的確に捉えています。AWSやGCPのような従来のクラウド・コンピューティング・サービスは、コンピューティング・パワーを提供するために集中的なリソースのプロビジョニングと管理に大きく依存している。一方、EigenLayerは金銭的インセンティブと分散コンピューティング・リソースを巧みに組み合わせることで、クラウド・コンピューティングの新しいインフラ・モデルを作り上げました。この記事では、私たちの理解に従ってEigenLayerの原理的なメカニズムに深く入り込み、数ヶ月の開発実践の後、EigenLayerに基づいた独自の分散型ネットワークを構築する方法とAVSを設計する方法について、いくつかの経験とアイデアも共有します。

Eigenlayerとは？

何よりもまず、EigenLayerはイーサリアムエコシステムの革命的なインフラです。ユーザーにとっては、イーサアセットを保有する人が誓約の利息を得るだけでなく、それらの預託クレデンシャルを使用して他の有望なプロジェクトを支援することで追加の報酬を得ることができます。これがEigenLayer - Restaking - のコア・コンセプトであり、Etherの強力なセキュリティと、ネットワーク上のコンセンサス・セキュリティを必要とするすべてのプロジェクトの間の魔法の橋渡しの役割を果たします。開発者にとっては、セキュリティを提供するクラウド・コンピューティング・プラットフォームのようなもので、複雑なコンセンサスやセキュリティ・システムをゼロから構築することなく、分散型サービス自体の構築に集中することができる。

AVSとは何か、どのように機能するのか？

Eigenlayerをベースに開発者は独自のActively Validated Service (AVS)を構築することができます。これはEigenlayerのエコシステムで最も重要なコンセプトです。 AVSとは、単に「タスク」を検証するためにセキュリティが必要なプロトコル、サービス、システムのことです。例えば、分散型の価格予測マシンネットワークを構築したい場合、予測マシンネットワークの参加ノードが犯罪を犯すのを防ぐために、これらのノードに特定の資産を誓約させ、各ノードが報告された価格をブロードキャストするためのコンセンサスメカニズムを設定する必要があります。このシナリオはAVSが完成するのに非常に適しており、AVSサービス自体が価格を取得し、価格を報告する作業を請け負うと同時に、AVSはサービス管理契約にも対応しています。AVSはサービス管理契約であるサービス・マネージャーに対応しており、サービス・マネージャーはEigenlayer契約と通信し、サービスを運営するオペレーターやサービスを保護するための保証金の額など、サービスの機能に関連する状態を含んでいる。Vyas Krishnan氏によると、Eigenlayerは「クリプトをクラウドに変換する」役割を担っており、AVSはWeb2でおなじみのクラウドサービスであり、クリプトの純粋なオンチェーンコンピューティング機能をオフチェーンのクラウドコンピューティングに拡張している。AVSは我々がWeb2から知っているクラウドサービスであり、Cryptoの純粋なオンチェーンコンピューティング機能をオフチェーンのクラウドコンピューティングに拡張するものだ。では、AVSはEigenlayerネットワーク上でどのように機能するのでしょうか？

1. まず、固有層を使いたいプロジェクト側として。まず、Eigenlayerネットワークを利用したいプロジェクト側として、AVSクライアントとServiceManagerコントラクトを独自に開発する必要があります。 クライアント自体はネットワークが検証するサービスやシステムであり、将来的にネットワークに参加する多数のノードが実行することになります。一方、ServiceManagerコントラクト自体は、ノードがネットワークに参加するための条件や、ノード自身に対する報酬や罰の仕組みを指定します。例えば、どのトークンを誓約する必要があるか、誓約するトークンの最小数などである。同時に、AVS ServiceManagerコントラクトの仕様の一部にも従わなければならず、Eigenlayerメインコントラクトによってインデックスされ、相互に通信できるように、いくつかの基本的なインターフェースを保持しなければならない。

2. ネットワークに参加するノードはEigenlayerでは**"Operator "**と呼ばれ、Operatorはネットワークノードの実際の運用と保守に責任を持つプロのノードオペレータです。Operatorsは、ネットワークノードの実際の運用・保守を担当するプロのノード運用者であり、ネットワークに参加する際には、ServiceManagerで指定されたアクセス条件を満たす必要があります。また、Operatorとして、自分のノードを誓約するStakerになることもできる。Eigenlayerはデリゲート機能を設計し、一般ユーザーが自分のトークンを好きなOperatorノードに委譲し、そのノードがAVSを実行することで追加のネットワーク収益を得ることができるようにしました。

3. AVSを構築し、ノードをリクルートした後、ネットワークのサービスを消費・利用できるように開放することができます。

サービスマネージャがオペレータのノードをトリガーして、イベントイベントを経由してチェーンの下の計算を実行していることがわかります。オペレータは秘密鍵に署名した後、計算結果をコントラクトに返し、コールを完了する。しかし、実際には、AVSの使用は、より柔軟にすることができます、まず第一に、トリガAVSは、サービスマネージャを介して実行する必要はありません、そのIPと他のゲートウェイ情報の登録でオペレータノードが公開されているので、直接ゲートウェイを呼び出すために行くことができますサービスインターフェイスを公開する（スパムの多数を防ぐために、認証する必要があります）結果を取得しますが、プロセスでは、結果だけでなく、結果を報告する必要があります。ただし、このプロセスでは、サービスの可用性を向上させるために、対応するサービスを実行するために、複数のノードから同じ呼び出しが行われる可能性があるため、アグリゲータを介して結果とコンセンサスを報告する必要があります。サービスマネージャは、報告された結果に基づいてノードに報酬と罰を与えるために、固有層契約と対話します。

EigenLayerのコア・ポジショニング

AVSとEigenLayerの紹介の後、EigenLayerのコア・ポジショニングを3つのポイントにまとめたいと思います。よりよく理解し、使うかどうかを判断する。

Platform for linking pledgers and developers

EigenLayerの核となる位置づけのひとつは、pledgersとdevelopersをつなぐプラットフォームです。この革新的なモデルは、分散型ネットワークが構築され従事する方法に革命を起こし、両者に前例のない機会と利便性をもたらしました。

1. 高い立ち上げコスト: プロジェクト当事者は、多くの資金と利便性を投資する必要があります。ネットワークに参加するノードを集めるために、多くの資金と人手を投資する必要がある。

2. 運用プレッシャー: ノードのアクティブなネットワークを維持するには、継続的な運用とインセンティブが必要です。

3. ノード参加への高い障壁：潜在的なノード運営者は、参加するためにネットワーク固有のトークンを購入する必要があり、リスクとコストが増加します。

4. Slow network effects: 参加者が少ないため、新しいネットワークがセキュリティと信頼性を迅速に確立するのは困難です。

EigenLayerは、その革新的なデザインでこれらの問題を巧みに解決しています。誓約者がETHやLSTを使って同時に複数のネットワークのノードを提供することを可能にし、参加への障壁を大幅に下げます。プロジェクト関係者は、既に存在する大規模なプレッジャー・ネットワークに素早くアクセスすることができ、コールドスタート・プロセスを加速させることができる。ノード運営者にとっては、参加ネットワークごとに特定のトークンを購入する必要がなくなり、リスクエクスポージャーが軽減される。誓約者が複数のネットワークから報酬を受け取ることを可能にすることで、EigenLayerは複数の当事者にとってWin-Winのエコシステムを構築し、インセンティブの効率的な調整を可能にします。この革新的なモデルは、分散型ネットワークの構築と参加のプロセスを簡素化するだけでなく、ほとんどのトークン保有者が関心を持つための効果的なシナリオを提供します。

現在のEigenLayerエコシステムから、Coinbase Cloud、Figment、Google Cloud、Galaxy.Hashkeyなどである。これらの機関が加わることで、エコシステムにプロフェッショナリズムと信頼性がもたらされるだけでなく、一般ユーザーの信頼性も大幅に向上する。デリゲーターは、これらの強力なバックグランドを持つオペレーターを選択し、自分の資産を委託することで、プロフェッショナルなノード運用サービスを得るだけでなく、リスクも軽減することができる。開発者にとって、このような利便性は自明である。開発者は、コンセンサスネットワークの開発とメンテナンスのコストを削減し、すでに成熟した大規模な誓約プールを使用することで、比較的高いレベルのセキュリティを得ることができる。

共有セキュリティプール

前述したEigenLayerの最初の大きな特徴は、プレッジャーと開発者をつなぎ、プロジェクトが自分たちのサービスのバリデータノードを素早く見つけられるようにする機能です。では、開発者やプロジェクトにとって、これらのノードの安定性をどのように確保し、その結果、独自のネットワークのセキュリティを実現するのでしょうか？これはEigenLayerが解決する核心的な問題の一つであり、EigenLayerの最大のセールスポイントとも言えます。

まず第一に、いわゆるネットワーク・セキュリティとは何かを定義する必要があります。 従来のブロックチェーンや分散型ネットワーク・アーキテクチャでは、各ネットワークが独自にセキュリティとコンセンサス・システムを構築し、維持する必要があることは周知の通りです。分散型システムでは、すべてのノードが悪事を働く可能性があるため、ネットワークはゼロトラストの基盤の上に構築されなければならず、ネットワークの安定性とセキュリティを維持するために、ノードが悪事を働くのを防ぐための綿密なコンセンサスメカニズムを構築する必要がある。一般的に、ほとんどのネットワークは、**"スラッシュ "**を通じて、収益を得るために担保として自身のネットワークトークンを差し入れることで、ノードがネットワークの作業に参加できるようにすることを選択する。しかし、そのコスト自体が安定しているとは限りません。つまり、担保自体がこれらのネットワークのネイティブトークンである場合、価格の変動に伴い、ノードの悪のコストも常に変動し、「悪の利益が担保のコストよりも大きい」という条件を満たすと、ネットワークもセキュリティの危機に陥ります。このようなことは歴史上何度も起こっており、ネットワークのネイティブトークンの大半の価格は、実に非常に操作しやすく不安定である。

EigenLayerのソリューションは、シェアードセキュリティのコンセプトに焦点を当てており、事実上、イーサのセキュリティを収益の形でこれらの分散型ネットワークにリースします。担保提供者、ノード、様々なプロジェクトが集約され、悪事を働くコストを決定する担保がETH/LSTになるようにすることで、そのようなネットワークのセキュリティは、ETHの価格だけでなく、再誓約されたトークンの価格の安定性により、実際に信頼性が高まります。これはまた、ネットワーク全体の「セキュリティサービス料」を支払うための収益として自身のトークンを使用することで、ネットワークが早い段階で安定した安全な分散型サービスネットワークを迅速に確立するのに役立ちます。同じように、中央集権型サービスがこの方法で分散型に移行するのを助けることもでき、それによって元のサービスの品質と透明性を向上させ、そしてセキュリティ誓約を共有する人々に、改善されたサービスから得られる利益の一部を報酬として与え、正の循環に入る。

現在、EigenLayerは約120億ドル相当のTVL資産を持っており、これは共有セキュリティの巨大なプールに相当し、あらゆる種類のDA、シークエンサー、プレディケーター、およびあらゆる種類の分散型サイバーセキュリティサービスに提供するのに十分です。

プログラム可能なコンセンサス

EigenLayerの3つ目の核となる強みは、プログラム可能なコンセンサス能力です。ここでまずAVSの概念を紹介する必要があります。AVSの正式名称はActively Validated Servicesで、シーケンサー、DA、予言マシンネットワークやあらゆる種類の分散型ネットワークサービスなど、検証のために独自の分散システムを必要とするあらゆるサービスを指します。AVSは参加ネットワークのOperatorによって運営され、最終的にはAVSに対応するコントラクト（ServiceManager）によって管理・維持されます。このコントラクトはAVSのコンセンサスゲートウェイとして機能し、Operatorはコントラクトポータルを通じて登録する必要があり、報酬やペナルティはコントラクトによってトリガーされます。EigenLayerのプログラム可能なコンセンサス機能は、開発者にかつてない柔軟性とイノベーションの余地を提供します。開発者は独自のAVS検証ルールや要件、ノードアクセスルール、スラッシュルールなどを定義でき、誓約されたトークンの設定も可能です。この機能により、開発者はネットワークの開発段階やニーズに応じてコンセンサスパラメータを動的に調整することができ、ネットワークがさまざまなシナリオで最高のパフォーマンスとセキュリティを維持できるようになります。この適応性により、プロジェクトはいつでも運用メカニズムを最適化し、変化する市場の状況やユーザーのニーズに対応することができます。

AVS設計のアイデアと原則

独自のAVSを設計する前に、ほとんどの開発者は以下について考える必要があると思います:

独自のAVSを設計するために、ほとんどの開発者は以下について考える必要があると思います:

独自のAVSを設計するために、ほとんどの開発者は以下について考える必要があると思います:

1.プロジェクト自体が提供するサービスの必要性と種類

プロジェクトが提供するサービスの種類を理解することは、AVSを設計するための基本です。

必要性: 計算そのものがチェーン上のVMで実行できないものなのか、コストがかかりすぎるものなのか、そしてそれがチェーン上のコントラクトで検証できるものであれば、AVSを使う必要性を検討できます

検証ロジック: サービスによって必要な検証方法は異なります。を必要とします。

パフォーマンス要件: サービスの種類によって、速度とスループットの要件が決まります。例：

Security model: サービスによって直面するセキュリティの脅威が異なるため、ペナルティメカニズムの設計に影響を与えます。

Node Requirements: サービスの種類によって、ノードのハードウェアとソフトウェアの要件が決まります。たとえば、

• 計算負荷の高いサービスには高性能サーバーが必要

• ストレージ集約型のサービスには大容量ストレージが必要

• 金融サービスでは、より厳しいセキュリティ対策が必要になる場合があります。

• コンテンツ配信サービスは、改ざん防止やユーザビリティにより気を配るかもしれません

• リアルタイムのオンチェーン風制御サービスは、極めて低いレイテンシーを必要とします

• AIサービスは、多くのGPU演算パフォーマンスを必要とします

• AIサービスは、多くのGPU演算パフォーマンスを必要とします。

• 述語マシンサービスは、複数のデータソースの一貫性を検証する必要があるかもしれません

• DAサービスは、データの保存と取得を検証する必要があります

• オンチェーン・リスク・コントロールには、トランザクションのシミュレーションとレビューが必要であり、リアルタイムの効率性と正確性が求められます

2.悪質なノードを罰する方法

この問題はAVSのセキュリティと信頼性に直接関係します。開発者はネットワークのセキュリティと安定性を維持するために効果的な処罰メカニズムを設計する必要があります。

合理的な処罰メカニズムは、ノードが悪事を働く動機を効果的に減らし、ネットワークの長期的な健全な運用を保証することができます。

• どのような行動が「悪」とみなされるかを定義する

• 十分に抑止力があるが、ノードの参加が減るほど厳しくはない、適切な罰則を設定する

• 公正で透明性のある判定と執行の仕組みを設計する