
EigenLayer:リステーキングが中間ソフトウェアにもたらす信頼の革命
TechFlow厳選深潮セレクト

EigenLayer:リステーキングが中間ソフトウェアにもたらす信頼の革命
EigenLayerは来年初頭にメインネットのリリースを完了し、そのフラッグシップ製品であるEigenDAを展開する予定です。

昨年11月、当社はこの記事「EigenLayer:イーサリアムレベルの信頼をミドルウェアに導入する」において、EigenLayerについて紹介した。それからほぼ1年が経過し、EigenLayerはホワイトペーパーを発表し、5000万ドルのシリーズA資金調達を完了したうえ、第一段階のメインネットをリリースした。この期間中、イーサリアムコミュニティではEigenLayerおよびそのユースケースをめぐって広範な議論が行われてきた。本稿では、これらの議論を追跡・整理する。
背景
イーサリアムエコシステム内では、オラクルなど一部のミドルウェアサービスが完全にオンチェーンロジックに依存していないため、直接的にイーサリアムのコンセンサスとセキュリティを利用できず、信頼ネットワークの再構築が必要となる。一般的なアプローチとしては、まずプロジェクト側が運営を行い、その後にトークン報酬を導入して参加者を誘致し、徐々に分散化を進めていく方法がある。
しかし、この方法には少なくとも二つの課題がある。第一に、インセンティブメカニズムの導入には追加コストがかかる点である。すなわち、参加者がトークンを購入してステーキングを行う機会費用と、プロジェクト側がトークン価値を維持するために必要な運用コストだ。第二に、こうしたコストをかけても分散化されたネットワークを構築できたとしても、その安全性や継続性は依然として不確かなままである。新興プロジェクトにとっては特に、この二点が大きな障壁となっている。
これに対してEigenLayerが提案するのは、既存のイーサリアムステーカーによる「再ステーキング(Restaking)」を通じて、これらのミドルウェア(アクティブ検証サービス=AVS)に経済的セキュリティを提供するというアイデアである。再ステーキングを行う者が正直に行動すれば報酬を受け取れる一方、悪意のある行為を行えば、元のイーサリアムステーキング資産が没収される(スラッシング)リスクを負うことになる。
このアプローチの利点は二つある。一つは、プロジェクト側が新たな信頼ネットワークを自ら構築する必要がなくなり、代わりにイーサリアムバリデータにアウトソーシングすることで、資金的コストをできる限り低減できること。もう一つは、イーサリアムバリデータ集合がすでに非常に強固な経済的安全性を持っているため、一定のセキュリティが保証されやすい点である。また、イーサリアムステーカーの視点からは、再ステーキングによって追加収益を得られるため、明確な悪意がない限り、全体的なリスクは管理可能であると考えられる。
EigenLayerの創設者であるSreeramは、Twitterやポッドキャストで、EigenLayerの三つのユースケースおよび信頼モデルについて言及している。
-
経済的信頼(Economic Trust)。これは前述したように、イーサリアムステーキング資産の再利用であり、より高価値なトークンのステーキングにより、堅牢な経済的セキュリティが実現される。
-
分散化された信頼(Decentralized Trust)。一部のサービス(例:シークレットシェアリング)では、悪意ある行為が帰属できない場合があり、そのためスラッシングメカニズムに頼ることができない。このような場合は、共謀や談合のリスクを防ぐために、十分に分散化され独立した集団が必要となる。
-
イーサリアムバリデータのコミットメント(Commitment)。ブロック生成者がステーキング資産を担保にして、特定の信頼できる約束を行う。以下で具体例を挙げて説明する。

システム参加者

