隐藏的 Solana 升级错误可能会冻结网络读取器并悄悄禁用费用限制

索引器和费用赞助商必须读取 transactionConfig 或默默地强制执行错误的限制。

RPC 读取器必须选择使用 v1，否则当第一个 v1 事务出现时将面临硬故障的风险。

Solana 的 v1 交易格式承诺为每笔交易提供三倍以上的空间，但尚未做好准备的 RPC 客户端、索引器、中继器和费用赞助商可能会以两种截然不同的方式失败：一些系统停止，而其他系统则在错误的资源限制下继续运行。

截至 9 月 4 日，Solana 的实时升级页面仍将 v1 列为未在主网上激活。测试网处于活动状态，开发网已于 1140 纪元上线。8 月 28 日发布的 Solana 变更日志表示，v1 交易“即将到来”，为基础设施运营商留下了更新的预激活窗口。

V1将最大负载从1,232字节提高到4,096字节，大约增加了3.3倍。旧版和 v0 事务保留其现有的限制和行为，因此继续使用这些格式的用户和应用程序不需要迁移。

当使用 getTransaction 、 getBlock 或 blockSubscribe 时，RPC 消费者必须传递整数 maxSupportedTransactionVersion: 1 。如果没有该选择，v1 getTransaction 请求将返回错误 -32015 ，一个 v1 事务会使整个块的 getBlock 失败，并且 blockSubscribe 会发出 block: null 并在第一个受影响的槽处停止前进。

该参数仅告诉 RPC 服务客户端可以解码的最高格式。它不会请求 v1 数据或更改旧版和 v0 事务的返回方式。

其他故障则比较安静。 V1 将计算单元限制、加载帐户数据限制和优先级费用移至 transactionConfig 对象中，而不是 ComputeBudget 指令中。持续扫描这些指令的索引器将为每个 v1 事务报告零计算预算，而不会引发错误。

每日简报 噪音之前的信号。以由 CryptoSlate 编辑解码的推动市场的加密货币故事开始新的一天。一封电子邮件。一切重要的事情。电子邮件地址 免费加入 免费加入。随时取消订阅。哎呀，看来有问题了。请再试一次。你在名单上。您的下一份每日简报即将发送。

Geyser 和 gRPC 消费者面临着一个相关的陷阱。 protobuf 的版本标志对于 v0 和 v1 都适用。因此，过时的消费者可以将 v1 标记为 v0 并保留空预算。修复方法是重新生成 protobuf 存根并在读取标志之前检查 Message.config 字段 7。

中继者、支付者和其他服务器签名者也必须更改他们的策略检查。通过扫描 ComputeBudget 指令强制执行费用上限的赞助商不再具有绑定上限，因为这些指令可能出现在 v1 中但作为无操作执行。服务器必须识别 0x81 v1 前缀并在 transactionConfig 中强制执行费用和资源限制。这是应用程序控制失败，而不是共识缺陷或资金自动面临风险的证据。

链上程序面临更严格的限制：Solana 表示，当前没有 sysvar 或 syscall 公开 v1 消息配置。当 v1 上线时，控制内省 ComputeBudget 指令行为的程序必须停止依赖该检查。

谁需要升级 Solana v1

最低读者支持版本包括@solana/kit 8.0.0、@solana/web3.js 3.0.0-rc.3、Rust solana-* 4.2.x、Python焊接0.29.0和solana-go 1.23.0。 1.x web3.js 行可以从 1.99.0-beta.0 读取 v1，但无法构建、签名或发送它。

Yellowstone 用户至少需要 Yellowstone-grpc-proto 12.6.0、geyser 插件 15.1.1、gRPC 客户端 12.0.0 或 @triton-one/yellowstone-grpc 6.0.0，具体取决于他们的堆栈。