Firedancer 已上線，但 Solana 正違反 Ethereum 視為不可妥協的唯一安全規則

經過三年的開發，Firedancer 於 2024 年 12 月在 Solana 主網上線，此前已在少數驗證者上進行了 100 天的測試，產生了 50,000 個區塊。

這一里程碑由 Solana 官方帳戶於 12 月 12 日宣布，不僅標誌著性能的提升。它代表了網絡首次真正嘗試消除導致其最嚴重中斷的架構瓶頸：幾乎完全依賴單一驗證者客戶端。

Solana 多年來一直宣傳亞秒級最終確認和每秒四位數的交易處理能力，但當網絡 70% 到 90% 的共識能力運行相同的軟件時，速度意義不大。

主導客戶端中的關鍵錯誤可能會使整個鏈停止運行，無論其理論上運行得多快。Ethereum 在權益證明轉型初期就學到了這一教訓，現在將客戶端多樣性視為不可妥協的基礎設施衛生要求。

Solana 正嘗試相同的轉變，但起點更為集中。

Firedancer 不是現有基於 Rust 的 Agave 客戶端的補丁或分支。它是用 C/C++ 從零重寫的，由 Jump Crypto 構建，採用模塊化、受高頻交易啟發的架構。

這兩個客戶端不共享代碼、語言和維護團隊。這種獨立性創造了明確的故障域：理論上，Agave 的內存管理或交易調度器中的錯誤不應該使運行 Firedancer 的驗證者崩潰。

對於一個在五年內經歷了七次中斷的網絡，其中五次由客戶端錯誤引起，這種分離正是關鍵所在。

Solana 無法擺脫的單一文化問題

Solana 的中斷歷史可視為單一客戶端風險的案例研究。2022 年 6 月的一次停機持續了四個半小時，原因是持久隨機數交易功能中的錯誤導致驗證者失去同步，需要協調重啟。

其他事件可追溯至內存洩漏、過多重複交易和區塊生產中的競爭條件。Helius 對完整中斷歷史的分析將七次故障中的五次歸因於驗證者或客戶端錯誤，而非共識設計缺陷。

當單一實現錯誤可能凍結區塊生產時，網絡宣傳的吞吐量變得無關緊要。

數據證實了這種風險。Solana 基金會 2025 年 6 月的網絡健康報告顯示，Agave 及其 Jito 修改版本控制了大約 92% 的質押 SOL。

到 2025 年 10 月，這一數字有所下降。然而，降低得並不多：Cherry Servers 的質押概覽和多個驗證者指南報告，Jito-Agave 客戶端仍持有超過 70% 的質押，而混合型 Frankendancer 客戶端增長到網絡的約 21%。

Frankendancer 使用 Firedancer 的網絡層和 Agave 的共識後端。

儘管仍是少數，Cherry Servers 的數據指出，Frankendancer 的份額從 6 月的約 8% 增長了。這些增長代表了部分解決方案的穩定採用，但 12 月在主網上線的完整 Firedancer 客戶端改變了局面。

驗證者現在可以運行完全獨立的堆棧，消除了將過去的客戶端錯誤轉變為全網事件的共享依賴。

Ethereum 的經驗提供了參考模型。

Ethereum 基金會的客戶端多樣性文檔警告說，任何控制超過三分之二共識能力的客戶端都可以單方面確認不正確的區塊。此外，超過三分之一的客戶端如果離線或行為不可預測，可能完全阻止最終確認。

Ethereum 社區將所有客戶端保持在 33% 以下視為硬性安全要求，而非優化選項。Solana 的起點是一個客戶端接近 90% 的參與率，遠遠超出了安全區域。

客戶端	語言	狀態	質押份額 (2025 年 10 月)	驗證者	真正獨立性
Jito	Rust	主網	~72%	~700+	Agave 的分支
Frankendancer	C + Rust	主網	~21%	207	混合獨立
Agave	Rust	主網	~7%	~85	原始
Firedancer	C	非投票主網	0%	0	完全獨立

Firedancer 實際改變了什麼

Firedancer 重新實現了 Solana 的驗證者管道，採用了借鑒低延遲交易系統的架構：並行處理瓦片、自定義網絡原語和針對負載下確定性性能調整的內存管理。

來自技術會議演示的基準測試顯示，該客戶端在受控測試中每秒處理 600,000 到超過 1,000,000 筆交易，遠高於 Agave 展示的吞吐量。

但性能上限不如故障域分離重要。Firedancer 文檔和驗證者設置指南將客戶端描述為模塊化設計，具有處理網絡、共識參與和交易執行的不同組件。

