ERPC 推出了 Shredstream UDP Forwarding：一种通过 UDP 将原始 Solana Shreds 直接转发至指定 IP 地址与端口的交付方式。本文从协议选择、目标地址的生效机制、接收端实现以及区域部署几个角度，梳理这种交付方式的技术设计。
为什么选择 UDP
UDP 是一种简单、低开销的协议，传送数据时不会先等待确认、重传或按序交付。因此，它非常适合到达时间比交付保证更重要的工作负载。
Shreds 就是一个典型的例子。它们越早抵达应用程序，价值就越高，因此在延迟敏感型场景中，UDP 的特性与数据的使用方式高度契合。
对于更看重顺序和交付保证的工作负载，通过 gRPC 交付的 Shredstream 与 Geyser gRPC 仍照常提供。两种交付方式并存，可以根据工作负载的特性进行选择：
| 交付方式 | 确认 / 重传 / 按序交付 | 适合的工作负载 |
|---|---|---|
| UDP（Shredstream UDP Forwarding） | 不等待 | 到达时间优先 |
| gRPC（Shredstream / Geyser gRPC） | 由协议保证 | 顺序与交付保证优先 |
目标地址的生效机制：30 秒周期读取，无需重启
使用时只需选择区域，并提供用于接收数据的公网 IPv4 地址和端口，交付节点即会将原始 Shreds 直接转发至该目标地址。
目标地址设置由交付节点以 30 秒为周期读取，无需重启节点。目标地址的变更同样通过这一机制生效，因此可以在服务持续运行的同时更新转发目标。
每个订阅对应一个目标地址，即单个公网 IPv4 地址与端口的组合。如需在多个目标地址接收 Shreds，需要为每个目标地址分别配置订阅。
接收端实现：无会话、无心跳
这种交付方式无需建立会话，也无需维持心跳。接收端应用程序需要做的只有三件事：
- 绑定一个 UDP 套接字；
- 放行来自交付源地址的入站 UDP；
- 直接解码收到的原始 Shreds。
下面是一个最小的接收循环示例（Python，端口号需与订阅中登记的端口一致）：
python
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(("0.0.0.0", 8001)) # 与登记的目标端口一致
while True:
data, addr = sock.recvfrom(2048) # 缓冲区需大于单个数据报
handle_shred(data) # 交给 Shred 解码逻辑由于没有连接状态需要维护，接收端的重启、扩容或迁移都不涉及会话重建；目标地址变更也只需等待下一个 30 秒读取周期。
交付由自有的区域基础设施承载
在每个区域，Shreds 均由直接运营的 ERPC 生产节点供给，面向接收端的 UDP 转发也由该基础设施提供。
交付路径由 ERPC 自行运营，因此可以将从 Solana 网络到接收端套接字的整条链路视为一个整体系统，进行测量、调优和持续优化。
6 个区域与物理距离
可选区域共 6 个：阿姆斯特丹、法兰克福、伦敦、纽约、东京和新加坡。
物理距离无法通过工程手段消除。光在光纤中每毫秒大约传播 200 公里，再多的 CPU、NIC 或内核优化，也无法追回跨越漫长地理距离所耗费的时间。要更早到达，交付就需要从更靠近接收方的位置开始。
粗略估算：阿姆斯特丹与东京之间的大圆距离约 9,300 公里，仅光纤传播的单程时间下限就约为 46 毫秒，而实际光纤路径通常更长。因此，把接收端部署在与交付区域相同或相近的位置，是降低端到端延迟最直接的手段。
这 6 个地点均为 ERPC 已在运营 Solana 基础设施的区域，UDP 转发依托的是同一套针对延迟持续优化的网络与数据中心布局。
产品线变化：从"机器"到"交付本身"
专用 Shredstream 产品与 Stream Bundle 已于 9 月 5 日停止服务，产品线围绕 UDP 交付重新构建。此前的专用产品以服务器和端点为单位，而 Shredstream UDP Forwarding 围绕低延迟 Shreds 交付本身构建，而非承载这一交付的具体机器。
共享型 Shreds 产品保持不变：Direct Shreds Connect、Shreds Bundle 多 IP 方案，以及 ERPC Bundle 方案中包含的 Direct Shreds Connect 均继续提供。通过 gRPC 交付的 Shredstream 同样继续提供，Yellowstone Geyser gRPC 不受影响。
小结
Shredstream UDP Forwarding 的设计可以概括为三点：用 UDP 让 Shreds 以最短路径抵达接收端；以 30 秒周期读取目标地址，免去会话与心跳管理；在 6 个区域由自有生产节点承载交付，从更靠近接收方的位置开始传输。对于延迟敏感型的 Solana 数据处理，交付方式与部署位置本身就是架构设计的一部分。