Solana v1 事务详解：大小限制与破坏性变更

Quicknode

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

分享

添加为首选来源

在Solana 上构建复杂应用程序的开发者们，多年来一直在设法绕过交易大小限制。v0版本引入了地址查找表，使交易能够在不超出1,232字节的情况下引用更多账户。最新升级引入了v1交易，将该限制本身提高了3.3倍。

Transaction 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 位于偏移量零处，因此任何消费者都能通过单个字节识别该格式

• 签名将移至交易尾部，而不是置于消息之前

• 固定宽度 u8 计数替换 compact-u16 编码

• 指令头在有效载荷之前进行分组，因此边界可直接计算得出

• 资源限制移入标头配置掩码

地址查找表已不复存在

v1 中已移除了对地址查找表的支持。现在，每个账户都以内联形式作为完整的 32 字节公钥传输，最多 64 个地址占用的空间为 2,048 字节，这仅相当于在添加任何指令之前新信封大小的一半。

Solana 对mainnet 流量进行了成本测算。大约62%的v0交易至少引用了一个查找表。转换为v1后，其中一半的交易超额部分小于420字节，90%的交易小于1,400字节。那些引用多个表、每次只提取少量地址的交易，其大小反而变小了，因为表的开销超过了压缩带来的收益。

移除查找表还简化了验证器的数据摄取过程。v0 版本要求在验证器甚至还不知道交易涉及哪些账户之前，就必须进行基于状态的表解析。v1 版本则直接将交易本身包含的完整账户集传递给验证器，因此手续费和优先级的计算能够更早地进行。

额外的字节能带来什么

有效载荷丰富的应用程序获得了更大的容量，因为证明和指令数据虽然会占用字节空间，但不会占用账户槽位。而账户密集型应用程序（包括多场所路由和广泛的协议组合）则将大部分新增空间用于重新内联查找表原先用于压缩的地址。对于这些团队而言，64个账户的上限现已成为限制性约束，因此继续使用v0版本是一个合理的选择。

字节是 v1 版本设定的唯一限制。寄存器数量保持为 64 个，指令数量保持为 64 条，签名数量保持为 12 个。

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

当查询的区块中首次出现 v1 交易时，读取或索引Solana 数据的应用程序会失败。从前端读取交易的代码会遇到消息数据中原本存放旧版和 v0 交易签名的位置，因此无法通过提高解析器的长度检查阈值来修复该问题。

getBlock 和 getTransaction 会拒绝 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 停止前进

blockSubscribe 释放 null 当遇到 v1 事务时，系统会卡住，且没有可捕获的错误。基于错误率构建的监控机制从未触发，因此订阅会在第一个 v1 插槽处卡住并一直停滞在那里。设置 maxSupportedTransactionVersion: 1 关于订阅，请处理 block: null 将其视为失败而非空块，并添加过期检查，因为除此之外不会有其他机制能检测到它。

ComputeBudget 扫描结果为零

v1 将计算限制和优先级费用从指令中移出，改为在消息级别进行配置。扫描 ComputeBudget 指令的索引器将无法匹配任何内容，并会在不引发任何层级错误的情况下，将零写入所有下游数据集。请改从事务配置中读取限制值。该配置在已启用该功能的消息响应中包含，而在旧版和 v0 中则完全不存在。未设置的字段将保持原样返回 null:

"message": {
    "instructions": ["… no ComputeBudget instruction here …"],
    "recentBlockhash": "GsdgFbNBoZmAB5uPHfk2xUFYyM4Wg2hYZBfBrxrqjxfF",
    "transactionConfig": {
        "computeUnitLimit": 30000,
        "heapSize": null,
        "loadedAccountsDataSizeLimit": 200000,
        "priorityFee": null
    }
}

优先级费用汇总在单位变更时中断

Legacy 和 v0 将手续费表示为每计算单位的微拉姆波特。v1 则将其表示为拉姆波特的绝对总和。要将这两种表示方式合并到一个仪表盘中，只需将 v0 的价格乘以交易请求的计算单位上限，再除以 1,000,000：

20,000 个 CU × 250,000 个微 Lamport/CU = 5,000 个 Lamport   // v0
                                        5,000 个 Lamport   // 等同于 v1

跳过单位换算，否则总和就毫无意义。

Geyserstreams 不受版本限制

流媒体用户没有与之相当的 maxSupportedTransactionVersion 而且无法选择退出。请将Yellowstone 的geyser插件升级至15.1.1，并在12.6.0或更高版本中重新生成protobuf存根，这将添加 Message.config 字段。过期的消费者在 v1 上不会报错。它会将该事务视为 v0，且计算预算为空。

通过结构化方式检测版本，具体如下： Message.config，并按以下顺序进行检查：

顺序很重要，因为 已版本化 对于 v0 和 v1 均成立。首先进行测试会将每笔 v1 交易默认归类为 v0，且不会显示任何提示，同时计算预算被清零。

