EIP-7002: イーサリアムにステークするより良い方法

イーサリアムのプルーフ オブ ワーク (Pow) からプルーフ オブ ステーク (PoS) への移行、別名マージは、ネットワークの歴史における重要な瞬間でした。カーボン フットプリントを削減することでイーサリアムに待望のブランド変更をもたらしただけでなく、プルーフ オブ ステークは、イーサリアムのコンセンサスへの参加障壁を減らすという重要な長期目標にとって極めて重要でした。マージにより、イーサリアムの経済的安全性の基盤として、計算リソース (マイニング パワー) が金融資本に置き換えられ、ビーコン チェーンに 32 ETH をステークすることで、誰でも簡単にバリデータ ノードを収益性の高い方法で実行できるようになりました。

Proof of Stake はメリットをもたらしましたが、まだ改善できる点が数多くあります。その一部を以下に示します。

• ステークの集中化とバリデーターのカルテル化の削減
• バリデーターの運用オーバーヘッドを最小限に抑え、ソロステーキングを奨励する
• ステーキングの経済性とユーザーエクスペリエンス（UX）の向上
• 委任型および複数当事者によるステーキング操作のシンプルさ、セキュリティ、分散化を強化する

EIP-7002: 実行レイヤートリガー可能な引き出しは、前述の問題のいくつかを修正する新しい Ethereum 改善提案 (EIP) です。EIP は、引き出し操作をトリガーするためにバリデータの署名キーに依存するのではなく、引き出し資格情報を使用してステーカーがビーコン チェーンからバリデータを引き出しできるメカニズムを導入します。これにより、バリデータの署名キーと引き出しキーが効果的に分離されます。

バリデーター署名キーと出金キーの間のこの「関心の分離」には、出金認証情報を有効にしてステークされた ETH の制御を維持できるようにすることで、委任ステーキングにおける信頼の想定を減らすという重要な利点があります。この記事では、この機能が必要な理由を探り、特にソロ ステーキングと DVT (分散バリデーター テクノロジー) ステーキングにおける EIP-7002 のその他の利点について説明します。また、この記事では、Ethereum に EIP-7002 を実装する場合の潜在的な欠点についても検討します。

さあ、始めましょう！

舞台設定: 鍵、白い手袋、そして悲しみの物語

今日、ETH をステークしてビーコン チェーンを検証したい場合、主に 2 つのオプションがあります。ソロ ステーキングと委任ステーキングです。ETH をステーキングする方法は他にもありますが、これらは前述のオプションの間のスペクトル上で多かれ少なかれ引き出しになります。ソロ ステーキングは簡単です。

• 新しいバリデーターをアクティブにするには、ビーコンチェーンデポジットコントラクトに32 ETHをデポジットします。
• バリデーターの義務（トランザクションの検証、ブロックの証明、証明の集約、ブロックの提案）を実行するためのキーを生成します。
• バリデータノードを設定し、実行層（EL）とコンセンサス層（CL）クライアントを同期する
• ペナルティを回避するために、バリデーターをオンラインにして適切に機能させておく

他にも手順はありますが (Staking Launchpad のバリデータ FAQ には、バリデーターを目指す人向けの優れた概要があります)、これらはバリデーターの立ち上げにおける最も重要な側面です。重要なのは、ソロ ステーキングには仲介者やカウンターパーティは必要なく、ビーコン チェーンでの検証 (ブロックの証明とブロックの提案) から受け取った報酬の 100% を保持できることです。ただし、これは無料のサービスではありません。バリデーターを管理する責任があり、ソロ ステーキング操作を実行するにはある程度の技術的専門知識が必要になります。

バリデーターの管理が難しそうなら、委任ステーキングのルートを選ぶことができます。新しいバリデーターを登録するために 32 ETH を提供する責任は変わりませんが、バリデーターの運用責任を第三者に委任することになります。バリデーター ノード オペレーターは、いわゆる「ホワイト グローブ サービス」を提供しており、このサービスに対して報酬を要求します。たとえば、最初の契約の一環として、バリデーターの報酬の一部をノード オペレーターと共有することが求められる場合があります。

「ホワイト グローブ」の部分は、オペレーターがバリデーターを運用し、安全に保つ責任を負うことを意味します。つまり、バリデーターの義務を怠ったことによるペナルティやバリデーター キーの安全性を心配することなく、金曜の夜に Netflix をストリーミングするなどの操作 (または自由時間に行う操作) を行うことができます。

ただし、注意点があります。委任ステーキングでは、ノード オペレーターを信頼して、スラッシュ可能な違反行為 (2 つの競合するブロックに署名するなど) を犯したり、資金を完全に盗んだりして 32 ETH を危険にさらさないようにする必要があります。これは要求が多く、信頼の問題を抱えている人には絶対に適していませんが、ノード オペレーターが正直であれば、ほとんどの場合、この取り決めはうまく機能します。

しかし、イーサリアムは web2 の「信頼してくれよ」という精神に基づいて構築されたわけではないため、暗号通貨関連の Twitter や Reddit での会話では「信頼できない」や「信頼できないこと」という言葉が頻繁に登場します。委任ステーキングの最も純粋な形はこの精神と矛盾しますが、新しいバリデーターをアクティブ化するプロセス中にキーペアを生成する方法から回避策があります。

各バリデーターには、引き出しキーとバリデーターキーの 2 つのキーがあります。引き出しキーは、公開キーと秘密キーのペアで、ビーコン チェーン バリデーターの残高を部分的または完全に引き出すために必要なもので、"スキミング" (報酬のみを引き出す) または "終了" (32 ETH の残高 + 報酬を引き出す) のどちらを行うかによって異なります。バリデーターの残高を部分的または完全に引き出すには、引き出しキーをデフォルトの BLS ( 0x00 ) 認証情報から、Ethereum アドレスを指す0x01認証情報に更新する必要があることに注意してください。

出金キーは、 Staking Launchpadなどのインターフェースを介して入金時に生成され、ハッシュ化されて出金 ID が作成されます。この ID はバリデータの入金データに含まれ、ビーコン チェーンに 32 ETH を誰が入金したかに関する情報を提供します。Attestant の「Protecting Withdrawal Keys」の以下のインフォグラフィックは、出金キーがバリデータの入金リクエスト プロセスにどのように統合されるかを示す優れた概要を示しています。

