Vitalik: Ethereum PoS には他にどのような改善点があり、それを改善する方法は何ですか?

もともと、「The Merge」は、イーサリアム プロトコルのローンチ以来最も重要なイベント、つまり、長い間待ち望まれ、苦労して実現したプルーフ オブ ワークからプルーフ オブ ステークへの移行を指していました。現在、イーサリアムはほぼ 2 年間安定して稼働しており、この PoS は安定性、パフォーマンス、集中化リスクの回避の点で非常に優れたパフォーマンスを発揮しています。ただし、PoS にはまだ改善すべき重要な領域がいくつかあります。

私が作成した2023年のロードマップは、安定性、パフォーマンス、小規模バリデーターへのアクセス性などの技術的機能の改善と、集中化リスクに対処するための経済的な変更といういくつかの部分に分かれています。前者は「The Merge」の一部となり、後者は「the Scourge」の一部となった。

この投稿では、「マージ」に焦点を当てます。Proof of Stake (PoS) の技術設計をどのように改善できるか、また、これらの改善を実現する方法は何でしょうか。

これは PoS で実行できることの完全なリストではありません。むしろ、積極的に検討されているアイデアのリストです。

シングルスロットファイナリティ（SSF）とステーキングの民主化

私たちはどんな問題を解決しているのでしょうか?

現在、イーサリアムはブロックを確定するのに2〜3エポック（約15分）かかり、ステーカーになるには32 ETHが必要です。

これはもともと、次の 3 つの目標のバランスを取るための妥協案でした。

• ステーキングに参加するバリデーターの数を最大化する（つまり、ステーキングに必要なETHの最小量を最小化する）

• 最終処理時間を最小限に抑える

• ノード実行のオーバーヘッドを最小限に抑える

これら 3 つの目標は互いに矛盾しています。つまり、「経済的最終性」 (つまり、攻撃者が最終的なブロックを回復するために大量の ETH を破壊する必要がある) を達成するには、各バリデーターはブロックが最終的なブロックになるたびに 2 つのメッセージに署名する必要があります。したがって、バリデーターが多数ある場合、すべての署名を処理するのに長い時間がかかるか、すべての署名を同時に処理するために非常に強力なノードが必要になります。

これらすべては、攻撃が成功しても攻撃者にとってコストがかかるようにするという、Ethereum の重要な目標に依存していることに注意してください。これが「経済的最終性」という言葉の意味です。この目標がない場合は、各スロットを確定するために委員会（Algorand が行っているようなもの）をランダムに選択することで、この問題を回避できます。このアプローチの問題は、攻撃者がバリデーターの 51% をコントロールしている場合、非常に低コストで攻撃 (確定したブロックの取り消し、確定の検閲または遅延) を実行できることです。委員会内のノードの一部だけが攻撃に参加していることを検出され、スラッシングまたは少数派ソフトフォークのいずれかによって処罰されます。これは、攻撃者がチェーンを複数回繰り返し攻撃できることを意味します。したがって、経済的な最終性を求める場合、単純な委員会ベースのアプローチは機能せず、一見すると、バリデーターからの完全な集団参加が必要になります。

理想的には、次の 2 つの領域で現状を改善しながら、経済的な最終性を維持したいと考えています。

1. 15分ではなく、1つのスロットでブロックを完了します（理想的には、現在の12秒の長さを維持するか、さらに短縮します）。

2. バリデーターが1 ETH（当初は32 ETH）をステークできるようにする

最初の目標は 2 つの目的によって正当化されます。どちらも「イーサリアムの特性を (より集中化された) パフォーマンス重視の L1 チェーンの特性と一致させる」と見ることができます。

まず、すべての Ethereum ユーザーがファイナライズ メカニズムを通じて実現されるより高いレベルのセキュリティ保証の恩恵を受けることが保証されます。現在、ほとんどのユーザーは 15 分間待つことを望まないため、この保証を享受していません。シングルスロットのファイナライズメカニズムにより、ユーザーはトランザクションを確認した後、ほぼ即座にトランザクションがファイナライズされたことを確認できます。 2 番目に、ユーザーとアプリケーションがチェーン ロールバックの可能性を心配する必要がなくなると (比較的まれな非アクティブ リークを除く)、プロトコルとその周囲のインフラストラクチャが簡素化されます。

2 番目の目標は、ソロ ステーカーをサポートしたいという願望によって動機付けられています。世論調査では、より多くの人々がソロステーキングを行うことを妨げている主な要因は、32 ETH の最小値であることが繰り返し示されています。最小値を 1 ETH に下げると、この問題は解決しますが、ソロ ステーキングを制限する主な要因は他の問題になります。