function messageVersion(message: Message): "legacy" | "v0" | "v1" {
    if (message.config !== undefined) {
        return "v1";
    }
    return message.versioned ? "v0" : "legacy";
}

config 这是一个子消息，而在 proto3 中，子消息字段总是显式包含“存在”标记，因此无论解码器如何处理默认值，此检查都成立。

较旧的Yellowstone 构建版本将版本号从v1降级为v0

Yellowstone 15.1.1 之前的 Geyser 插件会在交易发送至网络之前，将其从 v1 格式转换为 v0 格式。数据流仍可正常运行，但其传输的内容将不再与链上实际执行的结果一致。请升级至 15.1.1 或更高版本，并在使用旧版本时，针对任何将数据流与链上状态进行对账的逻辑，妥善处理这一差异。

发送 v1 交易时会出现什么问题

无论equipe 是否采用v1版本，上述故障都会发生。而这些故障则不会。在应用程序自行构建并提交v1交易之前，以下情况均不会发生，且每一项更改都仅涉及交易的构建方式，而非读取方式。旧版和v0交易仍以1,232字节的容量照常运行，因此是否发送v1交易取决于容量。需要超过1,232字节的交易别无选择。

未设置的资源限制默认值为零

当事务未作任何指定时，Legacy 和 v0 版本将回退至每条指令 200,000 个计算单元以及 64 MiB 的加载账户数据。v1 版本将回退至零，并导致事务失败。每个 v1 事务都会显式地设置计算单元限制和加载账户数据大小限制。在 @solana/kit 8.0 将这些内容从 ComputeBudget 指令中移出，放入消息配置中：

import { setTransactionMessageConfig } from '@solana/kit';

const message = setTransactionMessageConfig(
    {
        computeUnitLimit: 20_000,
        loadedAccountsDataSizeLimit: 64 * 1024,
        priorityFeeLamports: 5_000n,
    },
    baseMessage,
);

在一次模拟迭代中，将两个限制值均设为最大值，然后写入返回的 unitsConsumed 和 已加载账户数据大小 回到配置文件中。将数据大小向上取整至下一个 32 KiB 页面。由于块成本模型按 32 KiB 页面计费，因此低于下一个边界的剩余空间是免费的。

请预留比模拟结果所示更大的空间。不存在的账户加载时不占用任何空间，但一旦创建，就会占用 64 字节加上其数据，因此如果限制大小与模拟结果完全一致，将会导致错误： 已超过最大加载账户数据大小 如果账户信息在交易入账前就显示出来了。

ComputeBudget 指令变为无操作

v1 接受这些指令，每条消耗 150 个计算单位，并在配置时忽略它们。携带 ComputeBudget 指令但不包含消息配置的交易会通过验证，随后在无限制的情况下运行。请将它们完全从 v1 构建器中移除。消息配置已取代了这些指令，而每条残留的指令都会占用 64 个可用指令槽中的一个，并消耗 150 个计算单位，却什么也不做。

优先权费

v1 将优先级费用设置为一个绝对的拉姆波特总和。v0 中基于“每计算单元微拉姆波特”的计算方式不再沿用。该值为 bigint 类型，且在处理旧版和 v0 消息时，该设置器会在编译时被拒绝：

import { setTransactionMessagePriorityFeeLamports } from '@solana/kit';

const message = setTransactionMessagePriorityFeeLamports(5_000n, baseMessage);

Base58 编码的最大长度为 1,232 字节

超过该金额的交易需要 编码："base64" 在提交时。那些硬编码了 base58 的申请，在 v1 支持的大额交易中会失败。

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sendTransaction",
    "params": [
        "<base64-encoded transaction>",
        { "encoding": "base64" }
    ]
}

重复的地址将被拒绝

Legacy 和 v0 允许同一笔交易中出现重复的账户地址，而 v1 会拒绝此类情况。

哪些客户端版本支持 v1？

v1 支持从 @solana/kit 8.0.0、4.2.x 版本的 Rust 库、solders 0.29.0 以及solana-go 1.23.0。

v1 格式目前可在本地验证器上运行，无需启用功能门。 solana-测试验证器 从 4.2 版开始支持该功能，Surfpool 从 1.5 版开始支持，以及一个 为 SIMD-0296 配置的临时 Surfnet 提供托管服务选项。

Quicknode 对 v1 的支持

Quicknode RPC 端点和 API 在激活时即支持 v1 事务。无需进行endpoint 迁移、计划变更、配置标志设置或提交支持工单。

Quicknode 目前Alpenglow集群已支持v1事务，因此该格式可在提交至testnet 之前，先在运行中的endpoint 上进行测试。Testnet 正在等待SIMD-0385事务V1的激活，预计于2026年9月2日星期三UTC时间10:30生效。

剩下的工作就在应用程序代码中。通过 maxSupportedTransactionVersion: 1 在……上 getTransaction 和 getBlock，请升级至上述列出的客户端版本，用消息配置替换 ComputeBudget 指令扫描功能，在各种格式中统一优先级费用单位，并将大于 1,232 字节的交易切换为 base64 编码。