バリデーターキーは、すべての Ethereum バリデーターに期待される義務 (主にブロックへの投票と、他のユーザーが投票するためのブロックの提案 (「投票」と「証明」は同じ意味で使用されますが、トランザクションの検証とブロックの有効性の確認という同じ概念を指します) を実行するために必要な公開キーと秘密キーのペアです。バリデーターの公開キーは、Ethereum のコンセンサス プロトコルで独自の暗号化 ID として機能しますが、秘密キーは非表示にされ、ブロック データの署名に使用されることが期待されます (このため、バリデーター キーは署名キーとも呼ばれます)。

さて、バリデータ（署名）キーと引き出しキーの主な違いは次のとおりです。

バリデータの署名キーは頻繁に使用されます (6.5 分ごと、またはブロックを証明または提案するために各バリデータが選択されるスロットの長さ)。ホット ウォレットなどのオンラインでアクセスしやすい場所に保管するのが最適です。ただし、引き出しキーはそれほど頻繁には使用されず、ステーカーが特定のバリデータに関連付けられた引き出しアドレスから資金を引き出すまで、コールド ウォレットなどの安全なオフラインの場所に保管できます。

この区別は、委任型ステーキング設定における信頼の仮定を減らすために重要です。検証義務には引き出しキーが必要ないため、ステーカーはノード オペレーターとバリデータ キーを共有し、引き出しキーを保持することで、ステーキングされた ETH の制御を維持できます。こうすることで、不正なオペレーターがステーカーの承認なしにバリデータ 残高を引き出してステーカーの資金を持ち逃げすることはできません。

委任型ステーキングの取り決めでは、ステーカーが引き出しキーを保持しますが、これは通常、ステーカーに代わってバリデータノードを操作するエンティティが、ステーキングされた ETH を最終的に制御できないことを反映して、「非カストディアル」と呼ばれます。これは、ステーキングサービスが署名キーと引き出しキーの両方を制御するカストディアルステーキングソリューションとは対照的です。「強化されたホワイトグローブサービス」は、カストディアルステーキングの優れたメンタルモデルです。ステーカーはバリデータに資金を提供するために 32 ETH を提供するだけで、バリデータへの入金リクエストの開始や引き出しキーの保存など、他のすべてをステーキングサービスに委任します。

バリデーターの署名キーを出金キーから分離することで、委任ステーキング契約における信頼の問題は理論的には解決されます。実際には、非管理型ステーキング設定におけるノードオペレーターとステーカーの関係には、バリデーターを出金し、バリデーターの残高の全額または一部を出金アドレスに引き出す現在のメカニズムにより、信頼の要素が残っています。

ビーコン チェーンからバリデーターを撤退させるには、バリデーター キーで署名された「自発的退出メッセージ」(VEM) をコンセンサス レイヤーで処理するために送信する必要があります。撤退メッセージはブロックに含まれると (各ブロックには最大 16 の撤退要求操作を含めることができます)、 撤退要求キューに追加されます。最終的な撤退の遅延は、キューに入れられた撤退の数やバリデーターの解約率などの要因によって左右されます。

既存の「非管理型」ステーキング ソリューションの問題点を浮き彫りにするために、バリデーターの署名キーを使用して自発的な引き出しリクエストに署名する必要があることを強調しました。つまり、ステーカーは引き出しリクエストを処理するために、VEM に署名するために必要なバリデーター キーを管理するノード オペレーターに頼らなければなりません。これにより、ノード オペレーターとステーキング サービスの関係に信頼が効果的に再導入されます。さらに悪いことに、ステーカーは悪意のあるノード オペレーターから「嫌がらせ」を受けるリスクにさらされます。

グリーフィング攻撃では、攻撃者の目的は相手に損失を与えることであり、必ずしも直接利益を得ることではありません。これを理解するために、アリスがボブにバリデーターの操作を委任し、後で 32 ETH を引き出すことにしたというシナリオを考えてみましょう。ボブはアリスの要求を尊重し、自発的退出メッセージ (VEM) に署名して引き出し要求をトリガーするか、引き出し要求メッセージに署名することを拒否してアリスの引き出し操作を遅らせることができます。ボブはアリスの要求を拒否することで直接利益を得ることはありません。彼にできることは、アリスがバリデーターを引き出すのを手伝うことを拒否してアリスの ETH を「人質」にすることだけです。

そうですね、それは 100% 正確ではありません。ボブはアリスにさらなる「悲しみ」を与えるために、さまざまな悪いことをする可能性があります。

1. 意図的にスラッシュ可能な違反を犯したり、ペナルティを課したりして、アリスのバリデータ残高を減らします。バリデータ義務の不履行 (例: 証明の欠落) やスラッシュ可能な違反 (例: 同じスロットで 2 つの競合するブロックに署名) に対する個々のペナルティは通常は低いですが、同じ期間に同様の違反を犯したバリデータ数に比例して増加します。たとえば、1 つまたは 2 つの証明の欠落によりバリデータ残高はわずかに減少しますが、複数のバリデータがオフラインになる非アクティブ リークが発生すると、その減少は指数関数的に増加します。

   
   

現在のメカニズムでは、悪意のあるボブは、バリデータがビーコン チェーンのコンセンサスから強制的に脱退するまで (実効残高が 16 ETH に低下した後)、ペナルティとスラッシングを課すことで、アリスのバリデータ残高 32 ETH を最大 50% 削減できます。1 ETH = 2,000 ドルとすると、ボブのグリーフィング攻撃により、アリスは通常の場合 (相関ペナルティなし) で少なくとも 32,000 ドル (16 ETH)、最悪のシナリオ (相関ペナルティにより残高全体が削減される可能性がある場合) で 64,000 ドル (32 ETH) の損害を被ることになります。

何かを破壊できる者は、何かをコントロールできる。— ポール・アトレイデス（『デューン』）

1. スラッシュ可能な犯罪を犯さないことと引き換えに、アリスに身代金を要求する。これは、前述のグリーフ行為の定義と完全に一致するわけではありませんが、アリスが強硬な態度を取ると決めた場合、ボブの唯一の手段は ETH を燃やすことであると考えてください。したがって、この状況は、目標が (常に) 最小限の損失で利益を上げることである、より一般的なタイプの攻撃とは異なります。

注: このシナリオでは、ボブ (ノード オペレーター) は実際には正直かもしれませんが、敵対者がバリデータ キーを侵害し、アリスの ETH を人質にする可能性があります。これは、ステーキング サービス (SaaS) プラットフォームのユーザーが負わなければならない「カウンターパーティ リスク」を説明しており、ソロ ステーキング (「自分以外は誰も信用しない」という精神) が Ethereum ステーカーのゴールド スタンダードと見なされるもう 1 つの理由です。

これは、すべての非カストディアル ステーキング サービスが実際には非カストディアルではないことを意味するのでしょうか? 必ずしもそうではありません。簡単な回避策は、ステーキング サービスが事前に自発的な引き出し要求メッセージに署名することです (できれば、ビーコン チェーンでバリデーターがアクティブ化された後)。ステーカーは引き出したいときにいつでも、そのメッセージを Ethereum コンセンサス ノードに独立して送信できます。

ステーカーの自発的な引き出しリクエストに事前署名することで、ステーカーとノードオペレーター間の取り決めは元の非管理状態に戻ります。ただし、事前署名された引き出しリクエストメッセージは、多くの理由から持続可能ではありません。

非管理型ステーキングの事前署名付き出金リクエストに関する問題

複雑

事前署名された出金リクエストのワークフローでは、ステーキングサービスオペレーターとステーキング委任者の間でより多くのコミュニケーションが必要になります。出金リクエストメッセージのリクエストを送信し、ステーキングサービスが署名された出金リクエストを送信するのを待つ必要があります。また、事前署名された出金リクエストの使用と交換にはセキュリティの問題もあります。

• ステーキング サービスでは、出金要求メッセージが悪意のある人物の手に渡らないように、出金要求メッセージを暗号化し、安全な (オフチェーン) 通信チャネルを介して共有するなどの特別な予防措置を講じる必要があります。
• 出金リクエスト メッセージを紛失すると、バリデーターの残高を独自に引き出す能力を失う可能性があるため、ステーカーは出金リクエスト メッセージを安全な場所に保管するために特別な注意を払う必要があります。

さらに、事前署名された出金リクエストは現在、2 回の Ethereum フォーク、または約 12 か月間有効です (フォークが約 6 か月ごとに発生すると想定した場合)。つまり、ステーカーは暦年内にステーキング サービス オペレーターに自発的な出金リクエストを複数回再送信する必要があります。ただし、 EIP-7044が実装され、署名されたバリデーターの出金リクエストが無期限に有効になると、この状況はなくなります。

EIP-7044 は、期限切れの終了メッセージの問題を修正しますが、特に大規模なステーキング プールでは、一連の新しい問題が発生します。背景として、分散型ステーキング プールの現在のアプローチでは、新しいバリデータ ノード オペレーターがプールから資金を受け取る前に、事前署名された引き出しリクエストを送信することを要求します。ここで、署名された引き出しリクエストは、(信頼されていない) オペレーターがバリデータ ファンドに対して持つ力を減らすため、暗号経済的セキュリティを提供します。ステーキング プールは、チェーン上で事前署名された引き出しリクエストを送信することで、協力しないバリデータ ノード オペレーターの引き出しリクエストをトリガーできます。

しかし、署名済みの出金リクエストがランダムなサーバーに保存されると、誰かが署名済みの終了メッセージを入手して誤ってまたは故意に偽の出金リクエストをトリガーするリスクがあるため、バリデータノードのオペレーターは安心できません。最悪のシナリオでは、強制終了によりバリデータノードのオペレーターが損失を被る可能性があります (たとえば、将来のビーコンチェーン報酬に対してローンを組んだ場合)。つまり、ステーキングプールは、署名済みの出金リクエストに無期限の有効期限がある EIP 7044 以降の世界では特に、さらに安全対策を講じて出金リクエストメッセージを安全に保存する必要があります。

考えられる解決策としては、署名済みの出金リクエストをDKG (分散鍵生成) プロトコルで生成された共有公開鍵で暗号化し、出金リクエストを復号化する前に、一定数のキーシェアが秘密鍵を再構築することを要求するというものがあります。これにより、他の参加者からの入力なしに署名済みの出金リクエストを一方的に復号化できるほど十分なキーシェアを誰も管理していない限り、出金リクエストを保管する当事者による信頼の仮定が軽減されます。ただし、1 つ以上の秘密鍵シェアが置き忘れられたり、紛失したり、盗まれたりした場合はエッジ ケースが発生し、バリデーターの出金をトリガーする必要がある場合に、署名済みの出金リクエストを復号化することが困難、またはまったく不可能になります。

規制遵守

ステーキング サービスは、仮想通貨の最大の敵であるゲイリー ゲンスラー氏が率いる SEC (証券取引委員会) をはじめとする、さまざまな規制当局から厳しい監視を受けています。たとえば、クラーケンは今年初めに、サービスとしての保管型ステーキング業務を停止し、「仮想通貨ステーキング プラットフォームを通じて未登録の証券を提供した」として 3,000 万ドルの罰金を支払いました。

理論的には、非カストディアル ステーキング サービスは、ステーク所有者との契約が非カストディアルであるため、SEC の監視対象となる可能性は低いです。

1. バリデーターをアクティブ化するための 32 ETH（または 32 ETH の倍数）のデポジットは、ステーカーが管理する出金アドレスから行われ、プロトコルは出金アドレスを 32 ETH デポジットの所有者として識別します。つまり、非カストディアル ステーキング サービスは、SEC によって Kraken が行ったと非難されたように、バリデーターの残高を引き出して「顧客の資金を自社の資金と混合する」ことはできません。

Kraken のような取引所では、すべての顧客資金が取引所が管理する 1 つ以上のウォレットに保管されるため、ユーザーのウォレット残高は「仮想」です。そのため、取引所が運営するカストディアル ステーキング サービスを介して 32 ETH をステーキングした場合、実際に手元にあるのは、引き出したいときにいつでも 32 ETH (およびバリデータ報酬の一定割合) を返済することを約束する取引所からの借用書です。

1. ステーカーは、不正なステーキングサービスによって引き出しが阻止されるリスクを冒すことなく、事前に署名されたエグジットを送信することで、独自に資金を引き出すことができます。対照的に、カストディアルステーキングサービス、特にKrakenのような取引所は、ステーカーの資産を管理しており、恣意的な理由で引き出しをブロックすることができます。

これら 2 つの事実により、「投資家保護」の必要性がなくなります。私は政策の専門家ではないので、この考え方に誤りがあった場合はご容赦ください。ただし、現在、機関投資家向けの非管理型ステーキング サービスを運営している場合は、まだ 1 つまたは 2 つの問題が残っている可能性があります。

• バリデーターをアクティブ化してから、事前署名された自発的な終了をステーカーに送信するまでの短い期間（またはおそらく長い期間）、ステーキング サービスは 32 ETH を制御します。これは、規制当局の目から見ると「保管」となります。さらに問題を複雑にしているのは、事前署名された終了の有効期限が短いことです（EIP 7044 以前）。新しい終了メッセージが署名されてステーカーに送信されるまでの間、バリデーター ノード オペレーターはステーキングされた ETH をある程度制御します。
• 通常の終了メッセージはオンチェーンでブロードキャストされ、公的に検証可能ですが、事前署名された終了メッセージは暗号化され、ノード オペレーターとステーカーの間でオフチェーンで非公開に共有される必要があります。これにより、規制当局などの第三者が、ステーキング サービスが最初のバリデーター預託契約の一部として終了の意図に本当に署名したかどうか、または元の終了メッセージの有効期限が切れた後に交換が再開されたかどうか (つまり、EIP 7004 以前) を確認することが難しくなります。

まとめると、事前署名されたエグジットは委任ステーキングの問題の一部を軽減しますが、イーサリアムのステーキングをトラストレス、セキュリティ、分散化するには不十分です。非管理ステーキングに「非管理」を戻すには、より優れたソリューションが必要ですが、EIP-7002のおかげでそれが実現しました。以降のセクションでは、EIP-7002について詳しく説明し、EIPのさまざまな利点と、実装に関連する潜在的な問題についても触れます。

EIP-7002の概要: 実行層トリガー可能な引き出し

EIP-7002 は、バリデーターの引き出し認証情報でトリガーできる新しい自発的な引き出し操作を導入することで、委任ステーキングにおけるプリンシパルエージェント問題 (ステーカーがバリデーターノードオペレーターを信頼して引き出しリクエストに事前署名するか、将来の引き出しリクエストを尊重する必要がある) を修正します。これにより、ステーカーは、引き出し処理のためにバリデーターの署名キーを保持するエンティティ (委任ステーキング設定のステーキングサービスなど) に依存せずに、ステーキングされた ETH を引き出すことができます。

EIP-7002 の主な特徴は、実行層から発信されたバリデーターの引き出し要求のキューを維持する、ステートフルなバリデーターの引き出し要求契約の導入です。一定間隔で、いくつかの引き出し要求がキューから削除され、ビーコン チェーン ブロックの実行要求に追加されます。これにより、実行層からの引き出し要求をコンセンサス層に「注入」し、ビーコン チェーン操作の一部として処理することができます。これは、デポジット契約から発信されたデポジットが処理のために実行層からコンセンサス層に渡されるのと同様です。

出金リクエストは、バリデーター コントラクト アドレスをターゲットとする通常の Ethereum トランザクションであり、バリデーター (公開鍵で識別) を撤退させる意図を示します。バリデーターの撤退メッセージは、(a) バリデーターの実行レイヤー ( 0x01 ) の撤退認証情報で参照される Ethereum アドレスによって署名されていること、(b) 撤退されるバリデーターがビーコン チェーン上でアクティブであることの 3 つの条件を満たす場合に有効です。これらのチェックは、出金リクエストがビーコン チェーンに届いた後にコンセンサス レイヤーによって実行されます。バリデーターの撤退リクエスト コントラクトは、ステーカーによって撤退リクエスト コントラクトが呼び出された時点で、撤退リクエスト トランザクションが十分なガスを支払っているかどうかのみを確認します。

実行レイヤーのすべての引き出しリクエストは、コンセンサスレイヤーからトリガーされる通常の自発的な引き出しリクエスト操作と同じ方法で処理され、アクティブなバリデーターの引き出しからの最大許容引き出しリクエストに関する不変性が保持されます。実行レイヤーとコンセンサスレイヤー間で引き出しリクエストを転送するための EIP-7002 のプロトコル内メカニズムにより、引き出しリクエストをトリガーするためのコンセンサスノードへの接続も不要になります (これは、事前に署名された引き出しリクエストを持つバリデーターを引き出すために必要です)。バリデーターへの資金提供と引き出しは、同じ実行レイヤーアドレスから行えるようになりました。これが、EIP が「実行レイヤートリガー可能な引き出し」と名付けられている理由です。

EIP-7002 が大まかにどのように機能するかを確認したところで、EIP の詳細について掘り下げていきます。次のセクションでは、 EIP-7002 の現在の仕様について説明し、バリデーターの引き出しリクエスト メカニズムの主要な側面について説明します。技術的な説明を飛ばして、EIP-7002 を実装する利点について調べたい場合は、次のセクションに進んでください。次のセクションでは、EIP-7002 によって実現されるステーキング ユーザー エクスペリエンス (UX) の改善点のいくつかについて説明します。

バリデーターの引き出しリクエスト操作

EIP-7002 によれば、バリデーターの引き出しリクエスト (疑似コードではadd_withdrawal_request()として定義) は、バリデーターの引き出しリクエスト コントラクト アドレスへのCALLです。バリデーターの引き出しリクエスト コントラクトへの呼び出しのトランザクション フィールドには、次の 2 つの値があります。

• source_address : トランザクションを開始した引き出しアドレスを表す20バイトの値
• validator_pubkey : 終了するバリデータの公開鍵を表す48バイトの値

ステーカーがvalidator_pubkeyを入力として引き出しリクエスト コントラクトを呼び出すと、バリデーター引き出しリクエスト コントラクトは次の操作を実行します (この操作の重要な部分については後で説明します)。

• トランザクションがEXIT_FEEカバーするのに十分なガスを支払ったことを確認する
• 現在のブロックの終了カウンタ（ EXIT_COUNT ）を1つ増やします。
• 終了メッセージをキューに挿入します
• 現在のブロックの超過引き出し（ EXCESS_EXITS ）を1つ増やす
• ガス料金を払い過ぎた場合、2300 ガスの補助金を送金して発信者に返金します ( EXCESS_RETURN_GAS_STIPEND )

重要な詳細: バリデーターの引き出しリクエスト コントラクトは、 source_addressがvalidator_pubkeyで識別されるバリデーターの有効な引き出しアドレスであるかどうかをチェックしません。また、 validator_pubkeyであるかどうかもチェックしません。これにより、攻撃者が失敗する運命にあるメッセージでキューを埋め尽くした場合に発生する可能性のある、微妙なセキュリティ問題が露呈します。これは主に、正当な引き出しリクエストの処理を妨害することを目的としたグリーフィング攻撃です。EIP-7002 は、引き出しリクエスト トランザクションに対して動的に調整される手数料を請求することでこの問題に対処します (引き出し手数料のメカニズムについては後述します)。

ブロックあたりの最大および目標引き出し額

ブロックあたりの最大ウィッシュ数

MAX_WITHDRAWAL_REQUESTS_PER_BLOCKは、ビーコン チェーン ブロックに含めることができる実行レイヤーの引き出しリクエストの数です。この値は現在 16 に設定されており、 VoluntaryExit (ステーカーのバリデータ キーを使用してコンセンサス レイヤーから直接トリガーされる終了操作) などのビーコン チェーン上の同様の操作を反映しています。

仕様では、 MAX_WITHDRAWAL_REQUESTS_PER_BLOCK 16 に設定すると、実行ペイロードのサイズ (ひいてはビーコン チェーン ブロックのサイズ) が制限され、コンセンサス レイヤーでの終了操作の処理のオーバーヘッドが削減されることも記載されています。これは、一部のステーカーがコンセンサス レイヤーからの終了をトリガーする現在のメカニズム (つまり、事前署名された終了またはリアルタイムの自発的な終了メッセージ経由) を使用してバリデーターを終了し続けることが予想されるため、便利です。

ブロックあたりのターゲットウィッシュリクエスト数

EIP-7002 では、理論上、ブロックに最大 16 の実行レイヤー終了操作を含めることができますが、ブロックあたり 2 つの終了というより保守的な見積もりを目標としています。仕様によると、 TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK 2 に設定されており、これは、流通しているすべての ETH がステークされている状況でも、バリデーターの解約率を制限し、ビーコン チェーンのget_validator_churn_limit()関数で定義されたエポックあたりの最大許容引き出し回数の不変性を維持するためです。

バリデーターの引き出しリクエストキュー

引き出し要求数

WITHDRAWAL_REQUEST_COUNTは、現在のブロックに含まれる引き出しリクエストの数です。バリデーター引き出しリクエスト コントラクトへの呼び出しが成功するたびに、バリデーター コントラクトのストレージに保存されているWITHDRAWAL_REQUEST_COUNT変数の値が 1 ずつ増加します (疑似コードではincrement_count()として定義されています)。

いつでも、 WITHDRAWAL_REQUEST_COUNTの値は、ブロックの実行ペイロードに追加される出金リクエスト操作の数に応じて、 TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK (2) とMAX_WITHDRAWAL_REQUESTS_PER_BLOCK (16) の間になります。WITHDRAWAL_REQUEST_COUNT WITHDRAWAL_REQUEST_COUNT 、新しい出金リクエスト操作によって支払われる金額 ( MIN_WITHDRAWAL_REQUEST_FEE ) を計算する関数への入力でもあります。

超過出金リクエスト

EXCESS_WITHDRAWAL_REQUESTS 、 MAX_WITHDRAWAL_REQUESTS_PER_BLOCKとTARGET_WITHDRAWAL_REQUESTS_PER_BLOCKの差です。これは、現在のブロックで使用されていない引き出しリクエストの数です。前述のように、各ブロックには最大 16 の引き出しリクエストを含めることができますが、通常の状況では 2 つの引き出しリクエストを対象としているため、 EXCESS_WITHDRAWAL_REQUESTS 「ブロックが理論上消費できる引き出しリクエストの数と実際に使用される引き出しリクエストの数の差」に相当します。

出金リクエスト コントラクトの超過カウンターは、最後のブロックの使用状況に基づいて更新され、バリデーターの出金リクエスト コントラクトを呼び出すトランザクションによって支払われる手数料を決定する要素の 1 つです。これにより、出金手数料が現在の使用量に応じて価格設定されます。これは、新しいブロックのbase_feeがターゲット ガス制限と前のブロックで使用されたガスの差に基づいて計算されるEIP-1559と似ています。

取り消し要求キュー

WITHDRAWAL_REQUEST_QUEUEは、バリデーター コントラクトのWITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT ( WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOTおよびWITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOTとして) に現在保存されているすべての保留中の出金リクエスト (到着順に並べられている) のリストです。キュー内の出金リクエストの数は無制限にすることができますが、 MAX_WITHDRAWAL_REQUESTS_PER_BLOCK変数レートは、各ブロックにキューから取り出せる保留中の出金リクエストの数を制限します。

引き出しリクエスト キューは、「ヘッド」インデックスと「テール」インデックス (どちらもキューの先頭と末尾付近のリクエスト セットを参照) を保持します。このインデックスは、1 つまたは複数の引き出しリクエストの処理を反映するために、各ブロックの後に更新されます。これは先入れ先出し (FIFO) キューであるため、リクエストはキューに追加された時点に従って実行されます。これは、特に正直なバリデーターへの嫌がらせに関して、セキュリティ上の意味を持ちます。

バリデーターの撤退契約手数料

MIN_WITHDRAWAL_REQUEST_FEEバリデータを引き出すためにバリデータ引き出しリクエスト コントラクトを呼び出すアドレスがガスで支払う必要がある金額です。引き出しリクエストをキューに挿入する前に、バリデータ引き出しリクエスト コントラクトは、トランザクションに添付されたガス料金がMIN_WITHDRAWAL_REQUEST_FEEの現在の値以上であることを確認します。トランザクションが正常に実行された後にガスが残っている場合、送信アドレスにはちょうど 2300 ガスがクレジットされます。

仕様によると、この設計は、宛先コントラクトでfallback()関数を呼び出すか、 transfer()またはsend()を介して ETH を送信すると、受信者に 2300 ガスの補助金が転送される、現在非推奨となっている Solidity の機能に従っています。ガス コストの変更 (ベルリン/イスタンブール フォーク以降) により、この機能の有用性は低下しましたが (背景については、 Solidity の transfer() の使用を今すぐ停止するを参照してください)、シンプルなガス会計システムという当初のアイデアは依然として有用です。EIP-7002 のコンテキストでは、2300 ガスの固定払い戻しを送信すると、バリデーターの引き出し要求コントラクトの手数料メカニズムが簡素化されます。

代替案としては、引き出し要求コントラクトがトランザクションから残ったガスの最大量を返せるようにする特別なメカニズムを設計することです。これは、特に引き出しアドレスが EOA である場合に理にかなっています。スマート コントラクトは、コントラクトの状態をチェックすることでMIN_WITHDRAWAL_REQUEST_FEEの正確な値を計算できますが、EOA は引き出し要求コントラクトへの呼び出しごとにより多くのガスを送信する可能性があります。このルートでは、単純なCALL使用して固定量のガスを払い戻しとして転送する場合と比較して、EIP-7002 の設計が複雑になります。ただし、EIP-7002 の作者は、関係者からのフィードバックに応じて、この機能が最終仕様に含まれる可能性があることを示唆しています。

MIN_WITHDRAWAL_REQUEST_FEEの計算は興味深いところです。引き出しリクエスト手数料は動的であり、EIP-1559 で導入された基本手数料と同様にネットワーク状況に応じて設計されており、次の 3 つの変数の関数です。

• 最低（基本）出金手数料: MIN_WITHDRAWAL_REQUEST_FEE
• 現在のブロックでの超過引き出し数: EXCESS_WITHDRAWAL_REQUESTS
• 出金リクエスト手数料更新式: WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

EIP-1559 のbase_feeと同様に、バリデーターの引き出しコントラクトの終了手数料はレート制限メカニズムです。平均的なケース (ブロックあたり 2 つのリクエスト) では、バリデーターの引き出しリクエスト コントラクトを呼び出す人は誰でも最小の引き出し手数料を支払うことが予想されますが、引き出し操作のコストは、ブロックに含まれる引き出しリクエストが増えるにつれて徐々に増加します。これは、引き出しリクエスト手数料を更新するための EIP-7002 の正式な仕様から推測できます。 withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) 。

