Vitalik の最新研究: イーサリアムにおける多数の二重誓約によって引き起こされるリスクをどのように解決するか?

翻訳标题:《分散化を改善し、コンセンサスのオーバーヘッドを削減できるプロトコルとステーキングプールの変更》

著者: ヴィタリック・ブテリン

コンパイル: Bayemon.eth、ChainCatcher

*フィードバックとレビューをくださった Mike Neuder 氏、Justin Drake 氏、その他の方々に心より感謝いたします。同様のトピックに関する Mike Neuder、Dankrad Feist、arixon.eth の以前の投稿も参照してください。 *

現在のイーサリアムの開発状況は二層ステーキング(2層ステーキング)が多いと言えますが、ここで言う二層ステーキングとは2種類の参加者によるステーキングモデルを指します。

  1. ノード運営者: ノードを運営し、自身の評判や一定量の自己資本を担保として使用します。
  2. エージェント委任者: エージェントは一定量のイーサリアムを誓約します。最低金額はなく、担保以外の他の参加方法に追加の制限はありません。

この新たなダブルステーキングは、ステーキング トークン (LST) に流動性を提供するステーキング プールへの大量の参加によって生成されます。 (Rocket Pool と Lido は両方ともこのモードです)。

しかし、現在の二重誓約には次の 2 つの欠陥があります。

  1. ノードオペレーターの集中化リスク: すべてのステーキングプールにおけるノードオペレーターの現在の選択メカニズムは依然として過度に集中化されています。
  2. 不必要なコンセンサス負担: イーサリアム L1 の各エポックでは約 800,000 の署名を検証する必要があり、これは単一スロットにとっては大きな負荷となります。さらに、流動性ステーキングプールにはより多くの資金が必要となるため、ネットワーク自体はこの負荷から十分な恩恵を受けられません。したがって、イーサリアムネットワークが各ステーカーに期間に応じた署名を要求せずに合理的な分散化とセキュリティを実現できれば、コミュニティはそのようなソリューションを採用でき、期間ごとの署名数を効果的に削減できます。

この記事では、上記 2 つの問題の解決策について説明します。** まず、現在の形式でステーキング ノードを個人的に管理したくない人々が資本の大部分を保有し、各スロットの情報に署名し、デポジットをロックし、資金が削減されると再配分する それでは、この場合、ネットワークの分散化とセキュリティに有意義な貢献を続けるために、これらの人々はどのような役割を果たせるのでしょうか? **

**二重担保は現在どのように機能しますか? **

現在、最も人気のある 2 つのステーキング プールは、Lido と RocketPool です。Lido に関する限り、参加している 2 つの当事者は次のとおりです。

  1. ノード オペレーター: Lido DAO によって投票されました。これは、実際に LDO 保有者によって選出されたことを意味します。誰かが ETH を Lido スマート コントラクト システムに入金すると、stETH が作成され、ノード オペレーターはそれを誓約に入れることができますプール(ただし、出金証明書はスマートコントラクトアドレスにバインドされているため、オペレーターは自由にお金を引き出すことができません)
  2. エージェント: 誰かが ETH を Lido スマート コントラクト システムに入金すると、stETH が生成され、ノード オペレーターはそれを質権として使用できます (ただし、出金バウチャーはスマート コントラクト アドレスにバインドされているため、オペレーターは自由にお金を引き出すことはできません)

Rocket プールの場合は次のとおりです。

  1. ノード オペレーター: 8 ETH と一定数の RPL トークンを提出することで、誰でもノード オペレーターになることができます。
  2. エージェント: 誰かが Rocket Pool スマート コントラクト システムに ETH を入金すると、rETH が生成され、ノード オペレーターはそれを質権として使用できます (出金伝票はスマート コントラクト アドレスにバインドされているため、オペレーターは自由に撤退することはできません)。

エージェントの役割

これらのシステム (または、将来のプロトコル変更の可能性によって可能になる新しいシステム) では、次のような重要な疑問が生じます。 ** プロトコルの観点から見ると、エージェントを配置する意味は何ですか? **

この問題の深刻な重要性を理解するために、まず投稿で言及したプロトコルの変更について考えます。これによりペナルティは 2ETH に制限され、Rocket Pool はノードオペレーターのステーク量も 2ETH に削減され、Rocket Pool の市場シェアも減少します。 100% に増加します/(ステーカーと ETH 保有者の場合、rETH がリスクフリーになると、ほぼすべての ETH 保有者が rETH 保有者またはノード オペレーターになります)。

