Solana Stream SDK 新增 Solana v3 支援

ELSOUL LABO B.V.（總部：荷蘭阿姆斯特丹，CEO：Fumitake Kawasaki）與 Validators DAO 釋出了開源 Solana Stream SDK 的新版本，已全面更新以支援 Solana v3 升級。Rust 和 TypeScript 版本均已升級，以確保在即將到來的 Alpenglow 時代可靠且高效能地訪問 Solana 的實時資料流，包括 Shreds 和 Geyser gRPC。

Rust crate solana-stream-sdk 現已透過 0.6.1 版本支援 Solana v3，TypeScript / Node.js 包 @validators-dao/solana-stream-sdk 已更新至 0.12.0 版本。它們共同為 Solana 過渡到下一代架構時的高效能流處理提供了統一基礎。

背景——為什麼 Solana v3 和 Alpenglow 需要客戶端更新

Solana v3 標誌著向新的 Alpenglow 共識架構的重大轉變。Alpenglow 用重新設計的共識路徑取代了現有的 TowerBFT + 歷史證明組合，旨在大幅提升網路響應性。在 Alpenglow 下，最終性預計將從目前的約 12 秒縮短到約 100-150 毫秒。這一轉變從根本上改變了區塊生產的速度和實時資料在網路中的傳播特性。

同時，驗證者和 RPC 運營者在 v3 下面臨更高的運維要求，構建週期和配置更新更加頻繁。Validators DAO 一直在透過 SLV 等工具現代化服務端環境，但這一轉變也突顯了一個關鍵點：

客戶端軟體也必須更新到 v3，否則網路的效能提升無法完全實現。

這對於 Shreds 和 Geyser gRPC 等實時流尤其如此。不遵循新規範或執行時特性的客戶端往往會隨時間累積延遲或失去一致性。隨著 RPC 節點和驗證者遷移到 v3，客戶端軟體現在必須並行遷移。

此 Solana Stream SDK 更新的目標是彌合這一差距，為 Alpenglow 時代的實時應用提供即用的基礎。

Solana Stream SDK v0.6.1（Rust）和 v0.12.0（TypeScript）的新功能

Solana Stream SDK 從一開始就設計為同時支援 Shreds 和 Geyser gRPC。在此版本中，SDK 進行了多項改進，以確保在 Solana v3 上的穩定效能和對基於 Alpenglow 執行時的準備。

Rust Crate v0.6.1

Rust 版本設計為交易者、索引器和任何需要最大吞吐量的實時工作負載的高效能參考實現。主要更新包括：

支援 Solana v3 系列中的協議變更
透過 Rust 的非同步執行時高效處理 Shreds 和 Geyser gRPC 流
圍繞 Shreds 相關 protobuf 定義的精煉封裝，使流處理邏輯更易實現
最佳化的多執行緒執行路徑，即使在持續高吞吐量下也能最小化延遲累積

Rust 版本推薦給需要在最高效能水平上充分利用 Shreds 和 Geyser gRPC 的使用者。

TypeScript / Node.js v0.12.0

TypeScript 版本旨在保留 Node.js 開發的人體工程學，同時在底層整合 Rust 驅動的流處理。在 v0.12.0 中，應用了以下增強：

完全保留現有的事件驅動介面（如 emitter.on），避免破壞性變更
整合 Rust 和 NAPI-RS 用於內部流處理，允許 Node.js 在 @grpc/grpc-js 之前達到瓶頸的地方可靠地處理 Shreds
更新了 Geyser gRPC 和 Shreds 流的處理，以確保與 Solana v3 的相容性

對於大多數使用者來說，升級到 v0.12.0 只需在 package.json 中更新版本號——無需修改程式碼。

為什麼僅靠 Node.js 無法跟上 Shreds

ShredStream 是 Solana 生態系統中延遲最低、頻率最高的資料來源。雖然 Shreds 能夠提供對網路活動的無與倫比的實時可見性，但它們也要求客戶端具有非常高的處理吞吐量。

基於 @grpc/grpc-js 構建的 Node.js 客戶端面臨結構性瓶頸：

事件迴圈是單執行緒的，因此 protobuf 反序列化和使用者回撥互相阻塞
當訊息快速到達時，JavaScript 執行緒會飽和，處理佇列不斷增長
HTTP/2 流量控制在緩衝區填滿時減少接收視窗，最終暫停流並導致"網路變慢"或"無資料"的假象

在許多觀察到的案例中，問題不在於網路也不在於 ShredStream 伺服器——而是 Node.js 客戶端內部跟不上。

這一限制在大規模處理未過濾 Shreds 時是 Node.js 固有的。

Rust + NAPI-RS 克服了這一點。

Rust + NAPI-RS 如何加速 Node.js 流處理

Solana Stream SDK 的 TypeScript 版本將繁重的工作交給 Rust，同時保留熟悉的 JavaScript API。

gRPC 連線管理、流攝取和 protobuf 反序列化在 Rust 中非同步執行
Node.js 以標準流或事件發射器的形式接收處理後的資料，允許現有程式碼繼續按原樣工作
NAPI-RS 最小化 Rust 和 Node.js 之間的開銷，在 JavaScript 介面背後實現真正的多執行緒吞吐量

因此，使用 Solana Stream SDK 編寫的應用可以處理比使用 @grpc/grpc-js 的純 Node.js 方法顯著更大的 Shred 和 Geyser gRPC 吞吐量，同時即使在高流量下也保持穩定的延遲特性。

為什麼在一個 SDK 中同時支援 Shreds 和 Geyser gRPC 很重要

Solana 的實時資料可以在兩個互補層中檢視：

Shreds：直接從 leader 發出的超低延遲碎片，提供鏈上活動的最早檢視
Geyser gRPC：槽位、交易和賬戶更新的結構化流，提供清晰且可預測的資料模型

Solana Stream SDK 使開發者能夠從 Geyser gRPC 開始瞭解資料結構，然後過渡到 Shreds 以應對超低延遲場景——無需切換工具或重寫管道。

隨著 Alpenglow 加速區塊生產和確認，這種雙層方法變得更加有價值。

入門：資源和測試環境

Solana Stream SDK 完全開源，Shreds 和 Geyser gRPC 的示例程式碼在 GitHub 上可用。

Rust Crate（v0.6.1）：https://crates.io/crates/solana-stream-sdk npm（TypeScript，v0.12.0）：https://www.npmjs.com/package/@validators-dao/solana-stream-sdk GitHub - Solana Stream SDK：https://github.com/ValidatorsDAO/solana-stream

對於真實測試，ERPC 提供高效能 ShredStream 和 Geyser gRPC 端點的一日免費試用，允許開發者在生產級條件下驗證 v3 行為。

ERPC 官方網站：https://erpc.global/

加入 Validators DAO 社群

關於 Solana v3、Alpenglow、實時流設計或 SDK 改進的問題、回饋和討論，歡迎加入 Validators DAO 社群。

Validators DAO 官方 Discord：https://discord.gg/C7ZQSrCkYR

隨著 Solana 過渡到 Alpenglow 時代，其網路將實現前所未有的實時效能水平。Validators DAO 和 ELSOUL LABO 將繼續提供高質量的開源工具，幫助開發者在 Solana 上構建下一代實時應用。

感謝您的持續支援。