仕様からの出金リクエスト手数料の仕組みの説明:

「ブロックごとの動作は、おおよそ次のようになります。ブロック N が X 件の出金リクエストを処理する場合、ブロック N の終了時に、 excess_withdrawal_requestsがX - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCKだけ増加し、ブロック N + 1 の withdrawal_request_fee はe**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / (WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION)の係数だけ増加します。したがって、既存の EIP-1559 と同様の効果がありますが、時間の経過に伴う分散に関係なく、同じ合計出金リクエストに同じように応答するという意味で、より「安定」しています。」

EIP-7002 は、バリデーターの引き出しリクエスト コントラクトの使用状況に応じて引き出しリクエスト料金を徐々に増加させることで、攻撃者が意図的に引き出しリクエスト キューをいっぱいにして他のバリデーターの引き出しを阻止するリスクを軽減します。引き出しリクエスト キュー内のリコール メッセージは、たとえば後入れ先出し (LiFo) や最高支払トランザクション順ではなく、先入れ先出し (FiFo) スタイルでキューから取り出されます。ガス価格によって引き出しリクエスト コントラクトへの不要な呼び出しが防止されると想定できますが、悪意のある攻撃者は、引き出しリクエスト キューを「詰め込み」、別のバリデーターの引き出しリクエストをキューの最後に押し出すために、より多くのガスを支払う可能性があります。

