Vitalikの新しい記事:SSFはどのようにしてイーサリアムのシングルスロット署名の数を8192で安定させるのですか?

原題:“Sticking to 8192 signatures per slot post-SSF: how and why”

ヴィタリック・ブテリンによるオリジナル記事、ETHリサーチ

オリジナルコンピレーション:Luccy、BlockBeats

*編集者注:SSF(Single Slot Finality)はSingle Slot Finalityの略で、イーサリアムのレイテンシーを大幅に削減する方法を提供します。 ブロックチェーンコンセンサスメカニズムでは、ファイナリティとは、トランザクションまたはブロックが取り消不能になり、改ざんや取り消しができないようにすることを意味します。 ファイナリティを達成することは、二重支出やその他の悪意のある活動のリスクを排除するため、分散化システムの信頼性とセキュリティにとって不可欠です。 *

*SSFは、BlockchainConsensus Mechanismでは、単一のタイムスロットまたは時間の単位を「最終」と見なすことができることを示唆しています。 オリジナルのイーサリアムコンセンサスとは異なり、すべてのバリデーターがスロットの承認または署名に参加できるため、トランザクションの確認時間が短縮され、全体的なユーザーエクスペリエンスが向上します。 *

*Vitalik ETHは、SSF後、参加するバリデーターがスロットごとに2つの署名を持つこと、つまり8192の署名に到達する必要がある理由を探り、この目標を達成する方法について3つの仮説、すなわちフルステーキング、2層ステーキング、ローテーション参加を提唱し、プロトコルのセキュリティを維持しながらスロットあたりの署名数をより効率的に処理する方法を分析し、それらの長所と短所、およびプロトコルとユーザーへの影響について議論します。 BlockBeatsは原文を以下のようにまとめました。

イーサリアムと他のほとんどの(ファイナリティのある)PoSシステムとの大きな違いの1つは、イーサリアムが非常に多くのバリデーターをサポートするよう努めていることです:現在、895, 000人のバリデーターがおり、Zipfの法則の分析によると、数万人の独立した個人または団体に相当します。 その目的は、分散化をサポートし、誰もが行動する能力を放棄し、数少ないステーキングプールの1つにコントロールを渡すことなく、一般の人々がステーキングに参加できるようにすることです。

しかし、このアプローチでは、イーサリアムチェーンがスロットごとに多数の署名を処理する必要があり(現在の約28,000、SSF後は1,790,000)、これは非常に高い負荷です。 この負荷をサポートするには、いくつかの技術的な犠牲を払わなければなりません。

• プルーフが複数のサブネットに分割される複雑なプルーフ伝播メカニズム、それらのシグニチャを検証するための超最適化された BLS シグネチャ操作などが必要です。 *現在のところ、量子抵抗に代わる明確で効率的な代替手段はありません。
• ビューのマージなどのフォーク選択の修正は、個々の署名を抽出できないため、より複雑になります。
• SNARKの処理は、非常に多くの署名に対して困難です。 Heliosは、同期委員会署名と呼ばれる特殊な追加署名で実行する必要があります。
• スロット内に 2 つではなく 3 つのサブスロットが必要なため、安全な最小スロット時間が長くなります。

署名集約システムは、一見合理的に見えるかもしれませんが、実際には、システム全体に浸透する体系的な複雑さを生み出します。

さらに、それはその目標さえ達成しませんでした。 ステーキングの最低要件はまだ32 ETHであり、多くの人にとって手の届かないものです。 論理的な分析の観点からのみ、誰もが長期的にすべてのスロットに署名できるシステムの目標は、一般の人々に真にステーキングを提供することは不可能に思えます:イーサリアムに5億人のユーザーがいて、そのうちの10%がステーキングに参加している場合、それはスロットごとに1億の署名を意味します。 情報理論の観点から見ると、この設計の処理ペナルティには、スロットあたり少なくとも 12.5 MB のデータ空き領域が必要であり、これはフル シャーディングの目標とほぼ同じです。 それは可能かもしれませんが、ステーキング自体がデータ可用性サンプリングに依存する必要があるため、複雑さが大幅に増します。 それでも、世界人口の約0.6%しかステーキングに参加しておらず、これほど多くの署名を検証するという計算上の問題はまだ始まっていません。

