シングルスロット・ファイナリティ

イーサリアムのブロックが確定するまで、約15分かかります。しかし、イーサリアムのコンセンサスメカニズムでブロックをより効率的に検証することで、ファイナリティまでの時間を大幅に短縮することができます。 15分間待つ必要はなく、同じスロット内でブロックが提案され、確定することができます。このコンセプトは、シングルスロット・ファイナリティ(SSF)と呼ばれます。

ファイナリティとは

ファイナリティとは、イーサリアムの新しいコンセンサスメカニズムであるプルーフ・オブ・ステークにおいて、ステークされたETH全体の少なくとも33%をバーンしない限り、ブロックを変更したり、ブロックチェーンから削除したりできないことを保証する仕組みです。これは、「暗号経済」を利用したセキュリティです。チェーンの順序や内容を変更する際に非常に高いコストがかかるため、合理的な経済主体がチェーンを変更しようとする試みを防ぐことができます。

ファイナリティを短縮する理由

現在のファイナリティに至るまでの時間は、長すぎることが判明しています。ほとんどのユーザーは、ファイナリティに至るまで15分待つことも嫌がります。高いトランザクションスループットを必要とするアプリや取引所でも、トランザクションが永続的になったことを確認するために、長い間待たなければならなりません。ブロックの提案とファイナリティの間に遅延があると、攻撃者が特定のブロックを検閲したり、MEVを抽出したりするなど、ショートレンジの再編成の機会が生じてしまいます。ブロックを段階的にアップグレードするメカニズムも非常に複雑で、セキュリティの脆弱性を解消するために何度もパッチが当てられており、イーサリアムのコードベースの中でちょっとしたバグが入りやすい部分の1つです。これらの問題は、ファイナリティに至るまでの時間を単一のスロットに短縮することで、すべて解決できます。

分散化・時間・オーバーヘッドのトレードオフ

ファイナリティ保証は、新しいブロックの即時のプロパティではありません。新しいブロックがファイナライズされるまでには時間がかかります。時間がかかる理由は、ネットワーク上でステーキングされたETHの合計の3分の2以上に相当するバリデータが、ブロックをファイナライズするために投票(「証明」)する必要があるからです。ネットワーク上の各バリデータノードは、他のノードから送られるアテステーションを処理して、ブロックが3分の2のしきい値に達したかどうかを確認する必要があります。

ファイナライズに達するまでの時間が短くなるほど、アテステーションの処理を速く実行する必要があるため、各ノードでより高いコンピューティングパワーが必要になります。また、ネットワーク上のバリデータノードの数が増えるほど、各ブロックごとに処理するアテステーションが増えるため、必要な処理能力も増加します。より高い処理能力が必要になると、バリデータノードを実行するために必要なハードウェアの費用が高くなるため、参加できる人が減ってしまいます。一方、ブロックの間隔を長くすると、各ノードで必要なコンピューティングパワーは減りますが、アテステーションの処理が遅くなるため、ファイナリティに至るまでの時間が長くなります。

したがって、オーバーヘッド(コンピューティングパワー)、分散化(チェーンの検証に参加できるノードの数)、ファイナリティまでの時間の間にトレードオフがあります。理想的なシステムでは、最小のコンピューティングパワー、最大の分散化、ファイナリティに達する最短の時間というように、3つのパラメータを最適なバランスで実現することが重要です。

イーサリアムの現在のコンセンサスメカニズムでは、次のように、これら3つのパラメータのバランスを取っています。

最小ステークを32ETHに設定。 これにより、個々のノードが処理する必要があるバリデータのアテステーションの上限数が設定されます。よって、各ノードの計算要件の上限も設定されます。
ファイナリティまでの時間を約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を使って不正なブロックをファイナライズさせる可能性があるためです。これはまだ研究中の分野ですが、そもそもスーパー委員会を必要とするほどの大きなバリデータセットの場合、そのサブ委員会のいずれかを攻撃するコストが非常に高くなると考えられます(例: ETH建ての攻撃コストは、2/3 * 125,000 * 32 = ~2.6 million ETHになります)。攻撃のコストは、バリデータセットのサイズを増やすことで調整可能です(例: 攻撃のコストを100万ETH、400万ETH、1000万ETHなどにするために、バリデータのサイズを調整する等) 。コミュニティの事前調査(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はまだ研究段階です。バークルツリーやダンクシャーディングなどの他の大きなアップグレードが完了してから、数年後になるかもしれません。