Firedancerとは？Solana 2.0の徹底解説

この記事で解説すること

Solanaは最速のブロックチェーンです。しかし、さらに高速化できます。現在のSolana Labsバリデータクライアントは優れていますが、市場投入までのスピードを重視して最適化されています。Jumpは、これまでに得られた知見、ゼロから設計できる環境、数十年にわたる高性能コンピューティングの経験を活かし、Solanaをさらに高速で信頼性の高いものにしようとしています。高頻度取引で培った経験を応用し、JumpはFiredancerを開発しています。これは、あらゆるブロックチェーンの中で最も高性能なバリデータクライアントです。Solanaの現行バリデータクライアントをCプログラミング言語で全面的に書き直すものです。

この記事では、バリデータとバリデータクライアントの多様性が重要である理由を解説します。次に、Jumpが新しいバリデータクライアントを構築する理由と、高頻度取引の経験を持つ同社がFiredancerの開発に最適なチームである理由を説明します。その後、Firedancerとは何か、どのように動作するのか、なぜ高速なのか、どのように保護されているのか、そして現在の状況を解説します。

この記事を読み終える頃には、Jumpの新しいバリデータクライアントを深く理解できるようになります。画期的な最適化によって、あらゆるブロックチェーンの中で最も高性能なバリデータクライアントとなる理由も把握できます。また、FiredancerがSolanaネットワークの性能と信頼性に不可欠である理由も理解できます。Firedancerについて学ぶために必要な記事は、これだけです。

付録には、コンピュータハードウェアとネットワークの完全に任意の入門解説があります。一般の読者が、この記事で扱うより高度なハードウェアとネットワークの概念を理解するために必要な背景知識を提供する目的で追加しました。ただし、必要な箇所では本文中でも背景を説明します。この記事は、Solanaを利用する誰もがFiredancerとその重要性を理解できるよう、読みやすさを重視しています。

バリデータとバリデータクライアントの多様性とは？

バリデータとは、Proof of Stakeブロックチェーンに参加するコンピュータです。バリデータはSolanaネットワークの基盤を形成します。トランザクションの処理とコンセンサスへの参加を担います。バリデータは、Solanaのネイティブトークンを一定量ステークとしてロックすることで、ネットワークの安全性確保に貢献します。これは、バリデータがネットワークに対して金銭的な責任を負う保証金のようなものです。貢献に応じて報酬を得られるため、この責任がバリデータにタスクを正確かつ効率的に遂行する動機を与えます。悪意のある行為や不具合のある動作をしたバリデータには、ペナルティも科されます。不適切な行動をすると、スラッシングと呼ばれるプロセスによってバリデータのステークが減額されます。したがって、バリデータにとって、責務を適切に遂行してステークを増やすことが最善の選択です。

バリデータクライアントは、バリデータが責務を果たすために使用するアプリケーションです。クライアントはバリデータの基盤となり、暗号学的に一意なIDを使用してコンセンサスに参加します。

互いに異なる複数のクライアントが存在すると、いずれかの実装で障害が発生した場合の耐障害性が向上します。たとえば、どのクライアントもステークの33%を超えていなければ、クラッシュやライブネスに影響するバグが発生しても、ネットワーク全体が停止することはありません。同様に、無効な状態遷移を引き起こすバグがクライアントに存在しても、そのクライアントを利用するステークが33%未満であれば、ネットワークは安全性の障害を回避できます。ネットワークの大部分が有効な状態を維持し、ブロックチェーンの分裂やフォークを防げるためです。したがって、1つのクライアントにバグや脆弱性があってもネットワーク全体が機能不全に陥らないため、バリデータクライアントの多様性はネットワークの回復力を高めます。

クライアントの多様性は、各クライアントで稼働するステークの割合と、利用可能なクライアントの総数で評価されます。この記事の執筆時点では、Solanaネットワーク上に1979のバリデータがあります。これらのバリデータがメインネットで使用する2つのクライアントは、Solana LabsとJito Labsが提供しています。Solanaは2020年3月に、Solana Labsが開発した1つのバリデータクライアントとともにローンチしました。2022年8月には、Jito Labsが2つ目のバリデータクライアントをリリースしました。このクライアントは、Jitoが保守、デプロイするSolana Labsコードのフォークです。このクライアントは、ブロック内のMEV（最大抽出可能価値）の抽出を最適化します。Solanaはmempoolを使用せずにブロックをストリーミングするため、Jitoのクライアントは疑似mempoolを作成します。なお、mempool（メモリプール）とは、保留中で未確認のトランザクションが蓄積されたものです。疑似mempoolにより、バリデータはこれらのトランザクションを検索し、最適な形でまとめてJitoのBlock Engineに送信できます。

2023年10月時点で、Solana Labsクライアントはアクティブステークの68.55%、Jitoは31.45%を占めています。Jitoのクライアントを使用するバリデータの数は、Solana Foundationの前回の健全性レポートから16%増加しています。Jitoクライアントの利用拡大は、クライアント多様化に向けた好ましい傾向を示しています。

この成長は喜ばしいものですが、完璧ではありません。JitoのクライアントはSolana Labsクライアントのフォークである点を強調しておく必要があります。つまり、Jitoは元のバリデータコードベースと多くのコンポーネントを共有しており、Labsクライアントに影響するバグやエクスプロイトの影響を受ける可能性があります。理想的な将来像では、Solanaに少なくとも4つの独立したバリデータクライアントが存在します。異なるチームが、異なるプログラミング言語でこれらのクライアントを構築します。各クライアントが~25%のステークを保持し、単一の実装が33%を超えることはありません。この理想的な構成では、バリデータスタック全体から単一障害点がなくなります。

この未来を実現するには、2つ目の独立したバリデータクライアントの開発が不可欠です。Jumpはその実現に注力しています。

Jumpが新しいバリデータクライアントを構築する理由

Solanaのメインネットでは、過去に4回ブロック生成が停止しました。そのたびに、数百のバリデータによる手動修正が必要でした。これらの停止により、Solanaネットワークの信頼性に対する懸念が注目されるようになりました。Jumpは、プロトコル自体は健全だと主張しています。一方で、ダウンタイムの原因はコンセンサスに影響するソフトウェアモジュールの問題にあると考えています。そこでJumpは、これらの問題に対処するため、新しいバリデータクライアントを開発しています。このクライアントの総合的な目標は、Solanaネットワークの安定性と効率を高めることです。

独立したバリデータクライアントの開発は困難な作業です。しかし、Jumpが信頼性の高いグローバルネットワークを構築するのは、これが初めてではありません。かつて証券取引（株式の売買など）は、マーケットスペシャリストが手作業で執行していました。電子取引プラットフォームの登場により、証券取引所はより開かれたものになりました。この開放性によって競争と自動化が進み、投資家の取引にかかる時間とコストが削減されました。その結果、マーケットスペシャリスト間で技術開発競争が始まりました。

トレーダーは取引のために生きています。最適な取引体験を実現するには、ソフトウェア、ハードウェア、ネットワークのソリューションに一切の妥協が許されません。これらのシステムには、高度なマシンインテリジェンス、低いリアルタイムレイテンシ、高いスループット、高い適応性、高いスケーラビリティ、高い信頼性、そして高い説明責任が必要です。

コモディティ化されたソリューション（企業がそのまま購入できるソフトウェアなど）は、競争優位にはなりません。正しい注文を取引所へ10回送っても、毎回2番手では、損失を出すために高いコストを払うようなものです。高頻度取引における激しい競争は、最高水準のグローバル取引インフラを構築し続ける終わりのない開発サイクルにつながります。