EigenLayerはオープンマーケットとして、以下の三者の主要参加者を結びつける。
-
再ステーカー(Restakers)。イーサリアムステーキング資産を保有している場合、引き出し資格証明書(withdrawal credentials)をEigenLayerに移行することで再ステーキングに参加できる。あるいは、stETHなどのLSTを単純に預けることでも参加可能である。再ステーカー自身がAVSノードを運用できない場合、その資産をオペレーターに委任することもできる。
-
オペレーター(Operators)。再ステーカーからの委任を受け、AVSノードを運用する。どのAVSにサービスを提供するかは自由に選択できるが、一度AVSにサービスを提供する場合には、その定めるスラッシングルールに従わなければならない。
-
AVS。AVSは需要側または消費者として、再ステーカーに対して支払いを行い、その提供する経済的セキュリティを獲得する。
以上のような基本概念を踏まえて、次にEigenLayerの具体的なユースケースを見てみよう。
EigenDA
EigenDAは、EigenLayerが展開するフラッグシップ製品であり、そのソリューションはイーサリアムのスケーリング案であるDankshardingに由来する。ここで用いられるデータ可用性サンプリング(Data Availability Sampling, DAS)は、CelestiaやAvailといった他のDAプロジェクトでも広く採用されている。本章ではまずDASについて簡単に紹介し、その後、EigenDAの実装方法とその革新点について見ていく。
-
DAS

Dankshardingの前段階として、EIP-4844は「Blob-carrying Transaction」を導入し、各トランザクションが約125KBの追加データを保持できるようになった。データシャーディングによるスケーリングの文脈では、この追加データはノードの負担を増大させる。そこで、「ごく一部のデータしかダウンロードしなくても、すべてのデータが利用可能であることを検証できる」ような仕組みが必要となる。
DASのアプローチは、ノードが小規模なデータに対して複数回ランダムにサンプリングを行うというものだ。各サンプリングの成功により、ノードはデータが利用可能であるという信頼度を高めていき、ある所定の水準に達すれば、データは利用可能であると判断する。ただし、攻撃者は依然として一部のデータを隠蔽する可能性があるため、何らかの耐故障性(フォールトトレランス)機構が必要となる。
ここに登場するのが、消散符号(Erasure Coding)である。消散符号の主な考え方は、データを複数のブロックに分割し、それらをエンコードして余分な冗長ブロックを生成するというものだ。これらの冗長ブロックは元のデータブロックの部分情報を含んでおり、一部のデータブロックが失われたり破損したりしても、冗長ブロックを使って欠落したデータを復元できる。このように、消散符号はDASに冗長性と信頼性を提供する。
さらに、生成された冗長ブロックが正しくエンコードされているかどうかを検証する必要もある。誤った冗長ブロックでは、元のデータを再構築できないためだ。DankshardingではKZG(Kate-Zaverucha-Goldberg)コミットメントを採用している。KZGコミットメントは多項式の検証手法であり、特定の位置における多項式の値が指定された数値と一致することを証明できる。
証明者は多項式 p(x) を選び、p(x) を使って各データブロックに対するコミットメント C1、C2、...、Cm を計算する。そして、証明者はコミットメントとともにデータブロックを公開する。エンコードの検証のために、検証者は t 個の点 x1, x2, ..., xt をランダムにサンプリングし、証明者にこれらの点におけるコミットメントの開示(p(x1), p(x2), ..., p(xt))を要求する。ラグランジュ補間法を用いて、検証者はこれらの t 個の点から多項式 p(x) を再構築できる。その後、検証者は再構築した p(x) とデータブロックを用いて、コミットメント C1'、C2'、...、Cm' を再計算し、それが公開されたコミットメント C1、C2、...、Cm と一致するかを検証する。
つまり、KZGコミットメントを使うことで、検証者はごく少数の点だけでエンコード全体の正当性を検証できる。これにより、DASの全体像が完成する。
-
How

EigenLayerはDASの考え方を借用し、これをEigenDAに応用している。
1. 最初に、EigenDAノードがEigenLayerコントラクト内で再ステーキングを行い、登録する。
2. 次に、Sequencerはデータを受け取った後、それを複数のブロックに分割し、消散符号を使って冗長ブロックを生成し、各データブロックに対応するKZGコミットメントを計算する。SequencerはKZGコミットメントを一つずつEigenDAコントラクトに公開し、証人として記録する。
3. その後、SequencerはデータブロックとそのKZGコミットメントをそれぞれEigenDAノードに配布する。ノードはKZGコミットメントを受け取り、EigenDAコントラクト上のものと比較して確認し、問題なければデータブロックを保存し、署名を行う。
4. その後、Sequencerがこれらの署名を収集し、集約署名を生成してEigenDAコントラクトに公開し、コントラクトが署名の検証を行う。検証が成功すれば、一連のプロセスは完了となる。
上記のプロセスにおいて、EigenDAノードは署名によってデータブロックの保存を主張しているにすぎない。したがって、ノードが嘘をついていないことを保証する仕組みが必要となる。EigenDAは「保管証明(Proof of Custody)」を採用している。
保管証明の発想は、データ中に「爆弾」を仕込むというものだ。ノードがこれに署名すれば、スラッシングの対象となる。保管証明を実現するには、以下を設計する必要がある:異なるDAノードを区別するための秘密値(チート防止用)、DAデータと秘密値を入力として「爆弾あり/なし」を出力するDAノード特有の関数。ノードが保存すべき完全なデータを持っていなければ、この関数を計算できない。Dankradはブログで保管証明の詳細を共有している。