この問題は、マージ後のイーサリアムにおけるブロック構築の集中化によってさらに複雑化しています。攻撃者が 1 人以上の支配的なビルダーと統合し (参考:イーサリアムのこれまでのブロックの 80～90% は 4～5 人のビルダーによって生成されています)、ブロックの先頭に組み込むために料金を支払う意思がある場合、攻撃者は 1 人以上のステーカーからの引き出し要求を効果的に先取りし、ビーコン チェーンからバリデーターが適時に引き出しを行うのを阻止できます。

なぜ人はそのようなストレスを経験するのでしょうか? 考えられる動機としては、攻撃者が引き出し認証情報を使用してバリデーターを引き出したいステーカーを困らせたいということが考えられます。(悪意のある) ノード オペレーターの Bob とステーカーの Alice の例を使用すると、Alice は引き出し認証情報を使用してバリデーター引き出し要求コントラクトを呼び出すことで、Bob の困らせ攻撃を遅らせるためにバリデータをすばやく引き出しますが、Bob はバリデーター引き出し要求コントラクトをスパムして Alice の引き出し要求を遅らせることで、Alice のバリデーター残高を漏らす可能性がさらに高くなります。

ブロック構造と有効性

EIP-7002 は、引き出しリクエストをブロックの実際の本体 (およびコンセンサス レイヤーの実行ペイロード) に配置することを要求することで、ビーコン ブロックの構造と検証をわずかに変更します。リクエストは実行ペイロードに埋め込まれている必要があります。これにより、コンセンサス レイヤーが達成できない場合でも、コンセンサス レイヤーには状態遷移関数のコンセンサス部分を完全に実行するために必要なデータが保持されます。