この状況に心当たりがあるかもしれません。成功する取引システムに求められる要件は、成功するブロックチェーンの要件に似ています。ブロックチェーンには、高性能、耐障害性、低レイテンシのネットワークが必要です。遅いブロックチェーンは、現代のエンタープライズアプリケーションの要求を満たせない失敗した技術です。イノベーション、スケーラビリティ、現実世界での有用性を妨げるだけです。グローバルネットワークの拡張と高性能システムの開発に20年以上携わってきたJumpは、独立したバリデータクライアントを構築するのに最適なチームです。このプロセスは、Jump Tradingの最高科学責任者であるKevin Bowersが監督しています。

なぜ光速でも遅すぎるのか？

Kevin Bowersは、光速ですら遅すぎるという問題について詳しく語っています。光速は有限の定数であり、単一のトランジスタが処理できる計算量に自然な上限をもたらします。現在、ビットはトランジスタ内を移動する電子によって表現されています。シャノンの通信路容量定理（通信路を介して送信できる誤りのないデータ量の上限）は、トランジスタを通過できるビット数を制限します。基礎物理学と情報理論により、計算速度は電子が物質内を移動する速さと、送信できるデータ量によって制限されます。こうした制約は、スーパーコンピュータを限界まで稼働させると明確になります。その結果、「コンピュータの数値計算能力と、数値を移動させる能力の間には劇的な不均衡」が生じています。

Intel Core i9 13900K CPUを例に考えてみます。このCPUには24個のx86コアがあり、ベースクロックは2.2 GHz、最大ターボクロックは5.8 GHzです。最悪の場合、光はこのCPU上を合計~52.0 mm移動する必要があります。CPUのマンハッタン距離（直角に交わる軸に沿って測定した2点間の距離）は~73.6 mmです。CPUの最大ターボクロックである5.8 GHzでは、光は空気中を~51.7 mm移動できます。つまり、1クロックサイクルの間に、信号はCPU上の任意の2点間をほぼ1往復できます。

実際の状況は、これよりはるかに深刻です。これらの測定では空気中を進む光速を使用していますが、信号は二酸化ケイ素（SiO2）内を移動します。5.8 GHzのクロックサイクルでは、光が二酸化ケイ素内を移動できる距離は~26.2 mmです。シリコン（Si）内では、5.8 GHzのクロックサイクルで~15.0 mmしか移動できません。これはCPUの長辺の半分をわずかに超える程度です。

Firedancerチームは、近年のコンピューティングにおける技術進歩は、CPUコアを高速化することではなく、より多くのコアをCPUに詰め込むことに重点を置いてきたと指摘しています。より高い性能が必要になると、ハードウェアを追加購入することが推奨されてきました。スループットがボトルネックである間は、当面この方法で対応できます。しかし、実際のボトルネックは光速です。この自然法則による制約が、意思決定を停滞させます。システムには多くのコンポーネントがあり、どれも十分に最適化されていないため、1つの最適化だけではすぐに効果が現れません。最適化されなかった部分は、利用できる計算資源が減るため、時間とともに悪化します。では、どうすればよいのでしょうか？

高性能コンピューティングの世界では、最終的にすべてを最適化する必要があります。その結果、地球規模で物理学と情報理論の限界に迫って稼働する、本番取引と定量分析向けのシステムが構築されます。これには、独自のネットワークスイッチング技術から、こうした物理的限界を考慮して設計されたロックフリーアルゴリズムまでが含まれます。Jumpは、取引会社であると同時にテクノロジー企業でもあります。サイエンスフィクションと現実の境界で、JumpとSolanaが現在直面する問題には驚くほどの共通点があります。そこでJumpはFiredancerを開発しています。

Firedancerとは？

Firedancerは、FiredancerチームがCプログラミング言語で開発する、完全に独立した新しいバリデータクライアントです。モジュール型アーキテクチャ、最小限の依存関係、広範なテストプロセスにより、信頼性を重視して構築されています。Solana Labsクライアントの3つの機能コンポーネント、ネットワーク、ランタイム、コンセンサスを大幅に書き直すものです。各レベルは最大限の性能を発揮するよう最適化されるため、クライアントの処理能力を制限するのはバリデータのハードウェアだけになります。これは、ソフトウェアの非効率性によってバリデータが現在直面している性能上の制限とは異なります。Firedancerにより、Solanaは帯域幅とハードウェアに応じてスケールします。

Firedancerの目標は次のとおりです。

• Solanaプロトコルを文書化して標準化する（最終的には、Rustのバリデータコードではなくドキュメントを見るだけで、誰でもSolanaバリデータを作成できるようにする）
• バリデータクライアントの多様性を高める
• エコシステムの性能を向上させる

Firedancerの仕組み

モジュール型アーキテクチャ

Firedancerは、独自のモジュール型アーキテクチャによって、現在のSolanaバリデータクライアントと一線を画しています。単一のプロセスとして動作するSolana LabsのRustバリデータクライアントとは異なり、Firedancerはtileと呼ばれる多数の個別Linux Cプロセスで構成されています。tileは、1つのプロセスと一定のメモリからなります。このtileアーキテクチャは、Firedancerの運用思想と、堅牢性および効率性へのアプローチの基盤です。

プロセスとは、実行中のプログラムのインスタンスです。現代のオペレーティングシステムを構成する基本要素であり、一連の命令の実行を表します。各プロセスには、オペレーティングシステムによって割り当てられた独自のメモリ空間とリソースがあり、ほかのプロセスから独立して動作します。プロセスは、大規模な工場で独自の道具と作業場所を使い、特定のタスクを担当する独立した作業員のようなものです。

Firedancerでは、各tileが明確な役割を持つ個別のプロセスです。たとえば、QUIC tileは受信したQUICトラフィックを処理し、カプセル化されたトランザクションをverify tileに転送します。verify tileは署名検証を担当し、ほかのtileも同様にそれぞれの役割を担います。これらのtileは独立かつ並行して動作し、システム全体の機能を支えます。個別のLinuxプロセスにより、障害領域を小さく独立させられます。つまり、1つのtileで発生した問題がシステム全体に与える影響、すなわち「爆発半径」を最小限に抑えられます。このアプローチは、単一障害点によってバリデータ全体が即座に危険にさらされる可能性のあるSolana LabsのRustクライアントとは異なります。

Firedancerのアーキテクチャが持つ重要な利点は、ダウンタイムなしで各tileを数秒以内に交換、アップグレードできることです。アップグレード前に完全なシャットダウンが必要なSolana LabsのRustクライアントとは、対照的です。この違いは、RustにABI（Application Binary Interface）の安定性がないことに起因します。そのため、純粋なRust環境では稼働中のアップグレードができません。Cランタイムモデルのバイナリ安定性を活用できるCプロセスを使用することで、アップグレードに伴うダウンタイムを大幅に削減できます。これが可能なのは、tileが異なるワークスペースでバリデータの状態を管理するためです。これらの共有メモリオブジェクトは、バリデータの電源が入っている限り保持されます。各tileは、再起動やアップグレードの際に、中断した箇所からシームレスに処理を再開できます。

全体として、FiredancerはNUMAを考慮したtileベースのアーキテクチャに基づいて構築されています。その意味は次のセクションで説明します。現時点では、スレッドごとに専用のハードウェアリソースが提供されるということです。このアーキテクチャでは、tileごとに1つのCPUコアを使用します。tile間では高性能なメッセージパッシングを実現し、メモリ局所性、リソース配置、コンポーネントのレイテンシを最適化しています。

ネットワーク処理

Firedancerのネットワーク処理は、Solanaネットワークがギガビット毎秒規模に拡大した際の高負荷な要件に対応できるよう設計されています。この処理は、受信と送信のアクティビティに分かれています。

