Firedancerは稼働していますが、Solanaはイーサリアムが譲れないと考える唯一の安全規則に違反しています

3年間の開発を経て、Firedancerは2024年12月にソラナメインネットで稼働を開始しました。すでに少数のバリデーターで100日間のテストを行い、50,000ブロックを生成しています。

ソラナの公式アカウントが12月12日に発表したこのマイルストーンは、単なるパフォーマンスアップグレード以上のものです。これは、ネットワークに最も深刻な障害をもたらしてきた構造的なボトルネック、つまり単一のバリデータークライアントへの依存をなくす最初の本格的な試みを表しています。

ソラナは長年、1秒未満のファイナリティと1秒あたり4桁のトランザクション処理能力をアピールしてきましたが、ネットワークのコンセンサスパワーの70%から90%が同じソフトウェアを実行している状況では、速度はほとんど意味をなしません。

支配的なクライアントに重大なバグがあると、理論上どれだけ速く動作するとしても、チェーン全体が停止する可能性があります。イーサリアムはプルーフ・オブ・ステークへの移行の初期段階でこの教訓を学び、現在ではクライアントの多様性を譲れないインフラ衛生の要素として扱っています。

ソラナも同様の転換を試みていますが、はるかに集中した状態からスタートしています。

FiredancerはRustベースのAgaveクライアントのパッチやフォークではありません。Jump Cryptoによって構築されたC/C++での完全な書き直しであり、モジュール式の高頻度取引にインスパイアされたアーキテクチャを採用しています。

2つのクライアントはコード、言語、メンテナンスチームを共有していません。この独立性が明確な障害ドメインを作り出します：理論上、AgaveのメモリーマネジメントやトランザクションスケジューラーのバグがFiredancerを実行しているバリデーターをダウンさせることはありません。

5年間で7回の障害を経験し、そのうち5回がクライアント側のバグによるものだったネットワークにとって、この分離こそが重要なポイントです。

ソラナが逃れられなかった単一文化の問題

ソラナの障害履歴は、単一クライアントリスクの事例研究として読み取れます。2022年6月の停止は、耐久性のあるノンストランザクション機能のバグによってバリデーターが同期を失い、協調的な再起動が必要となり、4時間半続きました。

他のインシデントは、メモリリーク、過剰な重複トランザクション、ブロック生成における競合状態に起因していました。Heliusによる完全な障害履歴の分析によると、7回の障害のうち5回はコンセンサス設計の欠陥ではなく、バリデーターまたはクライアントのバグによるものでした。

単一の実装エラーがブロック生成を凍結させる可能性がある場合、ネットワークがアピールするスループットは無関係になります。

数字がこのリスクを裏付けています。ソラナ財団の2025年6月のネットワーク健全性レポートによると、AgaveとそのJito修正バリアントがステーキングされたSOLの約92%を支配していました。

2025年10月までに、この数字は低下しました。しかし、わずかな変化にとどまり、Cherry Serversのステーキング概要と複数のバリデーターガイドによると、ハイブリッドのFrankendancerクライアントがネットワークの約21%に成長する中でも、Jito-Agaveクライアントは依然として70%以上のステークを保持していました。

FrankendancerはFiredancerのネットワーキングレイヤーとAgaveのコンセンサスバックエンドを使用しています。

依然としてマイノリティではあるものの、Cherry Serversのデータによると、Frankendancerのシェアは6月の約8%から成長しました。これらの増加は部分的な解決策の着実な採用を示していますが、12月にメインネットに到着する完全なFiredancerクライアントが状況を変えます。

バリデーターは現在、完全に独立したスタックを実行でき、過去のクライアントバグをネットワーク全体のイベントに変えた共有依存関係を排除できます。

イーサリアムの経験が参考モデルを提供しています。

イーサリアム財団のクライアント多様性に関するドキュメントでは、コンセンサスパワーの3分の2以上を支配するクライアントが一方的に不正なブロックを確定できると警告しています。さらに、3分の1以上のクライアントがオフラインになったり予測不能な動作をしたりすると、完全にファイナリティを妨げる可能性があります。

イーサリアムのコミュニティは、すべてのクライアントを33%未満に保つことを最適化ではなく、厳格な安全要件として扱っています。90%近い参加率を持つ単一クライアントというソラナの出発点は、この安全ゾーンからはるかに外れています。

クライアント	言語	ステータス	ステークシェア（2025年10月）	バリデーター	真の独立性
Jito	Rust	メインネット	~72%	~700+	Agaveのフォーク
Frankendancer	C + Rust	メインネット	~21%	207	ハイブリッド独立
Agave	Rust	メインネット	~7%	~85	オリジナル
Firedancer	C	非投票メインネット	0%	0	完全独立

Firedancerが実際に変えること

Firedancerは低レイテンシー取引システムから借用したアーキテクチャでソラナのバリデーターパイプラインを再実装しています：並列処理タイル、カスタムネットワーキングプリミティブ、負荷下での決定論的パフォーマンスに調整されたメモリ管理などです。

技術会議のプレゼンテーションからのベンチマークでは、制御されたテストで1秒あたり60万から100万以上のトランザクションを処理するクライアントが示されており、これはAgaveの実証されたスループットをはるかに上回っています。

しかし、パフォーマンスの上限よりも障害ドメインの分離の方が重要です。Firedancerのドキュメントとバリデーターセットアップガイドでは、クライアントは設計上モジュール式であり、ネットワーキング、コンセンサス参加、トランザクション実行を処理する個別のコンポーネントを持つと説明されています。