EIP-7002 では、ブロックの新しい有効条件も追加されています。まず、出金リクエストのリスト ( withdrawal_requests_list ) は、 MAX_WITHDRAWAL_REQUESTS_PER_BLOCKを超えることはできません。次に、出金リクエストのリストは、そのようなリクエストが先入れ先出し (FiFO) の順序で並べられている場合、 WITHDRAWAL_REQUEST_QUEUEからデキューされた出金リクエストの数に対応している必要があります。

EIP-7002 には、ブロックにNUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCKの計算結果よりも多くの引き出しリクエストが含まれていないことを確認するための関数 ( expected_exit ) があります。また、ブロックを再実行するコンセンサス ノードは、引き出しリクエスト リストのハッシュのコミットメントと比較してrequest_typeとrequest_dataを反復処理することにより、引き出しリクエストのエンコーディングを独立して計算します。

EIP-7002 の理由: 実行レイヤーでトリガー可能な引き出しのケース

委任ステーキングにおける信頼の前提の削減

はじめに、バリデーターの終了を開始するためにバリデーターの署名キーに依存することで信頼の問題が発生することを指摘しました。信頼の定義は含めませんでしたが、Vitalik のTrust Models の記事にあるこの定義は、それをうまくまとめています。「信頼とは、他の人の行動について行う仮定のことです。」ステーキング サービスにサインアップすることで、ステーカーは悪意のあるノード オペレーターが引き出しを凍結できることを知りながら、ノード オペレーターが忠実に行動することを基本的に信頼しています。

EIP-7002 は委任ステーキングにおける信頼要素を完全に排除するわけではありません。ノード オペレーターがグリーフィング攻撃を実行しないことを信頼する必要がありますが、ステーカーが引き出し認証情報を使用して引き出しを行えるようにすることで、信頼の負担がある程度軽減されます。たとえば、ユーザーは、ノード オペレーターが要求に応じて自発的な終了メッセージに署名することを「信頼する」必要はありません。

「トラストレス」に関する微妙な点は、必ずしも信頼する必要を回避することではなく、(a) すべての当事者が正直に行動する強いインセンティブがあること (b) 正直な当事者は不正直な当事者の行動からある程度保護されていることから、信頼する必要がないということです。 撤回資格情報を使用してバリデーターを撤回する機能は、後者の例です。ボブはアリスを困らせようとするかもしれませんが、アリスは、ボブがさらに損害を与える前にバリデーターを撤回する権限を持っています。

