OrbitFlare Jetstream

​

概述

OrbitFlare Jetstream 是一个高性能 gRPC 服务，用于实时流式传输 Solana 交易。它在更丰富、更灵活的协议之上提供极低延迟的数据流——让您可以即时调整订阅，并接收预先计算好的交易元数据，从而让客户端的工作更少。

​

亮点

• 动态过滤器——在数据流打开期间随时添加和移除过滤器，每个过滤器都带有由客户端选择的 filter_id，并会在每笔匹配的交易上回显。无需重连，且每次更改都会通过 FilterResult 得到确认。
• 可选富化——直接在每笔交易上请求 fee_payer、writable_accounts、program_ids、compute_unit_price（计算单元价格，即微 lamports/CU，而非总费用）、compute_limit、tx_size 以及已解析的地址查找表地址，而无需在客户端重新推导。
• 槽位生命周期流——专用的 SubscribeSlots 流为每个槽位发出 ALIVE / COMPLETE / DEAD 事件，并附带当前 leader 和父槽位。
• 内置存活检测——每条消息都携带一个单调递增的 sequence 编号用于间隙检测，并且当交易流空闲时服务器会发出 Heartbeat。
• 按需富化——默认情况下，交易是一条包含核心字段的扁平消息；随时可以按订阅开启富化，在您需要时添加额外字段。

​

身份验证

在 x-token gRPC 元数据头中提供您的 API 密钥，或使用 IP 白名单身份验证。设置详情请参见身份验证。

​

连接

1. 选择离您基础设施最近的区域端点。
2. 从 jetstream.v2 protobuf 定义生成客户端——请参见参考文档中的代码生成。
3. 使用您的 x-token API 密钥（或从白名单 IP）进行身份验证并打开数据流。

​

流式传输的工作原理

SubscribeTransactions 是一个双向流——您可以在接收数据的同一连接上管理订阅：

1. 打开数据流并发送一个包含一个或多个过滤器的 AddFilters 请求。每个过滤器至少需要 account_include / account_exclude / account_required 之一。（空的”匹配一切”过滤器会被拒绝。）account_required 是任一匹配——如果一笔交易引用了所列账户中的至少一个，则匹配，而不需要引用全部账户。
2. 服务器为每个过滤器回复一个 FilterResult（accepted，或一个 rejection_reason）。
3. 匹配的交易作为 FilteredTransaction 消息到达，每条都列出它所匹配的 filter_id 值。
4. 随时发送 AddFilters / RemoveFilters 来更改您接收的内容——无需重连。
5. 当交易流空闲时，服务器会发送 Heartbeat 消息；请使用它们（以及 Ping/Pong）来确认存活。
6. 跟踪 sequence 编号以检测任何间隙，如果数据流关闭则重新连接（并重新发送您的过滤器）。

要接收富化交易，请在过滤器上设置 include_enrichment: true。

​

槽位事件

打开 SubscribeSlots（一个独立的、服务器流式 RPC，无参数）以接收每次槽位转换的 SlotEvent：

• ALIVE——收到了该槽位的第一个 shred。
• COMPLETE——收到了该槽位的最后一个 shred。
• DEAD——该槽位被跳过，或在未完成的情况下被后续槽位取代。

每个事件都包含 current_leader（32 字节公钥，当前 leader 可用时）和 parent_slot。

​

从 v1 迁移

早期的 Jetstream v1 协议已弃用，但仍可供现有集成使用。如果您正在使用 v1，两个服务在相同的端点上并行运行，因此迁移只是客户端的协议改动，网络无需任何变更。逐字段的对照请参见从 v1 迁移，或参见已弃用的 v1 概述。

​

最佳实践

1. 过滤——始终设置至少一个账户约束，并为每个过滤器使用稳定且唯一的 filter_id，以便您可以关联匹配结果并在之后移除过滤器。
2. 富化——除非您需要额外字段，否则将其关闭；它会应用于整个订阅。
3. 重连——跟踪 sequence 以发现间隙并自动重连，同时重新发送您的过滤器。
4. 存活检测——依靠 Heartbeat / Ping 来检测停滞的连接。

​

另请参阅

​

支持

如需有关 Jetstream 的技术支持或问题咨询，请联系我们的支持团队或加入我们的 Discord 社区。