怠惰なノードが存在する場合、誰でも証拠をEigenDAコントラクトに提出でき、コントラクトが証拠を検証し、有効であればそのノードをスラッシングする。
ハードウェア要件に関しては、32MBのデータに対するKZGコミットメントを1秒以内に計算するには、32〜64コアのCPUが必要だが、これはSequencer側のみに求められる条件であり、EigenDAノードには負担がかからない。EigenDAのテストネットでは、100のEigenDAノードによるスループットは15MB/sに達し、ノードのダウンロード帯域幅要件はわずか0.3MB/s(イーサリアムバリデータの要件よりもはるかに低い)だった。
まとめると、EigenDAはデータ可用性とコンセンサスの分離を実現しており、データブロックの伝播はもはやコンセンサスプロトコルやP2Pネットワークの低スループットというボトルネックに縛られない。なぜなら、EigenDAは事実上イーサリアムコンセンサスの恩恵を受けているからである:SequencerがKZGコミットメントと集約署名を公開し、スマートコントラクトが署名を検証し、悪意あるノードをスラッシングするプロセスはすべてイーサリアム上で行われ、イーサリアムがコンセンサス保証を提供するため、信頼ネットワークを新たに構築する必要がないのだ。
-
DASの問題点
現在、DAS自体にもいくつかの限界がある。悪意ある攻撃者が、軽ノードを欺いて偽のデータを受け入れさせようとあらゆる手段を尽くすと仮定する必要がある。Sreeramは自身のツイートで以下のように述べている。
個々のノードがデータが利用可能であると十分高い確率で判断するためには、以下の条件を満たす必要がある:
-
ランダムサンプリング:各ノードが独立かつランダムに多数のサンプルを選んでサンプリングを行い、攻撃者がどのノードがどのサンプルを要求したかを知ることができない。これにより、攻撃者は戦略を変更してノードを騙せなくなる。
-
並列サンプリング:DASが複数のノードによって同時に実行されること。これにより、攻撃者はあるノードのサンプリングを他のノードのものと区別できなくなる。
-
プライベートIPサンプリング:各データブロックの問い合わせに匿名IPを使用すること。そうでなければ、攻撃者はサンプリングを行う複数のノードを識別し、すでに問い合わせられた部分だけを返すことで、他のデータを隠蔽できる。
複数の軽ノードによるランダムサンプリングで並列性とランダム性は確保できるが、プライベートIPサンプリングを実現する良い方法はまだ存在しない。したがって、DASに対する攻撃ベクターは依然として残っており、DASは現時点では比較的弱い保証しか提供できない。これらの問題は現在も積極的に解決が進められている。
EigenLayer & MEV

