Solana Shreds 和 LaserStream：赢得毫秒之战

赢得毫秒级游戏：Shreds、LaserStream 以及 Solana 的边缘

13 分钟阅读

2025 年 8 月 18 日

如果你有一台能够永远提前 10 毫秒的时间机器，你会做什么？你会进行哪些交易？你会监控哪些账户？你会多赚多少钱？

LaserStream 是 Helius 的下一代 gRPC 流媒体服务，它在全球所有区域始终优于其他数据流媒体服务，而无需维护专用节点。

尽可能快地流式传输数据对于检测链上事件（例如，交换、清算、价格更新）和提交对这些事件做出反应的交易至关重要。对于 RFQ 交易台、清算机器人和高频交易来说，几毫秒的差别就是抓住和错过机会的差别。

LaserStream 在对延迟敏感的操作方面的最佳性能主要归功于它建立在低延迟的 shreds 之上。也就是说，LaserStream 一旦获取到传播的区块数据，就会立即接收，从而让用户更早地看到 Solana 状态更新。凭借其全球分布式管道、自动重放、自动故障转移和客户端 SDK，毫无疑问，LaserStream 是在 Solana 上流式传输实时数据的最简单、最快的方式。这些优势使得 LaserStream 的集成对于交易所、交易应用程序、MEV 机器人以及任何认真对待延迟敏感操作的人来说至关重要。

本文探讨了 shreds，Solana 上区块的最小单位，为什么它们很重要，以及 LaserStream 如何使用它们来驱动最快的数据流解决方案。本文的设计使得每个部分都可以独立阅读。然而，对于 Solana 上的 shreds 和流式数据的新手读者来说，按顺序阅读每个部分会更有益。

什么是 shreds？

Shreds 是实现 Solana 高性能数据传播的基础单元，提供对链上状态变化的早期访问。

Solana 旨在实现最高速度和吞吐量。为了实现这一点，它不能将区块作为单个大型单元在网络上传输。相反，区块被分成更小的包，称为 shreds——Solana 中数据传播的原子单元。

这些 shreds 代表在被组装成一个区块之前的交易数据部分。每个 shred 的大小约为 1.2 KB，经过优化，可适应标准网络数据包的最大传输单元 (MTU)，以确保闪电般的快速交付而无需分片。

有两种类型的 shreds：

数据 Shreds

数据 shreds 封装了来自区块的核心交易数据，分成固定大小的片段。它们包括序列化的条目批次，这些批次是交易组，前缀是一个计数，以便进行高效处理。

编码 Shreds

编码 shreds 使用 Reed-Solomon 纠删码提供冗余，Reed-Solomon 纠删码是一种前向纠错技术，可生成奇偶校验数据。这允许重建丢失或损坏的 shreds。编码 shreds 与数据 shreds 一起组织成前向纠错 (FEC) 集，通常以平衡的比例（例如，32 个数据到 32 个编码 shreds）来容忍高达 50% 的数据包丢失。领导者可以根据网络状况调整此比率，以保持高可靠性。

Shreds 如何在 Solana 上传播？

该过程从领导者（即当前负责生产区块的验证者）将交易批量处理并序列化为条目开始。然后将这些条目分成更小的段，称为 shreds。所有 shreds 都由领导者签名，可以使用旧系统（即，单独签署每个 shred）或基于 Merkle 的方案（即，签署整个 FEC 集的 Merkle 根），如 Solana 的 shred 规范 中所定义的那样。这确保了真实性和数据完整性。

Shreds 使用 Turbine（Solana 的多层、扇出式传播系统）发送给其他验证者。在 Turbine 下，领导者将 shreds 传输到根节点，根节点将它们分发到树状结构中的后续验证者层。每一层都以每Layer200 个节点的扇出转发到下一层，通常跨越 2 到 3 跳，具体取决于活动验证者的数量。这种树状结构最大限度地减少了带宽，同时在几毫秒内实现了全网络范围的交易分发。

