Bitget App
スマートな取引を実現
暗号資産を購入市場取引先物コピートレード自動売買Bitget Earn
Vitalik の新しい記事: イーサリアムの将来の可能性、マージ

Vitalik の新しい記事: イーサリアムの将来の可能性、マージ

cointime-jp-news2024/10/16 06:33
著者:cointime-jp-news

作者: ヴィタリック ブテリン

編集者: Alex Liu、Foresight News

フィードバックとレビューを提供してくれた Justin Drake、Hsiao-wei Wang、@antonttc、Anders Elowsson、Francesco に感謝します。

当初、「マージ」とは、イーサリアムプロトコルの立ち上げ以来の歴史の中で最も重要な出来事、つまり、長く待ち望まれ、苦労して勝ち取ったプルーフ・オブ・ワーク(PoW)からプルーフ・オブ・ステーク(PoS)への移行を指していました。現在、イーサリアムはほぼ丸 2 年間、安定して機能するプルーフ オブ ステーク システムとして機能しており、このプルーフ オブ ステーク システムは、 安定性 、パフォーマンス、 集中化リスクの回避 の点で非常に優れたパフォーマンスを発揮しています。ただし、プルーフ・オブ・ステークには改善が必要な重要な領域がまだいくつかあります。

私の 2023 年のロードマップは、安定性、パフォーマンス、小規模バリデーターのアクセシビリティなどの技術的機能の改善と、集中化のリスクに対処する経済的変化といういくつかの部分に分かれています。前者は「ザ・マージ」の称号を引き継ぎ、後者は「ザ・スカージ」の一部となった。

この記事では「マージ」の部分に焦点を当てます。プルーフ・オブ・ステークの技術設計を他にどこで改善できるか、そしてこの目標を達成する方法は何でしょうか?

これはプルーフ・オブ・ステークでできることの完全なリストではなく、現在積極的に検討されているアイデアのリストです。

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

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

現在、ブロックを完了するには 2 ~ 3 エポック (約 15 分) かかり、ステーカーになるには 32 ETH が必要です。これはもともと、次の 3 つの目標のバランスを取る ための妥協案でした。

  • ステーキングに参加できるバリデーターの数を最大化します (これは直接、ステーキングに必要な最小 ETH を最小限に抑えることを意味します)
  • 完成までの時間を最小限に抑える
  • ノード実行のオーバーヘッドを最小限に抑えます。この場合、他のすべてのバリデーター署名のダウンロード、検証、再ブロードキャストにかかるコストが最小限になります。

これら 3 つの目標は互いに矛盾しています。経済的なファイナリティを可能にする (つまり、攻撃者はファイナライズされたブロックを取り消すために大量の ETH を消費する必要がある) ため、ファイナライゼーションが発生するたびにすべてのバリデータが必要です。両方のメッセージに署名します。したがって、バリデーターが多数ある場合は、すべての署名を処理するのに長い時間がかかるか、すべての署名を同時に処理する非常に強力なノードが必要になります。

これら 3 つの目標は互いに矛盾しています。経済的なファイナリティを可能にする (つまり、攻撃者はファイナライズされたブロックを取り消すために大量の ETH を消費する必要がある) ために、ファイナライゼーションが発生するたびにすべてのバリデータが必要です。両方のメッセージに署名します。したがって、バリデーターが多数ある場合は、すべての署名を処理するのに長い時間がかかるか、すべての署名を同時に処理する非常に強力なノードが必要になります。

これら 3 つの目標は互いに矛盾しています。経済的なファイナリティを可能にする (つまり、攻撃者はファイナライズされたブロックを改ざんするために大量の ETH を消費する必要がある) ため、ファイナライゼーションが発生するたびにすべてのバリデータが必要です。両方のメッセージに署名します。したがって、バリデーターが多数ある場合は、すべての署名を処理するのに長い時間がかかるか、すべての署名を同時に処理する非常に強力なノードが必要になります。

