## 5年間の設計ミスに気づくまでの誤り2024年12月、Solanaは重要な転換点を発表した:クライアントバリデーターFiredancerが100日間の試験を経てメインネットで稼働を開始し、その間にいくつかのバリデーターが50,000ブロックを処理した。しかし、この出来事は単なるパフォーマンスの向上だけではない—それは、Solanaが実際に過去5年間に最も深刻な5つの障害を引き起こした構造的問題を解決した最初の例でもある。根本的な問題は非常に単純だ:ネットワーク上のバリデーターのほぼ90%が同じソフトウェア—クライアントAgave—を実行していることだ。ブロックチェーンの合意力の70-90%が単一のコードベース上で動作している場合、そのクライアントにおけるいかなるバグも局所的な問題ではなく、ネットワーク全体の問題となる。確認時間が1秒未満や毎秒何千もの取引を処理できる能力は、ソフトウェアのバグによってチェーン全体が凍結する可能性があるときには意味をなさなくなる。EthereumはProof-of-Stakeに移行した早期からこの教訓を理解していた:多様なクライアントは最適化ではなく、堅牢な安全性のための厳格な要件だ。Solanaも追いつこうとしているが、出発点ははるかに集中化された状態から始まっている。## 技術選択の失敗により苦しむネットワークSolanaの停止履歴は、一連の待合室の災害のコレクションだ。2022年6月の停止は、durable-nonce機能のバグによりバリデーターの同期が失われ、4.5時間続いた。その後もメモリリーク、過剰なトランザクションの重複、ブロック生成のレース条件などの問題が続いた。Heliusによる停止履歴の分析は、次の指標を示している:7回の失敗のうち5回は、合意メカニズムの設計ミスではなく、バリデーターやクライアントのバグによるものだ。言い換えれば、Solanaはコアメカニズムの欠陥ではなく、その実行ソフトウェアにバグがあったために停止したのだ。現在の集中度の高さは、これをさらに危険にしている。2025年6月のSolana Foundationのネットワークヘルスレポートによると、Agaveとその変種Jito-modifiedは、ステークされたSOLの92%を制御している。2025年10月にはこの数字はわずかに減少しただけだ。Cherry Serversによると、Jito-Agaveクライアントは依然として70%以上のステークを握っており、Frankendancerと呼ばれるハイブリッドクライアントも登場している—Firedancerのネットワーク層を利用しつつ、Agaveの合意層を維持しているもので、約21%を占める。最初のFiredancerクライアントは、まだ投票権のないメインネットの状態にあるため、ステークは持っていない。70%のステークが単一のコードベースに依存していることは、Agaveのバグがネットワークを麻痺させる可能性があることを意味している。## Firedancer:ゼロからのアーキテクチャ、パッチではないFiredancerはAgaveのアップデートやフォークではない。これはC/C++で完全に書き直されたもので、Jump Cryptoによって構築され、高頻度取引システムから借用したアーキテクチャを採用している。これらのクライアントはソースコード、プログラミング言語、さらにはメンテナンス構造さえ共有していない。重要なのは、この独立性がそれぞれのエラー領域を生み出すことだ。AgaveのRustで書かれたメモリリークはC++のFiredancerに伝播しないし、AgaveのブロックスケジューラーのロジックエラーはFiredancerの実行モデルに影響しない。2つのクライアントが独立して失敗できるため、ネットワークは重大なエラーから生き残ることができる—ただし、ステークが十分に分散していて、1つのクライアントのオフラインが合意の停滞を引き起こさない限り。( Frankendancer:スマートな移行の一歩Frankendancerは中間地点だ。Firedancerのネットワークコンポーネントとブロック生成を利用しつつ、Agaveの合意と実行層を保持している。これにより、バリデーターはFiredancerのパフォーマンス向上を享受しながらも、未検証の合意コードによるネットワーク全体のリスクを回避できる。2023年6月の約8%から10月には21%に増加したこのハイブリッドモデルは、関心を引きつけることを証明している。しかし重要なのは、すべてのバリデーターが引き続きAgaveの合意層に依存している限り、その層のバグは依然としてチェーンを麻痺させる可能性があることだ—Frankendancerが21%のステークを占めていても。だからこそ、2024年12月のFiredancer完全メインネットは本当の意味での転換点だ。## Firedancerはパフォーマンスと信頼性に何をもたらすかベンチマークによると、Firedancerは制御されたテスト環境で600,000から1,000,000を超える取引を処理し、Agaveの証明済みの能力をはるかに超えている。しかし、スループットの数値は焦点ではない。運営者や組織が関心を持つのは、回復力だ。Firedancerは明確なモジュール設計を採用しており:ネットワークコンポーネント、合意層、取引実行は分離されている。あるコンポーネントにバグがあっても、他の部分に伝播しない。100日間の稼働と5万ブロックの実績は、このクライアントが合意に参加し、有効なブロックを生成し、状態を維持できることを証明している—Agaveの一部に依存せずに。運用の実績はまだ限定的だ—数年にわたるAgaveのメインネット運用に比べて、わずか100日だ。しかし、それだけでも扉を開くには十分だ。バリデーターは本当に代替手段を持ち、ネットワークの回復力はステークの多様化の速度に比例するだろう。## オペレーターのクライアント選択:ビジネスの決定、技術だけではない「オペレーター」)運用者/管理者###という用語は、ブロックチェーンの文脈では、バリデータノードを運用する実体を指す—LidoやRocket Poolのようなインフラ組織から個人の運用者までさまざまだ。彼らがどのクライアントを選ぶかは、技術的な問題だけでなくビジネスの決定だ。組織はSolanaを、稼働プラットフォームとして捉え、次の問いを投げかける:何か問題が起きたときにどうなるか?90%のバリデーターが同じクライアントを使っているネットワークは、単一のポイントの故障を持つ。クライアントのいずれもがステークの33%以上を制御していなければ、バグによる全クライアントの停止を避けつつ、継続して稼働できる。Solanaの実資産7億6700万ドル(とEthereumの125億ドル)の間の差は、ネットワーク効果や開発者の注目だけではなく、稼働時間への信頼を反映している。リスク管理者は、重要なアプリケーションの構築に先立ち、信頼性を求める。Levexは、「Firedancerは、投資家がSolanaの信頼性について示した主要な懸念に対処している」と述べており、多様なクライアントは「企業が重要なアプリケーションに求める耐久性を提供する」としている。## 今後の道筋:集中から分散へAgaveの70%支配から、多クライアントのバランスの取れたネットワークへの移行はすぐには起こらない。オペレーターは移行コストに直面している:Firedancerはハードウェアの調整、運用プロセスの変更、パフォーマンス特性の違いを必要とする。100日間の成功は素晴らしいが、Agaveの何年にもわたる運用に比べるとまだ浅い。慎重なオペレーターは、さらなるデータを待つだろう。しかし、現行のインセンティブ構造は、多様性を促進している。公開されたバリデータのヘルスレポートは、クライアントの分布にプレッシャーをかけ、大手オペレーターに名誉のプレッシャーを与えている。ネットワーク停止の歴史は、明確な警鐘だ。そして、ETFやRWA、企業間決済といった組織的採用の物語は、Solanaが信頼性の課題を克服した証明に依存している。Solanaは現在、異なる言語で書かれた2つのクライアントを持ち、独立したソースコードを採用している。アーキテクチャは整っている。問題は、オペレーターがどれだけ迅速に移行できるかだ。
Firedancer正式に稼働開始:Solanaはついに危険な「クライアントの独身状態」から脱却
5年間の設計ミスに気づくまでの誤り
2024年12月、Solanaは重要な転換点を発表した:クライアントバリデーターFiredancerが100日間の試験を経てメインネットで稼働を開始し、その間にいくつかのバリデーターが50,000ブロックを処理した。しかし、この出来事は単なるパフォーマンスの向上だけではない—それは、Solanaが実際に過去5年間に最も深刻な5つの障害を引き起こした構造的問題を解決した最初の例でもある。
根本的な問題は非常に単純だ:ネットワーク上のバリデーターのほぼ90%が同じソフトウェア—クライアントAgave—を実行していることだ。ブロックチェーンの合意力の70-90%が単一のコードベース上で動作している場合、そのクライアントにおけるいかなるバグも局所的な問題ではなく、ネットワーク全体の問題となる。確認時間が1秒未満や毎秒何千もの取引を処理できる能力は、ソフトウェアのバグによってチェーン全体が凍結する可能性があるときには意味をなさなくなる。
EthereumはProof-of-Stakeに移行した早期からこの教訓を理解していた:多様なクライアントは最適化ではなく、堅牢な安全性のための厳格な要件だ。Solanaも追いつこうとしているが、出発点ははるかに集中化された状態から始まっている。
技術選択の失敗により苦しむネットワーク
Solanaの停止履歴は、一連の待合室の災害のコレクションだ。2022年6月の停止は、durable-nonce機能のバグによりバリデーターの同期が失われ、4.5時間続いた。その後もメモリリーク、過剰なトランザクションの重複、ブロック生成のレース条件などの問題が続いた。
Heliusによる停止履歴の分析は、次の指標を示している:7回の失敗のうち5回は、合意メカニズムの設計ミスではなく、バリデーターやクライアントのバグによるものだ。言い換えれば、Solanaはコアメカニズムの欠陥ではなく、その実行ソフトウェアにバグがあったために停止したのだ。
現在の集中度の高さは、これをさらに危険にしている。2025年6月のSolana Foundationのネットワークヘルスレポートによると、Agaveとその変種Jito-modifiedは、ステークされたSOLの92%を制御している。2025年10月にはこの数字はわずかに減少しただけだ。Cherry Serversによると、Jito-Agaveクライアントは依然として70%以上のステークを握っており、Frankendancerと呼ばれるハイブリッドクライアントも登場している—Firedancerのネットワーク層を利用しつつ、Agaveの合意層を維持しているもので、約21%を占める。最初のFiredancerクライアントは、まだ投票権のないメインネットの状態にあるため、ステークは持っていない。
70%のステークが単一のコードベースに依存していることは、Agaveのバグがネットワークを麻痺させる可能性があることを意味している。
Firedancer:ゼロからのアーキテクチャ、パッチではない
FiredancerはAgaveのアップデートやフォークではない。これはC/C++で完全に書き直されたもので、Jump Cryptoによって構築され、高頻度取引システムから借用したアーキテクチャを採用している。これらのクライアントはソースコード、プログラミング言語、さらにはメンテナンス構造さえ共有していない。
重要なのは、この独立性がそれぞれのエラー領域を生み出すことだ。
AgaveのRustで書かれたメモリリークはC++のFiredancerに伝播しないし、AgaveのブロックスケジューラーのロジックエラーはFiredancerの実行モデルに影響しない。2つのクライアントが独立して失敗できるため、ネットワークは重大なエラーから生き残ることができる—ただし、ステークが十分に分散していて、1つのクライアントのオフラインが合意の停滞を引き起こさない限り。
( Frankendancer:スマートな移行の一歩
Frankendancerは中間地点だ。Firedancerのネットワークコンポーネントとブロック生成を利用しつつ、Agaveの合意と実行層を保持している。これにより、バリデーターはFiredancerのパフォーマンス向上を享受しながらも、未検証の合意コードによるネットワーク全体のリスクを回避できる。
2023年6月の約8%から10月には21%に増加したこのハイブリッドモデルは、関心を引きつけることを証明している。しかし重要なのは、すべてのバリデーターが引き続きAgaveの合意層に依存している限り、その層のバグは依然としてチェーンを麻痺させる可能性があることだ—Frankendancerが21%のステークを占めていても。
だからこそ、2024年12月のFiredancer完全メインネットは本当の意味での転換点だ。
Firedancerはパフォーマンスと信頼性に何をもたらすか
ベンチマークによると、Firedancerは制御されたテスト環境で600,000から1,000,000を超える取引を処理し、Agaveの証明済みの能力をはるかに超えている。しかし、スループットの数値は焦点ではない。
運営者や組織が関心を持つのは、回復力だ。Firedancerは明確なモジュール設計を採用しており:ネットワークコンポーネント、合意層、取引実行は分離されている。あるコンポーネントにバグがあっても、他の部分に伝播しない。100日間の稼働と5万ブロックの実績は、このクライアントが合意に参加し、有効なブロックを生成し、状態を維持できることを証明している—Agaveの一部に依存せずに。
運用の実績はまだ限定的だ—数年にわたるAgaveのメインネット運用に比べて、わずか100日だ。しかし、それだけでも扉を開くには十分だ。バリデーターは本当に代替手段を持ち、ネットワークの回復力はステークの多様化の速度に比例するだろう。
オペレーターのクライアント選択:ビジネスの決定、技術だけではない
「オペレーター」)運用者/管理者###という用語は、ブロックチェーンの文脈では、バリデータノードを運用する実体を指す—LidoやRocket Poolのようなインフラ組織から個人の運用者までさまざまだ。彼らがどのクライアントを選ぶかは、技術的な問題だけでなくビジネスの決定だ。
組織はSolanaを、稼働プラットフォームとして捉え、次の問いを投げかける:何か問題が起きたときにどうなるか?90%のバリデーターが同じクライアントを使っているネットワークは、単一のポイントの故障を持つ。クライアントのいずれもがステークの33%以上を制御していなければ、バグによる全クライアントの停止を避けつつ、継続して稼働できる。
Solanaの実資産7億6700万ドル(とEthereumの125億ドル)の間の差は、ネットワーク効果や開発者の注目だけではなく、稼働時間への信頼を反映している。リスク管理者は、重要なアプリケーションの構築に先立ち、信頼性を求める。
Levexは、「Firedancerは、投資家がSolanaの信頼性について示した主要な懸念に対処している」と述べており、多様なクライアントは「企業が重要なアプリケーションに求める耐久性を提供する」としている。
今後の道筋:集中から分散へ
Agaveの70%支配から、多クライアントのバランスの取れたネットワークへの移行はすぐには起こらない。オペレーターは移行コストに直面している:Firedancerはハードウェアの調整、運用プロセスの変更、パフォーマンス特性の違いを必要とする。100日間の成功は素晴らしいが、Agaveの何年にもわたる運用に比べるとまだ浅い。慎重なオペレーターは、さらなるデータを待つだろう。
しかし、現行のインセンティブ構造は、多様性を促進している。公開されたバリデータのヘルスレポートは、クライアントの分布にプレッシャーをかけ、大手オペレーターに名誉のプレッシャーを与えている。ネットワーク停止の歴史は、明確な警鐘だ。そして、ETFやRWA、企業間決済といった組織的採用の物語は、Solanaが信頼性の課題を克服した証明に依存している。
Solanaは現在、異なる言語で書かれた2つのクライアントを持ち、独立したソースコードを採用している。アーキテクチャは整っている。問題は、オペレーターがどれだけ迅速に移行できるかだ。