再設計の観点からEigenLayerを理解する

ソース: denchain コミュニティ

このブログ記事では、EigenLayer プロトコルの進化を紹介し、EigenLayer アーキテクチャが元のコンセプトからどのように生まれたかを説明します。

このブログはDavid PhilipsonのAccount Abstraction Series^[5]にインスパイアされました。この記事に対するコメントやフィードバックをくれたNoam Horowitz^[6]、Shiva^[7]、NashQ^[8]、Mike Neuder^[9]、Sina^[10]のコミュニティに感謝する。

再スタートやEigenLayerという用語は多くの人が知っていますが、私たちのコア契約には何千行ものコード^[11]が含まれ、以下のように設計されていることを知っている人はごく少数です。

EigenLayer簡易アーキテクチャ

このブログポストでは、EigenLayerの現在の複雑なアーキテクチャが元のコンセプトからどのように生まれたかを説明することで、プロトコルの進化を紹介します。

この記事の対象読者は、スマートコントラクトの基本的な理解があり、EigenLayerやrestakingについて聞いたことがある人です。

このブログ記事の目的はEigenLayerのデザインの進化についてハイレベルな説明を提供することなので、インターフェース、変数、ロジックは現在のEigenLayerのコア契約^[12]とは異なるかもしれません。

さあ、始めましょう。

究極の目標：インフラ構築を簡単にする

まず、EigenLayerが解決しようとしている問題の紹介から始めよう。この部分についてはすでにご存知の方は、後のセクションは読み飛ばしてください。

イーサ上で分散型インフラを構築する開発者は、自身の経済的安全性を確立するという課題に直面しています。イーサはスマートコントラクトプロトコルの経済的セキュリティを提供しますが、ブリッジやシーケンサーのようなインフラは、ノードの分散ネットワークがコンセンサスに到達できるようにするために、独自の経済的セキュリティを必要とします。

コンセンサスメカニズムは、L1であれ、捕食者のネットワークであれ、ブリッジであれ、これらのノード間の相互作用を促進するために重要です。

プルーフ・オブ・ワーク^[13]はパワーを必要とし、プルーフ・オブ・オーソリティ^[14]は中央集権的すぎるため、プルーフ・オブ・ステーク^[15]（PoS）がほとんどのインフラプロジェクトのプライマリコンセンサスメカニズムとなっている。コンセンサス・メカニズムは、ほとんどのインフラ・プロジェクトで採用されている。

しかし、新しいPoSネットワークを始めるのは難しい。

まず、誓約者（誓約を提供する人）がどこにいるのかを特定するのが難しい。開発者が誓約者を見つける良い場所がないのです。

第二に、プレッジャーは新しいネットワークのプレッジを得るために多額の資金を投資しなければなりません。

第三に、プレッジャーは、イーサが提供する5%の報酬など、他の報酬の機会を見送らなければなりません。

最後に、現在のセキュリティモデルは最適とは言えない。

今のところ、インフラプロジェクトに関わる誓約者は、オフラインソフトウェアを安全に運用する責任も負っていると仮定しましょう。しかし、この前提は記事の後半で変更します。

EigenLayerはこれらの問題に対処するために作られました:

• 誓約者とインフラ開発者をつなぐプラットフォームとして機能します。

• プレッジャーは経済的な安全性を提供するために任意のトークンを使用することができます。

• プレッジャーは元のプレッジを破棄し、ネイティブのイーサ報酬を受け取りながら他のインフラのセキュリティに貢献することを選択できます。

• 再誓約することで、EigenLayerはセキュリティを分散（断片化）させるのではなく、一つにまとめることができます。

EigenLayerのホワイトペーパー^[16]はこれらの問題を掘り下げています。

EigenLayerは経済的保障を提供するというコンセプトを一般化しています。

目的1：誓約者とインフラ開発者をつなぐプラットフォームを作る

EigenLayerは、誓約者があらゆるインフラプロジェクトに誓約を提供できるプラットフォームです。EigenLayerは、EigenLayer上の潜在的な誓約者にインフラプロジェクトを提案できるプラットフォームです。プラットフォームのバックボーンは、誓約者が様々なインフラに対して信頼できる誓約を行えるようにすることです。