課題があります。より迅速なファイナリティとより民主化されたステーキングの両方の目標が、オーバーヘッドを最小限に抑えるという目標と矛盾しているのです。実際、この事実こそが、そもそもシングルスロットファイナリティを採用しない理由なのです。しかし、最近の研究では、この問題に対するいくつかの解決策が示唆されています。

SSF とは何ですか? また、どのように機能しますか?

シングルスロットファイナリティでは、1 つのスロット内のブロックをファイナライズするコンセンサス アルゴリズムを使用します。これ自体は達成するのが難しい目標ではありません。多くのアルゴリズム (Tendermint コンセンサスなど) がすでに最適なプロパティでこれを実装しています。 Tendermint がサポートしていない、Ethereum 固有の望ましい特性の 1 つは、「非アクティブ リーク」です。これにより、バリデーターの 1/3 以上がオフラインになっても、チェーンは実行を継続し、最終的には回復することができます。幸いなことに、この要望は解決されています。非アクティブ リークに対応するために Tendermint スタイルのコンセンサスを変更する提案があります。

主要なシングルスロットファイナリティ提案

問題の最も難しい部分は、非常に高いノード オペレーターのオーバーヘッドを発生させずに、非常に高いバリデータ数でシングル スロットのファイナリティを機能させる方法を見つけることです。これにはいくつかの主要な解決策があります。

• オプション 1: ブルート フォース — おそらく ZK-SNARK を使用した、より優れた署名集約プロトコルに向けて取り組みます。これにより、基本的にスロットごとに数百万の検証者からの署名を処理できるようになります。

Horn は、より優れた集約プロトコルのために提案された設計の 1 つです。

• オプション 2: 軌道委員会 - ランダムに選択された中規模の委員会がチェーンの完了を担当できるようにする新しいメカニズムですが、私たちが求める攻撃コストの特性は維持されます。
  Orbit SSF について考える 1 つの方法は、x=0 (経済的最終性のない Algorand スタイルの委員会) から x=1 (Ethereum の現状) までの妥協案の空間を開き、Ethereum が依然として十分な経済的最終性を持ち極めて安全である中間点を開く一方で、各スロットに参加するために適度なサイズのバリデーターのランダム サンプルのみを必要とするという効率上の利点も得られるというものです。

Orbit は、バリデーターの預金サイズにおける既存の異質性を活用して、ソロバリデーターに意味のある役割を与えながら、可能な限りの経済的最終性を獲得します。さらに、Orbit は、隣接する定足数間の重複を高く保つために委員会のローテーションをゆっくりと行うことで、委員会のローテーションの境界を越えて経済的な最終性が確実に適用されるようにします。

• オプション 3: 2 層ステーキング - ステーカーを 2 つのカテゴリに分け、一方にはより高いデポジット要件があり、もう一方にはより低いデポジット要件があるメカニズム。より高い預金要件を持つ層のみが、経済的最終性の提供に直接参加します。預金要件が低い層にどのような権利と責任があるのか​​を明記するためのさまざまな提案があります (たとえば、Rainbow ステーキングの記事を参照)。一般的なアイデアは次のとおりです。

• 上位レベルの誓約者に誓約権を委任する

• 各ブロックを証明し確定するために、下位層のステーカーをランダムに選択します。

• 包含リストを生成する権利

既存の研究との関連は何ですか?

• シングルスロットファイナリティへの道（2022年）: https://notes.ethereum.org/@vbuterin/single_slot_finality

• Ethereum シングルスロットファイナリティプロトコルの具体的な提案 (2023): https://eprint.iacr.org/2023/280

• オービットSSF: https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928

• Orbit スタイルのメカニズムのさらなる分析: https://notes.ethereum.org/@anderselowsson/Vorbit_SSF