权益加权混排优先将交付给更高权益的验证者。Turbine 首先按验证者持有的权益量（即，他们的权益权重）对验证者进行排序。具有较高权益的验证者在此列表中排在前面，并且在确定性混排之后，它们倾向于最终出现在更靠近领导者的树的早期层中。因此，更少的跳数意味着更低的延迟。因此，具有更多权益的验证者会更快地收到 shreds。

注意： 一旦实施了 Alpenglow，Turbine 将在未来被 Rotor 取代。即使进行了这些更改，验证者的权益仍将影响验证者将广播给哪些对等方。

Shreds 如何重新组装成区块？

一旦验证者收到 shreds，首先会验证其签名以确保真实性，并使用 Reed-Solomon 纠删码从 FEC 集中可用的编码 shreds 中重建任何丢失或损坏的数据 shreds。

然后将重建的数据 shreds 进行 deshredded。也就是说，使用 shred 索引按顺序连接它们的有效负载，以重新形成序列化的条目批次。

然后将这些批次反序列化为单个交易和条目，可以将其组装成一个完整的区块。

为什么 Shreds 重要？

Shreds 很重要，因为它们压缩了网络中的反应窗口，在网络中时间至关重要。

Shreds 对于释放 Solana 的高性能优势至关重要，尤其是在对延迟敏感的应用程序中，例如高频交易、询价 (RFQ) 交易台、清算引擎和预言机更新。

Shreds 提供了对新兴链上事件的最早可见性，这与大多数其他区块链不同，在这些区块链中，应用程序必须等到完整的区块生产和确认，这可能会增加数百毫秒到几秒的延迟。

原始 shreds 可能很难使用，因为接收者必须验证其真实性，重建任何丢失的数据 shreds，将它们 deshred 和反序列化为交易和条目，最后解析它们以获取可操作的事件，例如交换或帐户更改。

然而，这种对未决交易和帐户更新的“早期窥视”提供了无与伦比的优势，直接转化为在竞争场景中更高的成功率。

例如，一个监控抵押品比率的清算机器人可以使用 shreds 在其竞争对手使用较慢的方法（如 WebSockets）之前检测并对弱势头寸采取行动，从而赢得清算。

同样，识别市场低效率的套利交易者和低延迟 DEX 聚合器 报价 可以从此延迟优势中受益，因为毫秒决定了盈利能力。

Shred 延迟层次结构

重要的是要注意，shred 延迟在所有来源中并不统一。

高权益验证者

拥有大量权益的验证者在 Turbine 的传播树中获得最高优先级。它们通常直接从领导者或在早期的扇出层中获取 shreds，从而受益于 权益加权服务质量 (SWQoS)。

权益验证者

由于他们在传播队列中的优先级较低，因此具有适度权益的验证者会遇到适度的延迟，因为 shreds 需要进行额外的跳数。他们参与共识可确保可靠的访问，尽管延迟可能会因网络位置和当前权益分配而略有不同。与高权益验证者相比，低权益验证者不太适合超竞争、时间敏感的操作。

未抵押的验证者

没有权益的验证者缺乏已 stake 节点的QoS优势，并且不适合流式传输实时 Solana 数据以用于延迟关键型操作。它们是 Turbine 扇出中接收 shreds 的最后一个。

在树中越早，你在网络其余部分赶上之前就有更多时间做出反应。

全局可变性

重要的是，Turbine 与位置无关。全局传播会放大延迟可变性，因为物理距离和网络状况会引入超出 Turbine 跳数的延迟。

例如，区域间传输的 shreds（例如，从位于美国的领导者到亚太地区的验证者）可能会因跨大陆路由、数据包重传甚至对等问题而导致延迟——即使对于 Turbine 早期层中的高 stake 验证者也是如此。

这种地理分布为优化创造了机会。虽然单个高 stake 验证者可能在本地表现出色，但如果未进行最佳定位，则可能在全球范围内滞后。这可以通过分布式 shred 网络来缓解，该网络可以聚合来自各种来源的最快 shred，从而减少差异并实现一致的接收速度。这样的系统可以在全球场景中始终优于顶级 stake 验证者。