受信アクティビティは、主にユーザーからトランザクションを受け取る処理です。バリデータのパケット処理が遅れるとコンセンサスメッセージが失われる可能性があるため、Firedancerの性能は不可欠です。現在、Solanaノードの運用帯域幅は~0.2 Gbpsですが、Jumpノードで記録された最大のスパイクは~40 GBpsでした。この帯域幅の急増は、堅牢でスケーラブルな受信処理ソリューションの必要性を示しています。

送信アクティビティには、ブロックのパッキング、ブロックの作成、shredの送信が含まれます。いずれの手順も、Solanaネットワークを安全かつ効率的に運用するうえで重要です。これらのタスクの性能は、スループットだけでなく、ネットワーク全体の信頼性にも影響します。

Firedancerは、トランザクションを処理するSolanaのピアツーピアインターフェースが過去に抱えていた弱点への対処を目指しています。過去のSolanaピアツーピアインターフェースには、受信トランザクションに対する輻輳制御が欠けているという大きな問題がありました。この問題は、2021年9月14日（17時間）と2022年4月30日（7時間）の大規模なネットワーク停止につながりました。

これを受け、Solanaは大量のトランザクションを適切に処理するため、複数のネットワークアップグレードを実施しました。Firedancerも同様に、フロー制御にQUICを採用しています。QUICは、HTTP/3の基盤となる多重化トランスポートネットワークプロトコルです。DDoS対策とネットワークトラフィックの管理に重要な役割を果たします。ただし、場合によってはコストがメリットを上回る点に注意が必要です。QUICをデータセンターのDDoS攻撃軽減用専用ハードウェアと組み合わせることで、トランザクションを大量送信する動機を排除できます。

151ページに及ぶQUICの仕様は、開発に相当な複雑さをもたらしました。ライセンス、性能、信頼性の要件を満たす既存のCライブラリが見つからなかったため、Firedancerチームは独自の実装を構築しました。fd_quicという愛称を持つFiredancerのQUIC実装は、メモリ割り当てを最小限に抑え、メモリ枯渇を防ぐために最適化されたデータ構造とアルゴリズムを導入しています。

Firedancer独自のネットワークスタックは、その処理能力の中核です。このスタックは、receive-side scaling（RSS）を活用するため、ゼロから設計されました。RSSは、ネットワークトラフィックを複数のCPUコアに分散し、ネットワーク処理の並列性を高める、ハードウェアアクセラレーション型のネットワーク負荷分散です。各CPUコアは、最小限のオーバーヘッドで受信トラフィックの一部を処理します。このアプローチでは、複雑なスケジューラ、ロック、アトミック操作が不要になるため、従来のソフトウェアベースの負荷分散を上回る性能を発揮します。

Firedancerは、高性能なtileでアプリケーションを構成するための新しいメッセージパッシングフレームワークを導入しています。これらのtileは、AF_XDPを利用することで、ソケットベースであるため制約のあるカーネルネットワーク処理を迂回できます。AF_XDPは、高性能なパケット処理向けに最適化されたアドレスファミリです。AF_XDPを使用すると、Firedancerはネットワークインターフェースのバッファから直接読み取れます。

このtileシステムにより、Firedancerスタックでさまざまな高性能コンピューティングの概念を利用できます。これには以下が含まれます。

• NUMA対応 - NUMA（Non-Uniform Memory Access）は、プロセッサが別のプロセッサに関連付けられたメモリよりも、自身のメモリへ高速にアクセスできるコンピュータメモリ設計です。FiredancerがNUMAに対応しているということは、マルチプロセッサ構成でメモリを効率的に処理できることを意味します。利用可能なハードウェアリソースを最適に活用できるため、大量のトランザクション処理において重要です。
• キャッシュ局所性 - キャッシュ局所性とは、プロセッサの近くにあるキャッシュ内のデータを利用することです。一般的には、時間的局所性（最近アクセスされたデータ）の複雑な形態です。Firedancerはキャッシュ局所性を重視しているため、レイテンシを最小限に抑え、速度を最大化しながらネットワークデータを処理するよう設計されています。
• ロックレス並行処理 - ロックレス並行処理とは、同時操作を管理するためのロック機構（mutexなど）を必要としないアルゴリズムを設計することです。Firedancerでは、ロックレス並行処理により、ロックによる遅延を発生させずに複数のネットワーク操作を並列実行できます。これにより、多数のトランザクションを同時に処理するFiredancerの能力が向上します。
• 大きなページサイズ - メモリ管理で大きなページサイズを使用すると、ページテーブルの参照と潜在的なメモリ断片化を減らし、データセットを効率的に処理できます。Firedancerでは、これによりメモリ処理の効率が向上します。大量のネットワークデータを処理する際に有効です。

ビルドシステム

Firedancerのビルドシステムは、信頼性と一貫性を保証するための一連の基本原則に基づいて設計されています。外部依存関係を最小限に抑え、ビルドプロセスに関わるすべてのツール自体も依存関係として扱うことを重視しています。これには、コンパイラを含むすべての依存関係を厳密なバージョンに固定することも含まれます。このシステムで重要なのは、ビルド手順における環境の分離です。ビルドプロセスがシステム環境の影響を受けないため、環境を分離することで移植性が向上します。

Firedancerはなぜこれほど高速なのか？

高度なデータ並列処理

Firedancerは、ED25519署名検証などの暗号処理に、最新プロセッサ内部で利用可能な高度なデータ並列処理を採用しています。最新のCPUには、複数のデータ要素を同時に処理するための単一命令・複数データ（SIMD）命令と、CPUサイクルごとに複数の命令を実行するための最適化が備わっています。通常、1つの命令でデータ要素の配列やベクトルを並列処理するほうが、面積、時間、消費電力の面で効率的です。この点では、単純な処理速度の向上よりも、並列データ処理の改善のほうがスループットに大きく寄与します。

Firedancerがデータ並列処理を活用する領域の1つが、署名検証計算の最適化です。このアプローチでは、データ要素の配列やベクトルを同時に処理することで、スループットを最大化し、レイテンシを最小化できます。このED25519実装の中核にあるのが、ガロア体の算術演算です。この演算体系は、暗号アルゴリズムやバイナリ計算に適しています。ガロア体では、加算、減算、乗算、除算などの演算が、コンピューターシステムのバイナリ特性に合うように定義されています。以下は、23で定義されるガロア体の例です。

唯一の問題は、ED25519が2255-19で定義されるガロア体を使用することです。体の要素は、0から2255-19までの数値と考えてください。基本演算は次のようになります。

• x + y → 2255-19を法とする筆算の加算
• x - y → 2255-19を法とする筆算の減算
• x * y → 2255-19を法とする筆算の乗算
• 1/x → 2255-19を法とするxの2255-21乗

加算、減算、乗算は、ほぼuint256_t演算です（つまり、最大値が2256-1となる符号なし整数の演算です）。除算の計算は困難です。一般的なCPUやGPUはuint256_t演算に対応しておらず、「ほぼuint256_t演算」はもちろん、極めて難しい特殊な除算にはなおさら対応していません。この種の演算を実装して高いパフォーマンスを実現できるかどうかは、どれだけうまくエミュレートできるかにかかっています。

Firedancerの実装では、数値をより柔軟に捉えて算術演算を分解します。各桁から次の桁へ繰り上げる、筆算の長除法と乗算の原理を適用すれば、これらの桁を並列処理できます。この種の演算をエミュレートする最速の方法は、uint256_tを6個の43ビット桁と9ビットの「繰り上がり」で表現することです。これにより、CPUの既存の64ビット演算を利用しながら、繰り上がりビットに十分な領域を確保できます。この数値配置により、頻繁な繰り上がり伝播の必要性が減り、Firedancerは大きな数値をより効率的に処理できます。