rETH 保有者には 3% のリターン (プロトコル内報酬および優先手数料 + MEV を含む)、ノードオペレーターには 4% のリターンを想定します。また、ETHの総供給量は1億であると仮定します。

計算結果は以下の通り。複利計算を避けるために、日次ベースで収益を計算します。

Vitalik の最新研究: イーサリアムにおける多数の二重誓約によって引き起こされるリスクをどのように解決するか?

ここで、Rocket Pool が存在しないと仮定すると、ステーカーあたりの最低入金額は 2 ETH に低下し、総流動性の上限は 625 万 ETH に制限され、ノード オペレーターの収益率は 1% に低下します。もう一度計算してみましょう:

Vitalik の最新研究: イーサリアムにおける多数の二重誓約によって引き起こされるリスクをどのように解決するか?

攻撃コストの観点から両方のシナリオを検討してください。前者の場合、エージェントには基本的にお金を引き出す権利がないため、攻撃者はエージェントとして登録しません。したがって、意味がありません。したがって、彼らはすべてのETHを誓約し、ノードオペレーターになります。ステーク総額の 1/3 に達するには、208 万イーサリアムをステーキングする必要があります (公平を期すために、これでもかなり大きな数です)。2 番目のケースでは、攻撃者は、資金をステークするだけで、ステーキングプール 総額の 1/3 についても、208 万イーサリアムを投資する必要があります。

**ステーキングの経済性と攻撃コストの観点から見ると、両方のケースの最終結果はまったく同じです。 **ノードオペレーターが保有する総ETH供給量に占めるシェアは毎日0.00256%増加し、非ノードオペレーターが保有する総ETH供給量に占めるシェアは毎日0.00017%減少します。攻撃コストは208万ETH。 ** したがって、このモデルでは、エージェントは意味のないルーブ・ゴールドバーグ・マシンになっているように見え、合理的なコミュニティは仲介者を排除し、ステーキング報酬を大幅に削減し、ステーキングされたETHの総量を個人625万に制限する傾向さえあります。 **

もちろん、この記事はステーキング報酬を 4 倍に減らし、ステーキング総額を 625 万に制限することを主張するものではありません。それどころか、この記事の要点は、適切に機能するステーキング システムの重要な特性は、エージェントがシステム全体で重要な責任を負う必要があるということです**。さらに、エージェントが適切な行動をとるよう主にコミュニティの圧力や利他主義によって動機づけられていたとしても問題ではありません; 結局のところ、それが今日の主要な力となっている分散型の高セキュリティのステーキング ソリューションを動機づけているものなのです。

エージェントの責任

エージェントがステーキング システムで重要な役割を果たすことができるとしたら、その役割は何でしょうか?

答えには 2 つのカテゴリがあると思います。

  • **エージェントの選択: **エージェントは、自分のステークをどのノードオペレーターに委託するかを選択できます。コンセンサスメカニズムにおけるノードオペレータの「重み」は、ノードオペレータに託された賭け金の合計に比例します。現在、エージェント選択メカニズムはまだ制限されています。つまり、rETH または stETH 保有者は ETH を引き出して別のプールに切り替えることができますが、エージェント選択の実際の可用性は大幅に改善される可能性があります。
  • コンセンサスメカニズムへの参加: 委任者は、コンセンサスメカニズムにおいて特定の役割を果たすことを選択できます。責任は完全なサブスクリプションよりも「軽く」、長い離脱期間やリスク軽減はありませんが、依然として役割を果たすことができます。 a role ノードオペレーターの役割をチェックし、バランスをとります。

エージェントの選択を強化

代表者の選択力を高めるには 3 つの方法があります。

  1. プール内の投票ツールの改善
  2. プール間の競争を激化させる
  3. 代表権の修正

現在、プール内での投票は実際には現実的ではありません。Rocket Pool では誰でもノード オペレーターになれますが、Lido では投票は ETH 保有者ではなく LDO 保有者によって決定されます。 Lido は、LDO + stETH の二重ガバナンスに関する提案を提出しました。これらは、新しい投票を防止する保護メカニズムをアクティブにし、ノード オペレーターの追加または削除を防ぐことができます。これにより、何らかの形で stETH 保有者に発言権が与えられます。ただし、この力には限界があり、さらに強力になる可能性があります。

