企业官网建设流程全解析

在 Solana 的实时处理中，决定数据到达时间的往往不是单台服务器的规格，而是从数据产生到抵达应用程序为止的整条传输路径。本文从传输路径的角度，梳理 Shreds 的两种获取方式（UDP 直发与 gRPC 订阅）各自适合的场景，以及把"传输本身"作为服务单位所带来的结构差异。

Shreds 与传输路径

Shreds 是 Solana 在区块最终形成之前，于网络中传播的分片数据。对于需要尽可能早获取链上状态的应用而言，Shreds 是比区块更早的一层数据源。

正因为它的价值在于"早"，所以传输路径上的每一层处理都会直接抵消这份优势。网络距离、跳数、转发处理、抖动，以及传输途中存在的任何处理层，都会体现在实际的到达时间上。

换句话说，Shreds 的工程问题不是"如何更快地计算"，而是"如何更短地传输"。

UDP 直发与 gRPC 订阅的取舍

获取 Shreds 主要有两条路径。

gRPC 订阅：基于 HTTP/2 与 TCP。具备连接管理、重传与顺序保证，稳定性高，接入方式也符合大多数服务端框架的既有习惯。代价是连接建立与错误处理带来的额外开销。

UDP 直发：无连接。数据从传输端直接发往接收端指定的 IP:port，不做重传与顺序保证。丢包由应用层自行处理，换来的是更短的处理链路与更低的抖动。

两者并非替代关系，而是取舍关系：

• 以最低延迟为最优先的场景 → UDP
• 以现有 gRPC 接口进行流订阅、看重稳定性的场景 → Shredstream gRPC

ERPC 在这两条路径上都会持续提供服务。此次产品线调整中终止的是专用型 Shredstream 产品（以及 Stream Bundle），2026 年 9 月 5 日之后不再提供；而通过 gRPC 接收 Shreds 的既有产品不受影响。

端到端路径：延迟由哪些部分构成

把 Solana 网络到应用程序之间视为一个整体系统时，影响到达时间的要素大致可以拆成以下几层：

• 邻近性：与 Solana 网络的物理与网络距离
• 数据中心与网络路径：跳数、对等互联质量、拥塞状况
• 服务器硬件与 NIC：中断处理、队列、卸载能力
• OS 与内核：网络栈配置、调度、缓冲区
• 最终传输方式：数据以何种协议、经过多少中间层交付给用户

只优化其中一层，收益通常会被其他层吃掉。高速 CPU 与 NIC 无法弥补物理距离带来的传输时间；同样，路径再短，若最终交付环节多了一层代理或转换，抖动也会随之增加。

Shredstream gRPC 与 Geyser gRPC 的分工

两者都使用 gRPC，但传输的数据与用途不同，实践中经常被混为一谈。

Shredstream：面向 Shreds 的数据源，目的是在尽可能早的阶段获取分片数据。适合对"时间点"敏感的应用。

Yellowstone Geyser gRPC：以实时流的形式订阅 validator 已处理完成的交易、账户、区块等数据。数据结构完整、语义明确，适合需要可直接消费的结构化数据的场景。

选型时的判断标准并不是"哪个更快"，而是"需要的是更早的原始数据，还是已处理完成的结构化数据"。

把"传输本身"作为服务单位

传统做法是把专用服务器或专用端点作为产品单位：用户购买的是一套环境，传输是这套环境附带的能力。

这种结构在工程上有一个副作用——优化的对象变成了"环境"，而用户真正需要的是"数据更快到达"。两者并不总是一致。

因此新的做法是把传输路径本身作为服务单位：由传输端直接把 Shreds 通过 UDP 发往用户指定的 IP:port，中间不再保留以"环境"为单位的抽象层。路径变短，可控的变量也随之减少。

ERPC 计划于 2026 年 9 月提供的 UDP Shreds Forwarding 采用的正是这一结构。

小结

• Shreds 的价值在于"早"，因此传输路径上的每一层处理都值得单独评估
• UDP 与 gRPC 是取舍关系：前者压缩延迟与抖动，后者提供稳定性与既有接口兼容
• Shredstream 与 Geyser gRPC 的区别在于数据阶段（原始分片 vs 已处理结构化数据），而非速度
• 端到端延迟由邻近性、网络路径、硬件、内核与最终交付方式共同决定，单点优化收益有限
• 把传输本身作为服务单位，可以减少路径上的抽象层，使延迟更可控