ERPC 發布 Solana Stream SDK v4.0.0,加速 UDP Shreds 處理與 gRPC 連線恢復

ERPC 發布 Solana Stream SDK v4.0.0,加速 UDP Shreds 處理與 gRPC 連線恢復

ERPC 發布 Solana Stream SDK v4.0.0,加速 UDP Shreds 處理與 gRPC 連線恢復
ELSOUL LABO B.V. 與 Validators DAO 於 2026 年 11 月 6 日正式發布 Solana Stream SDK v4.0.0。這是一套用於處理 Solana 串流資料的開源 SDK。本機基準測試測得,Rust UDP Shreds 內部處理速度約為原本的 108 倍,TypeScript 事件佇列吞吐量約為原本的 4 倍。Geyser gRPC 在連線中斷後也能更快恢復接收更新。SDK 可免費使用,並提供 Rust 與 TypeScript 範例,協助開發者開始建置應用程式。
要在應用程式中發揮低延遲資料傳遞的優勢,也取決於處理傳入資料的速度。v4.0.0 提高了資料抵達後的內部處理效率,並改善了連線中斷後的恢復機制。搭配 ERPC Shreds UDP Forwarding Premium,開發者可以同時改善 Solana 應用程式的資料傳遞路徑與接收端實作。

透過三項測試衡量處理與恢復效能的改善

Solana Stream SDK v4.0.0 的 Rust UDP 內部處理、TypeScript 事件佇列與 gRPC 連線恢復比較
在 Rust UDP 接收路徑中,v4 加速了資料報解碼、插入內部緩衝區,以及從 Shreds 重建資料的 deshred 處理。透過調整原本對每個封包重複執行的內部狀態清理與時鐘讀取操作,在維持資料保留期限的同時,降低了處理負擔。在比較測試中,每個資料報的內部處理時間從 94,236 ns 縮短至 855–881 ns,處理速度約為原本的 108 倍。
該基準測試在 Apple M 系列 Mac 上執行,每次處理涵蓋 300 個 slot 的 403,200 個資料報,並以 5 次執行的中位數進行比較。測量範圍為 decode→insert→deshred 內部處理路徑,不包括網路傳遞時間,也不包括使用者應用程式的後續處理。減少重建傳入 Shreds 所需的運算工作,有助於開發者將更多運算資源用於應用程式邏輯。
TypeScript Geyser gRPC 範例與入門專案減少了佇列中仍有事件時的等待,讓已接收的資料能更有效率地被取出。在 Node.js 24 上處理 200 萬個事件的佇列單獨測試中,吞吐量從每秒 570 萬至 740 萬個事件,提升至每秒 2,480 萬至 2,940 萬個事件,約為原本的 4 倍。
Geyser gRPC 更新了負責重新連線的用戶端及首次重試間隔。在本機 tonic 伺服器上觸發 20 次連線中斷的測試中,每次中斷前後所接收更新之間的間隔中位數,從 3.0 runner 的 552 ms 縮短至 4.0 runner 的 103 ms。這項測試測量的是本機測試環境中恢復接收更新所需的間隔。
這三項結果來自測量範圍與條件各不相同的測試,分別呈現 Rust 內部處理、TypeScript 事件佇列及 gRPC 重新連線的改善幅度。實作細節與測試條件已公開於「相關連結」中的 PR #129。

延續 Alpenglow 支援並更新用戶端

Alpenglow 支援已在 v3.0.0 中導入。v4.0.0 延續了區塊標記與項目(entries)的區分:區塊標記表示區塊標頭、區塊尾部及父區塊的更新,項目則包含交易。應用程式可以將區塊結構資訊與需要處理的項目分開處理。
v4.0.0 將用戶端更新至 Agave 4.4.1 與 Yellowstone gRPC 17.x。重新連線時,Disconnected 事件可以回報用於識別尚未完整接收之資料的資訊,以及恢復位置。這些資訊讓應用程式能自行實作對重複重播資料及僅接收到部分內容之資料的處理。
從 v3 遷移至 v4 時,Geyser 的 protobuf 定義維持不變,重新連線事件以及 Rust 中使用的 Solana message 與 transaction 型別則有所更新。已發布的遷移指南說明了事件處理函式與相依套件版本的變更。

UDP 使用 Rust,gRPC 支援 Rust 與 TypeScript

已發布的 Rust 套件 solana-stream-sdk 與 TypeScript 套件 @validators-dao/solana-stream-sdk 均提供 v4.0.0。各連線方式支援的語言如下。
連線方式支援的語言
Shreds UDPRust
Geyser gRPCRust 與 TypeScript
Shreds gRPCRust 與 TypeScript
透過 UDP 接收 Shreds 時,請使用 Rust 用戶端。Rust UDP 範例與入門專案使用已發布的 SDK v4.0.0,可用來嘗試接收資料、從 Shreds 重建資料,以及偵測所監控程式的指令。開發者可以修改監控目標與偵測後的處理邏輯,將其作為建置自身應用程式的起點。
使用 TypeScript 開發時,可選擇 Geyser gRPC 或 Shreds gRPC。本次發布的事件佇列改善已納入 Geyser gRPC 範例與入門專案。請依據所使用的語言與資料傳遞方式,選擇相應的已發布實作。

發揮 Shreds UDP Forwarding Premium 的傳遞優勢

ERPC Shreds UDP Forwarding Premium 將各區域內的多個節點連成網狀網路,並轉送該網路最先收到的每個 Shred 副本。資料經傳遞路徑抵達的時間,以及抵達後 SDK 內部重建資料所需的時間,都會影響接收的資料何時能夠使用。Rust UDP 接收處理的改善可應用於接收端,用來處理 Premium 傳遞的資料。
在 2026 年 10 月 30 日於法蘭克福進行的比較中,測試在同一台機器上使用同一個時鐘,同時擷取 Standard 與 Premium 的資料 120 秒,並從 pcap 中比對內容相同的 UDP 酬載。在這個配對集合中,Premium 有 98% 率先抵達,抵達時間差的中位數為 1.78 ms。在 Standard 中觀測到的酬載裡,有 93.9% 也在 Premium 中被觀測到。
在法蘭克福相同條件下比較 Shreds UDP Forwarding Premium 與 Standard 的率先抵達結果
Premium 圖表呈現不同傳遞路徑之間的抵達時間差,SDK 圖表則呈現接收端的內部處理與連線恢復。在實際應用程式中,同時記錄封包抵達時間與偵測到相關指令的時間,可用來確認傳遞環節的領先優勢有多少最終反映在處理結果上。

透過按小時計費與範例,在自身環境中進行比較

Shreds UDP Forwarding Premium 支援按小時計費,價格為每小時 €1.39。可以從儀表板開始使用服務,並透過 Rust UDP 入門專案驗證接收情況。維持區域、接收伺服器及應用程式工作負載一致,即可分別評估抵達時間差與接收後的處理時間。
首先,在儀表板登記公用 IPv4 位址與 UDP 連接埠,並允許來自頁面所列來源的傳入流量。使用 Rust UDP 入門專案確認封包接收與資料重建後,再將需要監控的程式與應用程式的實際處理流程納入評估。搭配範例與傳遞服務,即可在自身環境中測量從接收到偵測的時間。

相關連結