SreeramはMEVconomics Summitにて、EigenLayerがMEVスタックに与える応用について語った。ステーキングとスラッシングに基づく暗号経済的プリミティブを活用することで、プロポーザーは以下の四つの特性を実現できる。これらは前述した第三のユースケース、「バリデータのコミットメント」に該当する。
イベント駆動型アクティベーション(Event-driven Activation)
Gelatoのようなプロトコルは、特定のオンチェーンイベントに反応する機能を提供する。すなわち、オンチェーンイベントを常時監視し、特定のイベントが発生すると、事前に定義された操作をトリガーする。こうしたタスクは通常、第三者のリスナー/実行者によって処理される。
「第三者」と呼ばれるのは、リスナー/実行者と実際にブロックスペースを処理するプロポーザーとの間に接続がないためである。リスナー/実行者がトランザクションをトリガーしても、何らかの理由でプロポーザーに含まれなかった場合、これは帰属不可能であり、経済的保証を提供できない。
再ステーキングに参加するプロポーザーがこのサービスを提供すれば、操作のトリガーに対して信頼できるコミットメントを提供できる。最終的にトランザクションがブロックに含まれなかった場合、プロポーザーはスラッシングされる。これにより、第三者のリスナー/実行者よりも強い保証が得られる。
実際の応用例(例:貸借プロトコル)では、過剰担保率を設定する目的の一つは、一定期間内の価格変動をカバーすることにある。これは清算までの時間枠に関係しており、より高い過剰担保率はより長い猶予期間を意味する。もし多くの取引がイベント駆動型の反応を採用し、プロポーザーによる強力な保証が得られれば、(流動性の高い資産については)過剰担保率の変動が数ブロックの間隔に限定される可能性があり、結果として過剰担保率を下げ、資本効率を向上させることができる。
部分ブロックオークション(Partial Block Auction)
現在のMEV-Boost設計では、プロポーザーはブロックスペースをビルダーに完全に外部委託しており、ビルダーが提出したブロック全体を受動的に受け入れ、提案するしかない。プロポーザーはMEV-Boostの中で自分が含めたいトランザクションを含めることができない。ビルダーはプロポーザーよりもはるかに少数派であり、談合して特定のトランザクションを検閲したり、身代金を要求したりする可能性がある。

EigenLayerはMEV-Boost++を提案し、MEV-Boostをアップグレードする。ブロック内にProposer-partを導入し、プロポーザーが任意のトランザクションを含められるようにする。また、プロポーザーは代替ブロックB-altを構築することもでき、中継がBuilder_partを解放しない場合にこのB-altを提案することができる。この柔軟性により、検閲耐性と中継の活性問題の両方が解決される。

これはプロトコル層の設計、すなわちePBSが提唱するcrListの目的と同じである。すなわち、広範なプロポーザーがブロック構成に参加できるようにすることで、検閲耐性を確保する必要がある。
閾値暗号(Threshold Encryption)
閾値暗号ベースのMEVソリューションでは、一組の分散ノードが暗号化・復号鍵を管理する。ユーザーはトランザクションを暗号化し、それがブロックに含まれてから復号されて実行される。
しかし、閾値暗号は多数派が誠実であるという仮定に依存している。大多数のノードが悪意を持てば、復号後のトランザクションがブロックに含まれない可能性がある。再ステーキングを行うプロポーザーは、暗号化されたトランザクションに対して信頼できるコミットメントを提供し、それがブロックに含まれることを保証できる。プロポーザーが復号後のトランザクションを含めなければ、スラッシングされる。もちろん、悪意ある多数派ノードが復号鍵を解放しなければ、プロポーザーは空ブロックを提案することもできる。
長期ブロックスペースオークション(Long-term Blockspace Auction)
長期ブロックスペースオークションでは、ブロックスペースの買い手が将来の特定のバリデータのブロックスペースを事前予約できる。再ステーキングに参加するバリデータは信頼できるコミットメントを提供でき、期日までに買い手のトランザクションが含まれなければスラッシングされる。この種のブロックスペース取得保証には実用的なケースがある。例えば、オラクルが一定周期で価格情報を更新する必要がある場合、Arbitrumが1〜3分ごと、Optimismが30秒〜1分ごとにL2データをイーサリアムL1に送信する場合などである。
PEPC

