VitalikのPoS簡略化提案：SSF後に各スロットで8192の署名を使用することを堅持
TechFlow厳選深潮セレクト
VitalikのPoS簡略化提案：SSF後に各スロットで8192の署名を使用することを堅持
これは技術の実装担当者の作業をより容易にし、ライトクライアントなどの補助インフラ構築者にとっても同様である。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Vitalik Buterin、ethresearch
翻訳：松雪、金色財経
イーサリアムと他の多くの（最終性を持つ）プルーフ・オブ・ステーク（PoS）システムとの主な違いは、イーサリアムが非常に多数のバリデータをサポートしようとしている点です。現在、895,000ものバリデータオブジェクトがあり、単純なジップ則分析によれば、これは数万のバリデータが個々の人物または独立した実体に相当することを示しています。この目的は、中央集権化を防ぎ、一般の人々がステーキングに参加できるようにし、誰もが自らの代理権を放棄して少数のステーキングプールに制御を委ねる必要がないようにすることです。
しかし、このアプローチでは、チェーンが各スロットで膨大な数の署名（現在約28,000件、SSF導入後は1,790,000件）を処理する必要があり、非常に高い負荷がかかります。この負荷に対応するには、多くの技術的妥協が必要になります：
-
複雑な証明伝播メカニズムが必要となり、証明を複数のサブネットに分割する必要があります。また、BLS署名操作の超最適化など、これらの署名を検証するための高度な最適化も求められます。
-
量子耐性を持つ代替的で十分に効率的な明確なソリューションが存在しません。
-
ビュー合併のようなフォーク選択の修正が、個別署名を抽出できないためにより複雑になります。
-
署名数が多いため、署名に対するSNARK処理が困難です。Heliosは、同期委員会署名と呼ばれる専用の追加署名上で動作する必要があります。
-
セキュリティ最小スロット時間が、2つの代わりに3つのサブスロットを要求することで延長されています。
署名集約システムは一見理にかなっているように見えますが、実際にはあらゆる側面に浸透する体系的な複雑さを生み出しています。
さらに、このシステムはそもそもその目的を達成してさえいません。ステーキングの最低要件は依然として32ETHであり、多くの人にとっては手の届かない金額です。論理的に考えると、長期的には全員が署名を行うシステムが一般人にとって本当に現実的なステーキング手段となるとは思えません。例えば、イーサリアムが5億人のユーザーを持ち、そのうち10％がステーキングを行う場合、各スロットで1億の署名が発生します。情報理論的に言えば、このような設計におけるスラッシング処理には、各スロットあたり少なくとも12.5MBのデータ可用性空間が必要となり、これはフルダクシャーディングの目標とほぼ同じ量（!!!）です。理論的には可能かもしれませんが、ステーキング自体がデータ可用性サンプリングに依存することを要求するのは大きな複雑性を伴います――たとえそれが世界人口の約0.6％のステーキングに過ぎず、まだ多数の署名を検証する計算上の問題にすら触れていないとしてもです。
したがって、暗号学者が「魔法の弾丸」（あるいは「魔法の防弾チョッキ」）を作り出して、各スロットでの署名数が無限に増えることを可能にするのを待つのではなく、私は哲学的な転換を提案します。つまり、最初からそういった期待を捨て去ることです。これにより、PoSの設計空間が大きく拡張され、技術的な簡素化が大量に可能になります。Heliosがイーサリアムコンセンサス上で直接SNARK処理を行えるようになり、安全性が向上し、Winternitzのように地味で古くからの署名方式でも量子耐性の課題を解決できるようになります。
なぜ「委員会のみ」ではいけないのか？
この問題に直面している多くの非イーサリアムブロックチェーンは、「委員会ベース」のセキュリティ手法を使用しています。各スロットにおいて、N人のバリデータ（例：N ≒ 1000）をランダムに選び出し、その委員会がそのスロットの作業を完了します。ただし、このアプローチが不十分な理由を再確認しておく必要があります。それは「説明責任（アカウンタビリティ）」の欠如です。
その理由を理解するために、51％攻撃が発生したと仮定しましょう。これは最終性の巻き戻し攻撃か検閲攻撃かもしれません。攻撃を仕掛けるには、依然として経済的に大部分のステークを支配する参加者が、攻撃用のソフトウェアを実行し、委員会に選ばれたすべてのバリデータと共に攻撃に参加することに同意する必要があります。ランダム抽出の数学的性質はこれを保証します。しかし、攻撃に同意した大多数のバリデータは委員会に選ばれなかったため、実際に攻撃に参加したと「見える」ことはほとんどなく、彼らが被るペナルティは非常に小さくなります。
現在、イーサリアムは正反対の極端を採用しています。もし51％攻撃が発生した場合、攻撃に関与したバリデータ集合の大部分が完全にスラッシングされます。現在の攻撃コストは約900万ETH（約200億ドル）であり、これはネットワークの同期が攻撃者に最大限有利な形で妨害されたという前提での数字です。
私はこれは高すぎるコストだと考えています。ある程度の妥協が可能です。攻撃コストが100〜200万ETH程度であっても十分に安全です。さらに、イーサリアムが現在直面している主要な中央集権化リスクは、まったく別の場所にあります。つまり、最低ステーキング額がゼロに近づけば、大規模ステーキングプール間の力の差はそれほど大きくなることはありません。
だからこそ、私は穏健な解決策を提唱します。バリデータの説明責任の一部を犠牲にしつつも、スラッシング可能なETHの総量は依然として非常に高く維持します。その見返りとして、バリデータ集合を小さくする恩恵の多くを得られるのです。
SSF下で各スロットに8192署名があるとどうなるか？
従来の2段階コンセンサスプロトコル（Tendermintが使用するものや、SSFが避けられない形で採用するであろうプロトコル）を想定すると、各参加バリデータは各スロットで2つの署名を必要とします。我々はこの現実を回避しなければなりません。その方法として、私が考える主なアプローチは3つあります。
方法1：分散型ステーキングプールへの全面移行
Pythonには次のような重要な格言があります：
何かを行うには、1つの——できればただ1つの——明らかな方法があるべきだ。
ステーキングの平等化に関して、イーサリアムは現在この原則に違反しています。なぜなら、(i) 小規模個人ステーキング、および (ii) 分散型バリデータ技術（DVT）を使った分散型ステーキングプール、という2つの異なる戦略を同時に推進しているからです。(i) は一部の個人ステーキング参加者しか支援できません。常に、最低預入額が高すぎて参加できない人々が存在します。しかし、イーサリアムは(i)を支援するために非常に高い技術的負担を抱えています。
1つの可能な解決策は、(i) を諦めて(ii) に全面的に注力することです。最小ステーキング額を4096 ETHに引き上げ、バリデータの総上限を4096（約1670万ETH）に設定します。小規模ステーカーはDVTプールに加入することになるでしょう。資金提供者として、またはノード運営者としてです。攻撃者の悪用を防ぐため、ノード運営者役割は評判によって何らかの形で制限される必要があり、プール同士はこの点で異なる選択肢を提供することで競争します。資金提供はパーミッションレスです。
このモデルでは、集団ステーキングに対して「より寛容な」罰則を設けることもできます。例えば、提供されたステーク総額の1/8までに罰則を限定するなどです。これによりノード運営者に対する信頼度は低下しますが、ここに述べられている問題点があるため、慎重な取り扱いが必要です。
方法2：二層式ステーキング
2つのステーキング層を導入します。「ヘビー」層は4096 ETHを要求し、最終化に参加します。「ライト」層は最低ステーク要件がなく（預入・引出の遅延もなく、スラッシングリスクもない）、追加のセキュリティレイヤーを提供します。ブロックを最終確定させるには、「ヘビー」層による最終化に加え、「ライト」層のオンラインバリデータの>=50%がそのブロックを証明する必要があります。
この異種混合構造は、検閲耐性や攻撃耐性に有益です。攻撃が成功するには、ヘビー層とライト層の両方を腐敗させる必要があります。一方だけが腐敗した場合、チェーンは停止します。ヘビー層が腐敗した場合は、スラッシングによって処罰できます。
この方法のもう一つの利点は、ライト層にアプリケーション内担保として使用されるETHを含められることです。主な欠点は、小規模ステーカーと大規模ステーカーの間に明確な分断を設けることで、ステーキングの平等性を損なう可能性があることです。
方法3：ローテーション参加（つまり「責任ある委員会」）
ここで提案されているスーパーコミッティ設計と類似したアプローチを取ります。各スロットごとに、現在アクティブなバリデータの中から4096人を選出し、各スロット期間中にその集合を注意深く調整することで、安全性を確保します。
しかし、この枠組み内で「最大のメリット」を得るために、いくつか異なるパラメータを選択します。特に、バリデータは任意に高い残高で参加でき、一定量M以上のETHを持つバリデータ（Mは可変値）は、各期間に必ず委員会に参加します。N
ここでは、「報酬目的の重み」と「コンセンサス目的の重み」を分離するという興味深いレバレッジがあります。委員会内の各バリデータの報酬は同一であるべきです（少なくともM ETH以下のバリデータについては）、平均報酬が比例関係を保てるようにするためです。しかし、コンセンサスにおける投票数のカウントは、引き続きETH量に基づいて重み付けすることができます。これにより、最終性の破壊には、委員会内の総ETH量の3分の1を超えるETH量が必要になります。
ジップ則分析は以下のようにETH量を算出します：
総残高の各二次レベルにおいて、バリデータの数はその残高レベルに反比例し、これらのバリデータの総残高は等しくなります。
したがって、委員会には各残高レベルから等しいETH量が参加することになります（ただし、障壁Mを超えるレベルのバリデータは常に委員会に含まれます）。
したがって、上記のレベルKの各バリデータについて、Log2(M)レベルとK+K/2+……=2K以上のバリデータがいます。よって、K = 4096 / (Log2(M) + 2) となります。
最大のバリデータはM×k ETHを持ちます。逆算すると、最大バリデータが2^18=262144 ETHを持っている場合、これは（おおよそ）M = 1024、k = 256を意味します。
ステーキングされたETHの総額は：
上位512バリデータの全株式（2^18×1 + 2^17×2 + …… + 2^10×2^8 = 2359296）
プラス、ランダムサンプリングされた小規模ステーク（2^8×(2^9 + 2^8 + 2^7……) ≒ 2^8×2^10 = 2^18）
合計で2,621,440 ETH、つまり攻撃コストは約90万ETHです。
この方法の主な欠点は、委員会の変更時にもコンセンサスの安全性を確保できるような方法でバリデータをランダムに選ぶために、プロトコル内部にさらなる複雑性を導入することです。
その主な利点は、独立ステーキングの識別可能な形態を保持し、単一のシステムを維持できること、そして最小ステーキング額を非常に低いレベル（例：1ETH）まで下げることさえ可能にすることです。
まとめ
SSFプロトコル以降、各スロットで8192署名に固定することを決定すれば、技術実装担当者やライトクライアントなどの補助インフラ開発者にとって作業が大幅に容易になります。誰にとってもコンセンサスクライアントを実行することが簡単になり、ユーザー、ステーキング愛好家、その他多くの人々がすぐにこの前提の上に構築を始められます。イーサリアムプロトコルの将来の負荷はもはや未知ではありません。ハードフォークによって今後増やすことは可能ですが、その際には開発者が、より多くの署名を各スロットで同じ容易さで処理できる技術的進歩が確実に達成されたと確信した場合に限り行われます。
残る課題は、上記の3つの方法のいずれか、あるいはまったく異なるアプローチを選ぶことです。これは、どのトレードオフであれば許容できるかという私たちの判断にかかっています。特に、流動ステーキングのような問題は、今やより簡単に技術的に扱えるようになるかもしれず、これらは分けて解決できるかもしれません。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@VitalikButerin