この実装は、算術計算を並列化された桁ごとの合計へ再構成することで、データ並列処理を活用しています。桁を並列処理すると、逐次処理のボトルネックになるはずだったタスクを並列化できるため、計算全体が高速化します。Firedancerは、AVX512や、そのIFMA拡張（AVX512-IFMA）などのベクトル化命令セットも使用します。これらの命令セットにより、前述したガロア体の算術演算を処理でき、速度と効率が向上します。

AVX512で高速化されたFiredancerの実装は、非常に高速です。単一の2.3 GHz Icelakeサーバーコア上で、コアクロック当たりのパフォーマンスは、2022年のBreakpointデモの2倍を超えています。この実装は、ベクトルレーン使用率100%と大規模なデータ並列化を実現しています。これはFiredancerチームによるもう1つの卓越した実証です。光速による遅延があるため、カスタムハードウェアを投入したとしても、1つずつ処理するより、独立した処理を並列に実行するほうがはるかに簡単です。

FPGAを活用した高速ネットワーク通信

CPUは、1コア当たり毎秒約~30,000件の署名検証を処理できます。エネルギー効率には優れていますが、大規模な処理には不十分です。この制約は、逐次処理方式に起因します。GPUでは、この処理能力が1コア当たり毎秒約~100万件の検証まで向上します。しかし、1基当たり約~300Wという大きな消費電力と、バッチ処理に伴う固有のレイテンシが足かせになります。

FPGAは、より優れた選択肢です。GPUと同等のスループットを実現しながら、消費電力はFPGA 1基当たり約50Wと大幅に抑えられます。レイテンシも、GPUの10ミリ秒を下回ります。FPGAは約~200マイクロ秒のレイテンシで、リアルタイム処理に対してはるかに応答性の高いソリューションを提供します。GPUのバッチ処理とは異なり、FiredancerのFPGAは各トランザクションをストリーミング方式で個別に処理します。FiredancerはFPGAを活用することで、8基のFPGAを400W未満の電力枠で動作させ、毎秒800万件という圧倒的な署名スループットを実現しています。

チームは、Breakpoint 2022でFiredancerのED25519署名検証プロセスを披露しました。このプロセスには、純粋なRTLパイプラインでのSHA-512計算や、カスタムECC-CPUプロセッサパイプラインでの各種チェックと計算など、複数のステージが含まれていました。基本的にFiredancerチームは、カスタムプロセッサ向けのコンパイラとアセンブラを作成し、RFC（Request for Comments）からPythonコードを取得して、演算子をオーバーロードしたオブジェクトで実行してマシンコードを生成し、そのマシンコードをECC-CPU上に配置しました。

Firedancerが、堅牢性とネットワーク接続性のバランスを取るために、AWSアクセラレータ形式のフォームファクターを採用している点は重要です。この選択は、クラウドプロバイダーによって制限されることが多い、ネットワークへの直接接続に伴う課題に対処します。これによりFiredancerは、クラウドベースのインフラストラクチャの制約内で、高度な機能をシームレスに統合できます。

各種の処理には、概念上のデータ空間だけでなく、実体のある物理空間が必要であることを認識する必要があります。Firedancerはこの点を踏まえ、物理コンポーネントを近接させ、再利用できるよう戦略的に配置しています。この構成により、FiredancerはFPGAの効率を最大化し、8年前のマシンに搭載された7年前のFPGAで800万TPSを達成しています。

ネットワーク通信向けReed-Solomon符号化の最適化

ネットワーク通信における根本的な課題は、新しいトランザクションを世界中にブロードキャストすることです。インターネットのポイントツーポイントという性質、帯域幅の有限性、レイテンシの問題により、ネットワークを直接ブロードキャストに使うといった従来の考え方の実装には限界があります。リング構造やツリー構造でデータを配信すれば、これらの問題を部分的に解決できますが、送信中にデータパケットが失われる可能性があるため、十分ではありません。

Reed-Solomon符号は、これらの問題に対する洗練されたソリューションです。データ送信に冗長性（パリティ情報）を導入し、失われたパケットを復元します。この概念は、2点によって直線が定まり、その直線上の任意の2点から元のデータ点を再生成できるという原理に基づいています。データ点に基づいて多項式を構築し、その関数上の異なる点を別々のパケットで配信すれば、受信側が少なくとも2つのパケットを受信する限り、元のデータを再構築できます。

多項式を構築するのは、直線上の点を表す従来の式（y = mx + b）では計算が遅いためです。Firedancerは、多項式を構築するための特殊な手法であるラグランジュ多項式を使用して高速化しています。これにより、Reed-Solomon符号化に必要な多項式の作成プロセスが簡素化されます。また、このプロセスは、高次多項式にも対応する、より効率的な行列とベクトルの積に変換されます。この行列は高度に構造化され、パターンが再帰的に繰り返されるため、その最初の行だけでパターン全体が決まります。この構造により、すべてをより高速に乗算できます。Firedancerは、この行列との乗算に2016年の論文で発表されたO(n log n)アプローチを使用しています。これは、Reed-Solomon符号化について理論上知られている最速のアプローチです。その結果、従来の手法と比べてパリティ情報を効率的に計算できます。

• RSエンコードは1コア当たり~120 Gbps超
• RSデコードは1コア当たり最大~50 Gbps
• これらの指標はすべて、現在のRSエンコード（rust-rse）の1コア当たり~8 Gbpsとの比較です

Firedancerは、この最適化されたReed-Solomon符号化アプローチを使用して、従来の手法より14倍高速にパリティを計算できます。これにより、高速で信頼性の高いデータのエンコードおよびデコード処理が実現します。これは、グローバル規模で高スループットと低レイテンシを維持するために不可欠です。

Firedancerのセキュリティはどのように確保されているのか？

機会

現在、すべてのバリデータは元のバリデータクライアントをベースにしたソフトウェアを使用しています。FiredancerがSolana Labsクライアントと明確に異なるものであれば、Solanaのクライアントとサプライチェーンの多様性を高められます。これには、類似した依存関係の使用や、クライアント開発へのRustの使用も含まれます。

Solana LabsとJitoのバリデータクライアントは、単一プロセスとして動作します。モノリシックなアプリケーションが本番環境で稼働した後にセキュリティを追加するのは困難です。これらのクライアントを実行するバリデータは、純粋なRustで動的なセキュリティアップグレードを行う場合、停止する必要があります。Firedancerチームは、新しいクライアントの開発当初から安全なアーキテクチャを構築できます。

Firedancerには、経験から学べるという利点もあります。Solana Labsは、スタートアップ環境でバリデータクライアントを開発しました。この速いペースの環境では、市場へ迅速に投入するため、Labsは開発を急ぐ必要がありました。その結果、将来の開発には不利な基盤となりました。Firedancerチームは、Labsや他のチェーンのチームが行ったことを振り返り、バリデータクライアントをゼロから開発できるなら何を変えるかを検討できます。

課題

FiredancerはSolana Labsクライアントとは異なりますが、その動作を忠実に再現する必要があります。再現できなければ、互換性の問題によってコンセンサスバグが生じる可能性があり、セキュリティ上の懸念となります。このリスクは、一定割合のステークが両方のクライアントで稼働するようインセンティブを設定し、長期間にわたってFiredancerを総ステークの33%未満に保つことで軽減できます。いずれにせよFiredancerチームは、正確かつ安全に実装することがどれほど難しくても、プロトコルの全機能を実装する必要があります。すべてをFiredancerと整合させなければなりません。そのため、チームはコードを切り離して開発することはできず、Labsクライアントの機能と照合してレビューする必要があります。仕様とドキュメントの不足がこの問題をさらに悪化させており、Firedancerはプロトコル由来の非効率な構造も導入しなければなりません。

