ヴィタリックのPoS簡素化案：SSF後、1スロットあたり8192署名

著者: Vitalik Buterin, ethresear; コンパイラ: Songxue, Golden Finance

Ether と他のほとんどの（究極的に決定論的な）株式等証明システムとの主な違いは、Ether が非常に多くのバリデータオブジェクトをサポートしようとしていることです。現在895,000のバリデータオブジェクトがあり、Zipfの法則を単純に分析すると、これはユニークな個人/エンティティである何万ものバリデータオブジェクトに相当する。 この目的は、分散化をサポートし、各個人が自分のエージェンシーを放棄し、小さな誓約者のプールの1つにコントロールを渡すことを必要とせずに、普通の個人でも誓約に参加できるようにすることです。

しかし、このアプローチでは、イーサチェーンがタイムスロットごとに大量の署名（現在～28,000件、SSF後は1,790,000件）を処理する必要があり、これは非常に高負荷です。

• これには、証明を複数のサブネットに分割する複雑な証明伝播メカニズムが必要で、これらの署名を検証するためにBLS署名操作の超最適化などが必要です。これらの署名を検証するためのBLS署名操作の最適化などが必要です。

• 私たちは、量子耐性を持つのに十分効率的な明確な代替案を持っていません。

• ビューのマージに似たフォーク選択修復は、個々の署名を抽出できないため、より複雑になります。

• 署名のSNARKは数が多いため困難です。heliosは同期委員会署名と呼ばれる専用の追加署名で動作する必要があります。

• 1つのタイムスロットに2つではなく3つのサブタイムスロットを要求することで、安全な最小タイムスロットを増やします。

署名集約システムは一見合理的に見えますが、実際にはあらゆる側面に浸透する体系的な複雑さを生み出しています。

しかも、その目的すら果たしていない。 誓約の最低条件はまだ32ETHで、多くの人にとって手の届かないものです。 そして論理的な分析からだけでも、全員がサインインするシステムで実際に一般人に誓約を提供するのは、長期的には実現可能とは思えません。仮にイーサのユーザーが5億人いて、そのうちの10%が誓約するとすると、1スロットあたり1億人の署名が必要ということになります。 情報理論的には、この設計の処理削減には、1スロットあたり少なくとも12.5MBのデータ利用可能領域が必要で、これはフルダクシャーディングの目標とほぼ同じである（！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！）。. それは実現可能かもしれませんが、誓約が本質的にデータの可用性サンプリングに依存することを要求することは、大きな複雑さの増加を導入します - たとえこれが世界の誓約の人口の約0.6%に過ぎないとしても、そしてそのような多くの署名を検証することに関係する計算上の問題に対処し始めることさえできません。

そこで、各タイムスロットで増え続ける署名を可能にするために、暗号技術者が魔法の弾丸（または魔法の防弾チョッキ）を作ることに頼るのではなく、哲学的な転換をすることを提案します。これによって、PoSの設計空間が大きく広がり、技術的な簡素化が大幅に可能になります。Heliosは、イーサのコンセンサス上で直接SNARK処理を行うことができるようになるため、より安全になり、Winternitzのような退屈で長年の署名スキームさえも実行可能にすることで、量子抵抗の問題を解決することができます。

なぜ「委員会を使うだけ」ではいけないのか？

この正確な問題に直面しているイーサ以外のブロックチェーンの多くは、委員会ベースのセキュリティアプローチを使っています。各タイムスロットで、そのタイムスロットを完了する責任を負うN人の検証者（例えば、Nは約1000に等しい）をランダムに選択します。このアプローチが不適切である理由を思い出す価値があります。

その理由を理解するために、51%の攻撃が発生したとします。これは最終的な逆転攻撃かもしれないし、検閲攻撃かもしれない。攻撃を仕掛けるには、やはり誓約の過半数を支配する経済参加者が、最終的に委員会に選ばれたすべての検証者とともに、攻撃を実行すること、つまり攻撃に関わるソフトウェアを実行することに同意する必要があります。ランダムサンプリングの数学はこれを保証する。しかし、攻撃に同意したバリデータのほとんどは、委員会に選ばれないため、結局見ることができないので、このような攻撃で彼らが負うペナルティは小さい。

現在、イーサは反対の極端な方法をとっている。51パーセントの攻撃では、攻撃するバリデータ全体の過半数が誓約から切り離されます。現在の攻撃コストは約900万ETH（約200億円）で、これは攻撃者の利益を最大化する方法でネットワーク同期が中断されることを想定しています。

これは高いコストであり、法外なものだと思います。100万～200万ETHの攻撃でさえ、完全に適切でしょう。また、現在イーサに存在する主な中央集権化リスクは、まったく別の場所にあります。最低誓約額がゼロ近くまで引き下げられれば、大規模な誓約プールの強さの差はそれほど大きくならないでしょう。

だからこそ、私は控えめな解決策を主張しているのです。検証者の説明責任という点である程度の犠牲を払いつつも、削減できるETHの総量をかなり高く保ち、それと引き換えに、以下のようなメリットが得られます。検証者のアカウンタビリティという点である程度の犠牲を払いつつも、削減できるETHの総量をかなり高く保ち、それと引き換えに、より少数の検証者のセットから得られるメリットのほとんどを得る。

SSFでは、時間枠あたり8192の署名はどのようになるでしょうか？

伝統的な2ラウンドのコンセンサスプロトコル（Tendermintで使用されているプロトコルに似ており、SSFが必然的に使用するプロトコルです）を仮定すると、参加する各検証者はタイムスロットごとに2つの署名が必要になります。この現実を回避する必要がある。私は主に3つの方法を考えています。

