Solana 周二在主网上启用了 Transaction V1 功能，允许在每笔交易中包含更多数据。该升级为开发者在单一原子流程中执行复杂操作提供了更多空间，也与 DeFi 开发者、钱包提供商、索引器和 RPC 运营商密切相关。它还可能影响处理代币化资产和支付解决方案的项目。

根据 Solana 升级页面，txv1 功能门控已在第 1035 个 epoch 开始时，于 9 月 15 日约 01:00 UTC 部署。Transaction V1 目前已在 Solana 主网、测试网和开发网上线。

交易规模从 1,232 字节提升至 4,096 字节

最明显的变化是序列化交易最大规模的提升。Solana 已将上限从 1,232 字节提高至 4,096 字节，为交易数据提供约 3.3 倍的空间。

新交易格式由 SIMD-0296 定义，而 V1 Message Format 基于 SIMD-0385。此前，Solana 的交易规模上限受较为保守的网络最大传输单元（MTU）限制。Transaction V1 摆脱了 QUIC 对流规模施加的硬性上限，从而支持更大的交易。

新增容量旨在支持需要大量交易数据的工作负载，包括零知识证明、大型多重签名操作以及使用 BLS 的签名。正如 Cryptopolitan 此前报道，V1 已于 9 月 1 日在第 1025 个 epoch 部署至测试网，为基础设施提供商准备主网上线留出了时间。

单笔原子交易为何重要

在升级之前，遇到 Solana 交易规模限制的开发者有时可以将操作拆分到多笔交易中，或使用 Jito bundles。不过，SIMD-0296 的说明指出，从协议层面的原子性来看，bundle 并不等同于原生交易。

Transaction V1 允许在一笔交易中放入更多指令和数据。因此，路由、证明检查和批处理可以全部成功或全部失败，而不必在多笔独立交易中执行。根据具体操作，这也可能减少所需的签名和确认数量。

Address Lookup Table 的权衡

Transaction V1 还改变了交易管理资源和账户引用的方式。计算限制和优先费设置已从 ComputeBudget 指令移至交易设置，使基础设施提供商更容易访问这些参数。

V1 交易不使用 Address Lookup Tables，因为被引用的账户会直接包含在交易中。这简化了交易结构，但可能增加交易规模。v0 Address Lookup Table 只需要一个字节的索引，而内联公钥则需要 32 字节。

对 Solana Address Lookup Tables 的分析发现，62% 的 v0 交易至少使用了一个 Address Lookup Table。因此，当账户引用直接包含在交易中时，使用多个表的高密度交易规模可能增加超过 1,500 字节。账户上限仍维持在 64 个不变。

在 Solana 代币化金融扩张中的作用

此次升级正值 Solana 扩大其在链上金融领域的作用之际。根据 DeFiLlama，Solana DeFi 部门的总锁仓价值接近 $5.95 billion，其 24 小时去中心化交易所交易量约为 $1.79 billion。

Solana 8 月份的总结还显示，该网络上的现实世界资产价值已超过 $4 billion，分布在超过 350,000 个地址中。此外，xStocks 管理的资产已超过 $500 million。

交易容量增加本身并不能保证采用率提升。Galaxy Research 观察到，Solana 代币中锁定的大量价值仍未被使用，而竞争平台在一些快速增长的领域仍处于领先地位。Transaction V1 扩大了开发者可以在 Solana 上构建的应用范围，但用户、流动性和交易活动随后将如何反应，仍是一个悬而未决的问题。

运营商和开发者需要进行的调整

RPC 读取方应为 getTransaction 和 getBlock 设置 maxSupportedTransactionVersion: 1。索引器需要从 transactionConfig 中读取 V1 的计算限制和优先费。

验证者和 RPC 运营商应运行 Agave v4.2.2 或更高版本。V1 发送方应明确设置计算限制和已加载账户限制，并对大于 1,232 字节的交易使用 base64 编码。

钱包提供商只有在确认其软件能够正确解析并签署新格式后，才应宣传支持 V1，并遵循 Solana 的升级指引。原报道由 Cryptopolitan 发布。