これはすべて、攻撃が成功しても攻撃者に高いコストを課すことを保証するというイーサリアムの重要な目標が条件であることに注意してください。これが「経済的終局性」という言葉の意味するところです。この目標がない場合は、各ブロックを最終決定する委員会をランダムに選択することでこの問題を解決できます。アルゴランドなど、経済的な最終性を達成しようとしないチェーンは、 多くの場合、まさにそれを行います 。しかし、このアプローチの問題は、攻撃者がバリデーターの 51% を制御している場合、非常に低コストで攻撃 (ファイナライズされたブロックの回復、検閲、またはファイナライゼーションの遅延) を実行できることです。つまり、 のいくつかのノードを制御するだけです。委員会内では、攻撃に参加したことが検出され、 スラッシュ または 社会的に調整されたソフトフォーク によって罰せられる場合があります。これは、攻撃者がチェーンを複数回繰り返し攻撃することができ、各攻撃で失うのは賭け金のごく一部だけであることを意味します。したがって、経済的な最終性を求める場合、単純な委員会ベースのアプローチは機能せず、一見したところ、バリデーターの完全な参加が必要です。

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

  1. ブロックを 15 分ではなく 1 つのスロットで完了します (理想的には、現在の 12 秒の長さを維持するか、短縮することさえできます)。
  2. バリデーターによる 1 ETH でのステークを許可 (32 ETH から減少)

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

まず、すべてのイーサリアム ユーザーが、ファイナリティ メカニズムを通じて達成されるより高いレベルのセキュリティ保証の恩恵を実際に受けられるようにします。現在、ほとんどのユーザーは、単一スロットのファイナライズで 15 分も待つことを望まないため、これを実行しません。ユーザーは、トランザクションが確認されるとほぼすぐにトランザクションが完了したことがわかります。第 2 に、ユーザーとアプリケーションがチェーン反転の可能性を心配する必要がなければ、プロトコルと周囲のインフラストラクチャが簡素化されます ( 非アクティブ リーク という比較的まれなケースを除く)。

2点目はソロステーカーを応援したいという思いから。世論調査に次ぐ世論調査では、より多くの人が単独でステーキングすることを妨げる主な要因は最低 32 ETH であることが繰り返し示されています。最小値を 1 ETH に減らすことでこの問題は解決され、他の問題が個人のステーキングを制限する主要な要因になります。

2点目はソロステーカーを応援したいという思いから。世論調査に次ぐ世論調査では、より多くの人が単独でステーキングすることを妨げる主な要因は最低 32 ETH であることが繰り返し示されています。最小値を 1 ETH に減らすことでこの問題は解決され、他の問題が個人のステーキングを制限する主要な要因になります。

課題があります。ファイナライゼーションの高速化とステーキングのより民主化という目標は、どちらもオーバーヘッドを最小限に抑えるという目標と矛盾します。実際、この事実が、単一スロットのファイナリティから始めない理由のすべてです。ただし、最近の研究では、この問題に対処する可能性のあるいくつかの方法が示唆されています。

それは何ですか?またどのように機能しますか?

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

主要な単一スロットの最終提案

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

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

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

オプション 2: オービット委員会 — ランダムに選択された中規模の委員会がチェーンの最終決定を担当できるようにする新しいメカニズムですが、求めている攻撃コストの特性を維持する方法で行われます。

Orbit SSF について考える 1 つの方法は、x=0 (アルゴランドスタイルの委員会、経済的最終性なし) から x=1 (イーサリアムの現状) までの 2 つの選択肢の間に妥協の余地を開き、その中間に何かがあるということです。 「イーサリアムには依然として十分な経済的ファイナリティがあり、非常に安全ですが、同時に、効率の利点を得るために各スロットに参加するバリデーターの適度なサイズのランダムなサンプルのみが必要です。」