これらの約束は、EigenLayerだけでなく、すべての利益証明システムに適用されます。L1 誓約者は通常、プロトコルのルールに従うことを約束し、同じブロックの高さで競合するブロックに署名した場合、誓約を失うリスクがあります。

インフラ開発者はインフラのロジックとソフトウェアを構築し、誓約者はインフラを保護するための誓約を提供する。この誓約は、インフラの利用者に対するコミットメントとして提供されます。この誓約は、プロトコルの円滑な運用と、特定の不正行為に対するものです。

概念的に、あるプロジェクトが1億ドルの誓約によって支えられている場合、これは、そのプロジェクトが約束から逸脱して悪意のある振る舞いを見せた場合、_その1億ドルの一部がカットされることを意味します。簡単に言えば、「カット」は資金を破棄すると解釈できる。

数字が高ければ高いほど、利用者に安全と安心を提供することになる。

誓約者が様々な約束に誓約を割り当てることができるようにすれば、その上にユーザーフレンドリーなプラットフォームを作ることができる。

私たちは、さまざまな誓約者のコミットメントを強制するために、信頼できるプログラム可能なプラットフォームが必要であり、イーサは完璧に適合します。さらに、イーサは最大の誓約を保持しており、誓約者市場を飛躍させるのに役立ちます。

ここでの目標は、誓約者がEigenLayerを介してEther上のブリッジプロトコルのセキュリティを提供できるようにすることです。もし誓約者が悪意を持ってEther上のメッセージを偽造し、それをGnosisに送信した場合、誰でも証拠を提出し、その誓約者を切り捨てることができます。

誓約と約束の執行はイーサ上で行われるため、カットのロジックもイーサのスマートコントラクトとして実装されています。誓約者が約束を破った場合、誰でもカットコントラクトに証拠を提供し、悪意のある誓約者から誓約を没収することができます。

これがEigenLayerの基礎を形成しています - どんな誓約者も、どんなインフラプロトコルに対しても信頼できる誓約を行うことができます。

EigenLayerの初期設計

さて、これを実装してみよう。最も単純な設計から始めよう。誓約者は、証拠が提示され、基準が満たされたときに誓約者のトークンをカットできる機能を含む契約にトークンを誓約する。その後、ユーザーは残高を引き出すことができる。

他の誓約者もこのコントラクトにトークンを誓約することができ、インフラのセキュリティを高めることができる。このコントラクトをTokenPoolと呼ぶことにする。

わかりやすくするために、この記事で使われている用語の定義を以下に示します:

• 誓約者: 誓約を行う人: 誓約を行う人。本人：EigenLayerにトークンを提供する人。

• トークン: トークンの種類は問いません。

• TokenPool: 誓約者のトークンを保持するスマートコントラクト。

• Reduce：誓約者のアクセスを削除する。アクセス権を削除する。

このは、：誓約者のアクセスを削除します。この TokenPool インターフェイスは次のように表すことができます:

    function stake(uint256 amount) public;
      ；function withdraw() public;
      function enroll(address slasher) onlyOwner;
}

stake、withdraw、balanceの関数と変数に加えて、新しい関数と変数を導入しました。変数slasherは、各誓約者の現在登録されているAVSを監視し、関数enrollは、誓約者がAVSに参加することを可能にします

つまり、AVSに登録することは、実際に「カッター」にあなたの誓約をカットする能力を与えることになります。つまり、AVSに登録することで、"裁断者 "はあなたの誓約書を裁断することができるようになるのです。

この変更により、TokenPoolに誓約した後、誓約者はenroll関数を呼び出すことで、特定のAVSに参加することができます。slasherのマッピングが含まれています。

ここでのenroll関数はアクセス制御の対象となります。このTokenPoolが安全に管理されるように、信頼できるサードパーティが監督しているものとします。

