Solana v1 交易解释：大小限制和重大变更

Solana v1 事务解释：大小限制和重大更改 事务 v1 将 Solana 的最大事务大小从 1,232 字节提高到 4,096 字节，并删除了地址查找表。以下是读取 Solana 数据的应用程序发生的变化以及发送数据的应用程序发生的变化。

Quicknode 2026 年 9 月 1 日 — 阅读 10 分钟

在 Solana 上构建复杂应用程序的开发人员花费了数年时间来解决交易大小限制。 v0 引入了地址查找表，让一笔交易可以引用更多账户而不超过 1,232 字节。最新升级引入了 v1 交易，将限制本身提高了 3.3 倍。

交易 v1 将最大序列化交易大小从 1,232 字节提高到 4,096 字节，并于 2026 年 9 月上旬使用 Agave v4.2 激活。对于构建零知识 (ZK) 应用程序、多重签名系统和复杂 DeFi 原语的团队来说，额外的空间消除了一整类解决方法。

没有人必须采用 v1 才会受到它的影响。读取 Solana 数据的所有内容都会受到影响，无论它是否发送过 v1 事务。

1,232 字节限制来自 UDP。 Solana 几年前将交易摄取转移到 QUIC，从而消除了这一限制。限制仍然存在。团队不断分割交易，建立查找表，并围绕不再与其下方的传输相匹配的天花板进行构建。

新限制并非基于网络限制。 4,096 字节与验证器内存页对齐。这为 ZK 证明、BLS 签名方案、机密传输、预言机价格更新请求以及在单个交易中容纳更多指令而不需要捆绑方案的能力腾出了空间。它还适合内联完整的 64 个帐户集，这就是 v1 完全放弃地址查找表的原因。

什么是 Solana v1 交易？

v1 交易是一种新的 Solana 有线格式，上限为 4,096 字节。它并不是v0有更大的限制，五处变化将它们分开：

版本字节 0x81 位于偏移量 0 处，因此任何使用者都可以从单个字节识别格式

签名移动到交易的尾部而不是消息之前

固定宽度 u8 计数取代紧凑型 u16 编码

指令头在其有效负载之前分组，使边界可直接计算

资源限制移至标头配置掩码中

地址查找表消失了

v1 中删除了对地址查找表的支持。现在，每个帐户都作为完整的 32 字节公钥内联传输，最多 64 个地址集占用 2,048 字节，这是添加单个指令之前新信封的一半。

Solana 测量了主网流量的成本。大约 62% 的 v0 事务至少引用一个查找表。转换为 v1 后，其中一半显示超出 420 字节以下，90% 显示低于 1,400 字节。引用多个表来提取少数地址的事务会变得更小，因为表开销成本高于返回的压缩成本。

删除查找表还简化了验证器的摄取。在验证器知道交易涉及哪些账户之前，v0 强制执行与状态相关的表解析。 v1 移交了交易本身的完整帐户集，因此费用和优先级计算发生得更早。

额外的字节可以买什么

有效负载丰富的应用程序获得了容量，因为证明和指令数据消耗字节而不消耗帐户槽。帐户密集型应用程序（包括多场所路由和广泛的协议组合）花费了大部分新空间来重新内联查找表用于压缩的地址。对于这些团队来说，64 个帐户的上限现在是约束条件，保留 v0 是一个合理的选择。

字节是 v1 提高的唯一限制。帐户保留为 64，指令保留为 64，签名保留为 12。

读取 Solana 数据时出现什么问题

当 v1 事务第一次出现在它们查询的块中时，读取 Solana 数据或为其建立索引的应用程序会失败。从前面读取交易的代码会命中遗留和 v0 放置签名的消息数据，因此无法通过提高其长度检查来修复解析器。

getBlock 和 getTransaction 拒绝 v1 交易

未声明 v1 支持的调用一旦触及 v1，就会返回错误 -32015，并且整个块读取都会失败。索引器和回填作业会停止而不是跳过它们无法解析的一项事务。在两次调用上设置 maxSupportedTransactionVersion: 1 作为 JSON 整数 1 。字符串“1”失败，0 也失败，因此在 v0 推出期间选择加入 v0 支持的代码尚未涵盖。 getSignaturesForAddress 不受影响，因为它从不检查交易主体。

中断的调用：

× 终端 □ { "jsonrpc": "2.0", "id": 1, "method": "getBlock", "params": [402184291, { "encoding": "json" }] }

相同的调用，已更正。 Base64 与版本参数一起需要，因为 Base58 无法对超过 1,232 字节的交易进行编码：

× 终端 □ { "jsonrpc": "2.0", "id": 1, "method": "getBlock", "params": [ 402184291, { "encoding": "base64", "maxSupportedTransactionVersion": 1 } ] }

blockSubscribe 在到达 v1 事务时会发出 null 并停止，并且不会捕获任何错误。基于错误率构建的监控永远不会触发，因此订阅会楔入第一个 v1 插槽并保留在那里。在订阅上设置 maxSupportedTransactionVersion: 1，将 block: null 视为失败而不是空块，并添加过时检查，因为没有其他内容会显示它。

ComputeBudget 扫描返回零

v1 将计算限制和优先级费用从指令中移至消息级配置中。扫描 ComputeBudget 指令的索引器不匹配任何内容，并将零写入每个下游数据集，而不会在任何层出错。相反，请从事务配置中读取限制。它到达选择加入响应的消息内部，并且对于旧版本和 v0 完全不存在。未设置的字段返回 null ：

× 终端 □ "message": { "instructions": ["…这里没有 ComputeBudget 指令…"], "recentBlockhash": "GsdgFbNBoZmAB5uPHfk2xUFYyM4Wg2hYZBfBrxrqjxfF", "transactionConfig": { "computeUnitLimit": 30000, "heapSize": null, “loadedAccountsDataSizeLimit”：200000，“priorityFee”：null } }

单位变更时优先收费聚合中断

Legacy 和 v0 将费用表示为每个计算单元的微型灯。 v1 将其表示为 lamports 中的绝对总数。将 v0 价格乘以请求交易的计算单元限制，然后除以 1,000,000，将两者放在一个仪表板上：

× 终端 □ 20,000 CU x 250,000 微型灯/CU = 5,000 灯 // v0 5,000 灯 // 相当于 v1

跳过转换，总数就没有任何意义。

Geyser 流没有版本门

流消费者没有 maxSupportedTransactionVersion 的等价物，也没有办法选择退出。将 Yellowstone geyser 插件升级到 15.1.1，并在 12.6.0 或更高版本重新生成 protobuf 存根，这会添加 Message.config 字段。过时的消费者在 v1 上不会出错。它将事务读取为 v0，计算预算为空。

在 Message.config 上结构性地检测版本，并按以下顺序检查：