核心要点

Solana 交易的字节上限已提升至 4,096 字节，此前的限制为 1,232 字节。V1 格式允许将复杂操作整合在单次交易中。传统的 V0 及旧版钱包交易仍可正常使用。大型交易可能会面临更高的优先费用。

Solana 激活 txv1 功能，显著提升交易数据承载能力

9 月 15 日，在第 1035 个纪元（Epoch）开始时，Solana 在主网正式激活了 txv1 功能。这一升级将最大交易尺寸从 1,232 字节扩大至 4,096 字节。新的限制标准为应用程序提供了更大的数据空间，使其能够在一个操作中容纳更多的指令、签名或加密数据，而不再受限于早期格式的容量瓶颈。

需要注意的是，应用程序必须主动选择接入 V1 格式才能使用这一更大的限制。与此同时，Legacy（传统）和 V0 交易继续按原有方式正常运行，确保了网络的向后兼容性。

技术边界澄清：交易大小不等于转账金额

此次调整针对的是附加在交易上的数据规模，而非用户可发送的 SOL 数量。简单的转账操作包含的信息相对较少，主要包括发送方、接收方、金额、签名及基础指令。然而，更复杂的应用场景可能需要多个指令、长长的账户列表或在同一笔交易中完成多次审批。

Solana 具备并行处理无关交易的能力，这是其底层架构的核心优势之一。Transaction V1 并未改变这一模型，而是解决了单个交易因数据量过大而无法拆分的问题——在没有 V1 之前，若强行拆分，往往需要额外的签名、确认或由应用层进行复杂的协调。

V1 格式支持的三大典型应用场景

• 多步骤交易： 交易应用程序可能需要同时提交相互关联的指令。通过 V1，这些工作可以在单笔交易中一次性上链，无需应用层协调多次独立的确认过程。
• 企业级钱包审批： 企业钱包通常要求多名管理者对转账进行签字。在多签安排较大的情况下，签名及相关账户信息会占用大量空间，V1 格式为此提供了必要的扩展性。
• 隐私证明： 零知识证明允许应用在不完全披露底层信息的情况下验证条件成立。这类证明的数据量往往较大，此前可能超出交易限制，现在可通过 V1 轻松处理。

Solana 基金会还指出，批量操作及某些链上签名方案等负载也可利用这种更大的格式。由于该更大格式仅通过 V1 提供，应用程序必须在代码中添加支持后方可使用。

用户与开发者的注意事项

对于钱包用户而言，此次变化主要在后台发生：

• Legacy 和 V0 交易仍受支持，用户无需迁移 SOL 或创建新地址。
• 保持钱包软件更新有助于在应用程序使用新格式时顺利签署 V1 交易。

应用团队则面临更多开发工作：

任何创建或读取 V1 交易的服务都必须支持新格式，包括遵循新的交易限制规则及解析 V1 交易数据。如果旧的交易日志读取器和索引器未进行更新，它们在遇到 V1 交易时可能会出现故障或误读数据。

容量增加可能伴随更高成本

相较于基本转账，大型交易消耗更多的验证者带宽。Solana 文档指出，在网络繁忙时段，调度器可能会要求大型交易支付更高的优先费用以确保被打包入块。

V1 旨在服务于真正需要更多空间的交易场景。例如，一笔隐私证明或多重审批的金库转账可以用单笔交易替代多次确认；而对于基本转账而言，使用更大格式带来的收益微乎其微。

费用不仅影响用户的即时成本，也是验证者收入的重要组成部分。随着网络活动的增加，交易费和优先小费近期有所上升，但这些收入会随着需求波动而快速变化。

宏观背景：Solana 经济模型的演变

Transaction V1 的推出正值 Solana 经济体系更广泛变革之际。V1 为应用构建者提供了一种在单次操作中嵌入更多数据的方式，而验证者则需要接收并处理这些更大的消息包。

与此同时，网络也在为未来减少 SOL 发行量的过渡做准备。此前，利益相关者投票支持更快的通缩机制。虽然这一供应决策与 Transaction V1 本身是独立的，但从长远来看，它可能使手续费收入、优先费用及其他基于活动的收入在验证者的经济模型中占据更重要的地位。

总结：为应用设计带来新选择

在 V1 出现之前，超出 1,232 字节限制的应用程序不得不将工作分散到多个独立交易中。新格式允许开发者将部分步骤合并处理。最终，用户可能会感受到更少的审批请求以及更少因需同步执行多个动作而导致的交易失败。

免责声明：本文仅供参考，不构成金融或投资建议。钱包兼容性、应用支持情况及交易费用均可能发生变化。