Quorum Store： Aptos Blockchainでコンセンサスを水平方向にスケールさせる方法
Aptos By Brian Cho and Alexander Spiegelman
Aptosの各コンテンツや、学習材料へはこちらからアクセスできます！
Aptos Labsは、Narwhaの最初のデプロイメント実装であるQuorum Storeを発表することに興奮しています。Quorum Storeは、リーダーのボトルネックを取り除くことによって、コンセンサスのスループットを大幅に向上させます。コンセンサスプロトコルの一部として大きなデータチャンクをブロードキャストするために単一のリーダーに依存する代わりに、Quorum Storeはデータの普及をメタデータの順序付けから切り離し、バリデータが並行して非同期にデータを普及させることができるようにします。
ブロックチェーンコンセンサスにおけるボトルネック
現在展開されているブロックチェーンの多くは、リーダーベースのコンセンサスを実装しています。これらのプロトコルでは、リーダーが進行を推進し、コンセンサス提案の一部としてユーザートランザクションを普及させる責任を負うものです。その結果として、リーダーのリソースは常に過剰に使用され、残りのバリデーターはほとんどアイドル状態となります。つまり、システム全体のスループットは、リーダーがデータをブロードキャストする能力によって決定されることになります。リーダーを交代させても、ボトルネックをあるリーダーから次のリーダーに移すだけなので、この問題は解決しません。
Narwhal ： データ配信をコンセンサスから切り離す
Narwhalで最初に観測されたように、データ配信はコンセンサスロジックから切り離すことができ、また切り離すべきものです。Narwhalの重要なアイデアは、バリデーターがトランザクションのバッチを継続的に互いに並行してストリームできることにあります。そして、リーダーがコンセンサスでブロックを提案する際に、そのブロックに含めるべき（以前に共有された）バッチのセットを指定します。これによって、リーダーは各ブロックのトランザクションをリストアップして送信する必要がなく、代わりにバッチ識別子（メタデータ）を指定するだけでよいので、ブロック提案ごとに共有する必要があるデータ量が削減される仕組みです。
1人のバリデータが1秒間にT個のトランザクションをブロードキャストできるとする。しかし、クォーラムストアでは、n人のバリデータが1秒間にnT個のトランザクションをブロードキャストできるため、コンセンサススループットの上限はそれに応じて増加します。
以前と同様に、コンセンサスロジックはトランザクションの総順序を提供する責任があります。しかし、Quorum Storeでは、リーダーはプロポーザルにメタデータのみを含みます。このメタデータは、コンセンサスで順序付けられ、実行前に対応するトランザクションバッチにマッピングされます。その結果として、高負荷のコンセンサスレイテンシーとスループットは劇的に改善されます。さらに、コンセンサスプロトコルのメッセージの複雑さは、全体的なパフォーマンスにとってあまり重要ではなくなります。このように、低レイテンシと低通信コストのトレードオフにおいて、Jolteonが使用され、Hotstuffのレイテンシは33%改善されました。
可用性の証明による有効性の確保
データの普及をメタデータの順序付けから切り離す際の微妙な点は、すべてのバリデータが実行に必要なトランザクションを持っていることを保証することです。例えば、悪意のあるバリデータがある人にはデータを送信し、他の人には送信しない場合、そのデータに対応するメタデータがコンセンサスによって順序付けられた場合、すべての正直なバリデータがデータを取得できなければなりません。
このため、Quorum Storeは可用性の証明を提供し、その証明の背後にあるデータが、そこで指定された有効期限までシステムで利用可能であることを保証します。
アーキテクチャの概要
バリデータパイプラインアーキテクチャの概要は以下の4つのコンポーネントで形成されます：
- Mempoolは、潜在的なユーザートランザクションの集合を保持する役割を担う
- Quorum Storeのコア機能は、Mempoolからトランザクションのバッチを取り出し、ブロードキャストし、その可用性の証明を形成すること
- Consensusは、Quorum Storeからプルーフを取り出し、順序付けし、Executionにプッシュする
- 実行は、Quorum Storeを使ってプルーフをトランザクションバッチにマッピングし、実行する
プロダクションレディ
この実装は、30カ国以上の100人のバリデータにわたる分散型ネットワーク環境でテストされ、低レイテンシー、高スループット、健全なガス市場手数料を確認するためにネットワークにストレスを与えました。合意形成のみのテスト（実行なし）とエンドツーエンド処理で、それぞれ12倍と3倍のTPS向上が達成しています。これらのエンドツーエンドの結果を検証する方法の詳細については、再現可能なパフォーマンスベンチマークテストをご確認ください。
興味深いことに、Quorum Storeがラウンドトリップを追加したにもかかわらず、高負荷時にはエンドツーエンドのレイテンシが向上しています。これは、リーダーのボトルネックを取り除くことで、コンセンサスのレイテンシが劇的に短縮されるためです。
コンセンサスのスケールアウト
Quorum Storeの大きな利点の1つは、水平方向のスケーラビリティを可能にすることです。データ発信はもともと並列化可能であり、つまりハードウェアを増やせば直線的にスケールする。コンセンサスをスケールアウトするには、Quorum Storeを実行するマシンを増やすだけでいいのです。現在、各バリデータは1台のマシンで動作しています。その代わり、各バリデータは複数のマシンを動かすことができます。1台は証明の順序を決めるコンセンサスを実行し、残りの1台はQuorum Storeを並列に実行します。Narwhalの図7で、600k TPSに達するマシン数の線形スケーラビリティの実験を見てください。
プロトコルと実装
ここで、プロトコルと実用的な配慮をいくつか紹介します。読みやすくするために、最適化や実装の詳細については省略します。一言で言えば、可用性の証明を形成するために、すべてのバリデーターは以下のことを並行して繰り返します：
- mempoolからトランザクションを引き出す
- トランザクションをガスに基づいてバッチに整理し、各バッチの有効期限を選択
- トランザクションのバッチを他のすべてのバリデーターにブロードキャストする
- 受信バッチを持続させ、そのダイジェストに署名し、署名を返送する
- 署名の定足数を集め、利用可能性の証明を形成する
図3：Proof of Availabilityプロトコル
署名
バリデータはバッチに署名するとき、指定された有効期限までバッチを持続させること、および他のバリデータからバッチが見つからないという要求に応えることを約束します。
証明の保証
バッチの可用性証明は、ステークに重み付けされた2f+1個の署名の定足数となります。有効な証明は、少なくともstake-weighted f+1の正直な検証者が署名を提供したことを保証するものです。つまり、少なくともステークに重きを置いたf+1人の正直な検証者が、 バッチの有効期限までそのバッチを存続させることを意味します。したがって、証明は、データが欠落しているバリデータが他の正直なバリデータからデータを取得できるような形で、期限切れでないバッチがシステム内で利用可能であることを保証します。
データのフェッチ
コンセンサスによって順序付けされた後、プルーフが実行にプッシュされます。この時点で、実行側はQuorum Storeにプルーフを対応するトランザクションにマッピングするよう依頼します。一般的なケースでは、正直なバッチ作成者はそれを全員にブロードキャストするので、Quorum Storeはローカルにトランザクションを保存します。しかし、最悪の場合、Quorum Storeはリモートバリデータからトランザクションを取得する必要があります。可用性の証明は、十分な数のリモートバリデータがデータを保存することを保証しますが、素朴に行うとレイテンシーが増大する可能性があります。このため、証明を含むConsensusブロックが最初に見られると同時に、リモートデータを事前にフェッチする最適化を実装している。こうすることで、ブロックが注文される頃には、Quorum Storeはすでにトランザクションをローカルに保存しています。
ロードバランシング
Quorum Storeは完全に負荷分散されています。すべてのバリデータはバッチをブロードキャストし、証明を並列に集約するため、リソースの使用率はバリデータ間で等しくなり、ネットワーク速度でデータを拡散することができます。すべてのバリデータはすべてのバッチを取得しなければ実行できないので、上記の「素朴な」フェッチメカニズムが最適であることに注意してください。データの配布とフェッチ/再構築に使用される消去コードなどの他の暗号ツールは、複雑さを増すだけで、負荷分散という点では何のメリットもありません。
バックプレッシャー
Quorum Storeのおかげで、コンセンサスはパイプラインアーキテクチャの中で最も性能の高いコンポーネントとなりました。コンセンサスが他のコンポーネントを圧倒しないように、各バリデータはTCPのような古典的な輻輳制御システムと同様に、バックログに基づいてローカルバッチの作成レートを調整します。さらに、コンセンサスは、異なるバリデータが作成したバッチ間の公平性を適用し、バリデータが公平にブロック空間を共有することを保証します。
メモリキャッシュ
ハードディスクなどの永続的なストレージからバッチを読み込むのは、コストがかかる場合があります。そこで、並列メモリキャッシュを実装し、Quorum Storeから並列にデータを読み込むことができるようにしました。このキャッシュには、Quorum Storeがストレージに保持するバッチのサブセットが含まれています。
クォータ
DDoS攻撃を防ぐために、メモリ内キャッシュとストレージの両方にクォータを課す。バリデータvからのバッチに署名して永続化する前に、バリデータはvのメモリとストレージの残高をチェックします。両方のバランスに問題がない場合、バッチはストレージに永続化され、キャッシュに保存されます。そうでない場合は、ストレージのバランス次第で、永続化されたり無視される可能性があります。
ガベージコレクション
正直なバリデーターが割り当てを超えないようにするため、期限切れのバッチをガベージコレクションします。有効性を保証するためには、注文されたバッチbごとに、正直な検証者が（1）bのトランザクションを取得して実行するか、（2）bを含む状態に同期することができることが必要となります。この目的のために、期限切れバッチはコミットされたブロックのタイムスタンプに基づきクリーニングされます。バリデータは、過半数のバリデータがそのブロックを実行したことを示すQuorum証明書を取得すると、そのブロックをコミットします。このQuorum証明書は、ステートシンクの際にバリデータにそのステートが有効であることを確信させるために使用されます。したがって、正直なバリデータ全員がバッチをガーベッジコレクションしたためにバリデータがバッチを取得できなかった場合でも、十分な数の正直なバリデータがバッチを実行し、対応するステートシンクのQuorum証明書を取得していることが保証されます。