Agave 的 Rust 分配器中的內存損壞錯誤不會傳播到 Firedancer 的 C++ 代碼庫。Agave 區塊調度器中的邏輯錯誤不會影響 Firedancer 的基於瓦片的執行模型。

這兩個客戶端可以獨立失敗，這意味著只要質押分佈防止超級多數同時離線，網絡就能在任一客戶端出現災難性錯誤時存活。

混合型 Frankendancer 部署作為分階段推出。運營商用 Firedancer 的等效組件替換了 Agave 的網絡和區塊生產組件，同時保留 Agave 的共識和執行層。

這種方法允許驗證者採用 Firedancer 的性能改進，而不會在未經測試的共識代碼上冒整個網絡的風險。

Frankendancer 到 10 月獲得的 21% 質押驗證了混合模型，但也突顯了其限制：只要所有驗證者仍依賴 Agave 進行共識，該共享層中的錯誤仍可能使鏈停滯。

12 月完整客戶端的主網發布消除了這種共享依賴。

少數運行 Firedancer 100 天並產生 50,000 個區塊的驗證者證明，該客戶端可以參與共識、產生有效區塊並維護狀態，而不依賴任何 Agave 組件。

生產記錄有限，僅在少數節點上運行了 100 天，但足以為更廣泛的採用打開大門。驗證者現在有了真正的替代選擇，網絡的彈性直接與選擇遷移的數量成正比。

為什麼機構關心驗證者軟件

客戶端多樣性與機構採用之間的聯繫並非推測。

Levex 的 Firedancer 解釋指出，該客戶端"解決了機構投資者對 Solana 可靠性和可擴展性提出的關鍵問題"，多客戶端冗餘"提供了企業關鍵應用所需的穩健性"。

9 月 Binance Square 關於 Solana 機構就緒性的文章將過去的中斷視為企業參與的主要障礙，並將 Firedancer 定位為"潛在的解決方案"。

分析認為，可靠性是 Solana 與 Ethereum 和其他第一層網絡競爭的"關鍵差異因素"，消除單一客戶端風險"可能消除 Solana 最大的弱點"，特別是在向不能容忍網絡級停機的機構推銷時。

這一邏輯反映了為 Ethereum 客戶端多樣性活動建立的框架。

評估區塊鏈基礎設施的機構風險團隊想知道當出現問題時會發生什麼。

在 90% 的驗證者運行相同客戶端的網絡中存在單點故障，無論其代幣分佈或驗證者集合在紙面上看起來多麼去中心化。

在沒有客戶端控制超過 33% 質押的網絡中，即使一個客戶端因災難性錯誤而完全失效，網絡仍能繼續運行。對於決定是否在特定鏈上構建受監管產品的風險管理者來說，這種差異是二元的。

Solana 約 7.67 億美元的代幣化現實世界資產代表的是立足點，而非規模化採用。根據 rwa.xyz 數據，Ethereum 託管了 125 億美元的代幣化國債、穩定幣和代幣化基金。

這一差距不僅反映了網絡效應或開發者關注度，還反映了對運行時間的信任。

Firedancer 在主網的到來為 Solana 提供了一條縮小這一差距的路徑，通過滿足 Ethereum 社區視為生產基礎設施基本要求的相同客戶端多樣性門檻。

未來的採用曲線

從 70% Agave 主導到平衡的多客戶端網絡的轉變不會很快發生。驗證者面臨轉換成本：Firedancer 需要不同的硬件調整、不同的操作手冊和與 Agave 不同的性能特性。

客戶端 100 天的生產記錄雖然成功，但與 Agave 多年的主網運行相比仍然淺薄。風險規避的運營商會等待更多數據才遷移質押。

儘管如此，激勵結構現在有利於多樣化。Solana 基金會的驗證者健康報告公開追踪客戶端分佈，對大型運營商施加聲譽壓力，避免在任何單一實現中過度集中。

網絡的中斷歷史提供了對弊端的直觀提醒。而機構採用敘事，包括 ETF 推測、RWA 發行和企業支付試點，取決於證明 Solana 已經克服了其可靠性問題。

架構現已就位。Solana 有兩個生產客戶端，使用不同語言，具有獨立代碼庫和分離的故障模式。網絡的彈性取決於質押從最初的單一文化向沒有單一客戶端可使鏈離線的分佈遷移的速度。

對於評估 Solana 是否可以作為生產基礎設施運行並且是否有現實路徑在下一次客戶端錯誤時無需協調重啟即可存活的機構來說。

文章 Firedancer 已上線，但 Solana 正違反 Ethereum 視為不可妥協的安全規則 首次發表於 CryptoSlate。