ですから、スロットあたりの署名数が増え続けるために、暗号に頼って魔法の弾丸(または魔法の防弾)を作成する代わりに、私は哲学的な転換を提案します。 これにより、PoSの設計空間が大幅に拡大し、技術的な簡素化が大幅に可能になり、HeliosがEthereumConsensus上で直接SNARKできるようにすることで安全性が向上し、Winternitzのような面白くないが長年の署名スキームでも実現可能にすることで量子抵抗の問題を解決します。

なぜ「委員会のみ使用」ではないのですか?

まさにこの問題に直面している多くの非イーサリアムブロックチェーンは、セキュリティに対して委員会ベースのアプローチを採用しています。 各スロットでは、最終的にスロットの確認を担当するN人のバリデーター(例:N ≈ 1000)をランダムに選択します。 このアプローチでは説明責任が果たされないため、このアプローチが十分ではない理由を思い出す価値があります。

その理由を理解するために、攻撃の51%が発生したとしましょう。 これは、ターミナルリバーサル攻撃または検閲攻撃である可能性があります。 攻撃を実行するためには、経済主体が攻撃に同意するためにステークの過半数を支配すること、つまり、攻撃に関与するソフトウェアを実行し、最終的に委員会に選出されたすべてのバリデーターとともに攻撃に参加する必要があります。 数学的に無作為抽出法がこれを保証します。 しかし、攻撃に同意したバリデーターのほとんどが最終的に委員会に選出されなかったため、これに対して受けたペナルティは最小限にとどまりました。

現在、イーサリアムは正反対のことをしています。 51%の攻撃が発生した場合、攻撃バリデーターコレクション全体の大部分がデポジットカットされます。 攻撃の現在のコストは約900万ETH(約200億ドル)であり、ネットワーク同期の停止は攻撃者にとって最も有利な方法で行われると想定されています。

コストは高いと思いますが、支払うには高すぎる代償であり、この問題ではいくらかの犠牲を払うことができます。 100万〜200万ETHの攻撃コストでも十分です。 また、現在イーサリアムに存在する主な中央集権化リスクは、最低入金額がゼロ近くまで下がっても、大規模なステーキングプールの力はあまり衰えないという、全く別のところに反映されています。

だからこそ、私は中道的な解決策を提唱しているのです:バリデーターの責任にいくらかの犠牲を払いながらも、高い総カット可能なETH額を維持し、その代わりに、少数のバリデーターのメリットのほとんどを享受することができます。

SSF のスロットごとに 8192 個の署名がある場合はどうなりますか?

従来の2ラウンドのコンセンサスプロトコル(Tendermintが使用するプロトコルや、SSFが必然的に使用するプロトコルなど)を想定すると、参加する各バリデーターはスロットごとに2つの署名を必要とします。 この現実に向き合う必要があり、この問題を解決するには大きく分けて3つの方法があると思います。

方法1:分散化ステーキングプールを全面的に採用する

Python Zenには、非常に重要なフレーズが含まれています。

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

イーサリアムは現在、ステーキングを平等にすることに関してこのルールに違反しており、この目標を達成するために、(i)小規模の独立したステーキングと、(ii)分散型バリデーター技術(DVT)を使用した分散型ステーキングプールの2つの異なる戦略を同時に実施しています。 上記の理由により、(i)少数の個々のステーカーしかサポートできず、最低入金額が大きすぎる人が常にたくさんいます。 しかし、イーサリアムは(i)をサポートするために非常に高い技術的負担コストを支払っています。

考えられる解決策の1つは、(i)をあきらめて(ii)全力で取り組むことです。 最低入金額を4096 ETHに増やし、バリデーターの合計上限を4096(約1670万ETH)に設定することができます。 小規模なステーカーは、資本を提供するか、ノードオペレーターになることでDVTプールに参加することが期待されています。 攻撃者による悪用を防ぐために、ノードオペレーターの役割は何らかの方法で名声のしきい値によって制限される必要があり、プールはこの点に関してさまざまなオプションを提供することで競争します。 資本金の供与は許可なしとなります。