引き出しプロセスの間、TokenPool契約は、各slasherに、誓約者が引き出す資格があるかどうかを判断するよう求めることができます。これは、slasherコントラクト内のisSlasher関数を通して検証される。もしisSlashedがTRUEであれば、誓約者は誓約を破棄されたことになり、誓約を撤回することはできません。

契約TokenPool {
    mapping(アドレス => uint256) public stakerBalance;
      mapping(アドレス => uint256) public operatorBalance;
    mapping(アドレス => アドレス) public delegation;
      mapping(アドレス => アドレス) public delegation;
    nbsp;mapping(address => address[]) public slasher;

    function stake(uint256 amount) public;
    functionwithdraw() public;
      function delegateTo(address operator) public;
    function enroll(address slasher)operatorOnly;
     function exit(address slasher) operatorOnly;
}

私たちはBalance変数を2つの異なる部分に分けました。さらに、delegationマッピングを導入し、質権者とオペレーターの間の委任関係を記録しています。

また、slasherマッピングにも小さな変更を加えました。これにより、slasher 契約が、誓約者の代わりにオペレーターの権限を削減するために付与されるようになりました。

     function withdraw() public;
}

TokenPool 契約は、各誓約の残高のみを追跡します。AVSのトラッキングと参加はDelegationManagerによって処理されます。

contract slasher {
   mapping (address => bool) isSlashed;

   function slash(address operator, ???????????);

   function slash(address operator, ? proof);

}

コントラクトの構造を整理し、各コンポーネントをモジュール化した結果、アーキテクチャは次のようになりました:

EigenLayer中間設計：Operatorの役割をPledgeeの役割から分離した後。

Goal: Support more tokens

これまでのところ、私たちは1つのトークンのみを維持するため、1つのトークンのプレッジをサポートするデザインを開発しました。1つのマッピングを維持します。

LPシェアに基づくモデルを採用し、トークン固有のTokenPoolsを作成することで、これを回避することができます。

これを行うために、TokenManagerという新しいコントラクトを作成します。TokenManagerは、プレッジャーがトークンをプレッジしたり引き出したりする場所になります。

TokenManagerの下で、各トークンはTokenPoolを持ちます。TokenManagerはすべてのトークンのための帳簿センターとして機能します。各 TokenPool は対応するトークンを保持します。

新しいコンポーネントは、プレジャーのさまざまなトークンを追跡するように設計されています。トークンを追跡するように設計された新しいコンポーネントです。

ユーザーがトークンを誓約するとき、それはTokenManagerによって処理されます。TokenManagerは次に、そのトークンに関連付けられた対応するTokenPoolのstake関数を呼び出します。ユーザのトークンはTokenPoolに転送されます。関数の最後で、totalSharesとstakerPoolSharesは新しい誓約を反映するように更新されます。totalSharesは、TokenPoolによって発行された株式の総数を追跡し、stakerPoolSharesは、各TokenPool内の個々の誓約者によって保有された株式数を記録します。

各契約のインターフェイスは以下のようになります:

contract DelegationManager {
    // ...
    mapping(address => mapping(address => uint256)) operatorPoolShares;
    // ....
}

さて、同じコアアーキテクチャで、誓約者は他のAVSを保護するためにEigenLayerに任意のトークンを誓約することができます

ゴール：AVSの設計を拡張する

次のシナリオを考えてみましょう。資産を切り崩す。

_例えば_、AVSで悪意を持って行動している、オペレーターであり質権者でもあるオペレーターがいるとします。そのオペレーターは、他の誰かがチェーンを切断する前に、EigenLayerの契約から誓約を撤回します。これが可能なのは、引き出しの時点ではslasherが自分の資産をカットするために更新されていないからです。その結果、カットできるトークンがなくなったため、AVSは悪意のあるオペレーター/プレッジホルダーをカットすることができなくなりました。

悪意のあるオペレーター/プレッジホルダーのイベントのタイムラインの可能性。

したがって、「安全な」AVSには、イベントが発生したブロックで不正なオペレーターをフリーズさせる契約削減が必要です。この制限は AVS の設計を大きく制限し、ほとんどの AVS を安全でなくします。

