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 数据处理,交付方式与部署位置本身就是架构设计的一部分。

相关推荐
2603_954708311 分钟前
微能网的核心硬件协调控制装置有哪些功能?
大数据·运维·人工智能·架构·能源
@不误正业22 分钟前
技术线05_端侧小模型不可靠先检查你的Agent架构
人工智能·架构·agent·端侧模型·4b
安易算力32 分钟前
GPU集群调度实践:Slurm/K8s混合部署与GPU共享优化 —— 从批处理到在线推理的统一调度架构
容器·架构·kubernetes
mldong1 小时前
一条审批流的数据库账:5 张核心表、3 张扩展表、0 张表单表
后端·架构
网络小江9 小时前
组网第十课:编码、速率与排障——从比特到信号的最后一公里
网络协议
网络小江9 小时前
上网第四十三课:路由原理——数据包是怎么找到路的
网络协议
Devlive 开源社区10 小时前
AuthX 正式更名 GrantForge:我们重新做了一遍权限管理系统
大数据·人工智能·架构
微三云生态系统架构师-彭丹11 小时前
抖店OPC智能选品与铺货架构:多店差异化与频率风控设计
架构
集智飞行12 小时前
无人机集群通信架构剖析,以及对未来发展的几点判断
架构·无人机
想要打 Acm 的小周同学呀12 小时前
无需自己设计Agent架构的业务系统,依赖第三方Agent,基于SKILL和MCP服务实现企业级内部提效工具开发
架构·agent