Jito ShredStream：构建并测量低延迟 Solana Shred 数据管道

直接答案与范围

Jito ShredStream 是一项服务，它将 Solana shred——验证者用于传播区块的片段——从区块领导者以比默认网络路径更低的延迟流式传输给订阅者。订阅者通常运行开源的 shredstream-proxy 客户端，该客户端使用密钥对进行身份验证，连接到区域端点，并在本地暴露传入的 shred 以供解码或转发。

本指南侧重于工程工作流程：先决条件、代理配置、解码、验证、延迟测量方法以及迁移规划。它不推荐特定的端点或提供商；有关具体的端点和提供商选择，请使用下方链接的 RPC Assistant 资源。文档中记录的行为与建议以及您必须在自己的环境中进行的测量是分开的。

• 文档记录：Jito 的文档将 ShredStream 描述为提供低延迟 shred，并包含一份停用通知，关闭日期为 2026 年 9 月 5 日。
• 文档记录：jito-labs/shredstream-proxy 仓库是用于从 Jito 网络接收 shred 的客户端。
• 建议：在您自己的主机和区域上进行测量之前，将任何延迟声明视为特定于环境的。

先决条件与假设

在构建 shred 管道之前，请确认您拥有用于身份验证的 Solana 密钥对、在支持区域内或附近具有稳定网络访问的主机，以及打开代理配置所需的 UDP 和 TCP 端口的能力。您还应该有一个解码 shred 的计划，因为原始 shred 不是可直接使用的事务数据。

以下示例假设使用 Linux 主机、Docker 或 Rust 工具链，以及存储在您控制路径下的密钥对。它们使用 RPC_URL 和 KEYPAIR_PATH 等占位符，而不是真实凭据。如果您仍在选择运行支持性 RPC 工作负载的位置，请在确定架构之前查看 Solana RPC 提供商指南 和 专用节点选项。

Shred 与 ShredStream 如何协同工作

Solana 验证者将区块分解为 shred，这些是较小的单元，可以高效地传输和重组。Shred 提供冗余和容错能力：如果某些片段延迟或丢失，网络仍然可以从其他片段重建区块。标准传播依赖于在验证者集合中进行涡轮式传播，这种方式健壮但并未针对单个订阅者的最早可能视图进行优化。

ShredStream 通过 Jito 的基础设施将 shred 从领导者发送给订阅者，从而改变了传递路径。代理接收这些 shred 并在本地提供。从那里，您的应用程序可以解 shred、解码事务或将数据转发到其他系统。重要的心智模型是，ShredStream 是一种早期信号，而不是索引历史数据或最终状态的完整 RPC 视图的替代品。将其与可靠的 RPC 源配对，可以同时获得最早的成交和可靠的历史记录。

使用 Docker 运行 shredstream-proxy

该代理以支持 Docker 的 Rust 项目形式分发。通常建议使用主机网络，因为它避免了桥接网络开销并简化了 UDP 流量的端口暴露。以下配置使用环境变量和挂载的密钥对；请将占位符替换为您自己的值。

使用主机网络运行容器，并传递密钥对路径和目标端口。确切的标志和环境变量名称可能因版本而异，因此请在生产使用前对照仓库的 README 和发行说明进行验证。

docker run --rm \
  --network host \
  -v "$KEYPAIR_PATH:/keys/id.json:ro" \
  -e KEYPAIR_PATH=/keys/id.json \
  -e DEST_IP=127.0.0.1 \
  -e DEST_PORT=8001 \
  ghcr.io/jito-labs/shredstream-proxy:latest

验证 shred 是否到达

在编写解码逻辑之前，请确认代理正在接收数据。一个简单的 UDP 监听器可以统计数据包并打印每个有效负载的前几个字节。这是一个诊断步骤，不是生产解码器。如果没有数据包到达，请检查防火墙规则、区域选择、密钥对权限以及代理日志是否显示订阅成功。

以下 Python 代码片段绑定到本地目标端口，并打印数据包大小和简短的十六进制前缀。在与代理相同的主机上或接收转发流量的主机上运行它。

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(("0.0.0.0", 8001))

count = 0
while count < 20:
    data, addr = sock.recvfrom(65535)
    print(f"packet={count} size={len(data)} from={addr} prefix={data[:16].hex()}")
    count += 1

