Solana Stream SDK 新增 Solana v3 支持

Solana Stream SDK 新增 Solana v3 支持

2025.12.10
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 上可用。
对于真实测试,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 上构建下一代实时应用。
感谢您的持续支持。