Solana 将其新的 4,096 字节交易限制设定为一个内存页

Solana 定于 9 月 9 日将单笔交易可携带的数据量增加两倍。 根据 GitHub 上的 SIMD-0296 提案，这个新的 4,096 字节上限适合验证器硬件的单个 4 KiB 内存页。

需要多笔交易的工作负载现在只需一次原子调用即可完成。

QUIC 使 1,232 字节上限变得毫无意义

Solana 的原始限制是一种网络谨慎。该网络以 1,280 字节的 IPv6 MTU 运行。

在协议开销之后，留给交易有效载荷的只有 1,232 字节，SIMD-296 的作者写道。当每条消息都必须通过 MTU 而不分片时，这是有道理的。

Solana 在 2022 年切换到 QUIC 作为处理交易的标准方式。RFC 9000 没有设置最大流大小，因此较大的有效载荷可以在网络级别毫无问题地传输。

1,232 字节的限制已经变成了一个没有技术依据的规则。

这两份文件由 Anza 工程师 Jacob Creech 和 Andrew Fitzgerald 撰写。SIMD-0296 提高了大小限制。

一份配套文件 SIMD-0385 定义了 v1 消息格式，其中包含额外字节。这对组合解决了自链推出以来开发人员一直在规避的约束。

该提案首选 4,096 字节而不是 QUIC 允许的最大大小，以便交易可以放入验证器内存的单个标准 4 KiB 页中。交易永远不会跨越页边界。

每笔交易的内存管理很便宜。每笔交易限制在一个页面内。

为了得出 4,096 字节的限制，Creech 和 Fitzgerald 分析了开发人员如何使用 Jito 束来规避旧限制：

• 提交的束中 50% 为 2,048 字节或更小。
• 65% 低于 6,144 字节。
• 100% 保持在 9,216 字节以下。

4,096 字节的上限在单次调用中涵盖了这些多交易工作负载的绝大多数，同时保持在验证器硬件页约束范围内。

未准备的 RPC 调用现在会抛出错误 -32015 在 Solana 上

额外的容量使得能够处理超过 1,232 字节限制的工作负载。

零知识证明（例如 Token Extensions 的 Confidential Transfers 中使用的）生成的负载超过了 1,232 字节的限制。

为了解决这个问题，开发人员链接多个调用或放弃原子加密转账。新的 4,096 字节限制允许在一个交易中容纳零知识证明。

BLS 签名聚合和大型多重签名配置也从这一变更中受益。SIMD-0296 引用了嵌套多重签名（机构金库和通过 Squads 使用的 DAO 所采用的多重签名类型）作为主要驱动因素之一。

它还提到了 Winternitz 一次性签名和无需预编译即可运行的链上 BLS 方案。

该格式摒弃了地址查找表（Address Lookup Tables），v0 版本曾使用短索引引用多达 64 个账户。由于现在有 64 个内联 32 字节地址（仅占用 2,048 字节，远低于上限），这些表增加了复杂性却无益，因此被弃用。

Solana 网络上每笔交易的 64 个账户 limit 仍然存在。即使解决了字节预算问题，重账户应用程序仍将达到限制。

Jito 捆绑包允许开发者将多达五个交易合并为一个全有或全无的序列，以解决字节限制问题。

Transaction v1 在单个交易中实现了相同的原子结果。它将原生原子性直接带入基础层。

V1 对发送者是可选的，因此旧版和 v0 交易继续有效。Solana 基金会的迁移 notes 表示，这对于读取区块的基础设施来说是一个破坏性更改

如果数据工具和区块浏览器未针对 Solana 的新版本进行更新，它们将完全冻结或输出错误。

当应用程序尝试读取没有新版本参数的 v1 交易或区块时，Solana 服务器将以系统错误代码 -32015 拒绝该请求。

持续流式传输实时区块的工具将遇到新的 v1 交易，收到完全空白的响应并停滞在那里。

索引器（或记录交易数据的工具）显示新交易为零优先费，因为它们查找的位置错误。

它们过去从交易内的特殊列表中读取这些费用。在新版本中，该信息保留在其专用的摘要框中。

Anza 要求 RPC 提供商升级到 Agave v4.2。Helius 已发布迁移清单，详细说明相关工作。

Transaction v1 于 9 月 1 日在 Solana 测试网的 epoch 1025 期间激活。Anza 正式将主网部署安排在 9 月 9 日。