• Horn、署名集約プロトコル (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219

• 大規模コンセンサスのための署名統合（2023 年）: https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn

• Khovratovich らが提案した署名集約プロトコル: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/

• STARK (2022) に基づく署名集約: https://hackmd.io/@vbuterin/stark_aggregation

• レインボーステーキング: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683

他にやるべきことは何ですか?どのようなトレードオフが必要でしょうか?

選択できる主なパスは 4 つあります (ハイブリッド パスも選択できます)。

1.現状維持

2. オービットSSF

3. ブルートフォースSSF

4. 2段階の誓約メカニズムを備えたSSF

1 は何もせずに現状を維持することを意味しますが、これにより、Ethereum のセキュリティ エクスペリエンスとステーキングの集中化特性が、そうでない場合よりも悪化します。

2 「ハイテク」を避け、プロトコルの前提を巧みに再考することで問題を解決します。つまり、「経済的最終性」の要件を緩和して、攻撃にはコストがかかるように要求しますが、攻撃のコストは現在の 10 分の 1 に抑えることができます (例: 250 億ドルではなく 25 億ドル)。今日のイーサリアムは必要以上に経済的な最終性が高く、主なセキュリティリスクは別のところにあることは広く認められているため、これは許容できる犠牲であると言えるでしょう。

主な作業は、Orbit メカニズムが安全であり、必要なプロパティを備えていることを確認し、それを完全に形式化して実装することです。さらに、EIP-7251（最大有効残高の増加）により、任意のバリデータ残高を統合できるようになり、チェーン検証のオーバーヘッドが即座に削減され、Orbit の展開の効果的な初期段階として機能します。

3. 巧妙な再考を避け、代わりに高度な技術で解決策を強制します。これを実現するには、非常に短い時間（5〜10秒）内に大量の署名（100万以上）を収集する必要があります。

4 は、巧妙な再考とハイテクを回避しますが、依然として集中化のリスクがある 2 層のステーキング システムを作成します。リスクは、下位の質権層が取得する特定の権利に大きく依存します。例えば：

• 下位層のステーカーが認証権限を上位層のステーカーに委任する必要がある場合、委任が集中化され、最終的に 2 つのステーキング層が高度に集中することになります。

• 各ブロックを承認するために下位レイヤーのランダムサンプリングが必要な場合、攻撃者はわずかな量の ETH を費やすだけでファイナリティを阻止できます。

• 下位レベルのステーカーが包含リストしか作成できない場合、証明レイヤーは集中化されたままになる可能性があり、その時点で証明レイヤーに対する 51% 攻撃によって包含リスト自体を検閲できます。

複数の戦略を組み合わせることも可能です。例:

1 + 2: Orbit を追加しますが、単一スロットの最終性を強制しません。

1+3: ブルートフォース手法を使用して、単一スロットの確定なしに最低入金額を減らします。必要なポリマーの量は純粋な（3）の場合の64分の1なので、問題はより簡単になります。

2+3: 保守的なパラメータ (8k または 32k ではなく 128k バリデータ コミッティなど) を使用して Orbit SSF を実行し、ブルート フォース手法を使用して超効率的にします。

1+4: レインボーステーキングを追加しますが、シングルスロットの確定は行いません

SSF はロードマップの残りの部分とどのように相互作用しますか?

その他の利点の中でも、シングルスロットファイナリティにより、特定の種類のマルチブロック MEV 攻撃のリスクが軽減されます。さらに、シングルスロットファイナリティの世界では、証明者と提案者の分離設計とプロトコル内ブロック生成パイプラインの残りの部分を異なる方法で設計する必要があります。

ブルートフォース戦略の弱点は、スロット時間を短縮することがより困難になることです。

単一秘密リーダー選挙 (SSLE)

私たちはどんな問題を解決しているのでしょうか?

現在、どのバリデータが次のブロックを提案するかは事前にわかっています。これにより、セキュリティ上の脆弱性が生じます。攻撃者はネットワークを監視し、どのバリデータがどの IP アドレスに対応しているかを判断し、バリデータがブロックを提案しようとしているときに DoS 攻撃を開始できます。

SSLE とは何ですか? また、どのように機能しますか?

DoS 問題を解決する最善の方法は、少なくともブロックが実際に生成されるまでは、どのバリデータが次のブロックを生成するかに関する情報を隠すことです。 「単一」という要件を削除すれば、これは簡単であることに注意してください。1 つの解決策は、誰でも次のブロックを作成できるようにしながら、ランダオが 2256/N 未満を明らかにすることを要求するというものです。平均すると、この要件を満たすことができるバリデータは 1 つだけですが、2 つ以上ある場合もあれば、まったくない場合もあります。 「秘密」という要件と「単一」という要件を組み合わせることは、常に難しい問題でした。

シングルシークレットリーダー選挙プロトコルは、暗号化を使用して各バリデーターの「ブラインド」バリデーター ID を作成し、多くの提案者にブラインド ID のプールをシャッフルして再度ブラインドする機会を与えることで、この問題を解決します (これはミックスネットの動作に似ています)。各期間中、ランダムなブラインド ID が選択されます。ブロックを提案するための有効な証明を生成できるのはブラインド ID の所有者だけですが、ブラインド ID がどのバリデーターに対応しているかは誰にもわかりません。

ウィスクSSLEプロトコル

既存の研究との関連は何ですか?

• ダン・ボネの論文（2020年）：https://eprint.iacr.org/2020/025.pdf

• Whisk (Ethereum 固有の提案、2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763

• ethresear.ch のシングルシークレットリーダー選挙タグ: https://ethresear.ch/tag/single-secret-leader-election

• リング署名を使用した簡略化された SSLE: https://ethresear.ch/t/simplified-ssle/12315

他にやるべきことは何ですか?どのようなトレードオフが必要ですか?

本当に残っているのは、メインネットに簡単に実装できるほどシンプルなプロトコルを見つけて実装することだけです。私たちは、Ethereum がかなりシンプルなプロトコルであることを真剣に受け止めており、複雑さがさらに増すことを望んでいません。私たちが目にした SSLE 実装では、仕様に数百行のコードが追加され、複雑な暗号化に新たな前提が導入されています。十分に効率的な量子耐性のある SSLE 実装を見つけることも未解決の問題です。

最終的には、他の理由（状態トライ、ZK-EVM など）で、L1 の Ethereum プロトコルに一般的なゼロ知識証明を実行するメカニズムを導入する思い切った場合にのみ、SSLE の「限界的な追加複雑性」が十分に低下するようになるかもしれません。

もう 1 つの選択肢は、SSLE をまったく使用せず、代わりにプロトコル外の緩和策 (例: p2p レイヤー) を使用して DoS 問題に対処することです。

ロードマップの残りの部分とどのように相互作用しますか?

実行チケットなどの証明者-提案者分離 (APS) メカニズムを追加すると、専用のブロック ビルダーに依存できるため、実行ブロック (つまり、Ethereum トランザクションを含むブロック) では SSLE が不要になります。ただし、コンセンサス ブロック (つまり、アテステーションなどのプロトコル メッセージやリストを含む可能性のある部分などを含むブロック) の場合、SSLE のメリットは依然として得られます。

より迅速な取引確認

私たちはどんな問題を解決しているのでしょうか?

イーサリアムのトランザクション確認時間を 12 秒から 4 秒にさらに短縮することは価値があります。そうすることで、L1 およびロールアップベースのプロトコルのユーザー エクスペリエンスが大幅に向上し、DeFi プロトコルの効率が向上します。また、多数の L2 アプリケーションがロールアップで動作できるようになるため、L2 の分散化が容易になり、L2 が独自の委員会ベースの分散型順序付けを構築する必要性が減ります。

より高速なトランザクション確認とは何ですか? また、どのように機能しますか?

ここでは、大まかに 2 つの手法があります。

1. スロット時間を、たとえば 8 秒または 4 秒に短縮します。これは必ずしも 4 秒で完了することを意味するわけではありません。完了自体には 3 ラウンドの通信が必要なので、各ラウンドを別々のブロックにして、少なくとも 4 秒後に暫定的な確認を得ることができます。

2. 提案者がスロット期間中に事前確認を発行できるようにします。極端なケースでは、提案者は、確認したトランザクションをブロックにリアルタイムで含め、各トランザクションの事前確認メッセージを即座に公開することができます (「最初のトランザクションは 0x1234 です...」、「2 番目のトランザクションは 0x5678 です...」)。提案者が 2 つの矛盾する確認を公開する状況は、(i) 提案者を罰する、または (ii) 証人を使用してどちらが早いかを投票する、という 2 つの方法で対処できます。

既存の研究との関連は何ですか?

• 事前確認に基づく: https://ethresear.ch/t/based-preconfirmations/17353

• プロトコル強制提案者コミットメント (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879

• パラチェーンのスタッガー期間（低レイテンシーのための 2018 年のアイデア）: https://ethresear.ch/t/staggered-periods/1793

他にやるべきことは何ですか?どのようなトレードオフが必要ですか?

スロット時間を短縮することが可能かどうかはまだ明らかではありません。今日でも、世界の多くの地域のステーカーにとって、十分な速さで証明を得ることは困難です。 4 秒のスロット時間を試すと、バリデーターが集中化されるリスクがあり、レイテンシーのために、いくつかの特権地域以外でバリデーターになることが非現実的になります。

プロポーザ事前確認アプローチの弱点は、平均的なケースの包含時間が大幅に改善されるものの、最悪のケースでは改善されないことです。現在のプロポーザのパフォーマンスが良好であれば、トランザクションは (平均して) 6 秒で包含されるのではなく、0.5 秒で事前確認されますが、現在のプロポーザがオフラインであるかパフォーマンスが悪い場合は、次のスロットが開始されて新しいプロポーザが提供されるまで、依然として 12 秒も待たなければなりません。

さらに、事前確認をどのように奨励するかという未解決の問題があります。提案者には、できるだけ長く当選の可能性を最大化しようとする動機がある。証人が事前確認の適時性に同意すれば、取引の送信者は手数料の一部を即時の事前確認を条件とすることができるが、これにより証人にさらなる負担がかかり、証人が中立的な「ダムパイプ」として機能し続けることがより困難になる可能性がある。

一方、これを行わず、ファイナリティ時間を 12 秒 (またはそれ以上) に維持すると、エコシステムはレイヤー 2 の事前確認メカニズムに重点を置くようになり、レイヤー 2 を介したやり取りに時間がかかります。

ロードマップの残りの部分とどのように相互作用しますか?

提案者ベースの事前確認は、実際には実行チケットなどの認証者と提案者の分離 (APS) メカニズムに依存しています。そうしないと、リアルタイムの事前確認を提供するプレッシャーが通常のバリデーターに集中しすぎる可能性があります。

その他の研究分野

攻撃回復率51%

51% 攻撃 (検閲など暗号的に証明できない攻撃を含む) が発生した場合、コミュニティが協力して少数派ソフトフォークを実装し、善人が勝利し、悪人が非アクティブ リークまたは削減されることが保証されるとよく​​考えられています。しかし、ソーシャル層へのこのレベルの過度の依存は、おそらく不健全です。回復プロセスを可能な限り自動化することで、ソーシャル レイヤーへの依存を減らすことができます。

完全な自動化は不可能です。なぜなら、それは 50% を超えるフォールト トレランスを備えたコンセンサス アルゴリズムと同等であり、そのようなアルゴリズムの (非常に厳密な) 数学的に証明可能な制限がすでにわかっているからです。しかし、このうちのいくつかは自動化できます。たとえば、クライアントが長期間にわたって確認してきたトランザクションを検閲する場合、チェーンを最終的なものとして、あるいはフォーク選択の先頭として受け入れることを自動的に拒否できます。重要な目標は、攻撃者が少なくとも迅速かつ完全な勝利を達成できないようにすることです。

クォーラムの基準を引き上げる

現在、ステーカーの 67% がそれをサポートする限り (翻訳者注: クォーラム メカニズムは、データの冗長性と最終的な一貫性を確保するために分散システムで一般的に使用される投票アルゴリズムです)、ブロックは確定されます。このアプローチは過激すぎると考える人もいます。イーサリアムの全歴史において、ファイナリティの失敗はたった 1 回（非常に短時間）しかありません。この比率が 80% に引き上げられた場合、追加の非ファイナリティ期間の数は比較的少なくなりますが、イーサリアムのセキュリティが向上します。特に、より論争の多い状況の多くでは、ファイナリティが一時的に停止することになります。これは、攻撃者かクライアントのどちらに責任があっても、「間違った側」がすぐに勝利する状況よりもはるかに健全な状況であるように思われます。

これは、「ソロステーカーになる意味は何ですか？」という質問にも答えます。現在、ほとんどのステーカーがすでにステーキングプールを通じてステーキングを行っているため、1人のステーカーがETHの51%に到達する可能性は低いと思われます。ただし、特に定足数が 80% の場合 (つまり、定足数をブロックする少数派には 21% しか必要ない場合)、一生懸命努力すれば、単一のステーカーが定足数をブロックする少数派に到達することは可能と思われます。個々のステーカーが 51% 攻撃 (ファイナリティ反転または検閲のいずれかを通じて) に参加しない限り、この攻撃で「完全な勝利」は得られず、個々のステーカーには少数派のソフトフォークを防ぐのに協力するインセンティブがあります。

量子抵抗

Metaculus 社は現在、誤差は大きいものの、量子コンピューターが 2030 年代に暗号を解読し始める可能性があると考えています。

スコット・アーロンソン氏などの量子コンピューティングの専門家も最近、量子コンピューターが中期的に実際に機能する可能性について真剣に考え始めている。これは、イーサリアムのロードマップ全体に影響を及ぼすことになります。つまり、現在楕円曲線に依存しているイーサリアム プロトコルのすべての部分に、何らかのハッシュベースまたはその他の量子耐性のある代替手段が必要になるということです。具体的には、大規模な検証セットからの署名を処理するために、BLS 集約の優れたパフォーマンスに常に依存できるとは想定できないことを意味します。これは、プルーフ・オブ・ステーク設計のパフォーマンス仮定における保守性を正当化し、量子耐性のある代替手段をより積極的に開発する理由となります。