从优化的来源可靠地访问 shreds 对于保持构建延迟关键型系统的开发人员的竞争优势至关重要。然而，这需要强大的基础设施来有效处理恢复、验证和全球分布。此外，Solana 大多数流行的实时数据流工具目前都没有利用 shreds。

在 Solana 上流式传输数据

在 Solana 上，希望流式传输实时数据的开发人员有几种选择，每种选择在延迟、可靠性和复杂性方面都有其自身的权衡：

Webhooks

Webhooks 启用事件驱动的更新，当特定帐户或程序发生更改时，将数据推送到你的应用程序。它们易于以编程方式集成，甚至可以直接在 Helius Dashboard 中设置，而无需任何编码。开发人员可以流式传输特定交易类型的人类可读、解析的数据、原始交易有效负载，甚至可以将这些更新作为格式化的消息直接流式传输到特定的 Discord 频道中。

虽然 webhooks 非常可靠，并且被 Solana 上的许多知名公司使用，但它们会在交易确认_后_发送通知。这意味着 webhooks 可能落后于 shred 级别数据数百毫秒，这使得它们对于高频交易或清算等延迟关键型操作来说太慢了。

标准 WebSockets

Solana 的 JSON RPC API 支持 WebSocket 订阅，例如 accountSubscribe 用于帐户更改，logSubscribe 用于交易日志，以及 programSubscribe 用于程序事件。WebSockets 在客户端和 RPC 提供程序之间维护持久连接，并在处理交易和帐户更改后立即流式传输更新。WebSockets 是双向的，适用于实时监控特定帐户或事件，同时减少轮询开销。

然而，与 webhooks 一样，WebSockets 在 shred 重新组装后传递数据（即，在 已处理、已确认 或 已最终确定 提交级别），具体取决于提交级别，会增加 400 毫秒到 30 秒的延迟。

WebSockets 也被认为是一种脆弱的连接类型，这意味着连接可能会因各种问题而断开，需要自定义重试逻辑。断开连接可能意味着永久性数据丢失，除非辅以轮询，否则会破坏实时可靠性。

增强型 WebSockets

与标准 WebSockets 相比，增强型 WebSockets 是一项重大改进，它提供了多项性能优化和增强的过滤功能。即，更好的事件解析和减少的噪音使它们更易于开发人员在生产中使用。

与标准 WebSockets 相比，增强型 WebSockets 可以减少延迟，非常适合常规流媒体应用程序。例如，与标准 WebSockets 和 webhooks 相比，使用增强型 WebSockets 流式传输 Pump AMM 数据 时，性能差异非常明显。

然而，增强型 WebSockets 从根本上仍然在 shred 重新组装后传递数据。同样，这限制了它们在每毫秒都很重要的应用程序中的用处。此外，虽然增强了，但它们缺乏自动重放或故障转移，需要手动处理间隙。

Yellowstone gRPC

Yellowstone gRPC 是一种低延迟的验证者到客户端流式传输协议，可以提供对 shred 级别数据的访问。这使得它比 WebSockets 和 webhooks 快得多，因为它可以在各自的提交级别上更快地传递更新。

Yellowstone 提供双向流式传输，可立即创建和取消订阅，以及高级过滤功能，可精确控制你在响应特定交易、帐户或程序更新时收到的数据。

Yellowstone 非常适合那些希望没有速率限制、没有 credit 并且保证隔离硬件用于自定义节点配置的用户。然而，存在几个主要的权衡：

1. 基础设施负担

你需要拥有自己的 专用节点 才能充分发挥 Yellowstone gRPC 的潜力。这需要访问硬件、正确的配置、持续管理上述硬件以及垂直专业知识来调试任何与硬件相关的问题。

2. 延迟可变性

仅仅因为 Yellowstone gRPC 可以 在 shred 级别传递数据，并不意味着它会以最最佳的方式传递。延迟可能因你的提供商以及你的专用节点是否与 shred 优化来源（即，高 stake 验证者）配对而异。与已 stake 到低 stake 验证者配对意味着它们不会始终位于第一个 Turbine 层中，这意味着你仍然将处于许多 shreds 的下游。

3. 故障风险

