目次
1、ファイアダンサー
2. 重要なポイント
3. はじめに
3.1 ソラナ 2.0 に向けて
4. レイアウトの初期段階
5. Solana 上のバリデータークライアントの現在のステータス
6. 別のバリデータークライアントが必要なのはなぜですか?
7、ファイアダンサー
7.1 ファイアダンサー スタック
7.2 モジュール式アーキテクチャ
7.3 セキュリティモデル
8. 未来への道
9. 結論
10. 参考文献
11. 声明
ファイアダンサー
次のレポートでは、Firedancer をさらに深く掘り下げ、その価値提案と、Solana のオリジナルのホワイト ペーパーで概説されているビジョンを実現する上で Firedancer が果たす役割を探ります。多くの人にとって、そのリリースは Solana 2.0 への第一歩となり、ハードウェアとソフトウェアの限界を極限まで押し広げ、既存の検証クライアントの課題を解決し、ネットワークの拡張性、信頼性、信頼性と効率を再定義します。
重要なポイント
Solana のビジョンはハードウェア中心であり、ソフトウェアの最適化が追いつくことができれば、ムーアの法則による線形スケーラビリティを信じています。
現状では、既存のバリデーターは、主にハードウェアの制限ではなくソフトウェアの制限により、パフォーマンスとスケーラビリティの問題に直面しています。
Solana ネットワークの回復力は、システム障害のリスクを軽減し、フォールト トレランスを向上させるために、バリデータ クライアントを多様化することに依存しています。新しいサードパーティ検証クライアント ソフトウェアである Firedancer の導入は、この回復力を高め、クライアントの多様性を促進し、限られたクライアントへの Solana の依存を解決する方向への動きを示しています。
Jump Crypto チームによって立ち上げられた Firedancer の方法論は、高性能のグローバル取引システムに基づいており、物理的および理論的限界の限界で運用するという最終目標を掲げ、Solana の最適化に自然に適合します。
Firedancer の開発は重要なマイルストーンですが、Solana がオープン スタンダードに進化するには、文書化、互換性、コミュニティ ガバナンスに対する継続的な取り組みが不可欠です。
導入
ソラナの物語は、アナトリー・ヤコヴェンコ氏が歴史の証明について説明したオリジナルの白書を発表した 2017 年に始まりました。これは、既存のソリューションのスケーラビリティの問題を克服できるブロックチェーンを構築するためのビジョンを示しています。これは、高性能、低遅延のプラットフォーム、つまりナスダックと競合できる取引エンジンを構築できるブロックチェーンとして設計されました。
アナトリーと創設チームによって提案されたオリジナルのコンセプトに基づくと、ソフトウェアがハードウェアを妨げない限り、ブロックチェーンの全体的なネットワーク パフォーマンスは、ムーアの法則で説明されているように、ハードウェアの進歩、トランジスタの数に応じて直線的に増加する可能性があります。集積回路のコスト増加は最小限に抑えられ、毎年約 2 倍に増加します。ソフトウェアが最適であれば、Solana のパフォーマンス指標は、それ以上アップグレードしなくても 2 年ごとに 2 倍になります。
出典: メディア
ただし、ハードウェアが進歩するにつれてパフォーマンスは向上しますが、ネットワーク帯域幅がボトルネックになるのを防ぎ、ネットワークの遅延を回避するには、効率的なノード通信が重要です。これは、ハードウェアが進歩したとしても、あらゆる形態のネットワーク遅延を防ぐために重要です。
Solana バリデータ クライアントには現在、パフォーマンスとスケーラビリティに影響を与える可能性のある制限がいくつかあり、多様性が不十分なためにネットワークの信頼性の問題も発生します。これらの制限のほとんどは、ハードウェア レベルの制限ではなく、ソフトウェア ベースの制限です。 Kevin J Bowers は Jump の高性能システム研究者で、Firedancer プロジェクトの推進を担当しています。「光の速度は遅すぎる」という大袈裟な発言で有名です。高性能のグローバル取引システムを開発してきた数十年の経験を持つ Jump は、独立したバリデータ クライアントである Firedancer を構築することで、Solana の信頼性を向上させたいと考えています。
出典: ソラナ
Firedancer は、過去に目を向けるだけで短期的な解決策として設計されているわけではありません。コンピューティング能力の限界を押し広げ、規模と信頼性を提供し、物理学と理論の境界で動作するように設計されています。
ソラナ2.0に向けて
従来の開発では、操作は通常、物理空間の観点ではなくデータ空間の観点から見られます。この考え方は、光の速度などの物理的な制限によって必然的に制約されるため、ハードウェアの使用率が低下し、システムのパフォーマンスが低下します。
出典: レベロ・インテル
従来の開発手法では物理的な制約が無視されることが多いため、その結果、ハードウェアの使用率が低下します。言い換えれば、システムのスケーラビリティはハードウェアによって制限されるのではなく、ソフトウェアの非効率によって制限されます。次のような有名な格言があります。「より高速なハードウェアは、低速なソフトウェアに対する主な解決策としては不十分です。」
Jump Trading はこれらの課題に正面から取り組み、従来の取引システムから高度にカスタマイズされたテクノロジー スタックに進化しました。この変革は、取引所への物理的な近接性、異種市場の需要、厳格な運用基準が重要である世界規模の取引特有の課題に対処します。
従来のスーパーコンピューターとは異なり、Jump のシステムは、迅速かつ透過的にフォールトトレラント性を備え、増分アップグレードが可能でなければなりません。企業は、厳格なデータ保持と責任基準を備えた、多様性があり、競争が激しく、厳しく規制された環境で運営する必要があります。 Solana にハードウェアを追加するだけでは十分ではありません。代わりに、ソフトウェアの最適化が重要であり、Firedancer はソフトウェアをこれらの目標の達成に近づけます。
参考までに、Firedancer を実行している単一のバリデーターは、2022 年 11 月のライブ デモンストレーション中に 120 万 TPS を処理しましたが、ほとんどの推定では、より現実的な数値として 600,000 TPS が指摘されています。この数字は、Solana の現在の理論上の制限である 50,000 TPS の数倍であり、Visa などの大手サービスプロバイダーが通常処理するトランザクション量 (約 1.5,000 ～ 2,000 TPS) をはるかに超えています。
出典: ツイッター
Firedancer は、Solana のバリデータ クライアント アーキテクチャと機能にパラダイム シフトをもたらします。これは単なるバリデータークライアントの構築ではなく、すでに高速で効率的な Solana ブロックチェーンを強化する、信頼性の高いパフォーマンス指向のクライアントを構築することです。
出典: 摩擦のない資本
Firedancer の発売により、Jump は多くの人が Solana 2.0 と呼ぶ新しい段階を迎えています。高頻度取引環境における長年の経験を活用することで、この今後登場する独立したバリデータ クライアントを Solana のツールボックスに追加することで、ネットワークの信頼性、効率性、堅牢性を高めることができます。
出典: レベロ・インテル
Solana は、優れたスピードとシステムのダウンタイム問題に対する最新のソリューションで際立っています。ただし、さらなる改善の可能性はあります。 Firedancer は、Solana のクライアントの多様性を高めることで、現在の少数のクライアントへの過度の依存を解決し、ブロックチェーン全体で最もパフォーマンスの高いバリデータ クライアントになることを目指しています。
出典: Github
舞台を整える
Solana では、バリデーターは Solana のプルーフ・オブ・ステーク・コンセンサス・メカニズムに参加して、トランザクションを検証し、チェーンに追加する新しいブロックを提案します。
出典: レベロ・インテル
このようにして、Solana ($SOL) トークン所有者はコンセンサスに参加し、$SOL トークンをバリデーターノードにロックすることでステーキング報酬を受け取ることができます。
出典: レベロ・インテル
プルーフ・オブ・ステーク (PoS) は、プラスとマイナスの両方のインセンティブを提供します。参加者は保証金として金銭的担保を保有する必要があります。バリデーターがルールに違反した場合、ペナルティとして賭け金の一部が「カット」されます。それ以外の場合は、ステーキング報酬を通じて補償されます。
作業を完了し、ネットワーク内の他のノードに接続するために、バリデーターは、コンセンサスへの参加を可能にするアプリケーションである検証クライアントを使用する必要があります。これは、トランザクションがネットワークのルールに準拠していることを確認するために検証および確認できるソフトウェアです。
異なるバリデータ クライアントには異なるコードを含めることができますが、それらはすべて同じロジックを実装する必要があります。 1 つのクライアントでエラーまたは障害が発生した場合でも、他のクライアントを実行しているノードがネットワークをオンラインに保ち、ネットワークのダウンタイムを防ぐことができるため、これは重要です。
出典: レベロ・インテル
クライアントの多様性が高まるということは、バリデータ クライアント コードにバグや脆弱性が発生する可能性がある場合の回復力と保護が強化されることを意味します。たとえば、2016 年に攻撃者はイーサリアム geth クライアントのバグを発見し、ネットワーク上で一連の DDoS (分散型サービス拒否) 攻撃を開始しました。このような攻撃から保護するための解決策は、ノード オペレータがすぐに別のクライアントに切り替えて、脆弱性がパッチされている間ネットワークの運用を維持することです。
Solana バリデータークライアントの現在のステータス
現在約 1,649 人のバリデーターを擁する Solana は、PoS ネットワーク内で最大数のノードの 1 つであり、サトシ ナカモト係数によって測定されるように最も広く分散されているものの 1 つでもあります。現在、Solana のバリデータークライアントには、Solana Lab Client と Jito Lab Client が含まれており、それぞれ有効株式の 68% と 32% を保有しています。 2023 年の Jito Labs クライアントの成長はネットワークの多様化に重要な役割を果たしますが、さらなる努力がまだ必要です。
Jito クライアントは Solana Labs クライアントのフォークですが、MEV を最適化するために疑似メモリ プール (Solana にはメモリ プールがないため) が導入されている点が異なります。これにより、バリデーターはメモリプール内で未確認または保留中のトランザクションを検索し、それらを最適にバンドルして、Jito ブロック エンジンに送信できるようになります。
出典: レベロ・インテル
ただし、これがフォークであるという事実は、2 つのクライアントが元のコード ベースで開発された多くのコンポーネントを共有していることを意味します。したがって、元の Solana Labs クライアントに未発見の脆弱性やバグがある場合、両方のクライアントが影響を受けます。
今後は、既存の 2 つのクライアント (Solana Labs と Jito) と Firedancer に加えて、2 つの独立したチームが新しいクライアントを開発します。これにより、合計 5 つのバリデータが作成され、3 つは Rust (Solana Labs、Jito、Anza が開発した Agave) を使用し、1 つは C (Firedancer) を使用し、もう 1 つは Zig (Sig が開発した Sig) を使用しました。
別のバリデータ クライアントが必要なのはなぜですか?
Solana にとって、Firedancer のような別の検証クライアントを持つことは、ネットワークの復元力とパフォーマンスを強化するために重要です。同じネットワークの問題に対してクライアントが異なれば反応も異なる可能性があるため、多様なバリデータ クライアントによりシステム障害のリスクが軽減されます。
出典: ソラナ
ソフトウェア検証済みのクライアントが多様であるため、1 つのクライアントの単一のバグや脆弱性がネットワーク全体を侵害することはありません。さらに、Firedancer のようなプロフェッショナルなクライアントは、Solana 独自のニーズに合わせてパフォーマンスを向上させ、ネットワークの効率と信頼性をさらに高めることができます。
出典: レベロ・インテル
ネットワーク上で複数の異なるクライアントが実行されている場合、それらのクライアントが同じ脆弱性を共有する可能性はほとんどありません。特定のバグや攻撃により 1 つのクライアントに障害が発生しても、異なるアーキテクチャを持つ他のクライアントは影響を受けず、ネットワークの継続性と安定性が確保されます。
出典: レベロ・インテル
もう 1 つの問題は、現在のクライアント (Solana Labs と Jito) が単一のプロセスとして実行されるため、実稼働環境でコードが実行されると変更を加えることが困難になることです。たとえば、これらのクライアントを実行しているバリデーターは、即時のセキュリティ アップグレードを実装する必要がある場合に強制的にシャットダウンされました。すべての分散システム (集中型決済プロセッサ、データベース、ブロックチェーンなど) には共通点が 1 つあります。実装上の 1 つのエラーがシステム全体を停止させる可能性があります。
さらに、いくらテストを行っても、考えられるすべてのエラーを防ぐことはできません。このため、特にダウンタイムゼロを達成し、限界まで脆弱性を維持するように設計されたブロックチェーンでは、運用環境で複数のクライアントをサポートすることが重要です。
理想的には、異なるプログラミング言語を使用して独立したチームによって開発された 4 つのクライアントがあり、それぞれがアクティブな株式の 25% を制御することができます。こうすることで、単一の実装でアクティブ シェアの 33% 以上を制御することがなくなり、単一障害点の防止に役立ちます。
出典: レベロ・インテル
Jump は、パフォーマンスの向上に加えて、ネットワークの信頼性を高めるために、Solana 用の新しいバリデータ クライアントを構築しています。たとえば、Solana では過去に、コンセンサスに影響を与えるソフトウェア モジュールの問題によりブロックの生産が停止するという 4 つのインシデントが発生しました。これらの問題は通常、Discord 上のバリデーターを調整することで解決され、手動で修正する必要があります。
Firedancer が運用環境に入ると、他のすべてのクライアントに同じ最適化を適用するのが簡単になります。たとえば、Jito は、Firedancer と連携するために必要な最適化を実装する JitoDancer を開発しています。
ファイアダンサー
Firedancer は、Solana の現在のバリデータ クライアントを C で書き直したもので、元のコードベースからバグが持ち込まれないようにしています。
ジャンプ社がゼロから開発しました。 Jump は、高頻度取引の専門知識を活用することで、このような高性能、低遅延、耐障害性のシステムを構築する最も有能なチームの 1 つです。
出典: レベロ・インテル
コードはオープンソースであるため、誰でも開発中の最適化を確認して理解できます。 Kevin Bowers は現在、高性能環境におけるテクノロジーの限界を押し広げ続けるチームを率いています。最適化されたデータ オーケストレーション、カスタム テクノロジー スタック、グローバル システム スケーリングに関する専門知識は比類のありません。
Jump と同様に、Solana は成長するエコシステムをサポートするために、堅牢かつ柔軟で効率的なインフラストラクチャを必要とします。独立した 2 番目のバリデータである Firedancer の導入は、この目標に向けた一歩です。 Firedancer は、グローバルに拡張可能で、段階的に進化し、耐障害性があり、幅広いコミュニティにオープンになるように設計されています。その開発はオープンであり、Solana コミュニティからのコラボレーションやフィードバックを歓迎しています。
出典: レベロ・インテル
それ以外の場合、クライアントは Rust で書かれているにもかかわらず、Solana Labs および Jito Labs のクライアントと互換性があります。 Firedancer クライアントは、Solana バリデーターが使用する既存のハードウェアとも互換性があり、新しいマシンへのアップグレードを強制しません。 Firedancer を使用すると、Solana は帯域幅とハードウェアに合わせて拡張できます。
Firedancer のビジョンはシンプルです。クライアントの実行能力がバリデーター ハードウェアによってのみ制限されるように、すべてのコンポーネントは最大のパフォーマンスを得るために最適化される必要があります。これを、ソフトウェアの非効率性によってバリデーターのパフォーマンスが制限されている現在の状態と比較してください。
Firedancer テクノロジースタック
Firedancer は、Solana Labs クライアントの 3 つの主要な機能コンポーネントを C でゼロから書き直すことによって構築され、クライアントをそのハードウェアの限界まで押し上げるために個々の部分を最適化します。
出典: レベロ・インテル
本質的に、Firedancer は単なる検証ツールではなく、トランザクション スループットの最適化とコストの削減を目指し、テクノロジーと金融の交差点で限界を押し広げ、革新するという Jump の信念の証です。
出典: レベロ・インテル
Firedancer は、これらの主要コンポーネントを最適化することで、Solana のスケーリングがソフトウェア自体ではなくクライアント ハードウェアによって主に制限されるようにします。これは、帯域幅がボトルネックにならないようにノード間で効率的に通信する方法を設計するという、何年も前に Anatoly によって提案された Solana の当初のビジョンと一致しています。
ハイパフォーマンス コンピューティングの世界では、最終的にはすべてが最適化される必要があります。このアプローチは、マイクロチップ上のトランジスタの数が約 2 年ごとに 2 倍になり、計算能力の向上とトランジスタあたりのコストの削減につながるというムーアの法則と一致しています。
Firedancer のスケーラビリティは、マイクロチップ内のトランジスタの数と密接に関係しています。これは、トランジスタが多いほど、チップ表面上の物理的スペースが増えることを意味するためです。その結果、チップ設計者はより多くのコアを追加でき、Solana のデータ スループットが向上します。これにより、十分なレベルの分散化を維持しながら、帯域幅とハードウェアの向上に応じてネットワークを拡張できます。
出典: レベロ・インテル
Solana のコンテキストでは、より多くのプロセッサ コアがあるということは、より多くのトランザクションを並行して実行できることを意味します。これにより、複数のトランザクションを互いに待たずに同時に処理できるため、データ スループットが大幅に向上します。
初期のシミュレーションでは、コアの数が増加するにつれて帯域幅がほぼ直線的に増加することが示されています。言い換えれば、バリデーターのハードウェアのコア数が 2 倍になると、同じ時間内にバリデーターが受信するトランザクションの数がほぼ 2 倍になります。
モジュラーアーキテクチャ
Firedancer のモジュラー アーキテクチャは、既存のクライアントとは一線を画しています。このモジュール性はその内部構造を指しており、ネットワーク検証プロセスの効率と信頼性を向上させるように設計されています。これを、ブロックチェーン ネットワーク自体がどのように構築され、動作するかに焦点を当てた、より広範なブロックチェーン アーキテクチャの議論と混同しないでください。
後者には、コンセンサス層、実行層、データ可用性層の分離など、ブロックチェーン エコシステム内の分業に関する議論が含まれますが、これは Firedancer の設計原則や機能に直接関連しない概念です。
出典: レベロ・インテル
Firedancer はタイルベースのアーキテクチャを使用しており、各タイルはメモリを備えた独立した Linux C プロセスです。対照的に、現在の Rust クライアントは単一のプロセスとして実行されます。
この文脈では、プロセスとは実行中のプログラムのインスタンスを指します。たとえば、最新のオペレーティング システムは、メモリとリソースをさまざまなプロセスに割り当てて動作し、それぞれが特定のタスクを処理します。
出典: レベロ・インテル
独立したプロセスであるタイルには、単一プロセス システムに比べていくつかの利点があります。さまざまなワークスペースでバリデーターの状態を管理することで障害を隔離し、1 つのタイルの問題がシステム全体に影響を及ぼさないようにします。
この分離により、システム全体を停止することなく個々のタイルを個別に変更または交換できるため、メンテナンスとアップグレードも簡素化されます。たとえば、再起動またはアップグレード中に、各タイルは中断したところから処理を続行できます。
さらに、各タイルは個別の CPU コアで実行できるため、リソースをより有効に活用でき、リソースの競合が回避され、パフォーマンスが最適化されます。これらの要因により、タイルは単一プロセスのアプローチよりも堅牢で、柔軟で、効率的になります。
初期のテストでは、Solana Labs クライアントと比較して 10 ～ 100 倍のパフォーマンスの向上が示されており、テストでは各 GPU コアが 100 万を超えるトランザクションを処理しました。
出典: レベロ・インテル
セキュリティモデル
C 言語と Rust の間のトレードオフの 1 つは、C 言語には Rust が提供するメモリの安全性保証がないことです。こうした状況を防ぐために、Jump は「オペレーティング システム サンドボックス」と呼ばれる手法を使用しています。これは基本的に、オペレーティング システムからさまざまなプロセス (タイル) を分離することを意味します。
最小特権の原則に従い、タイルはシステム リソースにアクセスし、作業を実行するために厳密に必要なシステム コールのみを実行できます。実際、C 言語メモリ セキュリティの分野での徹底的な研究により、チームは敵対的思考を採用し、攻撃対象領域を可能な限り減らすようになりました。タイルが分離されていない場合、攻撃が脆弱性を悪用して複数のバリデーターに影響を与えると、ネットワーク全体に損害が発生する可能性があります。
このアプローチは、「完璧なコード」などというものは存在せず、いくつかの脆弱性やセキュリティ ホールが必然的に導入されることを認識しています。ただし、これらのシナリオから保護するために、Jump は多層防御戦略を採用しているため、攻撃者がコードの一部を侵害したとしても、影響の範囲は限定され、テクノロジー スタックの他の部分には影響を与えません。
前方の道路
Firedancer の量産化が Solana にとって大きなマイルストーンであることは疑いの余地がなく、多くの人がこれを Solana 2.0 と呼んでいます。それでも、セキュリティの観点からは課題が待ち構えています。
Firedancer がもたらすメリットにもかかわらず、既存のクライアントの動作を厳密に再現する必要があります。そうしないと、互換性がないためにコンセンサス エラーが発生する可能性があります。
これらの問題に対処する 1 つの方法は、長期的に Firedancer の合計株式を 33% 未満に保つことを目標に、株式の一部を両方のクライアントにまたがって運用することです。
考慮すべき最も重要なことは、コードベースは単独で開発できないということです。そのため、Jump は既存の Labs クライアントの機能に基づいてパフォーマンスを評価し続けます。
Jump が現在直面しているもう 1 つの課題は、仕様と標準化されたドキュメントの欠如です。良い面としては、これは変わります。
新しい実装では、開発速度を維持しながら、新しいバグが発生しないように注意する必要があります。その結果、Jump は Solana ドキュメントの改善を優先事項の 1 つとしました。
Jump が Solana プロトコルを定義する実際の仕様ファイルを提供すると、誰でもバリデータ コードではなくドキュメントを参照するだけで Solana バリデータを作成できるようになります。
これは、Firedancer の互換性を長期にわたって維持するのに役立つだけでなく、独自のクライアントを構築する他の独立したチームにとっても、この包括的なドキュメントは重要です。最終的には、たとえネットワークが Jump の数十年にわたる専門知識を活用できたとしても、Solana の最終目標は、多様な貢献者のコミュニティによって管理されるオープン スタンダードになることです。
結論は
要約すると、Firedancer は Solana のスタンドアロンの検証クライアントにすぎませんが、その導入はネットワークにとって重要なマイルストーンを表します。
Firedancer は、Solana の信頼性、パフォーマンス、クライアントの多様性を向上させ、現在の少数のクライアントへの過度の依存に対処するように設計されています。
この動きは、ソフトウェアの非効率性によって制限されるのではなく、ハードウェアの改善に合わせて拡張できる、ノードが通信する効率的な方法を設計するという Solana のビジョンと一致しています。
参考文献
Solana ホワイトペーパー
Solana バリデーター
Solana Labsクライアント
Jito Labs クライアント
ファイアダンサークライアント
Tinydancer – Solana初の軽量クライアント
ジャンプと光の速度
ヘリウス: ファイアダンサーとは何ですか?
ファイアダンサードキュメント
披露
私たちは Solana または Jump Crypto と商業的な関係を持ったことはなく、このレポートはいかなる形でも資金提供や委託を受けていません。
上記の分析に直接関与しているメンバーを含む当社チームのメンバーは、議論されているコインのポジションを保持している可能性があります。
このコンテンツは教育のみを目的としており、財務または投資に関するアドバイスを構成するものではありません。自分で調査を行い、損失しても許容できる金額のみを投資する必要があります。私たちは研究プラットフォームであり、投資や財務アドバイザーではありません。
この記事の情報源: revelointel