次に、最近イーサリアムコミュニティで広く議論されているPEPC(Protocol-enforced Proposer Commitment)について触れる。PEPCは実際にはePBSの一般化(Generalization)または拡張版である。
この論理を一つずつ分解してみよう。
-
まず、プロトコル外のPBSであるMEV-Boostを例にとる。現在のMEV-Boostはイーサリアムプロトコルレベルのスラッシングメカニズムに依存している。すなわち、プロポーザーが同一のブロック高で異なるブロックヘッダーに署名した場合、スラッシングされる。プロポーザーは中継が提出したブロックヘッダーに署名する必要があり、この署名により、プロポーザーとブロックヘッダーが紐づけられる。これにより、中継はビルダーのブロックが実際に提案されると信じる根拠を持つ。さもなければ、プロポーザーはそのスロットをあきらめるか、別のブロックを提案せざるを得ず、いずれにせよスラッシングのリスクを負う。この場合、プロポーザーのコミットメントはステーキング/スラッシングという経済的安全性によって保証されている。
-
同様に、ePBS設計の重要な原則の一つは「honest builder publication safety」、すなわち正直なビルダーが公開したブロックが実際に提案されることを保証することである。ePBSはプロトコル内PBSとして、イーサリアムのコンセンサス層に組み込まれ、プロトコル自体が保証を提供する。
-
PEPCはePBSのさらなる一般化である。ePBSは「ビルダーのブロックが提案される」ことを保証するが、これを部分ブロックオークション、並列ブロックオークション、将来ブロックオークションなどに拡張すれば、プロポーザーがより多くのことをコミットできるようになる。そして、プロトコル層がこれらが正しく実行されることを保証する。
PEPCとEigenLayerの間には微妙な関係がある。上述のPEPCのユースケースは、EigenLayerのブロック生成者向けユースケースと類似していることに気づきにくいわけではない。しかし、重要な違いは、再ステーキングに参加するプロポーザーは理論的にはコミットメントを破ることができる(経済的罰則を受けるリスクはあるが)。一方、PEPCの重点は「プロトコルによる強制(Protocol-enforced)」にあり、プロトコル層で強制力を実装しており、コミットメントが履行されなければブロック自体が無効となる。
(PS:ざっくり見ると、EigenDAはDankshardingに似ており、MEV-Boost++はePBSに似ている。これら二つのサービスは、プロトコル層の設計のopt-in版のようなものであり、プロトコル層に比べて市場投入が早く、イーサリアムの将来の方向性と同期しながら、再ステーキングによってEthereum Alignmentを維持している)。
イーサリアムコンセンサスを過負荷にしない?(Don't Overload Ethereum Consensus?)
数ヶ月前、Vitalikの記事「Don't Overload Ethereum Consensus」は、多くの人々によってRestakingへの批判と見なされた。筆者はこれは社会的コンセンサスの維持に関する注意喚起や警告であり、社会的コンセンサスこそが焦点であり、再ステーキングそのものを否定しているわけではないと考えている。
イーサリアムの初期には、The DAO攻撃事件が大きな論争を引き起こし、ハードフォークを行うべきかについてコミュニティ内で激しい議論が交わされた。現在では、Rollupを含むイーサリアムエコシステムは膨大なアプリケーションを支えるまでになっている。したがって、コミュニティ内で極端な対立を避け、社会的コンセンサスの一貫性を保つことは極めて重要である。
Hermioneは成功したレイヤー2を構築し、「自分のL2が最大であるため、必然的に最も安全だ。もしバグにより資金が盗まれた場合、損失が大きすぎてコミュニティはユーザーの資金を回復するためにフォークせざるを得ない」と主張する。高リスク。
上記引用は優れた例である。今日のL2の総TVLは数百億ドルを超え、問題が起きれば影響は甚大である。その際にコミュニティが状態のロールバックを目的としたハードフォークを提案すれば、必ず大きな論争を呼ぶだろう。もしあなたや私がそこに大きな資金を置いていたら、どう選択するか――そのお金を取り戻すか、それともブロックチェーンの改ざん不可の性質を尊重するか? Vitalikの主張は、イーサリアム上に構築されるプロジェクトはリスクを適切に管理すべきであり、社会的コンセンサスを巻き込んで、プロジェクトの存亡をイーサリアムに強く結びつけるべきではないということだ。
EigenLayerの議論に戻ると、リスク管理の要点はAVSが客観的で、オンチェーンで確認可能かつ帰属可能なスラッシングルールを定義し、意見の相違を避けることにある。例えば、イーサリアム上でブロックの二重署名を行うこと;軽ノードベースのクロスチェーンブリッジで他チェーンの無効ブロックに署名すること;前述したEigenDAの保管証明など。これらはすべて明確なスラッシングルールの例である。
おわりに

EigenLayerは来年初頭にメインネットの完全リリースを予定しており、そのフラッグシップ製品EigenDAを正式に展開する見込みである。すでに多くのインフラプロジェクトがEigenLayerとの協業を発表している。本稿ではEigenDA、MEV、PEPCについて議論し、さまざまなユースケースをめぐる興味深いディスカッションを紹介した。再ステーキングは今や市場の主流ナラティブの一つになりつつある。今後もEigenLayerの進展を注視し、新たな見解を共有していく予定である!
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News