Method #1: Go all-in on decentralised pledge pools

Python には非常に重要なフレーズがあります:

これを行うための明白な方法が1つ、できれば1つだけあるべきです。

誓約の平等化について、Etherは現在このルールに違反しています。(i)少額の個人誓約、そして(ii) Distributed Validator Technology (DVT) を使用した分散型誓約プール。 これらの理由から、(i)一部の個人誓約者のみをサポートすることができます。最低入金額が大きすぎる多くの人が常に存在します。 しかし、イーサネットは(i)をサポートするために非常に高い技術負担コストを支払っている。

可能な解決策の1つは、(i)をやめて(ii)に全力を注ぐことです。最低誓約額を4096 ETHに増やし、検証者4096人（～1670万ETH）の合計上限を設定することができます。少額のプレッジャーがDVTプールに参加することが期待されます：資金を提供するか、ノードオペレータになることで。攻撃者による悪用を防ぐため、ノードオペレータの役割はレピュテーションによって何らかの形で制限される必要があり、プールはこの点で異なるオプションを提供することで互いに競争することになる。資金提供はライセンスフリーとなる。

このモデルのプール誓約は、たとえば罰則を制限することで、より「寛容」にすることができます。 これはノード運営者への信頼を低下させますが、ここで概説した問題のため、慎重に扱う価値があります。

Approach 2: Two Tiers of Pledges

4096 の誓約を求める「重い」層。最終化に参加するために4096ETHを要求する "ヘビー "層と、最低誓約要件がない（また、入出金の遅延もなく、カットのリスクもない）"ライト "層で、セキュリティのレイヤーをもう1つ追加します。ブロックを確定するには、ヘビーレイヤーがそれを確定し、ライトレイヤーがオンラインのライトベリファイアーの>=50%によってそれを証明する必要があります。

この異質性は、検閲への耐性と攻撃への耐性の点で有益です。攻撃が成功するためには、ヘビーレイヤーとライトレイヤーの両方が破損している必要があるからです。一方のレイヤーが破壊され、もう一方が破壊されなければ、連鎖は止まってしまう。破壊されたのがヘビーレイヤーであれば、罰することができる。

このアプローチのもう1つの利点は、ライトレイヤーにアプリ内担保としても使用されるETHを含めることができることです。主な欠点は、小規模と大規模の誓約者の間に乖離を設けることで、誓約が平和的でなくなることです。

Approach 3: Rotating participation (i.e., committee but in charge)

私たちは、ここで提案されたスーパー委員会と同様のアプローチをとりました。設計：各タイムスロットについて、現在アクティブな検証者を4096人選択し、各タイムスロット中にそのセットを慎重に調整して、まだ安全であることを確認します。

ただし、このフレームワークの中で「最大の利益を得る」ために、いくつかの異なるパラメータを選択します。 特に、私たちは検証者が任意に高い残高で参加することを許可し、検証者が一定量M以上のETH（これはフローティングでなければなりません）を持っている場合、彼らはすべてのセッションで委員会に参加します。 検証者がN<M個のETHを持っている場合、任意のタイムスロットで委員会に参加する確率はN/Mとなります。

ここで、インセンティブ目的の「重み」とコンセンサス目的の「重み」を切り離す、興味深いテコがあります。平均報酬を比例させる。ETHを重みとして使用することで、委員会内の検証者のコンセンサスを得ることができる。 これにより、最終性を破るには、委員会内のETH総量の1/3以上のETHが必要であることが保証されます。

Zipfの法則分析では、以下のようにETHの量をカウントします:

• 合計残高の各2次レベルでは、検証者の数はその残高のレベルに反比例します。これらのバリデーターの合計残高は同じになる。

• つまり委員会は、バリアM以上のレベル（バリデーターが常に委員会にいる）を除き、各残高レベルから等量のETHが参加することになります。

• そのため、上記のレベルの各KバリデータにはLog2（M）レベルがあり、K+K/2+......=2Kレベル以上となります。したがって、K = 4096/Log2 (M) + 2.

• 最大のバリデータはM*kの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)

  合計2621,440ETH、つまり約900k ETHの攻撃コストを得ることができました。

このアプローチの主な欠点は、プロトコルにさらなる複雑さをもたらすことです。

このアプローチの主な欠点は、委員会が変更されてもコンセンサスの安全性を確保できるように、バリデータをランダムに選択するために、プロトコルに若干の複雑さが生じることです。

主な利点は、独立した誓約の認識可能な形式を維持し、単一のシステムを維持し、最低誓約額でさえ非常に低いレベル（例えば1ETH）に減らすことができることです。

まとめ

SSFプロトコルの後に8192署名に固執することに落ち着くのであれば、技術的な実装者の仕事だけでなく、ライトクライアントのような補助的なインフラの構築者の仕事もずっと楽になる8192署名に固執したいと思います。誰でもコンセンサス・クライアントを実行することが容易になり、ユーザーや誓約愛好家などがすぐにその前提に取り組むことができるようになります。イーサリアムのプロトコルの将来的な負荷は、もはや未知数ではありません。ハードフォークによって将来的に改善することは可能ですが、開発者が、タイムスロットあたりにより多くの署名を同じレベルで簡単に扱えるほど技術が向上したと確信した場合に限られます。

残りの作業は、私たちが取りたい3つのアプローチのどれを取るか、あるいはおそらく完全に異なる何かを決めることです。どのトレードオフに私たちが納得できるか、そして特に、モバイル誓約書のような関連する問題をどのように解決するかが問題になるでしょう。