現在、プール間の競争はすでに存在していますが、比較的弱いものです。主な課題は、小規模なステーキング プールのステーキング トークンは流動性が低く、信頼を得るのが難しく、アプリケーションによるサポートが少ないことです。

**最初の 2 つの問題は、ペナルティの額を 2 または 4 ETH などのより小さい額に制限することで改善できます。 **残りの ETH は安全に入金および即座に引き出すことができるため、小規模なステーキング プールに対しても双方向の償還が引き続き適用されます。 3 番目の問題は、LST を管理するための総発行契約 (ERC-4337 や ERC-6900 がウォレットに使用する契約と同様) を作成することで改善でき、この契約を通じて発行されたステークされたトークンがすべて安全であることを保証できます。

現在、協定には確固たる代表権はないが、将来的にはそのような状況が存在する可能性が高いと思われる。これには上記のアイデアと同様のロジックが含まれますが、プロトコル レベルで実装されます。物を固めることの長所と短所については、この記事を参照してください。

これらのアイデアは現状を改善するものですが、提供される利点は限られています**。トークン投票のガバナンスには問題があり、最終的にはいかなるインセンティブのない代理人選択もトークン投票の一形態にすぎません; これが、Delegated Proof of Stake に対する私の主な不満でした。 **したがって、より強力なコンセンサスへの参加を達成する方法を検討することにも価値があります。

コンセンサスへの参加

流動性ステーキングに関する現在の問題を脇に置いても、現在の独立したステーキング方法には限界があります。単一スロットのファイナリティが使用されると仮定すると、各スロットは理想的には約 100,000 ~ 1,000,000 個の BLS 署名を処理できます。再帰的 SNARK を使用して署名を集約する場合でも、トレーサビリティのために各署名に参加者のビット フィールドを割り当てる必要があります。 **イーサリアムが世界規模のネットワークになった場合、完全に分散化されたストレージ ビット フィールドでは十分ではなくなります。各スロットの 16 MB では、約 6,400 万のステーカーしかサポートできません。

この観点から、ステーキングをより複雑性の高い削減可能な層と、より複雑性の低い層に分割することには価値があります。各スロットはアクティブになりますが、参加者は 10,000 人のみであり、より複雑性の低い層は、参加するために呼び出されることが時々しかありません。複雑さの低いレイヤーは削減から完全に免除されることも、参加者にランダムにいくつかのスロット内にデポジットする機会が与えられ、削減の対象となることもできます。

実際には、これは、バリデーターの残高上限を増やし、その後残高しきい値 (例: 2048 ETH) を増やして、既存のどのバリデーターがより高いまたはより低い複雑さの層に移動するかを決定することによって達成できます。

これらの小規模なステーキングの役割がどのように機能するかについて、いくつかの提案を示します。

  1. スロットごとに 10,000 人の小規模ステーカーがランダムに選ばれ、スロットを代表すると思われる内容に署名できます。小さなステーカーを入力として使用して、LMD GHOST フォーク選択ルールを実行します。小規模ステーカーによるフォーク選択とノードオペレーターによるフォーク選択の間に不一致がある場合、ユーザーのクライアントは最終確認としてブロックを受け入れず、エラーを表示します。このため、コミュニティは状況を解決するために介入する必要があります。
  2. エージェントは、オンラインであり、今後 1 時間小規模なステーカーとして機能する意思があることをネットワークに通知するトランザクションを送信できます。ノードによって送信されるメッセージ (ブロックまたはプルーフ) の計算では、ノードとランダムに選択されたエージェントの両方がノードの確認情報に署名する必要があります**。
  3. エージェントは、オンラインであり、今後 1 時間小規模なステーカーとして機能する意思があることをネットワークに通知するトランザクションを送信できます。各エポックでは、10 人のランダムなエージェントが包含リストの提供者として選択され、さらに 10,000 人のエージェントが投票者として選択されます。これらは k スロットの前に選択され、オンラインの存在を確認するメッセージをオンチェーンで公開するための k スロット ウィンドウが与えられます。確認済みの選択された各包含リストプロバイダーは、各包含リストについて、その包含リストに含まれる取引または一般の 1 人の選択された有権者の投票のいずれかによって包含リストが利用できないことが示されない限り、包含リストを公開できます。そうでない場合、ブロックは無効とみなされます。 。

