> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbitflare.com/llms.txt
> Use this file to discover all available pages before exploring further.
# v2 有哪些新变化
> Jetstream v1 与 v2 一览：v2 相比 v1 新增了什么，以及数据流中承载更多数据如何意味着更少的 RPC 调用和更快的结果。
Jetstream v2 流式传输与 v1 相同的低延迟交易，但它在**每条消息中承载更多内容**，并让您能够**在数据流打开期间管理订阅**。结果就是：您的客户端工作更少、发起的 RPC 调用更少，并且反应更快。
## 一览
| 能力 | 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`）。
**查找表这一行是重点。** 版本化交易并不携带其完整的账户列表。它携带的是一个指向链上查找表的*引用*外加一组索引。在 v1 上，为了得知交易实际触及哪些账户，您需要为每笔交易发起一次完整的 RPC 调用以获取该表，然后自己解析索引——一次额外的请求和响应，远比数据流本身慢，而且恰好位于您的关键路径上。开启 v2 富化后，那些已解析的地址已经包含在内，因此该查找不再位于您的关键路径上。其他各行都是您的客户端本会在每笔交易上重复的工作；v2 转而将答案内联送达。
对于版本化交易，会包含已解析的查找表地址。如果有任何地址无法被完整包含，该交易上会设置 `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 流式传输。无论如何，迁移只是您客户端代码的改动，而不是连接的改动：相同的端点、相同的身份验证，并行运行。
## 另请参阅
流式传输模型、连接和最佳实践。
完整的 v2 Protocol Buffer 规范、端点和代码生成。
v1 概述、客户端示例和过滤指南。
## 支持
如需有关 Jetstream v2 的技术支持或问题咨询，请联系我们的支持团队或加入我们的 [Discord 社区](https://discord.gg/orbitflare)。