Firedancerチームは、新しいクライアントをCで開発していることにも注意する必要があります。Cには、Rustなどの言語がネイティブに提供するメモリ安全性の保証がありません。Firedancerコードベースの主な目標は、メモリ安全性の脆弱性の発生件数と影響を減らすことです。Firedancerは開発ペースの速いプロジェクトであるため、この目標には特に注意を払う必要があります。Firedancerは、この種のバグを持ち込まずに開発速度を維持する方法を見つけなければなりません。OSサンドボックス化とは、タイルをOSから分離する手法です。タイルは、その役割に必要なリソースへのアクセスとシステムコールの実行のみを許可されます。各タイルの目的は明確に定義されており、クライアントコードの大部分をFiredancerチームが開発しているため、タイルの権限は最小権限の原則に従って必要最小限に削減されます。

多層防御を考慮した設計の実装

あらゆるソフトウェアには、いずれセキュリティ上の脆弱性が生じます。Firedancerは、ソフトウェアにはバグが存在するという前提から逆算し、1つの脆弱性が及ぼし得る影響を制限します。このアプローチは多層防御と呼ばれます。多層防御とは、さまざまなセキュリティ対策を用いて資産を保護する戦略です。攻撃者がシステムの一部を侵害しても、脅威がスタック全体に影響するのを防ぐ追加対策が存在します。Firedancerは、脆弱性が悪用に至るまでの段階で攻撃を緩和するよう設計されています。たとえば、攻撃者がメモリ安全性の脆弱性を悪用するのは困難です。

これは、この種の攻撃の防止が十分に研究されている問題だからです。Cのメモリ安全性については広範な研究が行われており、チームはFiredancerで多数の堅牢化手法とコンパイラ機能を活用しています。攻撃者が業界のベストプラクティスを回避できたとしても、そのエクスプロイトでシステムを侵害するのは困難です。これは、タイルの分離とOSサンドボックス化によるものです。

タイルの分離は、Firedancerの並列アーキテクチャによって実現します。各タイルは独自のLinuxプロセスで動作するため、明確かつ単一の目的を持ちます。たとえば、QUICタイルは受信したQUICトラフィックを処理し、カプセル化されたトランザクションを検証タイルに転送します。次に、検証タイルが署名検証を担当します。QUICタイルと検証タイルの通信は、共有メモリインターフェースを通じて行われます（つまり、Linuxプロセス間でデータを受け渡せます）。2つのタイル間のこの共有メモリインターフェースが、分離境界として機能します。悪意のあるQUICパケットを処理した際に攻撃者が任意のコードを実行できるバグがQUICタイルにあったとしても、他のタイルには影響しません。モノリシックなプロセスであれば、即座に侵害されます。攻撃者が複数のバリデータでこの脆弱性を悪用すれば、ネットワーク全体に損害を与える可能性があります。攻撃者はQUICタイルのパフォーマンスを低下させられるかもしれませんが、Firedancerの設計により、影響はQUICタイルだけに限定されます。

OSサンドボックス化とは、タイルをOSから分離する手法です。タイルは、その役割に必要なリソースへのアクセスとシステムコールの実行のみを許可されます。各タイルの目的は明確に定義されており、ほぼすべてのコードをFiredancerチームが開発しているため、タイルの権限は最小権限の原則に従って必要最小限に削減されます。タイルはそれぞれ独自のLinux名前空間内に配置され、システムに対して限定的なビューのみが提供されます。この限定的なビューにより、タイルはファイルシステムの大部分、ネットワーク、および同じシステム上で実行される他のプロセスにアクセスできません。名前空間は、セキュリティを優先した境界を提供します。ただし、攻撃者が権限昇格用のカーネルエクスプロイトを持っている場合は、これも回避される可能性があります。システムコールインターフェースは、タイルから到達できるカーネル内の最後の攻撃経路です。これを防ぐため、Firedancerはseccomp-BPFを使用し、カーネルが処理する前にシステムコールをフィルタリングします。クライアントは、タイルが実行できるシステムコールを選択したグループに制限できます。場合によっては、システムコールのパラメータもフィルタリングできます。これは、読み書きのシステムコールが特定のファイルディスクリプタのみを操作するようFiredancerで保証できるため、重要です。

組み込み型セキュリティプログラムの実装

Firedancerは、開発のあらゆる段階に包括的なセキュリティプログラムを組み込んで設計されています。クライアントのセキュリティプログラムは、開発チームとセキュリティチームによる継続的な取り組みであり、安全なブロックチェーン技術の新たな基準を確立します。

このプロセスは、セルフサービスのファジングインフラストラクチャから始まります。補足すると、ファジングとは、脆弱性を示すクラッシュやエラー状態を自動的に検出する手法です。P2Pインターフェース（パーサー）やSBPF仮想マシンなど、信頼できないユーザー入力を受け付けるすべてのコンポーネントにストレステストを実施します。OSS-Fuzzは、コード変更の間も継続的にファジングのカバレッジを維持します。セキュリティチームは、カバレッジガイド付きファジングを継続的に実行するため、専用のClusterFuzzerインスタンスも構築しています。開発者とセキュリティエンジニアは、ファジングハーネス（つまり、セキュリティ上重要なコンポーネント向けの特殊な単体テスト）も提供します。開発者は新しいファジングテストを追加することもでき、それらは自動的に取得され、テストされます。すべての部分が次の段階に進む前に徹底的にファジングされることが目標です。

内部コードレビューは、ツールで検出できなかったバグの特定に役立ちます。この段階では、リスクと影響が大きいコンポーネントに重点を置きます。この段階は、セキュリティプログラム全体に知見を還元するフィードバック機構です。チームは得られた知見をすべて適用し、これらのレビューを活用して、ファジングのカバレッジの改善、特定のバグ分類に対する新たな静的解析チェックの導入、さらには複雑な攻撃経路を設計段階から排除するための大規模なコードリファクタリングを実施します。業界を代表する専門家による外部セキュリティレビューと、ローンチ前後の活発なバグ報奨金プログラムが、これらの内部レビューを補完します。

Firedancerは、さまざまなテストネットワークで広範なストレステストも受けています。これらのテストネットワークでは、ノードの重複、ネットワークリンクの障害、パケットフラッド、コンセンサス違反などの攻撃や障害が発生します。これらのネットワークには、メインネットで現実的に想定されるどのシナリオよりもはるかに高い負荷がかかります。

ここで、Firedancerの現在の状況はどうなっているのか、という疑問が生じます。

Firedancerの現在の状況とFrankendancerとは？

Firedancerチームは、バリデータクライアントをモジュール化するため、Firedancerを段階的に開発しています。これは、ドキュメント化と標準化という目標に沿ったものです。このアプローチにより、FiredancerはSolanaの最新開発に追随できます。そして、Frankendancerが誕生しました。Frankendancerは、Firedancerチームが開発したコンポーネントを既存のバリデータクライアント基盤へ統合するハイブリッドクライアントモデルです。この開発プロセスにより、新機能を段階的に改善し、テストできます。

Frankendancerは、渋滞の中にスポーツカーを投入するようなものです。開発されるコンポーネントが増え、ボトルネックが解消されるにつれて、パフォーマンスは向上します。このモジュール式の開発プロセスにより、カスタマイズ可能で柔軟なバリデータ環境が実現します。開発者はニーズに合わせて、バリデータクライアントの特定のコンポーネントを変更または置換できます。