ステーキングプールのリスク管理の改善

現在、ステーキング プールにはバリデータ ノード オペレーターに撤退を強制する方法がないため、プールの貢献者はノード オペレーターが誠実に行動することを信頼するという不快な立場に置かれています。一部の分散型ステーキング プールでは、ノード オペレーターに保証金の提供を求めていますが、悪意のあるオペレーターが 0 ETH に削減される可能性があることを考えると、保証金によるセキュリティは、リスクを嫌うステーカーの目には不十分である可能性があります。

EIP-7002 を導入すると、ステーキング プールは、ノード オペレーターの担保を大幅に削減する脅威に対するセキュリティを、実行レイヤーの引き出しを介して不正行為を行うオペレーターを強制的に引き出す手順で補完することで、信頼の前提を大幅に削減できます。引き出し資格情報がスマート コントラクト アドレス (EOA ではなく) を指す可能性により、ステーキング プールの新しいインシデント対応設計も可能になります。たとえば、オペレーターが一定期間内に平均よりも高いペナルティを受けた場合、スマート コントラクトは自動的に引き出し要求を送信できます。ただし、これには、バリデーターのパフォーマンスを追跡するオラクルと、スマート コントラクトをトリガーするキーパー ネットワークを信頼する必要があります。

EIP-7002 を実装することによるステーキング プールのもう 1 つの仮想的な利点は、署名済みの引き出しメッセージを要求して保存する必要がなくなることです。これには、以前に説明したようにリスクが伴います (たとえば、引き出しメッセージへの不正アクセスにより、バリデータによる予期しない引き出しが発生する可能性があります)。これは、トラストレス ステーキング プールの設計の目標にも貢献します。つまり、少数の (信頼できる) 個人によって保存された署名済みの引き出しリクエストに依存するのではなく、引き出しアドレスとして指定されたスマート コントラクトをガバナンスによって制御し、コミュニティがノード オペレーターの引き出しを公的かつ透過的に決定できるようにします。

DVT セットアップのリスク管理の改善

分散バリデーター技術(DVT) は、さまざまな理由から、Ethereum のステーキング インフラストラクチャの重要な部分であると考えられています。

• DVT は、ソロ ステーキングの障壁を軽減します。複数のソロ ステーカーが資金をプールして、他のすべての当事者を信頼することなく、バリデーターを共同でアクティブ化できます。マルチパーティ コンピューティング (MPC) スキームは、最大 1/3 の障害ノードを許容できるため、仮想の分散バリデーターがバリデーターの署名キーを再構築するために 3/5 のキーシェアを必要とする場合、2 つの DVT ノードがオフラインでも署名を行うことができます。
• DVT は、機関投資家や個人投資家のステーキング設定のフォールト トレランスと回復力を向上させます。前述のように、バリデータの署名キーは異なるキーシェアに分割され、ブロック データの署名が必要な場合にのみ再構築されます。これにより、ハッカーがバリデータの署名キーを侵害したり、署名キーを保存しているデバイスが損傷したためにステーカーが資金にアクセスできなくなったりするリスクが軽減されます。

ただし、DVT セットアップは、ビーコン チェーンでの引き出しと終了の現在の仕組みにより、ステーカーにとって依然として一定のリスクを伴います。一部の DVT ノードがキーシェアを紛失したり、しきい値署名スキームへの参加を拒否したりすると、バリデーターから終了することは不可能になります。特に次の場合には危険です。

• DVT セットアップの各参加者のキーシェアは、バリデーターのアクティブ化時に生成され、最初の DKG セレモニー後に「更新」することはできません (「参加者」は、単に同じステーカーが所有する別の EOA である可能性があることに注意してください)。一部の DVT プロトコルでは、新しいキーシェアの生成が許可されていますが、残りのキーシェアが通常の署名に必要な署名の定足数を満たす必要がある場合があります。
• クォーラムしきい値（分散バリデーターの有効な署名を共同で生成するために必要なキーシェアの数）は、（分散）バリデーターがアクティブになると変更できなくなります。

EIP-7002 が引き出しキーを使用してバリデーターを引き出すオプションを提供しない場合、独立して、または他のバリデーターと協力して DVT セットアップを実行する利点は大幅に減少します (例: バリデーターの残高が永久にロックされる可能性があります)。EIP-7002 は、分散バリデーターにフォールバックの安全オプションを提供します。署名キーの再構築が実行不可能な場合は、キーシェアから再構築された引き出しキーで署名された引き出しリクエストを送信することで、バリデータをビーコン チェーンから引き出すことができます。

規制遵守の向上: 非管理型ステーキングに「非管理型」を導入

EIP-7002 の著者が、規制対象の機関向けステーキング サービス企業の運営を容易にすることを目標として明確に策定した可能性は低いでしょう。それでも、EIP は、ステーキングされた ETH を機関が管理していないことを規制当局に納得させるという問題の解決に役立ちます。このシナリオでは、ステーキング オペレーターは、ステーカーの引き出しキーで署名された預金トランザクションのハッシュ (これで、自発的な終了に署名して送信できます) を、バリデーターに預けられた資金がいかなる時点でも管理下にないことの証拠として提示するだけで済みます。

私が「任意の時点」を強調したのは、EIP 7044 以前は、事前署名された終了の有効期限が切れた後、ノード オペレーターがバリデーターの残高を一時的に管理していたためです。また、EIP-7044 の永続的に有効な署名された終了であっても、バリデーターがアクティブ化されてからステーカーがステーキング サービス オペレーターから署名された終了メッセージを受信するまでの短い期間、ノード オペレーターはバリデーターに預けられた 32 ETH を引き続き管理します。EIP-7002 はこれらの厄介な部分を取り除き、ビーコン チェーンへの参加から引き出し、資金をステーカーの引き出しアドレスに送信するまで、バリデーターのライフサイクル全体を通じてステーカーが資金を (証明可能な) 管理できるようにします。

ステーキングのユーザーエクスペリエンス（UX）を向上

EIP-7002 の優れたメンタルモデルは、これを「ステーキング インフラストラクチャのアカウント抽象化」と考えることです。コンテキストとしては、バリデータ キー (または署名キー) は常に EOA であり、今日の通常の Ethereum EOA に影響を与える秘密キーの安全性と使用に関する同じ一連の制約が伴います。

• バリデータ（署名）キーは、侵害されるリスクが高くなります。コールド（オフライン）ストレージに保存される引き出しキーとは異なり、バリデータキーはインターネットに接続されたホットウォレットに保存されるため、フィッシング攻撃を受けやすくなります。バリデータ署名キーが侵害された場合、ステーカーと委任ステーキングプロバイダーは、フォールバックプラン（「残高が16 ETHに減少し、バリデータがプロトコルによって強制的に引き出されるまで待つ」以外のプラン）がなければ、導入部で説明したグリーフィングベクトルの影響を受けやすくなります。
• バリデーターキーの回復スキームのオプションは限られています (一度失うと永久に失われます)。分散バリデーターテクノロジー (DVT) を使用してバリデーターキーを複数のキーシェアに分割すると、このリスクを軽減できますが、ソロ DVT ステーキング設定を実行するのは簡単ではありません。また、前に説明したように、キーシェアが失われ、キーシェアの更新が複雑になる可能性があるため、DVT は万能薬ではありません。
• バリデーターキーは、より柔軟なステーキング設計をサポートできません。さまざまなステーキングサービスでは、引き出し資格情報をスマートコントラクトにポイントする利点により、バリデーターに資金を提供するための自動化された柔軟なワークフローを開発してきました。ただし、バリデーターの引き出しは、自発的な引き出しリクエストメッセージに署名する必要がある手動プロセスです。このプロセスは、署名前の引き出しリクエストを保存するスマートコントラクトによって自動化できますが、前述の特定の信頼の前提とセキュリティの考慮事項が伴います。

