Solana Shreds 的 UDP 直投架构:Shredstream UDP Forwarding 的设计与实现

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,需要为每个目标地址分别配置订阅。

接收端实现:无会话、无心跳

这种交付方式无需建立会话,也无需维持心跳。接收端应用程序需要做的只有三件事:

  1. 绑定一个 UDP 套接字;
  2. 放行来自交付源地址的入站 UDP;
  3. 直接解码收到的原始 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 数据处理,交付方式与部署位置本身就是架构设计的一部分。

相关推荐
青瓦梦滋11 小时前
WebSocket协议
linux·服务器·网络·c++·websocket·网络协议·http
IpdataCloud14 小时前
批量查IP的API接口怎么选?免费API配额瓶颈与离线库本地批量方案实测
网络·网络协议·tcp/ip
天河归来14 小时前
从原始消息到业务数据:三层数据架构的设计与实践
数据库·数据仓库·架构
天远Date Lab15 小时前
零信任架构实战:基于天远企业年报信息核验构建自动化商业保理财务与社保穿透评估网关
人工智能·架构·自动化
EnCi Zheng15 小时前
后端怎么把AI接口稳定安全低成本接进业务:超时重试、密钥隔离与成本熔断清单
人工智能·后端·安全·架构·api
救救孩子把15 小时前
LangGraph 工程化架构:类型、状态、流式通信与可观测性
架构·agent·trace·opentelemetry·langgraph·graphrag
这个DBA有点耶16 小时前
从 MySQL 到时序数据库:我帮朋友做迁移的完整记录
数据库·架构·dba
wu_solo16 小时前
6.1 Transformer架构概述
深度学习·架构·transformer
张一凡9316 小时前
把“不要乱改”从提示词里拿出来,放进可校验的提案里
前端·后端·架构
IvorySQL16 小时前
PostgreSQL 日报| WAL summarizer 断言失败(10 月 26 日)
数据库·postgresql·区块链