実際に何が動作しているのか？

Frankendancerは、Solanaバリデータのすべてのネットワーク機能を実装しています。

• 受信：QUIC、TPU、Sigverify、Dedup
• 送信：ブロックのパッキング、shredの作成／署名／送信（Turbine）

Frankendancerは、Solana LabsのRustランタイムとコンセンサスコードの上で、Firedancerの高性能なCネットワークコードを使用しています。

Frankendancerのアーキテクチャは、ハイエンドハードウェアでの最適化を重視して設計されています。標準的なLinuxオペレーティングシステムを実行するローエンドの一般的なクラウドホストにも対応していますが、FiredancerチームはFrankendancerをコア数の多いサーバー向けに最適化しています。長期的な目標は、クラウドですでに利用可能なハードウェアを活用して、効率とパフォーマンスを高めることです。このクライアントは、複数の同時接続、ハードウェアアクセラレーション、負荷分散のためのランダム化されたフローステアリング（つまり、ネットワークトラフィックを均等に分散させること）、およびコンポーネント間のセキュリティを強化する多数のプロセス境界に対応しています。

技術的な効率性は、Frankendancerの基盤です。このシステムはクリティカルパスでのメモリ割り当てとアトミック操作を回避し、すべての割り当ては初期化時にNUMA向けに最適化されます。この設計により、最大限の効率とパフォーマンスが確保されます。さらに、システムコンポーネントを非同期かつリモートで検査できる機能と、タイル管理（非同期での起動、停止、再起動）の柔軟性により、システムの堅牢性と適応性が高まります。

パフォーマンスはどの程度か？

Frankendancerは、ネットワーク受信側でタイル当たり毎秒1,000,000件のトランザクション（TPS）を処理できます。各タイルが1つのCPUコアを使用するため、このパフォーマンスは使用するコア数に比例してスケールします。Frankendancerはわずか4コアを使用してこの処理能力を達成し、25 Gbpsのネットワークインターフェースカード（NIC）の性能を限界まで引き出しました。

Frankendancerは、Turbineの最適化により、ネットワーク送信処理を大幅に改善しました。現在の標準的なノードハードウェアでは、タイル当たり6 Gbpsの速度を達成します。これには、shredding（つまり、ブロックデータを分割してネットワーク経由でバリデータに送信する方法）の大幅な高速化も含まれます。現在の標準的なSolanaノードと比較すると、Frankendancerのshredding速度は、Merkle treeなしで~22%向上し、Merkle treeありではほぼ2倍になります。これは、現在のバリデータによるブロック伝播とトランザクション取り込みのパフォーマンスを大幅に改善するものです。

Firedancerのネットワークパフォーマンスは、ハードウェアの限界に到達したことを示しています。現在の標準的なバリデータハードウェアで可能な最大のパフォーマンスを実現しています。これは重要な技術的マイルストーンであり、極端なワークロードを効率的かつ効果的に処理できるクライアントの能力を示しています。

Frankendancerはテストネットで稼働中

Frankendancerは現在、テストネットでステークされ、投票し、ブロックを生成しています。約~2900台のSolana LabsおよびJitoバリデータと互換性を保ちながら共存しています。この稼働環境へのデプロイは、一般的なハードウェア上でFiredancerが堅牢なパフォーマンスを発揮することを実証しています。現在は、AMD EPYC 7513 CPUを搭載したEquinix Metal m3.large.x86サーバー上で動作しています。ほかにも多くのバリデータが同じ種類のサーバーを使用しています。ロケーションによって変動するオンデマンド料金で、費用対効果の高いソリューションを提供します。料金は1時間当たり$3.10から$4.65です。

Firedancerのメインネットローンチに向けた進展により、ノードハードウェアには複数の可能性が生まれます。

• 現在のバリデータハードウェアでも、ノード当たりの処理能力を大幅に高められます
• Firedancerの効率性により、バリデータは同等のパフォーマンス水準を維持しながら、より安価で低スペックなハードウェアを使用できます
• Firedancerは、ハードウェアと帯域幅の進歩を活用できるよう設計されています

これらの開発に加え、Wiredancer（つまり、Firedancerチームによるハードウェアアクセラレーションの実験）やモジュール式のRustベースRuntime/SVMなどの取り組みにより、Firedancerは将来を見据えたソリューションとして位置付けられています。

Firedancerの進展により、side-caringと呼ばれるプロセスで、バリデータがSolana LabsクライアントとFiredancerを並行して実行する可能性についての議論も始まっています。このアプローチでは、両クライアントの強みを活用し、いずれかのクライアントで問題が発生した場合にネットワーク全体へ及ぶ潜在的な影響を軽減することで、ネットワークの活性を最大化できる可能性があります。さらに、JitoのようなプロジェクトがFiredancerのフォークを検討するかどうかという推測も生まれています。これにより、MEV抽出とトランザクション処理効率がさらに最適化される可能性があります。結果は時間が経てば明らかになるでしょう。

まとめ

開発者は通常、処理が物理的な空間ではなく、データ領域を占有するものとして捉えます。しかし、光速という自然の制約があるため、この前提ではハードウェアを適切に最適化できず、低速なシステムにつながります。極めて敵対的で競争の激しい環境において、Solanaにハードウェアを追加するだけで性能が向上すると期待すべきではありません。必要なのは最適化です。Firedancerは、バリデータクライアントの構造と運用方法を根本から変革します。Firedancerチームは、信頼性、モジュール性、性能に優れたバリデータクライアントを構築することで、Solanaの大規模普及に備えています。

初級開発者でも一般的なSolanaユーザーでも、Firedancerとその重要性を理解することは不可欠です。この技術的偉業により、現在市場で最速かつ最高性能を誇るブロックチェーンがさらに進化します。Solanaは、高スループットかつ低レイテンシのグローバルステートマシンとして設計されています。Firedancerは、これらの目標を完成させるための大きな一歩です。

ここまでお読みいただき、ありがとうございます、anon！以下にメールアドレスを入力すれば、Solanaの最新情報を見逃すことはありません。さらに深く学ぶ準備はできましたか？今すぐDiscordに参加し、最高性能のブロックチェーン上で未来を構築しましょう。

その他のリソースと参考資料

• Jumpのウェブサイト
• Firedancer GitHubリポジトリ
• Breakpoint 2023：Firedancer最新情報
• Breakpoint 2023：Firedancerのセキュリティ確保
• Breakpoint 2023：ネットワーク通信向け高速リード・ソロモン符号化
• Breakpoint 2023：800万TPSで動作するFPGA
• Firedancerのfd_quic技術マイルストーン
• Solanaネットワークのアップグレード

付録

コンピュータハードウェアとネットワークの概要

コンピュータは、算術演算や論理演算の一連の処理を自動的に実行するようプログラムできる機械です。これらの処理は、基本的な計算の自動化から複雑なデータ処理まで多岐にわたります。コンピュータは本質的に、ハードウェアとソフトウェアのコンポーネントを組み合わせて命令を実行し、データを管理します。ハードウェアは物理的なコンポーネントで構成され、ソフトウェアにはハードウェアの動作方法を指示するプログラムやオペレーティングシステムが含まれます。

有用な計算処理には通常、演算、メモリ、ディスクストレージ、ネットワークという4つのリソースが関係します。主にCPU、GPU、場合によってはFPGAが担う演算処理は極めて高速で、毎秒数十億回の処理を実行できます。RAMへのアクセスは一般に、CPU内で計算を実行するより低速です。ディスクストレージは、計算処理に利用できる長期保存手段を提供します。しかし、ソリッドステートドライブ（SSD）やハードディスクドライブ（HDD）からのデータアクセスは、CPUの処理よりはるかに低速です。SSDは数千倍、HDDは数万倍も遅いことがあります。さらに、インターネットやローカルネットワークを含むネットワークは最も低速です。CPUより100万倍以上遅くなる場合があります。

