--- title: シングル・スロット・ファイナリティ description: シングル・スロット・ファイナリティの解説 lang: ja template: roadmap --- [イーサリアム](/)のブロックがファイナライズされるまでには約15分かかります。しかし、イーサリアムのコンセンサス・メカニズムをより効率的にブロックを検証するようにし、ファイナリティまでの時間を劇的に短縮することができます。15分待つ代わりに、ブロックを同じスロット内で提案し、ファイナライズすることができます。この概念は、**シングル・スロット・ファイナリティ (SSF)**として知られています。 ## ファイナリティとは？ {#what-is-finality} イーサリアムのプルーフ・オブ・ステーク (PoS) ベースのコンセンサス・メカニズムにおいて、ファイナリティとは、ステークされた総ETHの少なくとも33%をバーンしない限り、ブロックチェーンからブロックを変更または削除できないという保証を指します。これは「暗号経済的」なセキュリティです。なぜなら、チェーンの順序や内容を変更することに伴う非常に高いコストが、合理的な経済主体による試みを防ぐという確信から来ているからです。 ## なぜより迅速なファイナリティを目指すのか？ {#why-aim-for-quicker-finality} 現在のファイナリティまでの時間は長すぎることが判明しています。ほとんどのユーザーはファイナリティのために15分も待ちたくありませんし、高いトランザクション・スループットを求めるアプリや取引所にとって、トランザクションが永続的であることを確信するためにそれほど長く待たなければならないのは不便です。ブロックの提案とファイナライズの間に遅延があることは、攻撃者が特定のブロックを検閲したりMEVを抽出したりするために利用できる短い再編成（reorg）の機会を生み出します。ブロックを段階的にアップグレードするメカニズムも非常に複雑であり、セキュリティの脆弱性を塞ぐために何度かパッチが当てられており、イーサリアムのコードベースの中で微妙なバグが発生しやすい部分の1つとなっています。これらの問題はすべて、ファイナリティまでの時間を単一のスロットに短縮することで排除できます。 ## 分散化 / 時間 / オーバーヘッドのトレードオフ {#the-decentralization-time-overhead-tradeoff} ファイナリティの保証は新しいブロックの即時的な特性ではありません。新しいブロックがファイナライズされるには時間がかかります。その理由は、ネットワーク上でステークされた総ETHの少なくとも2/3を代表するバリデータが、ブロックがファイナライズされたと見なされるために、そのブロックに投票（「アテステーション」）しなければならないからです。ネットワーク上の各検証ノードは、ブロックがその2/3のしきい値に達したかどうかを知るために、他のノードからのアテステーションを処理する必要があります。 ファイナライズに到達するために許容される時間が短いほど、アテステーションの処理をより速く行う必要があるため、各ノードでより多くの計算能力が必要になります。また、ネットワーク上に検証ノードが多く存在するほど、各ブロックに対して処理しなければならないアテステーションが増え、必要な処理能力も増加します。必要な処理能力が増えるほど、各検証ノードを実行するためにより高価なハードウェアが必要になるため、参加できる人が少なくなります。ブロック間の時間を増やすと、各ノードで必要な計算能力は減りますが、アテステーションの処理が遅くなるため、ファイナリティまでの時間も長くなります。 したがって、オーバーヘッド（計算能力）、分散化（チェーンの検証に参加できるノードの数）、およびファイナリティまでの時間の間にはトレードオフがあります。理想的なシステムは、最小の計算能力、最大の分散化、および最小のファイナリティまでの時間のバランスを取ります。 イーサリアムの現在のコンセンサス・メカニズムは、以下の方法でこれら3つのパラメータのバランスを取りました： - **最小ステークを32 ETHに設定する**。これにより、個々のノードが処理しなければならないバリデータのアテステーションの数に上限が設定され、したがって各ノードの計算要件にも上限が設定されます。 - **ファイナリティまでの時間を約15分に設定する**。これにより、一般的な家庭用コンピュータで実行されるバリデータが、各ブロックのアテステーションを安全に処理するための十分な時間が与えられます。 現在のメカニズムの設計では、ファイナリティまでの時間を短縮するためには、ネットワーク上のバリデータの数を減らすか、各ノードのハードウェア要件を増やす必要があります。しかし、アテステーションの処理方法に改善を加えることで、各ノードのオーバーヘッドを増やすことなく、より多くのアテステーションをカウントできるようになります。より効率的な処理により、2つのエポックにまたがるのではなく、単一のスロット内でファイナリティを決定できるようになります。 ## SSFへの道筋 {#routes-to-ssf} 現在のコンセンサス・メカニズムは、ブロックを検証するために各バリデータが処理しなければならないメッセージの数を減らすために、コミッティと呼ばれる複数のバリデータからのアテステーションを組み合わせます。すべてのバリデータは各エポック（32スロット）でアテステーションを行う機会がありますが、各スロットでは「コミッティ」と呼ばれるバリデータのサブセットのみがアテステーションを行います。彼らはサブネットに分割され、その中で少数のバリデータが「アグリゲーター」として選ばれることでこれを行います。これらのアグリゲーターはそれぞれ、サブネット内の他のバリデータから見たすべての署名を単一の集約署名に組み合わせます。最も多くの個別の貢献を含むアグリゲーターは、その集約署名をブロック・プロポーザーに渡し、ブロック・プロポーザーはそれを他のコミッティからの集約署名とともにブロックに含めます。 このプロセスは、`32 slots * 64 committees * 256 validators per committee = 524,288 validators per epoch`であるため、すべてのバリデータが各エポックで投票するのに十分な容量を提供します。執筆時点（2023年2月）で、約513,000の稼働中のバリデータが存在します。 このスキームでは、すべてのバリデータがブロックに投票できるのは、アテステーションをエポック全体に分散させることによってのみ可能です。しかし、_すべてのバリデータがすべてのスロットでアテステーションを行う機会を持つ_ようにメカニズムを改善する方法が潜在的に存在します。 イーサリアムのコンセンサス・メカニズムが設計されて以来、署名集約スキーム（BLS）は当初考えられていたよりもはるかにスケーラブルであることが判明し、クライアントが署名を処理および検証する能力も向上しました。膨大な数のバリデータからのアテステーションを処理することは、実際には単一のスロット内で可能であることがわかりました。例えば、100万のバリデータが各スロットで2回投票し、スロット時間が16秒に調整された場合、ノードはスロット内の100万のアテステーションすべてを処理するために、最低でも毎秒125,000の集約の速度で署名を検証する必要があります。実際には、通常のコンピュータが1つの署名検証を行うのに約500ナノ秒かかるため、125,000回の検証は約62.5ミリ秒で完了し、1秒のしきい値をはるかに下回ります。 さらに、各スロットでランダムに選ばれた例えば125,000のバリデータからなるスーパーコミッティを作成することで、さらなる効率向上が図れます。これらのバリデータのみがブロックに投票できるため、このバリデータのサブセットのみがブロックがファイナライズされるかどうかを決定します。これが良いアイデアかどうかは、コミュニティがイーサリアムへの攻撃を成功させるためのコストをどれくらい高くしたいかにかかっています。なぜなら、ステークされた総イーサの2/3を必要とする代わりに、攻撃者は_そのスーパーコミッティ内の_ステークされたイーサの2/3で不正なブロックをファイナライズできるからです。これはまだ活発な研究分野ですが、そもそもスーパーコミッティを必要とするほど十分に大きなバリデータセットの場合、それらのサブコミッティの1つを攻撃するコストは非常に高くなる（例えば、ETH建ての攻撃コストは`2/3 * 125,000 * 32 = ~2.6 million ETH`になる）というのはもっともらしいと思われます。攻撃コストは、バリデータセットのサイズを増やすことで調整できます（例えば、攻撃コストが100万イーサ、400万イーサ、1000万イーサなどに等しくなるようにバリデータのサイズを調整します）。コミュニティの[予備調査](https://youtu.be/ojBgyFl6-v4?t=755)によると、100万〜200万イーサが許容できる攻撃コストであることが示唆されており、これはスーパーコミッティあたり約65,536〜97,152のバリデータを意味します。 しかし、検証は真のボトルネックではありません。バリデータノードにとって本当に課題となるのは署名の集約です。署名の集約をスケーリングするには、おそらく各サブネット内のバリデータの数を増やすか、サブネットの数を増やすか、または追加の集約レイヤーを追加する（つまり、コミッティのコミッティを実装する）必要があるでしょう。解決策の一部は、プロポーザー・ビルダー分離 (PBS) やダンクシャーディングの下で、ブロックの構築やロールアップデータのコミットメントの生成が専門のブロックビルダーにアウトソーシングされるのと同様に、専門のアグリゲーターを許可することかもしれません。 ## SSFにおけるフォーク選択ルールの役割とは？ {#role-of-the-fork-choice-rule} 今日のコンセンサス・メカニズムは、ファイナリティ・ガジェット（バリデータの2/3が特定のチェーンにアテステーションを行ったかどうかを決定するアルゴリズム）とフォーク選択ルール（複数の選択肢がある場合にどのチェーンが正しいかを決定するアルゴリズム）の間の密接な結合に依存しています。フォーク選択アルゴリズムは、最後にファイナライズされたブロック_以降_のブロックのみを考慮します。SSFの下では、ファイナリティはブロックが提案されるのと同じスロットで発生するため、フォーク選択ルールが考慮すべきブロックは存在しません。これは、SSFの下では、フォーク選択アルゴリズム_または_ファイナリティ・ガジェットの_いずれか_が常にアクティブになることを意味します。ファイナリティ・ガジェットは、バリデータの2/3がオンラインであり、誠実にアテステーションを行っているブロックをファイナライズします。ブロックが2/3のしきい値を超えられない場合、フォーク選択ルールが作動して、どのチェーンに従うかを決定します。これはまた、1/3以上のバリデータがオフラインになったチェーンを回復するインアクティビティ・リークのメカニズムを維持する機会も生み出します（ただし、いくつかの追加のニュアンスがあります）。 ## 未解決の問題 {#outstanding-issues} サブネットあたりのバリデータ数を増やすことで集約をスケーリングする際の問題は、ピア・ツー・ピアネットワークへの負荷が大きくなることです。集約のレイヤーを追加する際の問題は、設計が非常に複雑になり、レイテンシが増加することです（つまり、ブロック・プロポーザーがすべてのサブネットアグリゲーターから連絡を受けるのに時間がかかる可能性があります）。また、BLS署名の集約を使用しても、各スロットで現実的に処理できる数よりも多くの稼働中のバリデータがネットワーク上に存在するシナリオにどう対処するかも明確ではありません。1つの潜在的な解決策は、SSFの下ではすべてのバリデータがすべてのスロットでアテステーションを行い、コミッティが存在しないため、エフェクティブ・バランスの32 ETHの上限を完全に取り除くことです。これにより、複数のバリデータを管理するオペレーターはステークを統合してより少ない数で実行できるようになり、検証ノードがバリデータセット全体を考慮するために処理しなければならないメッセージの数を減らすことができます。これは、大規模なステーカーがバリデータの統合に同意することに依存しています。また、常にバリデータの数やステークされたETHの量に固定の上限を設けることも可能です。しかし、これにはどのバリデータが参加を許可され、どのバリデータが許可されないかを決定するための何らかのメカニズムが必要であり、望ましくない二次的影響を生み出す可能性があります。 ## 現在の進捗 {#current-progress} SSFは研究段階にあります。数年間はリリースされないと予想されており、おそらく[ヴァークル・ツリー](/roadmap/verkle-trees/)や[ダンクシャーディング](/roadmap/danksharding/)などの他の大幅なアップグレードの後になるでしょう。 ## 参考文献 {#further-reading} - [EDCON 2022でのヴィタリックによるSSFについての講演](https://www.youtube.com/watch?v=nPgUKNPWXNI) - [ヴィタリックのノート：シングル・スロット・ファイナリティへの道](https://notes.ethereum.org/@vbuterin/single_slot_finality)