依赖单个专用节点会创建一个单点故障，而 Yellowstone gRPC 没有任何本机重放功能这一事实加剧了这种情况。

4. 资源需求

在使用 Yellowstone 流式传输数据时，将密集 RPC 调用加载到专用节点上可能会导致性能下降。

长期以来，对于许多团队来说，Yellowstone gRPC 一直是 Solana 上实时数据的首选流媒体服务。它速度很快，适合高级用户，但如果没有访问全球大量专用节点的权限，很难对其进行操作以实现一致、全球性的低延迟覆盖。

LaserStream

LaserStream 将 shred 级别摄取的速度与全球分布式服务的可靠性和覆盖范围相结合，而无需运行多个专用节点的成本或运营难题。

LaserStream 通过以下方式实现此目的：

• 多源摄取：LaserStream 摄取最低延迟的 shreds，始终在全球范围内击败竞争对手。
• 全球覆盖：LaserStream 在全球多个地区可用，允许开发人员使用最靠近其基础设施的端点。每个区域运行多个服务器以实现冗余，并具有自动故障转移功能。
• 零间隙：LaserStream 的 历史重放 允许开发人员重放最近的区块链数据，最多可追溯到过去的 3000 个插槽（即，大约 20 分钟）。这对于处理断开连接和确保数据连续性非常有用。
• 对开发人员友好的体验：LaserStream 是 Yellowstone gRPC 的直接替代品——无需迁移、无需新语法、无需麻烦。

简而言之，LaserStream 是对 Yellowstone gRPC 和 WebSockets 的可扩展、低延迟和容错的改进。它可以始终如一地提供网络上发生的链上事件，而无需数百万的 stake 或自行运营高性能基础设施。

LaserStream 是在 Solana 上利用 shreds 的强大功能进行超低延迟数据流的最_简单_方法。

客户端和性能

[LaserStream 在 Go、Rust 和 JavaScript/TypeScript 中提供 客户端。这些客户端在断开连接时处理自动重放，因为它们会持续跟踪已流式传输的插槽。如果由于任何原因发生断开连接，客户端将自动重新连接并在上次处理的插槽处恢复流式传输。

LaserStream 的 JavaScript 客户端特别有趣，因为它使用本机 Rust 绑定。因此，该客户端拥有 1.3 GB/s 的吞吐量。这比当前 Yellowstone gRPC JavaScript 客户端提高了 40 倍，后者的最大吞吐量为 30 MB/s。

随着 Solana 继续扩展，Yellowstone gRPC JavaScript 客户端将难以跟上。LaserStream 的 JavaScript 客户端性能余量确保你的应用程序可以随着网络需求的增加而安全地扩展。

现实世界的胜利

低延迟 DEX 聚合器 DFlow 最近集成了 LaserStream 以馈送其价格引擎。他们决定集成的原因是能够在全球范围内扩展，而无需担心专用节点，并节省工程带宽以专注于路由和业务代码。

自集成以来，据报道，DFlow 节省了超过 8 小时的重复工程开销，通过不间断的数据流保持了 100% 的正常运行时间，并通过更快的交易确认提高了报价速度。

我们最关心的是用户的安全。为了给交易者提供最佳价格和最窄的点差，我们依靠 LaserStream 为我们的价格引擎提供最新、最快的链上数据。

Nitesh Nath

DFlow 首席执行官

xFractal 最近也集成了 LaserStream，理由是其快速简便的设置以及强大的消息和错误处理，这使得它们可以在没有自己管理专用 Geyser 节点的开销的情况下使用它。

更快的流媒体，今天。

毫秒不仅仅是延迟——它们是机会。有了 LaserStream，你不仅可以跟上网络。你领先于它。

想要亚秒级数据用于交易、清算或预言机？获取 LaserStream——获取对最快的 Solana 数据的访问权限。

或者，对于我们的高级用户，如果你对原始 shred 交付感兴趣，请通过填写以下 Typeform 在此处与我们联系。

更多资源

• LaserStream
• Agave 的 Shred 模块
• Solana 的 Shred 规范

• 原文链接： helius.dev/blog/solana-s...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～