こうした速度差を理解することは、Firedancerのようなハイパフォーマンスコンピューティングアプリケーションの設計原則と効率上の考慮事項を把握するうえで重要です。CPUの計算速度を基準とすると、メモリ、ディスクストレージ、ネットワークへのアクセスは、この順に速度が低下し、それぞれ遅延を加えます。

中央処理装置（CPU）

CPU（中央処理装置）は、コンピュータの機能を支える中核であり、機械の頭脳です。CPUはソフトウェアの命令を実行し、計算を行い、受け取った入力に基づいて判断します。ゼロと1の並びであるバイナリ信号を処理することで動作します。固有のバイナリコード列はそれぞれ、CPUが解釈して実行する特定の命令に対応します。これらの命令は逐次処理され、CPUは1つの処理を完了してから次の処理に進みます。この命令の逐次処理はCPUの役割の根幹であり、複雑な計算を実行し、受け取った入力に基づいて判断する方法を決定します。

現代のCPUは、多くの場合マルチコアです。これは、コアと呼ばれる複数の処理ユニットが1つのチップに搭載されていることを意味します。各コアは独立して命令を実行できるため、タスクを並列処理できます。マルチコアアーキテクチャにより、CPUは複数の処理を同時に扱えるようになり、全体的な性能が大幅に向上します。ただし、各コア内では依然として処理が逐次実行される点に注意が必要です。そのためCPUは、複雑で逐次的なタスクには適していますが、より単純な並列タスクを大量に処理する場合には非効率です。

CPUにはキャッシュもあります。これはCPU内にある小容量の高速メモリユニットです。キャッシュは頻繁にアクセスされるデータや命令を保存し、RAMからデータを取得するよりも短時間で取り出せるようにします。通常、キャッシュには複数のレベル（L1、L2、L3、場合によってはL4）があり、それぞれ容量と速度が異なります。最小かつ最速のL1キャッシュが最初に参照されます。必要なデータが見つからなければ、CPUはより大容量でわずかに低速なL2キャッシュを確認し、以降も同様に処理します。この階層型キャッシュシステムは、CPUがRAMからのデータを待つ時間を短縮し、全体的な処理速度を向上させます。CPUからRAMまでの距離が性能を妨げる可能性があるFiredancerのようなアプリケーションでは、キャッシュの効率的な利用が極めて重要です。これは特に、光速とFPGAの利用に関する議論に関連します。

余談ですが、「x86」という用語は、当初Intelが開発した特定のアーキテクチャに従うCPUファミリーを指します。販売されているデスクトップおよびノートパソコンの大半がx86アーキテクチャファミリーを基盤としているため、このアーキテクチャは幅広いソフトウェアとの互換性で知られています。

グラフィックス処理装置（GPU）

GPUは、コンピュータグラフィックスの画像や映像のレンダリングを高速化するために開発された専用プロセッサです。主な役割は、グラフィックス性能の管理と向上です。特に、ビデオゲームや3Dモデリングなど、高解像度の映像や複雑なグラフィックス計算を必要とするタスクで活用されます。

GPUは時間とともに、本来の用途を超えて進化してきました。そのアーキテクチャにより、GPUはより幅広いデータ処理タスクに欠かせない存在となっています。効率的な並列処理能力を持つため、大規模なデータセットを同時に扱う必要があるアプリケーションに適しています。ブロックチェーン技術では、GPUは暗号資産のマイニングに広く使用されています。暗号計算の並列ワークロードをCPUより効率的に処理できるため、この用途で優れた性能を発揮します。

ランダムアクセスメモリ（RAM）

RAMはコンピュータの短期記憶であり、現在使用または処理されているデータを保存します。CPUはここで現在の作業内容を「記憶」し、関連情報を保持して迅速にアクセス、処理します。

誤り訂正符号（ECC）RAMには、一般的な内部データ破損を検出して訂正する機能があります。この機能は、科学計算、金融取引、ブロックチェーンノードなど、データの正確性が重要な環境に不可欠です。ECC RAMは、保存しているデータ内の軽微なエラーを自動的に特定して修正できます。この誤り訂正処理は、RAMモジュール内の追加ハードウェアが保存済みデータを検査することで実行されます。

非ECC RAMは、標準的なコンピュータや一般消費者向けデバイスでより広く使用されているメモリです。ECC RAMのような誤り訂正機能はありませんが、一般に高速で低価格です。標準的なデスクトップコンピューティングではデータエラーのリスクが比較的低く、コスト効率にも優れるため、一般用途では非ECC RAMが好まれます。

ディスクストレージ

ディスクストレージは、コンピュータの電源が切れている間もデータを長期間保持します。主なディスクストレージには、ハードディスクドライブ（HDD）とソリッドステートドライブ（SSD）の2種類があります。

HDDは、プラッタと呼ばれる磁気ディスクにデータを保存する旧来型のディスクドライブです。プラッタには磁気ヘッドが組み合わされ、通常は可動式のアクチュエータアームに取り付けられています。ディスクが回転する間、このアーム上の読み書きヘッドがデータにアクセスします。回転するディスクと可動ヘッドというHDDの機械的な構造により、SSDと比べて比較的低速です。一方で、より低価格で大容量のストレージを提供します。そのため、大量データの保存において高いコスト効率を発揮します。

一方、SSDはフラッシュメモリを使用してデータを保存します。フラッシュメモリは、消去と再プログラムが可能な電子式の不揮発性ストレージです。フラッシュメモリを使用するため、HDDとは異なり可動部品がありません。代わりに、相互接続されたフラッシュメモリチップがデータを保存します。SSDは、ディスクの回転や読み書きヘッドによるデータの探索を待たずに即座にアクセスできるため、HDDより高速です。この速度により、SSDは迅速なデータ取得が不可欠なアプリケーションに最適です。ただし、HDDと比べて1ギガバイトあたりのコストは高くなります。

NVMe（Non-Volatile Memory Express） SSDもあります。これらのSSDは、コンピュータのPeripheral Component Interconnect Express（PCIe）バスを介して、高速性能を最大限に引き出すよう設計されています。NVMeドライブは、従来のSSDより大幅に高速で、レイテンシも低くなります。高速なデータ処理と取得が不可欠な高頻度取引やブロックチェーンアプリケーションなど、負荷の高いワークロードに最適です。NVMeは高価ですが、ハイパフォーマンスコンピューティングの標準になりつつあります。

マザーボード

出典：r/buildapcのReddit投稿に掲載されたGigabyte X570 Eliteの図

コンピュータのマザーボードは、各部品を相互接続し、それらの間の通信を可能にする大型の回路基板です。これらの部品には、CPU、GPU、RAM、ストレージデバイス、キーボードやマウスなどの周辺機器が含まれます。

マザーボードは、あらゆる動作の中心となるハブです。各コンポーネントが互いに効率よく通信できるようにします。また、電力分配でも重要な役割を担い、電源ユニットから主要な各部品へ電力を供給します。マザーボードは、各コンポーネントが動作に必要な適切な電力を受け取れるようにします。

マザーボードは、システム内のデータフローの管理を担います。処理のためにCPUからRAMへ、保存のためにRAMからストレージデバイスへ、映像のレンダリングのためにGPUからディスプレイ出力へとデータを転送する経路を管理します。さらに、マザーボードにはシステムのBIOS（Basic Input/Output System）も搭載されています。BIOSはシステムの制御と監視に不可欠です。起動時にコンピュータのハードウェアを初期化してテストします。また、温度、電圧、ファン速度などの要素を監視し、システムの状態を常に確認します。