出金キーがバリデーターから出金できるようになると、これらの問題のほとんど、または少なくとも一部は解決できます。これを機能させるには、ステーカー (またはステーキング プール) が0x0出金認証情報から0x01出金認証情報への 1 回限りの変更を完了する必要があります。0x0認証情報はデフォルトでは BLS (EOA) キーですが、 0x01認証情報はスマート コントラクトや EOA を含む任意の Ethereum アドレスを指すことができます。バリデーターの出金アドレスとしてスマート コントラクトを設定すると、ステーキングのユーザー エクスペリエンス (UX) を向上させるのに最適です。

1. 引き出しキーには、ソーシャルリカバリのような柔軟なリカバリメカニズムがあります。ステーカーには、元のキーが盗まれたり紛失したりした場合に、引き出しリクエストのスマートコントラクトを制御するための新しいキーを承認できる 1 人以上の「保護者」がいます。保護者は、友人、親戚、仲間のステーカー、または専門のサードパーティサービスである可能性があります。リカバリメカニズムの柔軟性は、特にソロステーカーにメリットをもたらします。バリデータが一定期間証明を停止した場合 (たとえば、「あの世へ旅立った」ため)、EL 出口をアクティブにして資金を指定のアドレスに送信するデッドマンスイッチを設定できます。

2. 柔軟なステーキング設計が生まれる可能性があります。たとえば、リスクを嫌うステーカーは、引き出しキー全体を保存する代わりに、2/2 マルチシグ引き出し契約 (ステーカーとノード オペレーターが引き出し要求を承認するために必要な 2 つのキーのうち 1 つを保持する) を好む場合があります。これは依然として非管理型 (ノード オペレーターは承認なしでバリデーターを終了できません) ですが、ステーカーが提案した引き出し要求トランザクションへの署名を拒否することでバリデーターの終了をブロックしないようノード オペレーターを信頼する必要があります。

ステーキング プールの場合、ステーキング設計の柔軟性は、バリデーターの所有権を更新または譲渡するための任意のロジックを備えた引き出し契約を実装することを意味する可能性があります。EIP-7002 がない場合、ステーキング プールがバリデーターの所有権を管理できる唯一の実際の方法は、事前に署名された引き出しリクエストを移動することですが、これにはさまざまなリスクとエッジ ケースが伴います。

3. バリデーターの引き出しは安全に自動化できます。スマート コントラクトに署名済みの引き出しリクエストを保存するのとは対照的に、引き出しリクエスト コントラクトにはバリデーターの引き出しリクエストを管理する複雑なルールを設定できます。「マッド サイエンス」なアイデアは、ノード オペレーターが信頼できない方法でローテーションされる「時間ベースのステーキング プール」です。または、Lido のような大規模なステーキング プールが分散化を望んでいる場合を考えてみましょう。ガバナンスは、大規模なノード オペレーターによって管理されているバリデーターの一部を引き出し、資金を小規模なオペレーター (または単独のステーキング者) に再分配して、多数のバリデーターを管理するノード オペレーターによるボトルネックを減らすことができます。

これらは EIP-7002 によって可能になる初期の可能性の一部にすぎませんが、Ethereum のスマート ウォレットの新しい機能や使用例が次々と登場しているのと同じように、さらに多くのアプリケーションが登場すると確信しています。この記事を読んでいて、EIP-7002 をステーキング設計に適用するためのより具体的なアイデアをお持ちの場合は、コメントでお気軽にご意見をお寄せください。

EIP-7002 を実装することには欠点がありますか?

既存のステーキング設計に重大な変更が生じる可能性がある

EIP 草案では、EIP-7002 の著者は、出金認証情報を有効にしてバリデーターの出金をトリガーすることに関する潜在的な懸念を認めていますが、さらに「この機能 [つまり、出金認証情報で出金できない機能] に依存するステーキング設計は知りません」と述べています。これは合理的に思えます。この機能を必要とする委任ステーキングの取り決めについて推論するのは、私でさえ困難でした。しかし、それが明白に見えないからといって、存在しないということではありません。

「静かに、しつこく湧き上がる疑問に耳を傾けてください。知らないと、何を知らないのか、どれだけ知らないのか、どれだけ知る必要があったのかもわかりません。」— エリーゼル・ユドコウスキー

背景を説明するために、 一般化メッセージ バス (GMB) を介して引き出し認証情報承認の終了を実装するという初期提案に関する会話のスクリーンショットを掲載します。GMB はシステム レベルのスマート コントラクトであり、そのイベントは現在の預金コントラクトのようにクライアントによって読み取られて処理され、実行層からコンセンサス層にメッセージを伝達できます。著者はより一般的な EL から CL へのメッセージ タイプを示唆していましたが、EL から CL へのメッセージ バスの主な提案された使用例は、0x01 引き出し認証情報を介して実行層から終了をトリガーする方法を提供することでした。

このやり取りから、ステーカーが退出キーを使用してバリデーターを退出させることができないという前提で構築されたステーカーとノード オペレーターの関係の例がすでにあります。EIP-7002 を実装する潜在的なエッジ ケースのもう 1 つの例は、 YouTube で視聴できる Lido Community Staking Podcast での Lido の分散化計画に関する会話です。(EIP-7002 はビデオで簡単に (28:55 から 30:00) のみ言及されています)。

背景として、Lido はビーコン チェーン バリデーターの約 33.3% を制御し、Ethereum のコンセンサスを危険にさらす可能性があるため、「Ethereum に対する体系的な脅威」と説明されています。たとえば、Lido DAO がノード オペレーターにトランザクションの検閲を強制したり、以前に確定したブロックを元に戻したりする場合などです (Mike Neuder のLido 攻撃ベクトルの規模と方向で、脅威の詳細が説明されています)。

しかし、前にリンクしたエピソードの講演者の一人は、ノード オペレーターが何らかの権限を持っているため、DAO がノード オペレーターを強制的に Ethereum プロトコルへの攻撃に取り込むというこの攻撃ベクトルはまだ存在しないという説得力のある主張をしています。DAO はバリデーターが退出した後もそのステークを保留することはできますが、バリデーターに強制退出の脅威を利用して Ethereum のコンセンサスを攻撃させることはできません。

EIP-7002 では、力関係が大きく変わります。DAO が管理する撤退契約により、オペレーターを意に反して撤退させることができ、DAO はノード オペレーターに対して影響力を持つことになります。このタイプの影響力は、以前に説明したように、悪意のあるオペレーター セットからステーキング プロトコルを保護するのに役立ちます。ただし、次のシナリオで悪用される可能性もあります。

• ステーキングプロトコルがガバナンス攻撃を受け、DAOが悪意のある提案を可決し、バリデーターの撤退契約からの撤退を誘発する
• 攻撃者は、出金リクエスト契約の所有権を乗っ取ることで1つ以上のバリデーターの制御を取得し、成功した脅迫戦略を実行します。

これは、EIP-7002 がステーキング設計における既存の想定をどのように変えることができるかを示すもう 1 つの例です。今回は、Lido のようなステーキング プールに代わって検証するノード オペレーターが対象です。ただし、この攻撃ベクトルは、安全で厳密に監査され、おそらくアップグレードできない引き出し要求契約を使用するか、安全な DAO ガバナンスのベスト プラクティスに従うなどのさまざまな方法で簡単に軽減できます。

ノード オペレーターがプロトコル ルールに違反するという攻撃者の要求を拒否した後に強制撤退によって損失を被るというエッジ ケースを考慮すると、ステーキング プールは不動産会社からヒントを得てノード オペレーターを保護することができます。

