一览
| 能力 | v1 | v2 |
|---|---|---|
| 实时交易流 | ||
账户 include / exclude / required 过滤器 | ||
| Ping 和版本检查 | ||
| 无需重连即可实时更改过滤器 | ||
| 带接受 / 拒绝确认的命名过滤器 | ||
| 富化的交易字段（费用支付者、计算单元价格、计算单元上限、程序 ID、可写账户、大小） | ||
| 已解析的地址查找表账户 | ||
| 槽位生命周期流（alive / complete / dead） | ||
| 用于间隙检测的逐消息序列号 | ||
| 空闲心跳 |
v1 和 v2 都会为您提供已解码的交易：签名、账户密钥、指令、消息头，以及任何地址查找表引用。v2 在此基础上新增了富化（上面那些预先计算好的字段），外加实时订阅、槽位和存活检测等功能。富化是可选的；参见下文。
更多数据，更少 RPC 调用
在 v1 中，您获得已解码的交易，其余部分要自己算出来。核心字段之外的任何内容都由您负责：谁支付了费用、它设置的计算单元价格、哪些账户可写，以及版本化交易的查找表背后真正的账户。 v2 可以为您完成这些工作。开启富化后，每笔交易还会携带下面的字段。| 要获取…… | 在 v1 上您需要…… | 在 v2 上（开启富化） |
|---|---|---|
| 版本化（v0） 交易的完整账户列表 | 每笔交易发起一次完整的 RPC 调用以获取查找表，然后自己解析索引 | 已解析并包含在内（loaded_writable_addresses / loaded_readonly_addresses） |
| 费用支付者 | 从账户密钥和消息头推导 | 已包含（fee_payer） |
| 计算单元价格和计算单元上限 | 自己解析计算预算指令 | 已包含（compute_unit_price、compute_limit） |
| 可写账户 | 从消息头和已解析的查找表计算 | 已包含（writable_accounts） |
| 交易触及的程序 ID | 遍历每条指令 | 已包含（program_ids） |
| 交易大小 | 重建并测量交易 | 已包含（tx_size） |
compute_unit_price 是计算单元价格——来自 SetComputeUnitPrice 的每 CU 微 lamports 值，而不是总的优先费。要得到以 lamports 计的总优先费，将其乘以计算单元上限再除以 1,000,000：compute_unit_price × compute_limit / 1e6。compute_limit 仅反映显式的 SetComputeUnitLimit（如果交易未设置，则为 0）。对于版本化交易，会包含已解析的查找表地址。如果有任何地址无法被完整包含，该交易上会设置
alt_resolution_incomplete，以便您自己解析那些地址（通过 RPC 获取查找表）——不会有静默的间隙。富化是可选的且默认关闭。随时可以按订阅开启它（在过滤器上设置
include_enrichment: true），在您需要额外字段时使用——开启它不会给数据流增加任何延迟；唯一的区别是消息略大一些。它是面向整个订阅的：如果任一活动过滤器开启了它，则该会话接收的每笔交易都会被富化。无需重连即可管理您的数据流
在 v1 中，您在打开数据流的那条消息里一次性设置过滤器。要监视不同的内容，就得断开连接并打开一个新连接，在重连期间失去实时数据流。 v2 让数据流保持打开，并允许您随时添加和移除过滤器。您为每个过滤器指定自己的filter_id，服务器会确认每次添加和移除（如果拒绝还会告诉您原因），并且每笔交易都会列出它所匹配的 filter_id 值。在一个连接上运行多个过滤器，即时更改它们，并始终知道是哪个过滤器产生了某笔交易。账户 include / exclude / required 的行为与 v1 完全相同——required 是任一匹配（如果一笔交易引用了至少一个所列账户则匹配），而不是全部匹配。
通过槽位事件跟随链
v2 新增了第二个独立的数据流SubscribeSlots，v1 完全没有类似的东西。当一个槽位开始（ALIVE）、结束（COMPLETE）或在未完成的情况下被跳过或被后续槽位取代（DEAD）时，您都会得到一个事件，并附带该槽位的 leader 和父槽位。这是一种低成本的方式，用来跟踪链的进展位置，而不必从交易流中推断它。
知道自己何时错过了内容
v1 从未给过您的两样东西：- 每条 v2 消息，无论是交易还是槽位事件，都携带一个逐一递增的
sequence编号。看到间隙，您就知道自己丢了一条消息。 - 当交易流安静下来时，v2 每 60 秒发送一个
Heartbeat，并盖上服务器时钟的时间戳。这可以让连接穿过负载均衡器的空闲超时保持存活，并把安静的数据流与已死的数据流区分开来。
为什么这加起来会带来更快的结果
- 将一次往返移出您的关键路径。 在 v1 上，解析查找表是一次完整的 RPC 请求和响应，比数据流本身慢得多。开启 v2 富化后，版本化交易的已解析地址会内联到达，因此那次调用永远不会卡在一笔交易到达和您据此行动之间。
- 您这边每笔交易的工作更少。 富化字段到达时已经计算完毕，因此您的客户端不必在每笔交易上重新推导它们。
- 没有重连间隙。 实时更改过滤器意味着您永远不必为重新订阅而断开数据流。
- 丢失和停滞立即可见——通过序列号和心跳，而不是事后推断。
您应该使用哪个
对于新集成，请使用 v2。富化、槽位事件、实时过滤器和存活检测信号都在这里，每一项新能力也都落地于此。v1 保持完全受支持，且目前没有设定退役日期，因此现有的 v1 客户端可以保持原样继续运行。不过，我们确实鼓励您迁移过来：随着更多流量向 v2 集中，它会释放我们如今为 v1 投入的容量，用于下一代 OrbitFlare 流式传输。无论如何，迁移只是您客户端代码的改动，而不是连接的改动：相同的端点、相同的身份验证，并行运行。另请参阅
Jetstream v2 概述
流式传输模型、连接和最佳实践。
v2 协议参考
完整的 v2 Protocol Buffer 规范、端点和代码生成。
Jetstream (v1)
v1 概述、客户端示例和过滤指南。