このモデルでは、ペナルティキャップを設定することで、ステーキングをより「寛容」にすることができます(例:提供された総入金額の1/8)。 これにより、ノードオペレーターへの信頼度が低下しますが、概説されている問題があるため、慎重に扱う価値があります。

方法2:2層のステーキング

ステーカーには、最終状態の確認に参加するために4096 ETHを必要とする「重い」レイヤーと、最低要件(入出金の遅延やカットダウンの脆弱性がない)のない「ライト」レイヤーの2つのレイヤーを作成し、2番目のセキュリティレイヤーを追加しました。 ブロックの最終状態を確認するためには、重い層の最終状態の確認と、オンラインの軽いバリデーターの証明の軽い層の少なくとも50%の両方が必要です。

この異質性は、攻撃を成功させるためには重い層と軽い層の両方を破壊する必要があるため、検閲と攻撃への耐性に有益です。 一方の層が破損し、もう一方の層が破損していない場合、チェーンは停止し、重い層が破損している場合は罰せられる可能性があります。

これのもう一つの利点は、軽量層にアプリ内担保としても使用されるETHを含めることができることです。 主な欠点は、小規模のステーカーと大規模なステーカーの間に格差を設けることで、ステーキングの平等性が低くなることです。

方法3:ローテーション参加(つまり、委員会だが説明責任)

私たちは、ここで提案されているスーパーコミッティの設計に似たアプローチを取ります:各スロットについて、現在アクティブな4096人のバリデーターを選択し、各スロットのセットを慎重に調整して、セキュリティを確保します。

ただし、このフレームワーク内で「コストパフォーマンス」を得るために、いくつかの異なるパラメーターを選択しました。 特に、バリデーターは任意に高い残高で参加できるようにしており、バリデーターが一定以上のETHを持っている場合(これは変動している必要があります)、各スロットの委員会に参加します。 バリデーターがN<M ETHを持っている場合、そのバリデーターは、委員会に参加するための任意のスロットでN/Mの確率を持っています。

ここでは、インセンティブ目的の「重み」とコンセンサス目的の「重み」を切り離すための興味深い手段があります:委員会の各バリデーターの報酬は、平均報酬を残高に比例させるために(少なくとも≤M ETHを使用するバリデーターの場合)同じであるべきですが、委員会のコンセンサスバリデーターの重みは、ETH重み付けによって計算できます。 これにより、ファイナリティを破るために必要なETHの量は、委員会の総ETHの1/3以上になります。

Zipfの法則を大まかに分析すると、このETH量は次のように計算されます。

• 総残高の各二次レベルでは、バリデータの数はその残高レベルに反比例し、これらのバリデーターの合計残高は同じになります。
• その結果、委員会は、バリデーターが常に委員会にいるバリアMを超えるものを除き、参加する各バランスレベルから同量のETHを持つことになります。

注:計算されたデータをより明確に表示するために、次のステップはスクリーンショットになります

このアプローチの主な欠点は、委員会が変更された場合にコンセンサスセキュリティを取得できるように、プロトコル内のバリデーターをランダムに選択する複雑さがわずかに増加することです。

主な利点は、独立したステーキングを認識可能な形で保持し、シングルクラスシステムを維持し、最低入金額を非常に低いレベル(1 ETHなど)に落とすことができることです。

まとめ

SSF プロトコルの後に 8192 署名に固執すると、ライトクライアントなどのサイドインフラストラクチャの技術実装者や構築者にとって、作業がはるかに容易になります。 コンセンサスクライアントは誰でも簡単に運営でき、ユーザーやステーキング愛好家などは、この仮定に基づいてすぐに作業することができます。 イーサリアムプロトコルの将来の負荷はもはや未知数ではありません:ハードフォークによって未来を後押しすることができますが、それは開発者が同じレベルの容易さでスロットあたりより多くの署名を処理できるほど技術が改善されたと確信している場合に限ります。

残りの作業は、3 つの方法のどれを採用するか、またはまったく異なるアプローチを決定することです。 どのようなトレードオフを許容できるか、具体的には、リキッドステーキングなどの関連する問題にどう対処するかが問題になりますが、これは、今でははるかに簡単になっている技術的な問題とは別に解決できる可能性があります。

元の記事へのリンク