Breakpoint で待望の Firedancer を理解するための 1 つの記事

特邀专栏作者

2024-09-24 11:00

この記事は約1693文字で、全文を読むには約3分かかります

Solana バリデータクライアント Firedancer はどのように動作しますか?どのように機能するのでしょうか?

原作者：かれん、フォーサイトニュース

先週開催されたソラナブレイクポイントカンファレンスでは、雰囲気は活気に満ち、環境に配慮した製品が次々とリリースされ、さまざまなカラフルな周辺アクティビティが華を添えました。この祝賀会で特に目を引くのは、Solana バリデータクライアント Firedancer の初期バージョンがメインネットワークに正式に導入されたことであり、このマイルストーンの成果は特別な注目を集め、Solana ネットワークが達成するであろうパフォーマンスを示すものでした。 Solana 上の単一クライアントのクラッシュによって引き起こされるネットワークダウンタイムのリスクを回避しながら、飛躍します。

Firedancer の開発プロセスは 2021 年から 2022 年まで遡ることができます。Jump Trading Group によって開発された Solana の 2 番目のバリデータークライアント (元のクライアント Agave は Anza によって開発されました) として、その元の設計は、単一ポイントの隠れた危険性を排除することです。ネットワーク全体の堅牢性と回復力を強化します。オリジナルの Rust ベースのバリデータとは異なり、Firedancer は C 言語で書かれており、Rust コードが含まれていません。この選択により、ネットワーク全体に対する潜在的な脆弱性の影響が大幅に軽減され、Solana のセキュリティにもう 1 つの強固な防御線が追加されます。

ファイアダンサーのパフォーマンスはどうですか?

Solana Breakpoint カンファレンスでの Jump Crypto 最高科学責任者の Kevin Bowers 氏のデモンストレーションによると、Firedancer は 1 秒あたり 100 万件を超えるトランザクションを処理する能力を実証しました。これは、Solana の現在の理論上の制限である数万 TPS をはるかに超える数です。 Kevin Bowers 氏はまた、この成果を「田舎道」を「州間高速道路」に拡張することに例え、ネットワークのコストと容量の二重の最適化を予告しました。

Jump Trading のコアエンジニアである Liam Heeger 氏は、クライアントが 20,000 ブロックを超えるブロックを生成し、1% のプレッジ率を達成したことについて、Firedancer の進捗状況を共有しました。

別のエンジニア Aryaman Jain によるデモンストレーションでは、特定の条件下での Firedancer のパフォーマンスがさらに明らかになりました。たとえば、10 個のバリデーター環境では、その TPS は 100 万レベルに達し、コンピューティングユニットを 1 秒あたり 12 億回以上処理し、3.5 Gbps のブロックスペース機能と VM の実行を実証しました。 500,000 TPSの効率。

ファイアダンサーはどのように機能しますか?

Firedancer は、ハイパフォーマンスコンピューティングスタックとネットワークスタック、ランタイム、コンセンサスメカニズムという 3 つの主要コンポーネントを中心に構築されています。 Solana ネットワークのパフォーマンスを 100 万 TPS まで向上させる Firedancer の能力の鍵は、その革新的なアーキテクチャ設計とデータフローの最適化にあります (現在のプロトコルレベルの制限により、パフォーマンスは約 81,000 TPS に制限されています)。

バリデーターは、少数のスレッドを通じて多様なタスクを実行する同時実行モデルを採用しており、各スレッドはネットワークパケット処理、トランザクション検証、ブロックパッケージ化などの特定のタスクに重点を置いています。この設計により、リソースの使用率が最大化され、トランザクション処理速度が大幅に向上します。

具体的には、各スレッドは 11 の異なるジョブの 1 つを実行します。ジョブによっては、完了するのに 1 つのスレッドだけが必要な場合もありますが、同じ作業を並行して実行するために多くのスレッドが必要な場合もあります。さらに、各スレッドには実行する CPU コアがあり、スレッドはそのコアの所有権を取得します。スレッドがスリープしたり、オペレーティングシステムが他の目的でそのコアを使用したりすることはできません。

Firedancer では、「タイル」と呼ばれるアーキテクチャも導入されています。各タイルはジョブとその実行中のスレッド、および割り当てられた CPU コアを表します。この組み合わせにより、パフォーマンスのチューニングが柔軟かつ効率的になります。たとえば、net および quic はタイルあたり 100 万を超える TPS を処理できますが、verify および Bank タイルはトランザクションの検証とブロックの実行に重点を置いていますが、処理速度は比較的遅いですが、高同時実行シナリオのニーズを満たすには十分です。

Firedancer の公式ドキュメントには、次の 11 種類のタイルがリストされています。

net: ネットワークデバイスからネットワークパケットを送受信します (タイルあたり 100 万 TPS を超える処理が可能)。
quic: クライアントからトランザクションを受信し、すべての接続管理とパケット処理を実行して、QUIC プロトコルを管理および強制します (タイルあたり 100 万を超える TPS を処理できます)。
verify: 受信トランザクションの暗号化された署名を検証し、無効なトランザクションをフィルタリングします (各タイルは 200,000 ～ 40,000 TPS を処理できます)。
dedup: 重複した受信トランザクションをチェックして除外します。
パック: リーダーになると、受信トランザクションをパックし、その実行をインテリジェントにスケジュールします。
銀行: 取り決められたトランザクションを実行します (各タイルは 200,000 ～ 40,000 TPS を処理できます)。
poh: はバックグラウンドでハッシュ演算を継続的に実行し、生成されたハッシュ値と実行されたトランザクションを混合することで順序とタイミングを証明するメカニズムです。
シュレッド: リーダーになると、ブロックデータをネットワークに配布します。リーダーでない場合は、ブロックデータを受信して再送信します (スループットは主にクラスターサイズに依存します。ベンチマークテストでは、クラスターサイズが小さい場合、1 タイルで処理できます) 100万TPS）;
ストア: リーダーになった場合はブロックデータを受信し、他のノードがリーダーになった場合は他のノードからブロックデータを受信し、ローカルディスク上のデータベースに保存します。
メトリック: 他のタイルに関する監視情報を収集し、それを HTTP エンドポイントに提供します。
署名: 検証者の秘密鍵を保持し、他のタイルからの署名要求を受信して応答します。

Firedancer が成熟する前に、その移行バージョン Frankendancer が最初に Solana メインネットに参入したことは注目に値します。 Frankendancer は Firedancer と Agave の一部をハイブリッドしたもので、Agave の実行機能とコンセンサス機能を保持しながら、ネットワークスタックとブロック生成における Firedancer の強みを組み合わせています。 Firedancer は完全にゼロから構築されており、Agave コードは含まれていません。