Solanaの10万TPSに関する熱い議論：理想的な実験の本質とアップグレードの背後にあるパフォーマンスの信頼性

ここ2日間、Solanaの10万TPSについて議論が活発化しています。 @cavemanloverboy がSolanaメインネットで10万TPS以上を記録したにもかかわらず、ほとんどの人がこのデータの背後にある意味を理解していなかったことが原因です。

1) まず、Caveyの実験は本質的に「理想的な条件」下での極端なテストでした。つまり、Solanaメインネットの典型的なパフォーマンスとは異なります。テストネット環境のラボデータは異なりますが、ほぼ同じです。

これはnoop（操作なし）テストプログラムを使用しているためです。名前の通り、最も基本的な署名検証のみを実行し、成功を直接返します。計算は実行せず、アカウントステータスの変更も行わず、他のプログラムを呼び出すこともありません。各トランザクションはわずか200バイトで、通常のトランザクションの1KB以上よりもはるかに小さいです。

つまり、10万TPSテストは異常な取引環境下で計算されたものであり、アプリケーション層の実際の処理能力ではなく、Solanaのネットワーク層とコンセンサス層の最大スループットをテストしたことになります。

2) この実験の成功のもう一つの鍵は、Frankendancerバリデータクライアントでした。簡単に言うと、FrankendancerはJump Cryptoで現在開発中のFiredancerバリデーターのハイブリッドベータ版であり、Firedancerの既に完成している高性能コンポーネントを既存のSolanaバリデーターに移植したものです。

本質的には、Solanaのノードシステムは、ウォール街で使用されているのと同じ高頻度取引技術スタックを使用して再構築されました。このパフォーマンス向上は、高度なメモリ管理やカスタムスレッドスケジューリングといった基盤となる最適化によって実現されました。一部のコンポーネントを交換するだけで、3～5倍のパフォーマンス向上が期待できます。

3) このテスト実験では、Solanaは理想的な条件下では10万TPS以上を達成できることを示しています。では、なぜ1日あたり3,000～4,000TPSにとどまるのでしょうか？

簡単にまとめると、理由は3つあります。

1. SolanaのPOHコンセンサスメカニズムは、その有効性を維持するためにバリデータによる継続的な投票を必要とします。これらの投票トランザクションだけでブロックスペースの70%以上を占め、通常のトランザクションに残されるパフォーマンスチャネルが減少します。

2. Solanaのエコシステムの活動は、多くの場合、大量のステート競合を伴います。例えば、新しいNFTまたはMEMEが発行されると、同じアカウントへの書き込み権限を巡って数千ものトランザクションが競合し、結果としてトランザクションの失敗率が高くなります。

3. MEV の利益を獲得するために、Solana エコシステムの裁定ロボットは大量の無効なトランザクションを送信し、リソースの無駄遣いにつながる可能性があります。

4) ただし、今後予定されている Firedancer の完全展開と Alpenglow のコンセンサス アップグレードにより、これらの問題は体系的に解決される予定です。

Alpenglowコンセンサスアップグレードの重要な側面は、投票トランザクションをオフチェーンに移行し、通常のトランザクションに利用可能なスペースの70%を解放することです。これにより承認時間は150ミリ秒に短縮され、SolanaのDEXエクスペリエンスはCEXに非常に近づきます。さらに、ローカル手数料市場の活性化により、人気のFOMOアプリケーションが1つあるだけでネットワークの混雑を引き起こすという厄介な状況を回避できます。

Firedancer の主な利点は、パフォーマンスの最適化と改善に加えて、クライアントの多様性を実現し、Solana を Geth Nethermind などの複数のクライアントを備えた Ethereum のようになることで、分散化と単一点ノード障害が直接改善されることです。

その上。

したがって、Solanaの10万TPSに関する議論に精通している人は、これをSolanaの将来のクライアントとコンセンサスプロトコルのアップグレードに対する信頼の表れと捉えているのに対し、そうでない人は、TPS競争を利用してSolanaの知名度を上げようとしている（TPS競争は既に時代遅れですが）。しかし、この実験の背後にある意義を理解していれば、それでも十分にやりがいのあるものです。参考までに、このことを皆さんと共有したいと思います。