一つの解決策は、拘束解除期間を導入することです。誓約者がすぐに誓約を撤回できるようにする代わりに、アンバンドル期間と呼ばれる撤回プロセスの遅延を導入します。その後、誓約者は以前と同じように撤回できる。

誓約者がシステムからの脱退を決定すると、その要求はキューに入れられます。このキューに入れられた脱退は、事業者の最長のアンバンドリング期間が満了した後にのみ処理される。これは、オペレーターは複数のAVSを管理することができますが、プレジデントの引き出しは1つのアンバンドリング期間にしか合わせることができないためです。セキュリティ上の理由から、システムはアンバンドル期間を最も長いものに設定します。

例えば、あるプレジェンシーが、アンバンドル期間が6日、5日、7日の3つのAVSに参加しているオペレーターにプレッジを委任した場合、EigenLayerに引き出しをリクエストした後、プレッジにアクセスするには7日間待たなければなりません。これは7日間が3つの期間の中で最も長いためです。

7日間の期間が終了すると、質権者は出金することができます。しかし、この期間中に委任されたオペレーターが削減された場合、保留中の引き出しも停止される。

この変更を導入するために、DelegationManagerは各オペレーターのアンバンドリング期間を追跡し、オペレーターが新しいAVSに追加されたときに更新する必要があります。

contract TokenManager {
?
 mapping(address => address) public tokenPoolRegistry;
 mapping(address => mapping(address => uint256)) public stakerPoolShares;
 mapping(address => uint256) public withdrawalCompleteTime;

 function stakeToPool(address pool, uint256 amount) public;
function queueWithdrawal(address pool) public;
 function completeWithdrawal(address pool) public;
}

質権者が引き出しのためにキューに入っている間、TokenManagerは、DelegationManagerと、質権者によって委任されたオペレータがスラッシュされていないことを確認します。TokenManagerは、DelegationManagerのunbondingPeriodと現在時刻に基づいて、質権設定者のwithdrawalCompleteTimeを更新します。

期間をアンボンドした後、質権者はcompleteWithdrawalで引き出しを完了することができます。この関数は、withdrawalCompleteTimeが期限切れになったかどうかを確認します。もし期限切れであれば、その誓約者のトークンは前のプロセスに従って送金されます。

このプロセスの設計は複雑で、私たちのプロセスでは何度か繰り返してきました。このトピックについては別の記事を書くこともできます！現在、私たちはこのアンバンドリングのトラッキングを実施するためにタイムトラッキングシステムを使用しています。この部分はまだ進行中です！

モジュール式スラッシャー

スラッシュ機構をより安全にするのですから、よりモジュール式で効率的なものにしてみましょう。

現在、抽出プロセスの間、TokenManagerは個々のslasherにオペレータがスラッシュされたかどうかを確認する必要があります。これは誓約者のガス・オーバーヘッドを追加し、小規模な誓約者の報酬を大幅に減らすかもしれません。

さらに、AVS 開発者はスラッシャーを設計することが多いため、この特定のコンポーネントをモジュール化することで、個々の AVS の開発プロセスを簡素化できます。

TokenManager と同様に、スラッシュ機構は2つの部分から構成されます。SlasherManagerは各演算子の状態を保持します。別のslasherが各AVSのスラッシュ・ロジックを処理する。

誓約者のガス代を減らすために、スラッシュ契約をさらにモジュール化します。

    function slash(address operator, ?????) public;
}

<span ) 10px 10px / 40px no-repeat ;height: 30px;width: 100%;margin-bottom: -7px;border-radius: 5px;'>契約EigenPodManager{
    mapping(address =>

    function createEigenPod(address owner) public;
    function stakeToPod(address pod, uint256 amount) public;
    function withdrawFromPod(address pod) public;
}
契約EigenPod{
      address BEACON_CHAIN_ORACLE;
     address podOwner;
    uint256 restakedAmount;

    functionstake(uint256 amount) public;
    function verifyRestakedBalance(uint256 amount, MerkleProof proof) public;
    ；function withdraw() public;
}