Orbit は、バリデーターのデポジットサイズにおける既存の不均一性を活用して、小規模なバリデーターに役割を与えながら、可能な限り経済的なファイナリティを獲得します。さらに、Orbit は、隣接する定足数間の高度な重複を確保するためにゆっくりとした委員会のローテーションを使用し、それによって経済的な最終性が委員会の切り替えの範囲内に留まるようにします。

  • オプション 3: 2 レベルのステーキング - 2 種類の質権者が存在するメカニズム。1 つはより高い証拠金要件を備え、もう 1 つはより低い証拠金要件を備えています。経済的なファイナリティの提供に直接関与するのは、より高い預金枠のみです。低位の預金層の権利と責任が正確にどのようなものであるかについては、さまざまな提案があります (たとえば、 レインボーステーキング ポストを参照)。一般的なアイデアには次のようなものがあります。
  • ステーキングをより高いレベルのステーカーに委任する権利
  • 各ブロックを認証して最終決定するには、ランダムな低レベルのステーカーが必要です
  • 包含リスト を作成する権利

既存の研究とのつながりは何ですか?

  • シングルスロットファイナリティへの道 (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality シングルスロットファイナリティへの道 (2022)
  • イーサリアムのシングル スロット ファイナリティ プロトコルの具体的な提案 (2023): https://eprint.iacr.org/2023/280 イーサリアムのシングル スロット ファイナリティ
  • Orbit SSF: https://ethresear.ch/t/orbit-ssf-solo-saking-friends-validator-set-management-for-ssf/19928
  • Orbit スタイルのメカニズムに関するさらなる分析: https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464 Orbit スタイルのメカニズムに関するさらなる分析
  • Horn、署名集約プロトコル (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219 Horn、署名集約プロトコル (2022)
  • 大規模コンセンサスのための署名のマージ (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn 大規模コンセンサスのための署名のマージ (2023)
  • Khovratovich らによって提案された署名集約プロトコル: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/ Khovratovich らによって提案された署名集約プロトコル
  • STARK ベースの署名集約 (2022): https://hackmd.io/@vbuterin/stark_aggregation STARK ベースの署名集約 (2022)
  • レインボーステーキング: https://ethresear.ch/t/unbundling-saking-towards-rainbow-saking/18683 レインボーステーキング

他に何をする必要があるか、どのようなトレードオフを行う必要があるか?

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

  1. 現状を維持する
  2. 暴力的なSSF
  3. オービットSSF
  4. 2 レベルのステーキングを備えた SSF

(1) は何もせずにそのままにしておくという意味ですが、これではイーサリアムのセキュリティ エクスペリエンスとステーキング集中化の特性が悪化します。

(2) 先端技術を駆使して暴力的に問題を解決する。これを達成するには、非常に短い時間 (5 ~ 10 秒) で大量の署名 (100 万以上) を集約する必要があります。このアプローチについて考える 1 つの方法は、 カプセル化の複雑さを完全に受け入れることによってシステムの複雑さを最小限に抑えること を含むということです。

(3) 「高度な手法」を回避し、プロトコルの前提条件を賢明に再考して問題を解決します。攻撃コストが高くなるように追求するために「経済的ファイナリティ」要件を緩和しましたが、攻撃コストが現在の 10 倍よりも低くなる可能性があることを受け入れました。 (たとえば、攻撃の費用は 250 億ドルではなく 25 億ドルでした)。今日のイーサリアムは必要以上に経済的なファイナリティを備えており、主要なセキュリティリスクは別の場所にあるため、これはおそらく許容可能な犠牲であると一般的に受け入れられています。

主な作業は、Orbit メカニズムが安全であり、必要な特性を備えていることを確認し、それを完全に形式化して実装することです。さらに、 EIP-7251 (最大実効残高の増加) により、自発的なバリデーター残高の統合が可能になり、チェーン検証のオーバーヘッドが即座にある程度削減され、Orbit のロールアウトの初期段階として効果的に機能します。

(4) これにより、賢明な反映と高度なテクノロジーは回避されますが、依然として集中化の危険を伴う 2 レベルのステーキング システムが作成されます。リスクは主に、より低いステーキングレベルで取得した特定の権利に依存します。例えば:

  • 下位レベルのステーカーが認証権を上位レベルのステーカーに委任する必要がある場合、委任を一元化できるため、最終的に 2 つの高度に一元化されたステーキング層になります。
  • 各ブロックを承認するために下位層のランダムなサンプルが必要な場合、攻撃者はファイナリティを防ぐために非常に少量の ETH を費やす可能性があります。
  • 下位レベルのステーカーが包含リストのみを生成できる場合、プルーフ層は集中化されたままになる可能性があり、その時点でプルーフ層に対する 51% の攻撃により包含リスト自体が検閲される可能性があります。

次のような複数の戦略を組み合わせることができます。

1 + 2): 単一スロットのファイナライズを行わずにオービットを追加します

(1 + 3): 強引な手法を使用して、単一スロットのファイナライズを行わずに最小入金サイズを削減します。必要な重合量は純粋な (3) の場合に比べて 64 分の 1 ですので、問題は容易になります。

(2 + 3): Orbit SSF に保守的なパラメータ (8k や 32k の代わりに 128k バリデータ委員会など) を使用し、テクノロジを使用して超効率化します。

(1 + 4): 単一スロットのファイナライズを行わずにレインボー ステーキングを追加します

ロードマップの他の部分とどのように相互作用するのでしょうか?

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

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

シングルシークレットリーダー選挙 ( シングルシークレットリーダー選挙 )

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

現在、どのバリデーターが次のブロックを提案するかは事前にわかっています。これによりセキュリティ ホールが発生します。攻撃者はネットワークを監視し、どのバリデーターがどの IP アドレスに対応するかを特定し、バリデーターがブロックを提案しようとしているときに各バリデーターに対して DoS 攻撃を実行する可能性があります。

それは何ですか?またどのように機能しますか?

現在、どのバリデータが次のブロックを提案するかは事前にわかっています。これによりセキュリティ ホールが発生します。攻撃者はネットワークを監視し、どのバリデータがどの IP アドレスに対応するかを特定し、バリデータがブロックを提案しようとしているときに各バリデータに対して DoS 攻撃を実行する可能性があります。

それは何ですか?またどのように機能しますか?

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

シングルシークレットリーダー選出プロトコルは、いくつかの暗号化技術を使用して各バリデーターの「ブラインド」バリデーター ID を作成し、多くの提案者にブラインド ID プールをシャッフルする機会を提供することでこの問題を解決します ( ミックスネットの 方法と同様)。各スロット中に、ランダムなブラインド ID が選択されます。ブラインド ID の所有者のみがブロックを提案するための有効な証明を生成できますが、ブラインド ID がどのバリデーターに対応するかは他の誰も知りません。

既存の研究とのつながりは何ですか?

  • Dan Boneh の論文 (2020): https://eprint.iacr.org/2020/025.pdf Dan Boneh の論文 (2020)
  • Whisk (イーサリアムの具体的な提案、2022 年): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763 Whisk (イーサリアムの具体的な提案、2022 年)
  • ethresear.ch の単一シークレット リーダー選挙タグ: https://ethresear.ch/tag/single-secret-leader-election ethresear.ch の単一シークレット リーダー選挙タグ
  • リング署名を使用した簡易 SSLE: https://ethresear.ch/t/simplified-ssle/12315 リング署名を使用した簡易 SSLE

他に何をする必要があるか、どのようなトレードオフを行う必要があるか?

実際に残っているのは、メインネットに簡単に実装できるほど単純なプロトコルを見つけて実装することだけです。私たちはイーサリアムを非常にシンプルなプロトコルとして高く評価しており、これ以上複雑になることを望んでいません。私たちが確認した SSLE 実装では、数百行の正規コードが追加され、複雑な暗号化に新しい前提が導入されました。十分に効率的な量子耐性 SSLE 実装を見つけることも未解決の問題です。

最終的には、他の理由で、思い切ってイーサリアム プロトコルの L1 に普遍的なゼロ知識証明のメカニズム (例: ステート ツリー、ZK-EVM) を導入すると、SSLE によって導入される追加の複雑性は低く抑えられるということです。十分。

もう 1 つのオプションは、SSL をまったく考慮せず、オフプロトコルの緩和策 (たとえば、p2p 層) を使用して DoS 問題を解決することです。

ロードマップの他の部分とどのように相互作用するのでしょうか?

もう 1 つのオプションは、SSL をまったく考慮せず、オフプロトコルの緩和策 (たとえば、p2p 層) を使用して DoS 問題を解決することです。

ロードマップの他の部分とどのように相互作用するのでしょうか?

たとえば、証明者と提案者の分離 (APS) メカニズムを追加するとします。 実行チケット 、その後の実行ブロック (つまり、イーサリアム トランザクションを含むブロック) は、専門のブロック ビルダーに依存できるため、SSL を必要としません。ただし、SSLE のコンセンサス ブロック (つまり、証明書などのプロトコル メッセージを含むブロック、おそらくリストを含むフラグメントなど) の恩恵を受けることはできます。

より迅速な取引確認

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

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

それは何ですか?またどのように機能しますか?

8 秒 や 4 秒など、スロット時間を短縮します。これは必ずしもファイナライズに 4 秒かかることを意味するわけではありません。ファイナライゼーションには基本的に 3 ラウンドの通信が必要です。そのため、各ラウンドの通信を個別のブロックにして、少なくとも 4 秒後に暫定的に確認されるようにすることができます。

提案者がスロットのプロセス中に事前確認を発行できるようにします。極端なケースでは、提案者はリアルタイムで確認したトランザクションを自分のブロックに追加し、各トランザクションの事前確認メッセージ (「最初のトランザクションは 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 プロトコル強制提案者コミットメント (PEPC)
  • 並列チェーン全体で期間をずらす (低レイテンシを達成するための 2018 年時代のアイデア): https://ethresear.ch/t/staggered-periods/1793 並列チェーン全体で期間をずらす (低レイテンシを達成するための 2018 年時代のアイデア)

他に何をする必要があるか、どのようなトレードオフを行う必要があるか?

スロット時間を短縮することが現実的かどうかは不明です。今日でも、世界の多くの地域の利害関係者は証拠を迅速に入手するのに苦労しています。 4 秒のスロット時間を試行すると、バリデーターが集中化するリスクがあり、少数の開発されたリージョンの外でバリデーターになるのは遅延のため現実的ではありません。具体的には、4 秒のタイムスロットに移行するには、ネットワーク遅延 (「デルタ」) 制限を 2 秒に減らす必要があります。

プロポーザーの事前確認方法の欠点は、平均的なケースではインクルード時間が大幅に改善されますが、最悪のケースではそうではないことです。現在のプロポーザーが正常に実行されている場合、トランザクションは 6 秒ではなく 0.5 秒で事前確認されます。 (平均して) 秒が含まれますが、現在のプロポーザーがオフラインであるか、パフォーマンスが良好でない場合は、次のスロットが開始されて新しいプロポーザーが提供されるまで、依然として 12 秒待つ必要があります。

さらに、事前確認をどのように奨励するかも未解決の問題です。提案者には、可能な限り長くオプションを最大化するインセンティブがあります。証明者が適時性を確保するために事前確認に署名した場合、トランザクション送信者は即時の事前確認に料金の一部を条件とすることができますが、これにより認証者にさらなる負担がかかり、認証者の続行がさらに困難になる可能性があります。中立的な「ダムパイプ」として機能します。

一方、これを行わずにファイナライゼーション時間を 12 秒 (またはそれ以上) に維持すると、エコシステムは L2 の事前確認メカニズムをより重視することになり、L2 を越えたインタラクションにかかる時間が長くなります。

ロードマップの他の部分とどのように相互作用するのでしょうか?

一方、これを行わずにファイナライゼーション時間を 12 秒 (またはそれ以上) に維持すると、エコシステムは L2 の事前確認メカニズムをより重視することになり、L2 を越えたインタラクションにかかる時間が長くなります。

ロードマップの他の部分とどのように相互作用するのでしょうか?

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

スロット時間をどれだけ短くできるかは、スロット構造によって決まります。スロット構造は、最終的に実装する APS バージョン、包含リストなどに大きく依存します。一部のスロット構造はラウンド数が少ないため、短いスロット時間に適していますが、他の部分でトレードオフがあります。

その他の研究分野

攻撃回復51%

51% 攻撃 (検閲などの暗号学的に証明できない攻撃を含む) が発生した場合、コミュニティが結集して 少数派のソフト フォークを 実装し、善玉が勝ち、悪玉が非アクティブ状態を漏洩または遮断されるようにするだろうとよく考えられています。しかし、この社会的側面への過度の依存は間違いなく不健全です。回復プロセスを可能な限り自動化することで、ソーシャル層への依存を減らすことができます。

完全な自動化は不可能です。もし可能であれば、それは 50% を超えるフォールトトレラントなコンセンサス アルゴリズムとみなされ、 そのようなアルゴリズムの (非常に厳密な) 数学的に証明可能な制限が すでにわかっているからです。しかし、部分的な自動化は実現できます。たとえば、クライアントが十分に長いトランザクションを確認した場合、クライアントは完了したチェーンやフォークで選択されたヘッドの受け入れを自動的に拒否できます。重要な目標は、攻撃側の悪者が少なくとも迅速かつ完全な勝利を収めることができないようにすることです。

クォーラムしきい値を増やす

現在、株式の 67% を保有する人々がそれを支持すれば、ブロックは完了します。これは過激すぎると考える人もいます。イーサリアムの歴史全体の中で、ファイナリティの失敗は (非常に短期間) 1 回だけ発生しました。この割合がたとえば 80% に増加すると、追加される非ファイナリティ フェーズの数は比較的少なくなりますが、イーサリアムはセキュリティ特性を獲得します。特に、物議を醸す状況の多くはファイナリティの一時的な停止につながります。これは、間違った側が攻撃者であるか、バグのあるクライアントを持っている場合にせよ、「間違った側」がすぐに勝つよりもはるかに健全であるように思えます。

これは、「別個の質権の意義は何ですか?」という質問にも答えます。現在、ほとんどのステーカーはマイニングプールを通じてステーキングを行っており、ステーキングされた ETH の 51% を 1 人のステーカーが受け取ることは考えにくいようです。しかし、私たちが熱心に取り組めば、特に定足数が 80% であれば、個々のステーカーが少数派を阻止するための定足数に達することは達成可能と思われます (つまり、少数派を阻止するために必要な定足数は 21% だけです)。個々のステーカーが 51% 攻撃 (ファイナリティ回復またはレビュー) に同意しない限り、そのような攻撃は「完全な勝利」を達成することはなく、個々のステーカーには少数派のソフトフォークの組織化を支援するインセンティブが与えられます。

クォーラムのしきい値と Orbit メカニズムの間には相互作用があることに注意してください。Orbit を使用することになった場合、「ステーカーの 21%」が正確に何を意味するかはより複雑な問題となり、バリデーターの分布に部分的に依存します。

量子抵抗

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

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

0

免責事項:本記事の内容はあくまでも筆者の意見を反映したものであり、いかなる立場においても当プラットフォームを代表するものではありません。また、本記事は投資判断の参考となることを目的としたものではありません。

PoolX: 資産をロックして新しいトークンをゲット
最大12%のAPR!エアドロップを継続的に獲得しましょう!
今すぐロック