• 賃貸契約に署名する前に、借主は「保証金」を支払う必要があります。保証金は不動産会社の管理外の銀行口座に保管されます。
• 借主がアパートから退去する際に重大な損害を残した場合、不動産会社は保証金を使って修繕費用を賄う権利があります。
• 借主の退去時にアパートが良好な状態であれば、保証金は借主に全額返金されます。

ステーキング プロトコルは、 Nexus Mutual 、 Tidal Finance 、またはその他の暗号通貨ネイティブ保険プラットフォームを介して「ノード オペレーター保険基金」ポリシーを取得することにより、ノード オペレーターを保護するための同様のアプローチを採用できます。オペレーターのバリデータが合法的に撤退した場合、保険基金は DAO に返還されます。逆の場合 (バリデータの撤退が悪意のある提案または撤退契約のバグによって引き起こされた場合など)、保険ポリシーによりノード オペレーターに損害が支払われます。このアプローチは、バリデーターからの撤退に関する現在の仕様に依存する既存の関係に一般化できることに注意してください。

より複雑なELからCLへのメッセージのサポートが不足している

EIP-7002 のバリデーター撤回要求コントラクトは、バリデーターを撤回するために、イーサリアムの実行レイヤーからコンセンサス レイヤーに撤回要求を送信するという単一の機能を提供します。ただし、実行レイヤーとコンセンサス レイヤー間で汎用的なタイプのメッセージを渡すために、一般的なメッセージング フレームワーク (たとえば、 SendMessageToConsensusLayerプリコンパイル、または前述の Generalized Message Bus (GMB) システム レベル コントラクト) を実装することを提案する人もいます。これには、特に ETH を EL-to-CL メッセージに添付できる場合、ビーコン チェーンでバリデーターをアクティブ化する新しい方法のロックを解除するなどの利点があります。

しかし、Danny Ryan (EIP-7002 の著者の 1 人) がコメントで説明しているように、汎用メッセージング EL → CL フレームワークに貴重なエンジニアリング時間を費やすことは、「価値提案が不明確な大規模な取り組み」です。たとえば、GMB (General Message Bus) 提案の著者は、EL と CL 間のメッセージ バスのユース ケースを他に 1 つだけ特定しました。それは、バリデーターの引き出し資格情報を0x0から0x01資格情報にローテーションすることです。

これは、コア開発者が一般的な EL から CL へのメッセージ バスの実装について話し合う前に、バリデーターの撤回要求コントラクトが最初に出荷される可能性が高いことを意味します (それが実現するかどうかはわかりません)。物事をシンプルに保つことは決して悪いことではありません。

シンプルさは信頼性の前提条件です。 — エドガー・W・ダイクストラ

既存のステーカーにとっての新たなリスクベクトル

引き出しの認証情報を有効にして引き出しをトリガーすることの利点については、大部分で詳しく説明しましたが、その機能に関連するエッジケースがいくつかあります。アイデアは次のようになります ( GitHub のこのコメントを参照)。

• バリデータの署名キーが侵害された場合、ハッカーは身代金を要求したり、バリデータの残高を減らそうとしたりすることができますが、いかなるシナリオでも資金を引き出すことはできません。攻撃者が残高全体を破壊するのか、バリデータが強制的に引き出された後にステーカーがステークの一部を引き出すことができるのか、待つゲームが続きます。
• ただし、EIP-7002 が実装されると、前のシナリオのハッカーは、荒らし/脅迫攻撃に落ち着くのではなく、バリデーターを終了して残高を引き出すことができます (EIP-7002 が実装されると)。

つまり、ソロ ステーカーとステーキング サービスは、EIP 7002 以降、引き出し認証情報の保護を強化する必要があります。このため、ソーシャル リカバリ、多要素 (MFA) 認証、およびキー ローテーションの採用は、ソロ/委任ステーキング操作のセキュリティを向上させるために重要と考えられています。

レート制限メカニズムの選択

バリデーターの引き出しリクエスト コントラクトadd_withdrawal_request()機能は、添付された引き出しリクエスト手数料のチェック以外に追加のチェックを実行しないため、攻撃者が無効な引き出しリクエストでメッセージ キューを詰まらせる可能性があります (例: 存在しないバリデーターまたは非アクティブなバリデーターの終了メッセージは、コンセンサス レイヤーの有効性チェック中に無効になります)。EIP-7002 は、動的に価格設定された引き出し手数料を使用して引き出しリクエストのレートを制限し、このような攻撃にコストがかかるようにします。これは、EIP-1559 がネットワーク アクティビティに基づいてガス価格を調整することでスパム攻撃やブロック スタッフィングを阻止するのと似ています。

代替設計としては、バリデーターの引き出し要求コントラクトへの呼び出しを実際のバリデーターに制限する方法があります。たとえば、 validator_pubkeyアクティブなビーコン チェーン バリデーターの公開キーに対応しているかどうかを確認します。これにより、複雑な EIP-1559 スタイルの価格設定メカニズムが不要になり、EIP-7002 の設計が簡素化され、偽の要求でキューをスパムすることが問題になることが少なくなるため、引き出し要求料金が削減される可能性があります。

ただし、これには、実行層がコンセンサス層の情報に信頼なくアクセスできること (つまり、 validator_pubkeyビーコン チェーンのバリデータ レジストリと照合できること) が必要です。この機能は、EIP-4788 の実装に依存します。これにより、EIP-7002 の複雑さが増し、2 つの EIP 間に新しい依存関係が導入されます。これは、 EIP-7002 の根拠のこのセクションで説明されているように、将来の設計改善に影響を与える可能性があります。

EIP-4788 が EIP-7002 と統合されたとしても、正当なバリデーターが関与する他の形式のスパム行為を防止するための追加のメカニズムが必要になります。たとえば、非常に短期間に同じバリデーターに対して複数の引き出しリクエストを送信することがこれに該当します。これにより、「3 ～ 4 か月ごとにバリデーターごとに 1 つの引き出しリクエストしか送信できない」などの新しいルールを追加 (および適用) する必要があり、バリデーターの引き出しリクエスト契約にさらに多くの変更が必要になる可能性があります。

対照的に、現在のレート制限メカニズムは簡単に理解でき、実行層の引き出しに関連するほとんどのセキュリティ問題に対して十分な保護を保証します。たとえば、引き出しリクエスト手数料は、グリーフィング（正当なバリデーターによる引き出しを阻止しようとする行為）やスパム攻撃、DOS 攻撃（コンセンサスノードに無効な引き出し操作のフィルタリングにリソースを浪費させることでビーコンチェーンを過負荷にしようとする行為）を阻止するために、自動的に上方調整できます。

結論: EIP-7002 とイーサリアムのステーキングの将来

委任ステーキングはここ数か月で大きな批判を受けていますが、サービスとしてのステーキング業界は今後も存続すると考えられます。もしそうであれば、流動的なステーキングプールにせよ、機関投資家の非管理型ステーキングサービスにせよ、ステーキングを委任する個人のリスクを軽減することが重要です。EIP-7002 は、0x01 引き出し認証情報を使用してバリデーターを終了し、ステーキングを引き出すことができるようにし、ステーカーがノードオペレーターの誠実さを信頼する必要を減らすことで、この目標を達成します。

EIP-7002 には、他にもプラスの波及効果があります。特に、バリデーター キーや DVT キーシェアの損失からの回復力を向上させることで、ソロ ステーキング操作と分散バリデーターの回復力とセキュリティを向上させることで、ソロ ステーキングの障壁が減り、Ethereum 上のステークの集中化が軽減されるはずです。

いつものように、この記事を役に立つと思われる人に共有することを検討していただき、さらに重要なこととして、Ethereum の研究開発に関するあらゆることをさらに深く掘り下げるために Ethereum 2077 を購読していただくようお願いして終わります。また、 Twitter で私とつながって、この記事に関するコメントやフィードバックを共有することもできます。