Firedancerの設計において、マザーボードのアーキテクチャは極めて重要な役割を果たします。CPUとRAMの距離は性能に大きく影響し、両者の距離が短いほどデータ転送速度が向上します。この距離は、高スループットと低レイテンシを必要とするFiredancerのようなアプリケーションにとって重要です。そのため、NUMAを考慮したアーキテクチャとFPGAの利用可能性は、メモリ割り当てと処理効率を最適化するというFiredancerの要件に合致します。NUMAを考慮することの意味とFPGAについては、この記事の後半で説明します。

オペレーティングシステム、仮想マシン、カーネルレベルの最適化

オペレーティングシステム（OS）は、コンピュータ内のハードウェアとソフトウェアを管理する中核ソフトウェアです。ユーザーとコンピュータのハードウェアとのやり取りを仲介します。ユーザーがシステムを操作するためのインターフェースを提供し、さまざまなアプリケーションにリソースを割り当てて管理します。代表例にはWindows、macOS、Linuxがあります。

カーネルは、あらゆるオペレーティングシステムの中核にあります。システムのハードウェアと直接やり取りする重要なコンポーネントです。カーネルはシステム内のすべてを完全に制御します。メモリ割り当て、プロセスのスケジューリング、入出力リクエストを管理します。この低いレベルで動作することで、カーネルはシステムの性能と安定性に極めて重要な役割を果たします。

システムコール（syscall）は、ユーザーアプリケーションとカーネルをつなぐインターフェースです。アプリケーションがシステムリソースへのアクセスを必要とする処理（ファイルの読み取りやネットワークデータの送信など）を実行する場合、syscallを呼び出します。その後、カーネルがアプリケーションに代わって要求された処理を実行します。この仕組みにより、システムリソースへのアクセスが制御され、システムのセキュリティと安定性が維持されます。

仮想マシン（VM）は、物理コンピュータをソフトウェアでエミュレートしたものです。ハイパーバイザー（ホストマシン上で仮想環境を作成、管理するソフトウェアの一種）上で動作しながら、隔離された環境内で物理コンピュータの全機能を再現します。VMには、隔離によるセキュリティ、リソース効率、テストや開発における柔軟性という利点があります。

Firedancerを理解するうえで、これらの概念を把握することは重要です。Firedancerは、性能向上のために複数のカーネルレベル最適化を採用しています。

• 大規模な静的割り当て： Firedancerは、大規模な静的割り当て（他のプロセスと共有できる共有メモリ割り当て）を使用して、動的メモリ割り当てを最小限に抑えます。ここでは、メモリを一度割り当てて再利用することで、頻繁な割り当てと解放に伴うオーバーヘッドを削減します。
• 標準ライブラリの迂回： 標準ライブラリ関数は抽象化レイヤーを追加することが多く、特定の処理では効率が低下する場合があります。Firedancerはこれらの標準ライブラリを迂回し、syscallを直接実行します。Firedancerのタイルアーキテクチャと、それがネットワーク性能を最適化する仕組みを説明する際に、さらに詳しく取り上げます。

Firedancerは、これらの処理によってタスクが大幅に遅くなるため、可能な限りsyscallとOSとのやり取りを避けます。

イングレスとイーグレス

イングレスとイーグレスは、コンピュータシステムやネットワークに出入りするデータフローを表す用語です。

イングレスとは、システムへのデータの流入を指します。これは、インターネットからのデータ受信、ユーザー入力の受け付け、IoT（モノのインターネット）デバイスのセンサーからの情報収集など、さまざまな活動を含む一般的な用語です。サーバーやブロックチェーンなどのネットワークシステムでは、イングレスには、処理または保存が必要なトランザクションリクエスト、ユーザークエリ、受信データストリームなどを受け取る重要なタスクが含まれます。イングレスデータの効率的な処理は、システムの応答性と機能に不可欠です。

イーグレスとは、システムから外部へ送られるデータを指します。これには、オンラインでの情報送信、ユーザーリクエストへの応答生成、処理済みデータの他システムへの送信が含まれます。ネットワーク化されたシステムでは、イーグレスには、検証済みトランザクションの送信、ブロックチェーン更新情報のブロードキャスト、外部ストレージへのデータ送信などがあります。情報を正しく配信し、システムがネットワークの他の部分と効率的に通信できるようにするには、イーグレスデータを適切に管理することが不可欠です。

パイプラインとデータ並列性

パイプラインを工場の組立ラインとして想像してください。複雑なプロセスを、より小さな連続するステージに分割します。パイプラインの各ステージは、特定の処理を実行します。この手法は、ブロックチェーンが継続的にトランザクションを処理するのと同様に、反復的または連続的な処理タスクで高い効率を発揮します。

データ並列性では、複数の要素を独立させながら同時に処理するという別の手法を取ります。工場にデータを処理する組立ラインが複数あるようなものです。これは、より小さなサブタスクに分割できるタスクに効果的です。ブロックチェーン、特にFiredancerのようなシステムでは、トランザクションやデータ処理タスクを同時に扱うためにデータ並列性が不可欠です。Firedancerの並列処理能力は、計算スループットを最大化し、処理時間を短縮します。

パイプラインの各ステージを、工場内の個別の作業ステーションとして想像してください。各作業ステーションは、独立かつ同時に稼働できます。つまり、あるステージがデータの一部を処理している間に、次のステージは別の部分を同時に処理できます。この手法では複数のパイプラインステージを同時に稼働できるため、スループットが大幅に向上します。Firedancerは、パイプライン処理の逐次的な効率性と並列処理の同時実行能力を組み合わせ、大量のトランザクションを処理します。

フィールドプログラマブルゲートアレイ（FPGA）

フィールドプログラマブルゲートアレイ（FPGA）は、製造後にプログラムまたは再構成できる汎用性の高い集積回路です。これらの回路は、従来のハードウェアコンポーネントにはない適応性を備えています。相互接続された多数のプログラム可能な論理ブロックで構成され、それぞれがさまざまなデジタル機能を実行できます。この設計により、速度、並列処理、適応性が最重要となるアプリケーションで、FPGAは高い柔軟性と効率性を発揮します。

一般的なFPGAは、プログラム可能な配線ですべて接続された小さなプログラム可能要素で構成されています。この複雑な部品と接続のネットワークにより、ユーザーはチップ内の異なる領域をプログラムして特定のタスクを実行できます。これにより、完全にカスタマイズされた処理環境が構築されます。

FPGAは、これらの小さなプログラム可能要素を同時に利用することで、並列処理で優れた性能を発揮します。その構造は、処理ステージへデータを継続的に供給する効率的なパイプライン処理を可能にします。適切に設計されたパイプラインは、システムのスループットをレイテンシから切り離します。このパイプラインは従来のCPUよりも出力に時間がかかる場合がありますが、システムは複数の入力データストリームを同時に処理できます。各処理のレイテンシがデータフロー全体に与える影響はわずかで、ホース内を流れる水に似ています。

Firedancerにおいて、FPGAは大きな利点をもたらします。データパイプラインをネットワークへ直接接続できます。GPUがデータ移動をCPUに依存する従来の構成と比べて、FPGAはネットワークトラフィックをより効率的に処理できます。直接接続と、FPGAファブリック上へのソフトプロセッサの構築など、カスタム処理ソリューションを作成できる能力により、高性能なバリデータクライアントの開発に欠かせない存在となっています。

‍