AgaveのRustアロケーターのメモリ破損バグはFiredancerのC++コードベースに伝播しません。Agaveのブロックスケジューラーのロジックエラーは、Firedancerのタイルベースの実行モデルに影響しません。

2つのクライアントは独立して障害を起こす可能性があり、これはステーク分布が同時に大多数がオフラインになることを防ぐ限り、ネットワークはどちらか一方の壊滅的なバグを生き延びることができることを意味します。

ハイブリッドのFrankendancerデプロイメントは段階的なロールアウトとして機能しました。オペレーターはAgaveのコンセンサスと実行レイヤーを維持しながら、Agaveのネットワーキングとブロック生成コンポーネントをFiredancerの同等物に置き換えました。

このアプローチにより、バリデーターは未テストのコンセンサスコードでネットワーク全体をリスクにさらすことなく、Firedancerのパフォーマンス向上を採用することができました。

10月までにFrankendancerが獲得した21%のステークはハイブリッドモデルを検証しましたが、その限界も浮き彫りにしました：すべてのバリデーターがコンセンサスのためにAgaveに依存している限り、その共有レイヤーのバグがチェーンを停止させる可能性はまだありました。

12月のフルクライアントのメインネット起動は、この共有依存関係を取り除きます。

100日間Firedancerを実行し、50,000ブロックを生成した少数のバリデーターは、クライアントがAgaveコンポーネントに依存することなくコンセンサスに参加し、有効なブロックを生成し、状態を維持できることを実証しました。

本番環境での実績は限られており、数ノードで100日間ですが、より広範な採用への道を開くには十分です。バリデーターは現在、本物の代替手段を持ち、ネットワークの回復力は移行を選択する数に直接比例します。

なぜ機関投資家はバリデーターソフトウェアを気にするのか

クライアントの多様性と機関投資家の採用の間のつながりは推測ではありません。

LevexのFiredancer解説では、クライアントが「ソラナの信頼性とスケーラビリティについて機関投資家が提起した主要な懸念に対応している」と主張し、マルチクライアントの冗長性が「企業がクリティカルなアプリケーションに必要とする堅牢性を提供する」と述べています。

9月のバイナンスSquareのソラナの機関投資家向け準備状況に関するエッセイでは、過去の障害を企業の関与への主要な障壁として位置づけ、Firedancerを「潜在的な治療法」として位置づけています。

この分析では、信頼性がソラナとイーサリアムおよび他のレイヤー1ネットワークとの競争における「主要な差別化要因」であり、単一クライアントリスクを排除することで「ソラナの最大の弱点」をなくし、ネットワークレベルのダウンタイムを許容できない機関へのアピールを強化できると主張しています。

この論理はイーサリアムのクライアント多様性キャンペーンで確立されたフレームワークを反映しています。

ブロックチェーンインフラを評価する機関リスクチームは、何かが壊れたときに何が起こるかを知りたいと考えています。

バリデーターの90%が同じクライアントを実行するネットワークは、トークン分布やバリデーターセットがどれだけ分散化されているように見えても、単一障害点を持っています。

クライアントがステークの33%以上を支配していないネットワークでは、壊滅的なバグによって1つのクライアント全体が失われても運用を継続できます。この違いは、特定のチェーン上で規制された製品を構築するかどうかを決定するリスクマネージャーにとって二元的です。

ソラナの約7億6700万ドルのトークン化された現実資産は、規模での採用ではなく、足がかりを表しています。rwa.xyzのデータによると、イーサリアムは125億ドルのトークン化された国債、ステーブルコイン、トークン化されたファンドをホストしています。

このギャップは、ネットワーク効果や開発者のマインドシェアだけでなく、稼働時間への信頼も反映しています。

Firedancerのメインネット到着により、ソラナはイーサリアムのコミュニティが本番インフラの前提条件として扱うのと同じクライアント多様性のしきい値を満たすことで、そのギャップを埋める道筋を得ました。

今後の採用曲線

Agaveの70%支配からバランスの取れたマルチクライアントネットワークへの移行は急速には起こりません。バリデーターは切り替えコストに直面しています：Firedancerは、Agaveとは異なるハードウェアチューニング、異なる運用手順書、異なるパフォーマンス特性を必要とします。

クライアントの100日間の本番実績は成功していますが、Agaveの数年間のメインネット運用と比較すると浅いものです。リスク回避的なオペレーターはステークを移行する前により多くのデータを待つでしょう。

それにもかかわらず、インセンティブ構造は現在、多様化を支持しています。ソラナ財団のバリデーター健全性レポートは公にクライアント分布を追跡し、大規模オペレーターが単一の実装に集中したポジションを避けるよう評判圧力を生み出しています。

ネットワークの障害の歴史は、そのデメリットの生々しい思い出を提供します。そして、ETF投機、RWA発行、企業の支払いパイロットを含む機関採用のナラティブは、ソラナがその信頼性問題を超えて進んだことを実証することに依存しています。

アーキテクチャは現在整っています。ソラナには、異なる言語、独立したコードベース、別々の障害モードを持つ2つの本番クライアントがあります。ネットワークの回復力は、単一文化から始まり、単一のクライアントがチェーンをオフラインにできない分布へとステークがどれだけ迅速に移行するかにかかっています。

ソラナが本番インフラとして機能し、協調的な再起動なしに次のクライアントバグを乗り切る現実的な道筋があるかどうかを評価する機関にとって重要です。

記事「Firedancerは稼働中だが、ソラナはイーサリアムが譲れないと考える安全規則に違反している」はCryptoSlateで最初に公開されました。