シングルスロットファイナリティ
イーサリアムのブロックが確定するまで、約15分かかります。 しかし、イーサリアムのコンセンサスメカニズムでブロックをより効率的に検証することで、ファイナリティまでの時間を大幅に短縮することができます。 15分間待つ必要はなく、同じスロット内でブロックが提案され、確定することができます。 このコンセプトは、**シングルスロットファイナリティ(SSF)**と呼ばれます。
ファイナリティとは
ファイナリティとは、イーサリアムの新しいコンセンサスメカニズムであるプルーフ・オブ・ステークにおいて、ステークされたETH全体の少なくとも33%をバーンしない限り、ブロックを変更したり、ブロックチェーンから削除したりできないことを保証する仕組みです。 これは、「暗号経済」を利用したセキュリティです。チェーンの順序や内容を変更する際に非常に高いコストがかかるため、合理的な経済主体がチェーンを変更しようとする試みを防ぐことができます。
ファイナリティを短縮する理由
現在のファイナリティに至るまでの時間は、長すぎることが判明しています。 ほとんどのユーザーは、ファイナリティに至るまで15分待つことも嫌がります。高いトランザクションスループットを必要とするアプリや取引所でも、トランザクションが永続的になったことを確認するために、長い間待たなければならなりません。 ブロックの提案とファイナリティの間に遅延があると、攻撃者が特定のブロックを検閲したり、MEVを抽出したりするなど、ショートレンジの再編成の機会が生じてしまいます。 ブロックを段階的にアップグレードするメカニズムも非常に複雑で、セキュリティの脆弱性を解消するために何度もパッチが当てられており、イーサリアムのコードベースの中でちょっとしたバグが入りやすい部分の1つです。 これらの問題は、ファイナリティに至るまでの時間を単一のスロットに短縮することで、すべて解決できます。
分散化 / 時間 / オーバーヘッドのトレードオフ
ファイナリティ保証は、新しいブロックの即時のプロパティではありません。 新しいブロックがファイナライズされるまでには時間がかかります。 この理由は、ネットワーク上でステーキングされたETH総額の3分の2以上を代表するバリデータが、ブロックがファイナライズ済みと見なされるために、そのブロックに投票(「証明」)する必要があるからです。 ネットワーク上の各バリデータノードは、他のノードから送られるアテステーションを処理して、ブロックが3分の2のしきい値に達したかどうかを確認する必要があります。
ファイナライズに達するまでの時間が短くなるほど、アテステーションの処理を速く実行する必要があるため、各ノードでより高いコンピューティングパワーが必要になります。 また、ネットワーク上のバリデータノードの数が増えるほど、各ブロックごとに処理するアテステーションが増えるため、必要な処理能力も増加します。 より高い処理能力が必要になると、バリデータノードを実行するために必要なハードウェアの費用が高くなるため、参加できる人が減ってしまいます。 一方、ブロックの間隔を長くすると、各ノードで必要なコンピューティングパワーは減りますが、アテステーションの処理が遅くなるため、ファイナリティに至るまでの時間が長くなります。
したがって、オーバーヘッド(コンピューティングパワー)、分散化(チェーンの検証に参加できるノードの数)、ファイナリティまでの時間の間にトレードオフがあります。 理想的なシステムでは、最小のコンピューティングパワー、最大の分散化、ファイナリティに達する最短の時間というように、3つのパラメータを最適なバランスで実現することが重要です。
イーサリアムの現在のコンセンサスメカニズムでは、次のように、これら3つのパラメータのバランスを取っています。
- 最小ステークを32 ETHに設定。 これにより、個々のノードが処理する必要があるバリデータのアテステーションの上限数が設定されます。よって、各ノードの計算要件の上限も設定されます。
- ファイナリティまでの時間を約15分に設定。 これにより、一般的な家庭用コンピュータで実行されるバリデータが各ブロックのアテステーションを安全に処理するのに十分な時間が与えられます。
現在の仕組みでは、ファイナリティまでの時間を短くするには、ネットワーク上のバリデータの数を減らすか、各ノードのハードウェア要件を増やす必要があります。 ただし、各ノードのオーバーヘッドを増加させることなく、より多くのアテステーションをカウントできるように処理方法を改善することができます。 これにより、2つのエポックにまたがることなく、単一スロット内でファイナリティを決定できるようになります。
SSFへの道筋
イーサリアムのコンセンサスメカニズムが設計された当初、署名集約スキーム(BLS)のスケーラビリティは懸念されていましたが、その後の研究により、BLSは当初考えられていたよりもはるかにスケーラブルであることがわかりました。また、クライアントにおける署名の処理および検証の処理能力も向上したことで、 バリデータから送られる膨大な数のアテステーションの処理が、現実的に1つのスロット内で可能になりました。 例えば、100万のバリデータが各スロットで2回投票し、スロットの時間を16秒に調節している場合、スロットあたり100万のアテステーションを処理するためには、ノードは1秒に最低125,000もの集約に対して署名を検証する必要があります。 実際には、一般的なコンピュータが1つの署名を検証するのに約500ナノ秒かかるので、125,000の署名の検証は約62.5ミリ秒で完了します。これは、1秒のしきい値をはるかに下回っています。
スーパー委員会を設けることで、効率性がさらに向上する可能性があります。例えば、スロットごとにランダムに選ばれた125,000ものバリデータで構成するなどです。 このバリデータのサブセットのみがブロックに対して投票できるため、ブロックがファイナライズされるかどうかを決定できるのです。 このアイデアが受け入れられるかどうかは、イーサリアムへの攻撃の成功に必要なコストを、コミュニティがどの程度高く設定するかにかかっています。 なぜなら、ステークされたイーサ総量の3分の2ではなく、_そのスーパー委員会内の_ステークされたイーサの3分の2で、攻撃者が不正なブロックをファイナライズできてしまうからです。 これはまだ活発な研究分野ですが、そもそもスーパー委員会を必要とするほど大きなバリデータセットの場合、それらのサブ委員会の1つを攻撃するコストは極めて高くなると考えられます（例えば、ETH建ての攻撃コストは2/3 * 125,000 * 32 = ~2.6 million ETHとなります）。 攻撃コストはバリデータセットのサイズを大きくすることで調整できます（例えば、攻撃コストが100万イーサ、400万イーサ、1,000万イーサなどになるようにバリデータサイズを調整するなど）。 コミュニティの事前調査 (opens in a new tab)によると、100万から200万イーサが許容可能な攻撃コストであるようです。これは、スーパー委員会あたり約65,536～97,152のバリデータがいることを意味します。
しかし、検証自体はボトルネックではありません。バリデータノードにとって実際に問題となるのは、署名の集約です。 署名の集約をスケールするには、各サブネットのバリデータの数を増やす、サブネットの数を増やす、集約レイヤーを追加する(つまり、委員会の委員会を実装する)などの方法が考えられます。 解決策の1つとして、専門のアグリゲーターを許可する方法があります。これは、プロポーザー/ビルダーセパレーション(PBS)とダンクシャーディングの環境下で、ブロック構築とロールアップデータのコミットメント生成を専門のブロックビルダーにアウトソーシングするのと似た方法です。
SSFにおけるフォーク選択ルールの役割
現在のコンセンサスメカニズムでは、ファイナリティガジェット(バリデータの3分の2がチェーンを証明したかどうかを判断するアルゴリズム)とフォーク選択ルール(複数のチェーンが存在する場合に、どのチェーンが正しいかを判断するアルゴリズム)が密接に連携して動作しています。 フォーク選択アルゴリズムは、最後にファイナライズされたブロック_以降の_ブロックのみを考慮します。 SSFでは、ブロックが提案されると同時に、そのスロットのファイナリティが発生します。そのため、フォーク選択ルールが適用されるブロックがありません。 つまりSSFでは、_フォーク選択アルゴリズム_か_ファイナリティガジェット_のいずれかが常にアクティブになります。 ファイナリティガジェットは、3分の2のバリデータがオンラインで、ブロックが正しいことが証明された場合に、そのブロックを確定します。 ブロックが3分の2のしきい値を超えることができない場合は、フォーク選択ルールが作動して、どのチェーンに従うかを決定します。 多少のニュアンスが追加されるものの、バリデータの3分の1超がオフラインになった場合でも、チェーンを回復する非アクティブリークメカニズムを維持する機会も生まれます。
残された課題
サブネットごとのバリデータ数を増やすことで集約をスケーリングする際の問題は、ピアツーピアネットワークの負荷が増大することです。 集約のレイヤーを追加する際の問題点は、エンジニアリングが非常に複雑になり、レイテンシーが増加することです（つまり、ブロック提案者がすべてのサブネットアグリゲーターからの連絡を受け取るまでに時間がかかる可能性があります）。 BLS署名集約を使用しても、ネットワーク上にアクティブなバリデータが多数存在する場合、各スロット内で処理できる数を超えてしまう可能性があります。その場合の対応方法は明らかになっていません。 1つの解決策として考えられるのは、全バリデータが各スロットで証明を行い、SSFにおいて委員会を廃止し、有効残高の32ETH上限を撤廃することです。つまり、複数のバリデータを管理するオペレータは、ステークを統合して実行回数を減らし、バリデータノードはバリデータセット全体を構成することで処理するメッセージの数を減らすことができます。 大規模なステーカーがバリデータを統合することに同意することで、この問題は解決します。 また、バリデータの数やステーキングされたETHの量に一定の上限を設けることも可能ですが、 その場合は、参加を許可するバリデータを選ぶ何らかのメカニズムが必要になるため、望ましくない二次的な影響が生じる可能性があります。
現在の進捗
SSFはまだ研究段階です。 VerkleツリーやDankshardingといった他の大規模なアップグレードの後になる可能性が高く、リリースは数年先になると予想されています。
参考リンク
- EDCON 2022でのSSFに関するヴィタリック氏の講演 (opens in a new tab)
- ヴィタリック氏のメモ：シングルスロットファイナリティへの道筋 (opens in a new tab)
最終更新： 2026年2月23日