将 shred 解码为可用事务

原始 shred 必须经过重组和解码才能成为事务。代理仓库包含解 shred 和解码实用程序，Jito 文档描述了各种解码方法。一种常见模式是使用代理内置的解 shred 服务，或将 shred 馈送到理解 Solana shred 格式和 DATA_COMPLETE 标志的解码器。

不要假设每个数据包都是完整的事务。Shred 可能是部分的、重复的或乱序的。您的解码器应处理去重和重建。如果您正在构建自定义管道，请针对已知的 slot 进行测试，并使用 RPC_URL 将解码后的签名与可信的 RPC 源进行比较。

curl -s "$RPC_URL" -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}'

在不编造数字的情况下测量端到端延迟

延迟声明只有在与方法关联时才有意义。一种可重现的方法是记录 shred 数据包到达的时间戳，将其解码为事务签名，并将该时间戳与同一签名通过参考 RPC 端点首次可见的时间进行比较。在同一时钟域中记录两个时间戳，最好使用 NTP 同步的主机。

在多个 slot 和区域上运行该过程，并报告百分位数而不是单个最佳情况。下表是一个模板；用您自己的测量值填充它。不要发布您未收集的数字。

• 捕获：当解码后的签名首次出现在您的 ShredStream 管道中时，记录 t_shred。
• 参考：在 RPC_URL 上轮询 getSignatureStatuses 或 getTransaction，并在首次观察到签名时记录 t_rpc。
• 计算：对于每个匹配的签名，delta = t_rpc - t_shred。
• 报告：计数、p50、p95、p99 以及每行使用的区域对。

| Region pair | Matched signatures | p50 delta (ms) | p95 delta (ms) | p99 delta (ms) |
|-------------|--------------------|----------------|----------------|----------------|
| your-region-A to reference-A | (fill) | (fill) | (fill) | (fill) |
| your-region-B to reference-B | (fill) | (fill) | (fill) | (fill) |

常见管道故障排查

大多数 ShredStream 问题可分为几类：身份验证、网络、解码和服务生命周期。身份验证失败通常意味着密钥对路径错误或密钥未授权。网络故障通常涉及 UDP 端口、主机防火墙或桥接网络丢包。解码失败通常源于不完整的 shred 或不匹配的格式假设。

首先检查代理日志。如果代理报告订阅成功但您的监听器看不到任何内容，请验证目标 IP 和端口，并确认监听器绑定到正确的接口。如果数据包到达但解码失败，请检查 DATA_COMPLETE 标志并与仓库的解码示例进行比较。有关更广泛的 RPC 可靠性问题，RPC 端点指南 和 多链 RPC 端点指南 涵盖了回退和一致性模式。

• 无数据包：检查防火墙、主机网络和目标端口。
• 身份验证错误：验证密钥对挂载和权限。
• 数据乱码：确认 shred 格式和解 shred 步骤。
• 间歇性间隙：检查区域选择和冗余路径。

限制、权衡与弃用路径

ShredStream 针对最早可见性进行了优化，而不是完整性或最终性。它可以传递后来被放弃的 shred，并且不能替代用于状态查询的完整 RPC 节点。运行代理增加了运营表面积：密钥管理、端口暴露、区域选择和解码器维护。团队应权衡这些成本与其策略中早期信号的价值。

Jito 的文档包含一份停用通知，声明 ShredStream 将于 2026 年 9 月 5 日关闭，并建议在此日期之前迁移到替代方案。将此视为硬性规划约束。清点依赖代理的每个系统，记录其解码假设，并构建一个迁移测试，在相同的 slot 上比较新旧数据源。对于整合基础设施的团队，区块链节点托管指南 和 RPC 定价概述 提供了预算和运营的背景信息。

生产就绪管道的后续步骤

首先在暂存环境中运行代理，并使用诊断监听器验证数据包到达。然后添加解码、去重和延迟测量工具，记录跨区域的百分位数。只有在这些步骤之后，才应通过该数据源路由生产流量。

对于端点和提供商选择，请使用 RPC Assistant，而不是在此处嵌入提供商列表。最佳 Solana RPC 提供商 和 Solana devnet 指南 是测试环境的有用起点，而 OnFinality 的 API 服务 和 网络覆盖 可帮助您规划支持性基础设施。保持迁移测试运行，直到旧数据源完全退役。