Firedancer驗證器推出,為Solana大規模採用鋪路
本文來自: 《What is Firedancer? A Deep Dive into Solana 2.0 》
原文作者: 0xIchigo
Odaily星球日報譯者:夫如何
衆所周知,Solana 作為目前公鏈中高性能的代表之一,其較快的鏈上處理速度受到衆多項目方的追捧,也吸引了像 Visa 等傳統巨頭的青睞。但 Solana 一直存在着網絡宕機的隱患,網絡宕機問題該怎么解決,Jump 將推出的 Firedancer 驗證其客戶端或能給出答案。
本文將從驗證器以及驗證器客戶端對區塊鏈的作用入手,探究 Firedancer 驗證器客戶端如何加持 Solana 網絡。
以下由Odaily星球日報編譯。
驗證器以及驗證器客戶端多樣性是什么?
驗證器是參與權益證明區塊鏈的計算機。驗證器是 Solana 網絡的支柱,負責處理交易並參與共識過程。驗證器通過鎖定一定數量的 Solana 原生代幣作為抵押來保護網絡的安全。質押代幣可以將其視為一筆安全保證金,將驗證器與網絡進行經濟聯系。這種聯系激勵驗證器准確高效地執行任務,因為他們會根據自己的貢獻獲得獎勵。同時,對於惡意或故障行為,驗證器也會受到處罰。驗證器的權益會因為不當行為而被減少,這個過程稱為減持。因此,驗證器有充分的動力正確執行職責以增加自己的權益。
驗證器客戶端是驗證器用來執行任務的應用程序。客戶端是驗證器的基礎,通過其加密的唯一身份參與共識過程。
擁有多個不同的客戶端可以提高容錯能力。例如,如果沒有任何一個客戶端控制超過 33% 的份額,崩潰或影響活躍性的錯誤就不會使網絡崩潰。同樣,如果一個客戶端存在錯誤導致無效的狀態轉換,只有少於 33% 的份額使用該客戶端,網絡就可以避免安全故障。這是因為大多數網絡將保持在有效狀態,防止區塊鏈出現分裂或分叉。因此,驗證器客戶端的多樣性能夠提高網絡的彈性,不會因為一個客戶端的錯誤或漏洞對整個網絡造成嚴重影響。
客戶端多樣性可以通過每個客戶端運行的權益份額百分比和可用客戶端的總數來衡量。在撰寫本文時, Solana 網絡上有 1979 個驗證器。 這些驗證器在主網上使用的兩個客戶端是由 Solana Labs 和 Jito Labs 提供的。Solana 在 2020 年 3 月推出時,使用的是由 Solana Labs 开發的一個驗證器客戶端。2022 年 8 月,Jito Labs 發布了第二個驗證器客戶端。該客戶端是由 Jito 維護和部署的 Solana Labs 代碼的分支。該客戶端優化了區塊中最大可提取價值(MEV)的提取。Jito 的客戶端創建了一個僞內存池,因為 Solana 在沒有內存池的情況下流式傳輸區塊。值得注意的是,內存池是一組未確認和待處理交易的隊列。僞內存池允許驗證器搜索這些交易,將其優化地捆綁在一起,並提交給 Jito 的區塊引擎。
截至 2023 年 10 月,Solana Labs 客戶端持有活躍抵押的 68.55 %,而 Jito 持有 31.45 %。使用 Jito 客戶端的驗證器數量比 Solana 基金會先前的健康報告增長了 16 %。 Jito 客戶端使用率的增長顯示出客戶端多元化的演變趨勢。
盡管這種增長的消息令人振奮,但它並非完美無缺。需要強調的是,Jito 的客戶端是 Solana Labs 客戶端的一個分支。這意味着 Jito 與原始驗證器代碼庫共享許多組件,並且可能容易受到影響 Solana Labs 客戶端的錯誤或漏洞的攻擊。在理想的未來中,Solana 至少應該擁有四個獨立的驗證器客戶端。不同的團隊將使用不同的編程語言構建這些客戶端。沒有單一的實現會超過 33 %的權益份額,因為每個客戶端將持有約 25 %的份額。這種理想化的設置將在整個驗證器堆棧中消除單一故障點。
开發第二個獨立的驗證器客戶端對於實現這種未來至關重要,Jump 致力於實現這一目標。
為什么 Jump 要構建一個新的驗證器客戶端?
Solana 的主網過去曾經四次出現宕機的情況,每次都需要數百個驗證器進行手動修復。這種宕機情況凸顯了對 Solana 網絡可靠性的擔憂。 Jump 認為協議本身是可靠的,而將停機時間歸因於影響共識的軟件模塊問題。 因此,Jump 正在开發一個新的驗證器客戶端來解決這些問題。這個客戶端的總體目標是提高 Solana 網絡的穩定性和效率。
开發一個獨立的驗證器客戶端是一項艱巨的任務。然而,這並不是 Jump 第一次構建可靠的全球網絡。過去,證券交易(即股票买賣)是由市場專家手動執行的。隨着電子交易平臺的出現,證券交易變得更加开放。這種开放性增加了競爭,自動化,並減少了投資者進行交易的時間和成本。市場專家之間开始了技術上的競爭。
交易者以交易為生。更好的交易體驗需要在軟件、硬件和網絡解決方案上更加注重。 這些系統必須具有高機器智能、低實時延遲、高吞吐量、高適應性、高可擴展性、高可靠性和高追責能力。
通用解決方案(即公司可以直接購买的軟件)並不是競爭優勢。以次於第二名的方式將正確的訂單發送到交易所是一種昂貴的賠錢方式。在高頻交易領域的激烈競爭導致了一個永無止境的开發循環,建立了一流的全球交易基礎設施。
這種情景可能聽起來很熟悉。成功的交易系統的要求與成功的區塊鏈相似。區塊鏈需要是性能優越、容錯性強、延遲低的網絡。一條慢速的區塊鏈是一種失敗的技術,無法滿足現代企業應用的需求,只會阻礙創新、可擴展性和真實世界的實用性。憑借二十多年的全球網絡擴展和高性能系統开發經驗,Jump 是創建獨立驗證器客戶端的完美團隊。Jump Trading 首席科學官 Kevin Bowers 負責全程監督構建過程。
光速為何太慢?
凱文·鮑爾斯(Kevin Bowers)詳細闡述了光速過慢的問題。光速是一個有限的常數,它對單個晶體管可以處理的計算數量提供了自然限制。目前,比特通過電子在晶體管中傳輸來進行建模。香農容量定理(即可以在信道上發送的無誤數據的最大量)限制了通過晶體管傳輸的比特數量。由於基本物理和信息理論的限制,計算速度受到電子在物質中移動的速度和可以發送的數據量的限制。當將超級計算機推向極限時,這些約束變得明顯。因此,“計算機在處理數據方面的能力與傳輸數據的能力之間存在顯著的不匹配”。
以 Intel Core i 9 13900 K CPU 為例。它擁有 24 個 x 86 核心,基礎時鐘頻率為 2.2 GHz,最高睿頻時鐘頻率為 5.8 GHz。最壞的情況是光线需要在 CPU 內總共傳播約 52.0 毫米的距離。CPU 的曼哈頓距離(即沿直角軸測量的兩點之間的距離)約為 73.6 毫米。在 CPU 的最高睿頻時鐘頻率 5.8 GHz 下,光线可以在空氣中傳輸約 51.7 毫米。這意味着在單個時鐘周期內,信號幾乎可以在 CPU 的任意兩點之間完成一次往返。
然而,實際情況要糟糕得多。這些測量使用的是光在空氣中的傳播速度,而信號實際上通過二氧化硅(SiO 2)傳輸。在 5.8 GHz 的時鐘周期內,光在二氧化硅中可以傳播約 26.2 毫米。而在硅(Si)中,光在 5.8 GHz 的時鐘周期內只能傳播約 15.0 毫米,略高於 CPU 的長邊的一半。
Firedancer 團隊認為,近年來計算技術的發展更多地是關於將更多核心集成到 CPU 中,而不是提高它們的速度。當人們需要更高的性能時,他們被鼓勵購买更多硬件。在吞吐量是瓶頸的情況下,這在目前是有效的。而實際上的瓶頸是光速。這種自然限制導致了決策的癱瘓。對於任何一種優化,系統中的許多組件都沒有立即的回報,因為它們都沒有進行良好的優化。未經優化的部分會隨着時間的推移而惡化,因為它們可用的計算資源較少。那么,現在怎么辦呢?
在高性能計算領域,一切最終都必須進行優化。結果是建立面向量化交易和量化研究的生產系統,以物理和信息理論的極限運行在全球範圍內。這包括創建定制網絡切換技術,以滿足這些物理限制的無鎖算法。Jump 既是一家科技公司,也是一家交易公司。在科幻和現實的最前沿,Jump 和 Solana 目前面臨的問題有着驚人的相似之處,Jump 正在开發 Firedancer。
Firedancer 是什么
Firedancer 是由 Firedancer 團隊使用 C 語言开發的全新獨立驗證器客戶端。Firedancer 的設計考慮了可靠性,採用模塊化架構、最小的依賴性和廣泛的測試流程。它提出了對 Solana Labs 客戶端的三個功能組件(網絡、運行時和共識)進行重大改寫。每個級別都經過了最大性能的優化,因此客戶端的運行能力只受驗證器硬件的限制,而不會受到當前面臨的軟件效率不足導致的性能限制。通過 Firedancer,Solana 將能夠根據帶寬和硬件進行擴展。
Firedancer 的目標是:
-
記錄和規範化 Solana 協議(最終,人們應該能夠通過查看文檔而不是 Rust 驗證器代碼來創建一個 Solana 驗證器);
-
提高驗證器客戶端的多樣性;
-
提高生態系統的性能。
Firedancer 的工作原理
模塊化架構
Firedancer 通過其獨特的模塊化架構與當前的 Solana 驗證器客戶端有所區別。與 Solana Labs 的 Rust 驗證器客戶端作為單個進程運行不同,Firedancer 由許多稱為“tiles”的獨立 Linux C 進程組成。一個 tile 是一個進程和一些內存。這種 tile 架構是 Firedancer 運行理念和提高魯棒性和效率的方法的基礎。
進程是運行中程序的實例。它是現代操作系統的基本組件,代表一組指令的執行。每個進程都有自己的內存空間和資源,操作系統獨立地分配和管理這些資源,不受其他進程的影響。進程就像是一個大工廠裏獨立的工人,使用自己的工具和工作空間處理特定的任務。
在 Firedancer 中,每個 tile 都是一個具有特定角色的獨立進程。例如,QUIC tile 負責處理傳入的 QUIC 流量,並將封裝的交易轉發到 verify tile。verify tile 負責籤名驗證,其他 tile 也有類似的任務。這些 tile 獨立且並發地運行,共同構成了整個系統的功能。獨立的 Linux 進程可以形成小的、獨立的故障域。這意味着一個 tile 的問題只會對整個系統產生最小的影響,或者說只會有很小的“影響範圍”,而不會立即危及整個驗證器。
Firedancer 架構的一個關鍵優勢是能夠在幾秒鐘內替換和升級每個 tile,且無需任何停機時間。這與 Solana Labs 的 Rust 驗證器客戶端在升級之前需要完全關閉的要求形成鮮明對比。這種差異源於 Rust 缺乏 ABI(應用程序二進制接口)的穩定性,這導致無法在純 Rust 環境中進行即時升級。而採用 C 進程的方式,可以依靠 C 運行時模型中的二進制穩定性,顯著減少與升級相關的停機時間。這是因為各個 tile 在不同的工作空間中管理驗證器狀態。只要驗證器开機運行,這些共享內存對象就會持續存在。在重新啓動或升級過程中,每個 tile 可以無縫地從離开的地方繼續處理任務。
總體而言,Firedancer 是根據 NUMA 感知、基於 tile 的架構構建。在這個架構中,每個 tile 使用一個 CPU 核心。它具有高性能的 tile 之間的消息傳遞,優化了內存局部性、資源布局和組件延遲。
網絡處理
Firedancer 的網絡處理旨在處理 Solana 網絡在升級到每秒千兆比特速度時的高強度需求。這個過程分為入站和出站活動。
入站活動主要涉及接收用戶的交易。Firedancer 的性能非常重要,因為如果驗證器在處理數據包時落後,共識消息可能會丟失。目前 Solana 節點的操作帶寬約為 0.2 Gbps,而 Jump 節點記錄的最大帶寬峯值約為 40 GBps。這種帶寬峯值突顯了一個強大而可伸縮的入站處理解決方案的需求。
出站活動包括區塊打包、區塊創建和發送碎片。這些步驟對 Solana 網絡的安全高效運行至關重要。這些任務的性能不僅影響吞吐量,還影響網絡的整體可靠性。
Firedancer 旨在解決 Solana 以往在處理交易的點對點接口方面存在的問題。過去 Solana 點對點接口的一個重大缺點是其在處理入站交易時缺乏擁塞控制。這個缺點導致了 2021 年 9 月 14 日(17 小時)和 2022 年 4 月 30 日(7 小時)的宕機 。
作為回應,Solana 進行了幾次網絡升級,以正確處理高交易負載。Firedancer 緊隨其後,採用 QUIC 作為其流量控制方案。 QUIC 是一種多路復用的傳輸網絡協議,是 HTTP/3 的基礎。 它在抵御 DDoS 攻擊和管理網絡流量方面起着重要作用。然而,需要注意的是,在某些情況下,成本超過了收益。QUIC 結合數據中心專用硬件用於緩解 DDoS 攻擊,消除了對交易洪水攻擊的動機。
QUIC 的 151 頁規範給开發帶來了相當大的復雜性。由於無法找到符合他們許可、性能和可靠性需求的現有 C 庫,Firedancer 團隊自行構建了自己的實現。Firedancer 的 QUIC 實現,被暱稱為 fd_quic,引入了優化的數據結構和算法,以確保最小的內存分配和防止內存耗盡。
Firedancer 的自定義網絡堆棧是其處理能力的核心。該堆棧從零开始設計,以利用接收端擴展(RSS)。RSS 是一種硬件加速的網絡負載均衡形式,將網絡流量分配到不同的 CPU 核心,以增加網絡處理的並行性。每個 CPU 核心處理一部分傳入流量,幾乎沒有額外开銷。這種方法通過消除復雜的調度器、鎖和原子操作,優於傳統的基於軟件的負載均衡。
Firedancer 引入了一種新的消息傳遞框架,用於組合高性能 tile 的應用程序。這些 tile 可以繞過受限於基於套接字的內核網絡,通過使用 AF_XDP 來利用 AF_XDP,一種專為高性能數據包處理進行優化的地址族。使用 AF_XDP 使 Firedancer 能夠直接從網絡接口緩衝區讀取數據。
這種 tile 系統在 Firedancer 堆棧中實現了各種高性能計算概念,包括:
-
NUMA 感知 - NUMA(非一致性存儲訪問)是一種計算機內存設計,其中處理器訪問自己的內存比訪問與其他處理器關聯的內存更快。對於 Firedancer 來說,具備 NUMA 感知意味着客戶端能夠在多處理器配置中高效處理內存。這對於高交易量處理非常重要,因為它優化了可用硬件資源的利用。
-
緩存局部性 - 緩存局部性指的是利用已經存儲在靠近處理器的緩存中的數據。這通常是一種時間局部性的變體(即最近訪問的數據)。在 Firedancer 中,對緩存局部性的關注意味着它被設計成在最小化延遲和最大化速度的同時處理網絡數據。
-
無鎖並發 - 無鎖並發指的是設計算法時不需要鎖定機制(如互斥鎖)來管理並發操作。對於 Firedancer 來說,無鎖並發允許多個網絡操作並行執行,而無需由於鎖而導致延遲。無鎖並發增強了 Firedancer 同時處理大量事務的能力。
-
大頁面大小 - 在內存管理中使用大頁面大小有助於處理數據集,減少頁面表查找和潛在的內存碎片化。對於 Firedancer 來說,這意味着改進了內存處理的效率。這對於處理大量網絡數據非常有益。
構建系統
Firedancer 的構建系統遵循一組指導原則,以確保可靠性和一致性。它強調最小化外部依賴,並將構建過程中涉及的所有工具都視為依賴項。這包括將每個依賴項(包括編譯器)固定到確切的版本。該系統的一個關鍵方面是在構建步驟期間進行環境隔離。環境隔離增強了可移植性,因為構建過程不受系統環境的影響。
為什么 Firedancer 的速度更快
先進的數據並行性
Firedancer 在加密任務(如 ED 25519 籤名驗證)中採用了現代處理器內部可用的先進數據並行性。現代 CPU 具有用於同時處理多個數據元素的單指令多數據(SIMD)指令,以及優化以每個 CPU 周期運行多個指令的能力。將單個指令並行地作用於數據元素的數組或向量通常在面積、時間和功耗上更為高效。在這方面,與純粹的處理速度提升相比,並行數據處理的改進可以主導吞吐量的提升。
Firedancer 使用數據並行性的一個領域是優化計算籤名驗證。這種方法允許同時處理數組或向量中的數據元素,以最大化吞吐量並最小化延遲。ED 25519 實現的核心是伽羅瓦域運算。這種形式的運算非常適合密碼算法和二進制計算。在伽羅瓦域中,加法、減法、乘法和除法等運算是根據計算機系統的二進制特性進行定義的。下面是一個由 2 ^ 3 定義的伽羅瓦域的例子:
唯一的問題是 ED 25519 使用由 2 ^(255-19)定義的伽羅瓦域。可以將域元素視為從 0 到 2 ^(255-19)的數字。基本運算如下:
加法、減法和乘法幾乎是 uint 256 _t 數學(即使用無符號整數進行計算,其中最大值為 2 ^( 256-1)。除法計算是具有挑战性的。普通的 CPU 和 GPU 不支持 uint 256 _t 數學,更不用說“幾乎 uint 256 _t 數學”,更不用說異常困難的除法了。實現這種數學並使其高性能是一個關鍵問題,取決於我們能夠如何模擬這種數學運算。
Firedancer 的實現通過更靈活地處理數字來分解算術運算。如果我們應用普通長除法和乘法的原則,將數字從一列進位到下一列,我們可以並行處理這些列。最快模擬這種數學運算的方法是將 uint 256 _t 表示為六個 43 位數字,帶有一個 9 位的“進位”。這樣可以在 CPU 上進行現有的 64 位操作,同時為進位位提供足夠的空間。這種數字排列減少了頻繁進位傳播的需求,並使 Firedancer 能夠更有效地處理大數字。
該實現通過將算術計算重新組織為並行化列求和來利用數據並行性。並行處理列可以加速整體計算,因為它將原本可能成為順序瓶頸的任務轉化為可並行化的任務。Firedancer 還使用了矢量化指令集,如 AVX 512 和其 IFMA 擴展(AVX 512-IFMA)。這些指令集允許處理上述伽羅瓦域算術,從而提高速度和效率。
Firedancer 的 AVX 512 加速實現非常快速。在單個 2.3 GHz Icelake 服務器核心上,每個核心的時鐘性能是其 2022 年 Breakpoint 演示的兩倍以上。該實現具有 100% 的矢量通道利用率和大規模數據並行化。這是 Firedancer 團隊的另一個出色演示,由於光速延遲,與一次只能處理一件事情相比,同時進行獨立的並行任務要容易得多,即使使用了定制的硬件也是如此。
利用 FPGA 實現高速網絡通信
CPU 每個核心每秒可以處理大約 30, 000 個籤名驗證。雖然它們是一種高能效的選擇,但在大規模操作方面存在不足。這種限制源於它們的順序處理方法。GPU 將這種處理能力提升到每個核心每秒約 1 百萬個驗證。然而,它們的功耗約為每個單位 300 W,並且由於批處理而具有固有的延遲。
FPGA 成為更好的選擇。它們與 GPU 的吞吐量相匹配,但功耗顯著降低,每個 FPGA 約為 50 W。其延遲也低於 GPU 的十毫秒延遲。FPGA 以大約 200 微秒的延遲提供了更響應的實時處理解決方案。與 GPU 的批處理不同,Firedancer 中的 FPGA 以流式處理的方式單獨處理每個交易。Firedancer 使用 FPGA 的結果是,在功耗低於 400 W 的情況下, 8 個 FPGA 每秒可以處理 800 萬個籤名。
團隊在 Breakpoint 2022 展示了 Firedancer 的 ED 25519 籤名驗證過程。該過程涉及多個階段,包括在純 RTL 流水线中進行 SHA-512 計算,並在自定義 ECC-CPU 處理器流水线中進行各種檢查和計算。基本上,Firedancer 團隊為他們的自定義處理器編寫了一個編譯器和匯編器,從 RFC(請求評論)中獲取了 Python 代碼,使用運算符重載的對象來生成機器代碼,然後將機器代碼放在 ECC-CPU 之上。
值得注意的是,Firedancer 採用了 AWS 加速器的形式因子樣式,以在魯棒性和網絡連接性之間取得平衡。此選擇解決了與直接網絡連接相關的挑战,而這個特性在雲提供商中通常受到限制。通過這種選擇,Firedancer 確保在雲基礎設施的限制下,其先進能力能夠無縫集成。
我們必須認識到,不同的操作需要有實際的物理空間,而不僅僅是概念上的數據空間。Firedancer 通過战略性地安排物理組件的位置,使其緊密且可重復使用。這種配置使 Firedancer 能夠最大化其 FPGA 的效率,在 8 年前的機器上使用 7 年前的 FPGA 實現每秒 800 萬個交易。
網絡通信中的基本挑战是在全球範圍內廣播新交易
互聯網的點對點性質、有限的帶寬和延遲問題限制了實現使用網絡進行直接廣播等傳統方法的可行性。將數據以環形或樹形結構分布部分解決了這些問題,但在傳輸過程中數據包可能會丟失。
Reed-Solomon 編碼是解決這些問題的優選方案。它引入了數據傳輸冗余(即奇偶校驗信息)以恢復丟失的數據包。其基本概念是,兩個點可以定義一條直线,並且在這條直线上的任意兩個點可以重建原始數據點。通過基於數據點構建多項式,並將該函數的不同點分布在單獨的數據包中,只要接收方至少收到兩個數據包,就可以重構原始數據。
我們構建多項式是因為使用傳統的直线上的點的公式(y = mx + b)在計算上比較慢。Firedancer 使用拉格朗日多項式(一種專門用於多項式構建的方法)來加快速度。它簡化了 Reed-Solomon 編碼所需的多項式創建過程。它還將該過程轉化為了一種更高效的矩陣-向量乘法,適用於更高階的多項式。這個矩陣具有高度結構化的特點,其模式以遞歸方式重復出現,使得這個模式的第一行能夠完全確定它。這種結構意味着有一種更快的方法來進行乘法計算。Firedancer 使用了一種 O(n log n)的方法,它在 2016 年的一篇文章中介紹了如何使用這個矩陣進行乘法運算,這是目前已知的 Reed-Solomon 編碼的最快理論方法。其結果是與傳統方法相比,以高效的方式計算奇偶校驗信息:
-
每個核心的 RS 編碼速度超過 120 Gbps;
-
每個核心的 RS 解碼速度高達 50 Gbps;
-
這些指標均與當前約 8 Gbps/核心 RS 編碼 (rust-rse) 進行比較。
使用這種優化的 Reed-Solomon 編碼方法,Firedancer 可以比傳統方法快 14 倍地計算奇偶校驗信息。這使得數據編碼和解碼過程快速可靠,對於在全球範圍內保持高吞吐量和低延遲至關重要。
Firedancer 如何保證安全?
機會
所有的驗證者目前都使用基於原始驗證者客戶端的軟件。如果 Firedancer 與 Solana Labs 的客戶端不同,那么 Firedancer 可以改進 Solana 的客戶端和供應鏈多樣性。這包括使用類似的依賴和使用 Rust 來开發他們的客戶端。
Solana Labs 和 Jito 驗證者客戶端作為一個單獨的進程運行。一旦在生產環境中運行,為單體應用程序添加安全性是困難的。運行這些客戶端的驗證者將不得不關閉以進行純 Rust 的即時安全升級。Firedancer 團隊可以從一开始就構建安全架構來开發他們的新客戶端。
Firedancer 還具有從過往經驗中學習的優勢。Solana Labs 在創業環境中开發了驗證者客戶端。這個快節奏的環境意味着 Labs 需要快速行動,以便快速進入市場。這使得他們未來的开發前景堪憂。Firedancer 團隊可以看看 Labs 做了什么,以及其他鏈上的團隊做了什么,並詢問如果他們可以從頭开始开發驗證者客戶端,他們會做什么不同。
挑战
盡管與 Solana Labs 的客戶端有所不同,但 Firedancer 必須密切復制其行為。如果未能做到這一點,可能會引入一致性錯誤,從而成為安全風險。可以通過激勵一部分份額在兩個客戶端上運行來緩解這個問題,將 Firedancer 的總份額保持在總份額的 33% 以下的時間較長。無論如何,Firedancer 團隊都需要實現協議的完整功能集,無論其實現的難度或安全性如何。一切都必須與 Firedancer 保持一致。因此,團隊不能孤立地开發代碼,必須根據 Labs 客戶端的功能對其進行審查。由於缺乏規範和文檔,這一情況變得更加嚴重,這意味着 Firedancer 必須引入協議中的低效構造。
Firedancer 團隊還必須意識到他們正在使用 C 語言开發他們的新客戶端。C 語言沒有像 Rust 等語言那樣本地提供內存安全性保證。Firedancer 代碼庫的主要目標是減少內存安全性漏洞的發生和影響。需要特別關注此目標,因為 Firedancer 是一個快節奏的項目。Firedancer 必須找到一種在不引入此類錯誤的情況下保持开發速度的方法。操作系統沙箱是將 Tile 與操作系統隔離的實踐。Tile 只被允許訪問其工作所需的資源和執行系統調用。由於 Tile 具有明確定義的目的,並且 Firedancer 團隊大部分开發了客戶端代碼,根據最小特權原則剝離了 Tile 的權限。
實施深度防御設計
所有軟件在某個時刻都會存在安全漏洞。從軟件將存在錯誤的前提出發,Firedancer 選擇限制任何一個漏洞的潛在影響。這種方法被稱為深度防御。深度防御是一種使用各種安全措施來保護資產的策略。如果攻擊者侵入系統的一部分,存在額外的措施來阻止威脅影響整個系統。
Firedancer 的設計旨在減輕漏洞和利用階段之間的風險。例如,攻擊者很難利用內存安全漏洞。這是因為防止這類攻擊是一個經過深入研究的問題。在 C 語言中,關於內存安全性的深入研究導致了一系列加固技術和編譯器功能,團隊在 Firedancer 中使用了這些技術。即使攻擊者能夠繞過行業最佳實踐,也很難通過利用漏洞來破壞系統。這是由於 Tile 隔離和操作系統沙箱的存在。
Tile 隔離是 Firedancer 並行架構的結果。由於每個 Tile 都運行在自己的 Linux 進程中,它們都有明確的、單一的目的。例如,一個 QUIC Tile 負責處理傳入的 QUIC 流量,並將封裝的交易轉發到驗證 Tile。然後,驗證 Tile 負責進行籤名驗證。QUIC Tile 和驗證 Tile 之間的通信是通過共享內存接口完成的(即 Linux 進程可以在彼此之間傳遞數據)。兩個 Tile 之間的共享內存接口充當着隔離邊界。如果 QUIC Tile 存在一個 bug,允許攻擊者在處理惡意的 QUIC 數據包時執行任意代碼,它不會影響其他 Tile。在一個單體進程中,這將導致立即被攻陷。如果攻擊者利用這個漏洞對多個驗證者進行攻擊,他們可能會對整個網絡造成傷害。攻擊者可能會降低 QUIC Tile 的性能,但 Firedancer 的設計將其限制在了 QUIC Tile 上。
操作系統沙箱是將 Tile 與操作系統隔離的實踐。Tile 只被允許訪問其工作所需的資源和執行系統調用。由於 Tile 具有明確定義的目的,並且幾乎所有的代碼都是由 Firedancer 團隊开發的,根據最小特權原則,Tile 的權限被剝減至最低限度。Tile 被放置在自己的 Linux 命名空間中,提供了對系統的有限視圖。這種狹窄的視圖防止了 Tile 訪問大部分文件系統、網絡和同一系統上運行的任何其他進程。命名空間提供了一個以安全為先的邊界。然而,如果攻擊者具有提升權限的內核漏洞,仍然可以繞過這種隔離。系統調用接口是內核中從 Tile 可達的最後一個攻擊向量。為了防止這種情況,Firedancer 使用 seccomp-BPF 在內核處理系統調用之前過濾它們。客戶端可以將 Tile 限制在一組選擇的系統調用中。在某些情況下,可以過濾系統調用的參數。這一點很重要,因為 Firedancer 可以確保 read 和 write 系統調用只對特定的文件描述符操作。
採用嵌入式安全計劃
在 Firedancer 的开發過程中,注重在每個階段嵌入全面的安全程序。客戶端的安全程序是开發團隊和安全團隊之間持續合作的結果,為安全的區塊鏈技術樹立了新的標准。
該過程始於自助模糊測試基礎設施。模糊測試是一種自動檢測崩潰或指示漏洞的錯誤條件的技術。通過對接受不可信用戶輸入的每個組件進行壓力測試,包括P2P接口(解析器)和 SBPF 虛擬機,來進行模糊測試。在代碼更改期間,OSS-Fuzz 保持持續的模糊覆蓋率。安全團隊還建立了一個專用的 ClusterFuzzer 實例,用於持續的覆蓋引導模糊測試。开發人員和安全工程師還提供模糊測試的工具(即針對安全關鍵組件的特殊版本的單元測試)。开發人員還可以貢獻新的模糊測試,這些測試會被自動接收和測試。目標是在進入下一個階段之前對所有部分進行充分的模糊測試。
內部代碼審查有助於發現工具可能忽略的漏洞。在這個階段,重點放在高風險、高影響的組件上。這個階段是一個反饋機制,為安全程序的其他部分提供反饋。團隊將所有的經驗教訓應用在這些審查中,用於提高模糊測試的覆蓋率,為特定的漏洞類別引入新的靜態分析檢查,甚至實施大規模的代碼重構,以排除復雜的攻擊向量。外部安全審查將由行業領先的專家和活躍的漏洞賞金計劃進行補充,包括在發布前和發布後。
Firedancer 還經歷了在各種測試網絡上的廣泛壓力測試。這些測試網絡將面臨各種攻擊和故障,如節點復制、網絡鏈接失敗、數據包洪泛和共識違規。這些網絡承受的負載遠遠超過主網上任何實際情況。
所以,這就引出了一個問題:Firedancer 目前的狀態如何?
Firedancer 的現狀如何,Frankendancer 又是什么?
Firedancer 團隊正在逐步开發 Firedancer,以模塊化驗證器客戶端。這與他們對文檔和標准化的目標一致。這種方法確保 Firedancer 與 Solana 的最新發展保持同步。這導致了 Frankendancer 的創建。Frankendancer 是一種混合客戶端模型,Firedancer 團隊將其开發的組件集成到現有的驗證器客戶端基礎架構中。這種开發過程允許逐步改進和測試新功能。
Frankendancer 就像將一輛跑車置於交通中心。隨着更多組件的开發和瓶頸的消除,性能將不斷提升。這種模塊化开發過程促進了可定制和靈活的驗證器環境。在這裏,开發人員可以根據自己的需求修改或替換驗證器客戶端中的特定組件。
實際運行的是什么
Frankendancer 實現了 Solana 驗證器的所有網絡功能:
-
入站:QUIC、TPU、Sigverify、Dedup
-
出站:塊打包、創建/籤名/發送 Shreds(Turbine)
Frankendancer 在 Solana Labs 的 Rust 運行時和共識代碼之上使用了 Firedancer 高性能的 C 網絡代碼。
Frankendancer 的架構設計注重高端硬件優化。雖然它支持運行標准 Linux 操作系統的低端雲主機,但 Firedancer 團隊正在為高核心數服務器優化 Frankendancer。長期目標是利用雲中已有的硬件資源來提高效率和性能。該客戶端同時支持多個連接、硬件加速、用於負載分布的隨機化流量導向(確保網絡流量均勻分布)以及為各個組件之間提供額外安全性的多個進程邊界。
技術效率是 Frankendancer 的基石。該系統避免在關鍵路徑上進行內存分配和原子操作,所有分配在初始化時都經過 NUMA 優化。這種設計確保了最大的效率和性能。此外,異步和遠程檢查系統組件的能力,以及對 Tile 的靈活管理(異步啓動、停止和重啓),為系統增加了一層穩健性和適應性。
Frankendancer 的表現如何?
Frankendancer 每個 Tile 在網絡入站端可以處理每秒 1, 000, 000 個交易(TPS)。由於每個 Tile 使用一個 CPU 核心,因此該性能與使用的核心數成线性比例。Frankendancer 通過僅使用四個核心,並充分利用每個核心上的 25 Gbps 網絡接口卡(NIC)來實現了這一成就。
在網絡出站操作方面,Frankendancer 通過其 Turbine 優化取得了顯著的改進。目前的標准節點硬件每個 Tile 實現了 6 Gbps 的速度。這包括了在分片(即如何將塊數據分割並發送到驗證者的網絡中)方面的大幅速度提升。與當前的標准 Solana 節點相比,Frankendancer 在沒有 Merkle 樹的情況下顯示出了約 22% 的分片速度提升,而在使用 Merkle 樹時幾乎翻了一番。這對於當前驗證者的塊傳播和交易接收性能來說是巨大的改進。
Firedancer 的網絡性能表明它已達到硬件極限,實現了與當今標准驗證器硬件相比的最大性能。這標志着一個重要的技術裏程碑,展示了客戶端有效高效地處理極端工作負載的能力。
Frankendancer 已上线測試網
Frankendancer 目前正在測試網絡上進行質押、投票和出塊。它與 Solana Labs 和 Jito 約 2900 個其他驗證者兼容共存。這個實際部署展示了 Firedancer 在普通硬件上的強大性能。目前,它部署在一臺 Equinix Metal m 3.large.x 86 服務器上,配備 AMD EPYC 7513 CPU。許多其他驗證者也使用相同類型的服務器。它提供了一種經濟實惠的解決方案,按需定價根據地點不同而有所變化,費率在每小時 3.10 美元至 4.65 美元之間。
Firedancer 朝着主網上线取得的進展為節點硬件帶來了幾個可能性:
-
當前驗證器硬件可以實現更高的每個節點性能容量;
-
Firedancer 的高效性使驗證者可以使用更經濟實惠、規格較低的硬件,同時保持類似的性能水平;
-
Firedancer 的設計使其能夠利用硬件和帶寬的進步。
這些發展,以及其他一些倡議,如 Wiredancer(即 Firedancer 團隊對硬件加速的實驗)和基於 Rust 的模塊化運行時/SVM,使 Firedancer 成為一種具有前瞻性的解決方案。
Firedancer 的進展也引發了關於是否讓驗證者在 Firedancer 旁邊運行 Solana Labs 客戶端的討論,這被稱為並行運行。這種方法可以通過充分利用兩個客戶端的優勢,並減輕任一客戶端在整個網絡中的潛在影響,從而最大程度地提高網絡的活躍性。此外,這也引發了關於像 Jito 這樣的項目是否會考慮分叉 Firedancer 的推測。這可能會進一步優化 MEV 提取和交易處理效率。只有時間能告訴我們。
結論
开發人員通常將操作視為佔據數據空間而不是物理空間。在光速作為自然限制的情況下,這種假設會導致系統變慢,無法正確優化其硬件。在一個高度對抗性和競爭性的環境中,我們不能簡單地將更多的硬件投入到 Solana 中,並期望它表現更好。我們需要進行優化。Firedancer 革新了驗證者客戶端的結構和操作方式。通過構建一個可靠、高度模塊化和高性能的驗證者客戶端,Firedancer 團隊正在為 Solana 的大規模採用做准備。
無論您是初級开發人員還是普通的 Solana 用戶,了解 Firedancer 及其意義是至關重要的。這一技術壯舉使目前市場上最快、最高性能的區塊鏈變得更加出色。Solana 旨在成為一個高吞吐量、低延遲的全球狀態機。Firedancer 是朝着完善這些目標邁出的巨大一步。
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。
Uniswap公告Unichain主網明年初上線!首測路線圖兩功能,UNI強彈17%
去 中心化交易所(DEX)龍頭 Uniswap 於 10 月宣佈推出專為 DeFi 設計的 Lay...
下周必關注|LayerZero決定是否开啓“費用开關”;Aligned空投注冊結束(12.23-12.29)
下周重點預告 12 月 23 日 Aligned 將向 891322 個地址空投 26% 的 AL...
空投周報 | OpenSea基金會官推上线;Azuki、Doodles疑似即將發幣(12.16-12.22)
@OdailyChina @web3_golem Odaily星球日報盤點了 12 月 16 日至...
資金費率的演變:從2021年黃金時代,到2024-2025年套利復興
資金費率起源 資金費率起源於加密貨幣衍生品市場,特別是從永續期貨合約中發展而來。它作為一種機制,用...
星球日報
文章數量
7670粉絲數
0