これらの小規模なステーキング ノードに共通しているのは、各スロットに積極的に参加する必要がなく、すべての作業を完了するのにライト ノードさえあれば十分であるということです。したがって、ノードのデプロイメントにはコンセンサス層の検証のみが必要であり、ノードオペレータはアプリケーションまたはブラウザプラグインを通じてこれを実現できますが、これらはほとんど受動的であり、計算オーバーヘッド、ハードウェア要件、または技術的ノウハウを課すことはありません。 ZK-EVMのような高度なテクノロジーが必要です。

これらの「小規模な攻撃者」には、ノード オペレーターの 51% 多数によるトランザクション レビューを阻止するという共通の目標もあります。 **1 番目と 2 番目のタイプでは、大多数の人が最終修復に参加できなくなる可能性があります。 3 つ目は検閲に直接関係しますが、多数派ノードのオペレーターの選択の影響を受けやすくなります。

Vitalik の最新研究: イーサリアムにおける多数の二重誓約によって引き起こされるリスクをどのように解決するか?

これらのアイデアは、プロトコルに実装されたダブルステーキング ソリューションの観点から書かれていますが、ステーキング プールの機能として実装することもできます。具体的な実装アイデアをいくつか示します。

  1. プロトコルの観点から、各検証者は 2 つのプレッジ キーを設定できます。連続プレッジ キー P と、呼び出し可能なバインドされたイーサリアム アドレスで、クイックプレッジ キー Q を出力します。フォーク選択のためのノードの署名情報追跡は P で表され、署名された情報は Q で表されます。PQ ストレージの結果が矛盾している場合、どのブロックのファイナライズも受け入れられず、流動性プールがランダムに選択する責任を負います。代表者。
  2. プロトコルはほとんど変更されませんが、この期間のバリデーターの公開鍵は P+Q に設定されます。リダクションの場合、2 つのリダクション可能なメッセージは異なる Q キーを持つ可能性がありますが、同じ P キーを持つことになることに注意してください。リダクション設計はこのケースを処理する必要があります。
  3. Q キーは、ブロック内の包含リストに署名し検証するためにプロトコル内でのみ使用できます。この場合、Q は単一のキーではなくスマート コントラクトになる可能性があるため、ステーキング プールはそれを使用してより複雑な投票ロジックを実装し、ランダムに選択されたプロバイダーからの包括的なリストを受け入れるか、含まれるリストが投票に使用できないことを示します。 。

### 結論は

正しく実装されていれば、プルーフ・オブ・ステークの設計を微調整することで、次の 2 つの問題を一気に解決できます。

  1. 現在、独立したプルーフ・オブ・ステークを実施するリソースや能力を持たない人々に、プルーフ・オブ・ステークに参加する機会を提供することで、より多くの権限を手中に保持します。これには、(i) どのノードをサポートするかを選択する権限が含まれます * *および (ii) プルーフ・オブ・ステーク・ノードを完全に運用するよりも軽いけれども意味のある何らかの方法でコンセンサスに積極的に参加します。すべての参加者がこれらのオプションの一方または両方を選択するわけではありませんが、これらのオプションの一方または両方を選択した参加者は現状からの大幅な改善を経験します。
  2. イーサリアム コンセンサス レイヤーが各スロットで処理する必要がある署名の数を削減します。たとえ単一スロットのファイナリティ方式であっても、約 10,000 などのより少ない数に減ります。これは分散化にも役立ち、誰もが検証ノードを簡単に実行できるようになります。

これらのソリューションでは、問題の解決策は、プルーフ・オブ・ステーク・プロトコル内でユーザーに付与される権限、プルーフ・オブ・ステーク・プロトコル間でのユーザーの選択、プロトコル内での確立など、さまざまな抽象化レベルで見つけることができます。この選択は慎重に検討する必要があり、望ましい目標を達成しながら、プロトコルの複雑さとプロトコルの経済性への変更の範囲を最小限に抑えるために、実行可能な最小限のセットアップを選択する方が良いことがよくあります。

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)