Agave 4.2 更新：你需要知道的一切

引言

随着 Agave 4.2 的发布，Solana 的核心验证者客户端继续开创新局面。这一重大版本围绕三项备受期待且由功能开关（Feature Gate）控制的升级展开：200ms 的 Slot 时间、状态债券（State Bond）降低 90%，以及通过新的 Transaction v1 格式实现 4,096 字节的交易。同时，功能完整的 Alpenglow 也随此版本发布，计划在下一个版本中激活；此外，XDP 传输现在默认启用。

Agave v4.2 将成为 Solana 历史上最疯狂的客户端升级。

Brennan Watt

Anza 首席执行官

值得关注的更新

• 交易体积扩大至原来的 3.3 倍，采用新的 Transaction v1 标准 *
• 状态债券（Rent）降低 90% *
• Slot 时间缩短至 200ms *
• Alpenglow 功能完整
• 新的治理工具（与 SIMD 相关）

* 由功能开关（Feature Gate）控制的升级

更大的交易（Transaction v1）

Agave 4.2 发布周期中有一个功能开关被激活，将交易大小上限从长期以来的 1,232 字节提升至 4,096 字节。该上限在 SIMD-0296: Larger Transaction Size 中正式定义，相当于约 3.3 倍的提升，且仅适用于由 SIMD-0385: Transaction V1 Format 引入的新 Transaction v1 格式。Legacy 和 v0 交易不受影响，继续正常工作，并仍然受现有的 1,232 字节上限约束。

对于开发者来说，这不仅仅是增加了指令数据的空间。加密证明、多签批准、大型账户列表以及其他以前无法容纳在单笔交易中的载荷，现在可以在协议原生的单个原子操作中执行。这一变更不会提高 Solana 的计算、账户、签名或指令数量的上限。

最初的 1,232 字节限制源自 Solana 早期的网络架构。交易作为独立的 UDP 数据报进行传输，必须能装进 IPv6 的最小最大传输单元（MTU），即 1,280 字节。扣除 40 字节的 IPv6 头部和 8 字节的 UDP 头部后，剩余 1,232 字节可供交易本身使用。将每笔交易保持在单个数据包中减少了分片，也让传输更加可预测。

Solana 早已从 UDP 迁移到 QUIC 来进行交易接收。QUIC 流不受单个网络数据报载荷的限制，因此旧的 1,232 字节上限不再是硬性要求。客户端仍然需要一个明确的上限来进行准入控制、内存分配和共识验证，但现在这个上限可以根据运行时和应用需求来选择，而非受限于 IPv6 MTU。

账户列表往往会占用交易大小配额中的很大一部分。每个 Ed25519 公钥或程序派生地址占用 32 字节，且交易必须指明其指令读取或修改的每一个账户。这以前使得有效上限大约为 32 个完整账户密钥。为了绕过这一限制，v0 交易引入了地址查找表（ALT），将每个 32 字节的密钥替换为单字节的表索引，使交易能够触及运行时的 64 个账户上限。

虽然 ALT 是一种有效的压缩方式，但遗憾的是它也引入了复杂性。应用程序必须在链上创建和管理查找表。解码原始 v0 消息的 RPC 服务和索引器，必须使用交易元数据或相关的表状态来重建其完整的账户列表。这在解析那些引用了已关闭且链上不再可用的 ALT 的交易时会带来挑战。

v1 交易解决了这一开发者痛点：它足够大，可以携带目前通过 ALT 才能支持的完整账户集（64 个完整公钥，共 2,048 字节）。因此，从 v0 迁移的应用程序可以解析其查找表条目，并将得到的地址直接包含在 v1 交易中。

此外，对于零知识证明和 BLS 实现等缺乏原生预编译的加密功能，1,232 字节的交易大小限制尤为严格。这些工作负载可能携带数百或数千字节的证明或签名数据。4,096 字节的上限覆盖了许多此类常见的加密用例。

Transaction V1 规范

序列化的 v1 交易以版本字节 0x81 开头。其后依次是 3 字节的 legacy 风格消息头、32 位交易配置掩码、32 字节的生命周期说明符、指令数和地址数、完整的 32 字节地址数组、配置值、固定大小的指令头、连续的指令载荷，最后是签名。

Transaction V1 规范

VersionByte (u8)
LegacyHeader (u8, u8, u8)
TransactionConfigMask (u32) -- 用于表示哪些配置请求存在的位掩码。
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- 长度与 NumAddresses 匹配
ConfigValues [[u8; 4]] -- 长度等于 TransactionConfigMask 的 popcount（置位数）。
  详见 TransactionConfigMask 部分。
InstructionHeaders [(u8, u8, u16)] -- 长度为 NumInstructions。值为
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- 长度 = NumInstructions。
  每个 InstructionPayload 是以下字节数组的拼接：
    InstructionAccountIndexes [u8] -- 长度 = 对应 InstructionHeader 中的
    NumInstructionAccounts
    InstructionData [u8] -- 长度 = 对应 InstructionHeader 中的
    NumInstructionDataBytes
Signatures [[u8; 64]]

指令头明确指明程序账户索引、指令账户数量和指令数据长度，使得无需解析每条指令的载荷即可确定消息边界。

V1 交易仍然限制为 12 个签名、64 个账户地址、64 条指令以及每条指令 255 个账户索引。大型交易仍然必须符合所请求的计算单元限制、加载的账户数据限制、账户锁定规则以及区块的可用执行能力。

现有的解析器不能把 v1 当作最大长度更大的 v0 来处理。检查序列化交易的索引器、RPC、SDK 和签名基础设施必须识别 0x81 前缀，并支持新的字段顺序。特别值得注意的是，v1 签名出现在交易的末尾，而不是像 legacy 和 v0 交易那样位于消息之前。

Transaction v1 用交易头中的字段取代了 Compute Budget 程序的配置指令。初始的 TransactionConfigMask 可以声明交易的：

• 以 lamports 为单位的总优先费
• 计算单元限制
• 加载的账户数据大小限制
• 请求的堆大小

每个被置位的位对应一个随后的四字节配置值，其中 64 比特的优先费占用两个掩码位置。该掩码被设计为可在未来的交易版本中扩展。

状态债券（Rent）降低

高昂的状态债券要求（通常称为 "rent"）仍然是 Solana 上账户密集型应用面临的主要摩擦来源之一。这个名称有点误导，因为 rent 并不是一种经常性存储费用，而是账户在其状态保持链上期间必须持有的一种可退还债券。Lamports 通常可以在账户关闭时收回，但在那之前，它们代表着开发者或用户必须预先提供且无法动用的资金。

Agave 4.2 引入了由功能开关控制的 SIMD-0437: Incrementally Reduce lamports_per_byte to 696 实现，将 lamports_per_byte 常量从 6,960 降低到 696。这意味着 rent 降低了 90%（更准确地说，是租金豁免最低余额降低了 90%），通过五个独立的功能开关逐步实施：6,960 → 6,333 → 5,080 → 2,575 → 1,322 → 696。

当其中一个开关激活时，Agave 会更新 Bank 的 rent 配置，并通过 Rent sysvar 发布新值。分阶段推出使网络能够观察应用程序在每个价位上的反应，如果状态增长或验证者资源使用变得令人担忧，可以在下一次降低之前叫停。

账户的租金豁免最低余额是根据其分配的数据大小加上固定的 128 字节存储开销计算的：

minimum_balance = (128 + account_data_size) × lamports_per_byte

在这一变更下，rent 机制本身没有改变：账户仍然需要最低余额，并且该余额在账户关闭时仍然可以收回。只有必须作为债券锁定的 SOL 数量发生了变化。

一个标准的 SPL Token 账户为 165 字节。加上 128 字节的开销，其有效大小为 293 字节。90% 的 rent 降低使得此类账户所需的 SOL 从约 0.16 美元降至不到 2 美分。

这对稳定币支付、代币分发、忠诚度系统和直接空投具有特别重要的影响。钱包并不直接持有 SPL Token；通常，每个 mint 都需要一个关联 Token 账户（ATA）。当接收者还没有所需的 ATA 时，发送者可以在转账的同时创建它，但还需要为接收者的租金豁免余额提供资金。这通常是对每个钱包与 mint 配对一次性支付的接入成本，而不是后续每笔支付都要承担的成本。尽管如此，当规模扩大时，这笔成本可能大到足以决定企业是补贴接入成本，还是将成本转嫁给用户。

Solana 的状态增长

分阶段降低之所以重要，是因为降低状态债券也减少了攻击者为创建和保留无用状态而必须锁定的资金量。Solana 状态会被每个验证者复制、索引、纳入快照并加以维护，因此持续的状态增长最终会影响磁盘需求、AccountsDB 操作乃至运营成本。

根据 Solana 基金会最近的分析，AccountsDB 存储文件占用约 495 GB，而建议的分配量为 1 TB。在计划中的 rent 降低之后，要耗尽这些余量，攻击者需要投入价值约 1,720 万美元的 SOL。如果将建议的验证者存储分配量翻倍至 2 TB，攻击者的资金需求将提高到 5,100 万美元。

综合考虑新账户的创建和旧账户的关闭后，状态每天约增长 0.3 GB。

epoch 997 的状态快照显示，状态消耗高度集中。SPL Token 账户是最大的类别，而 OpenBook 和 Serum 账户约占活跃状态的 30%，反映了链上订单簿的复杂架构。分析还估计，约 30% 的 SPL Token 空间与 Pump.fun 这类代币发行平台风格的资产相关。

安全措施

安全地降低状态债券需要一条可行的反向路径。如果没有额外的运行时变更，日后提高租金豁免最低余额会立即使现有账户跌破新的阈值。即使没有分配任何额外状态，写锁定这些账户的交易也可能失败，从而导致大规模中断。

这正是 SIMD-0392: Adapt Runtime for Rent Increases 发挥作用之处：它修改了执行后的最低余额规则，使现有账户在 rent 上涨时可以被豁免。当一个账户已存在、大小未增长且保持相同所有者时，其允许的最低余额取以下两者中的较低者：

1. 当前 rent 费率下的最低余额
2. 账户执行前的余额

新账户仍然必须满足当前的租金豁免最低余额。增加分配大小或更换所有者的账户也同样如此。零余额仍然代表账户关闭。这样一来，现有状态可以继续以之前的债券金额运行，同时确保新分配的状态按最新的费率支付。

SIMD-0438: Safeguard for rent-exempt minimum increase 增加了一个独立的保护性功能开关，将 lamports_per_byte 恢复为原来的 6,960。它预计只在 rent 降低导致过度状态增长或其他重大运营问题时才会被激活。由于该开关在降低措施开始之前就已存在，核心开发者无需在状态增长事件发生过程中再去设计、审查和部署新的共识变更。

五个降低开关、SIMD-0392 中的豁免规则以及 SIMD-0438 中的回退机制，共同让这一推行过程在协议层面具备可逆性。网络可以逐步降低债券，观察活跃状态和验证者存储行为，在某个中间值上暂停，或恢复原始要求，而无需强制每个现有账户立即补足余额。

缩短至 200ms 的 Slot 时间

Solana 最受期待的性能升级之一，是将目标 Slot 时间从 400ms 缩短到 200ms。主要好处是延迟更低。在 200ms 的 Slot 下，Solana 原本由连续四个 Slot 组成的领导者窗口将从 1.6 秒缩短到 800ms，从而减少确认时间，并限制恶意领导者拖延、重排或选择性打包交易的时间。更短的 Slot 还为预言机消费者和做市商等应用程序提供了更细粒度的链上时间。

该提案旨在保持 Solana 现有的经济模型和吞吐量。通胀参数、Alpenglow 下的 Validator Admission Ticket 成本以及每个 Slot 的工作限制都按比例进行了调整。然而，如果 200ms Slot 在 Alpenglow 之前到来，验证者的投票成本大约会翻一番，因为他们需要以两倍的频率投票。

要更深入地了解 200ms Slot，请参阅我们之前在 Agave 4.1 详解 中的报道。

其他值得关注的更新

Agave 4.2 发布周期还将激活几项较小但值得关注的改进。

Alpenglow 就绪状态

Agave 4.2 随版本发布了功能完整的 Alpenglow，但不会在主网上激活新的共识协议；核心工程团队正在利用这个发布周期进行进一步测试、审计和加固，为预计随 Agave 4.3 进行的共识迁移做准备。因此，运行 4.2 的验证者已经搭载了完整的 Alpenglow 实现，包括 Votor 投票引擎及其 BLS 证书验证组件。

为了扩大对代码的安全审查范围，Anza 还在举办 Alpenglow 漏洞赏金竞赛，奖金池高达 50,000 SOL，提交窗口为 8 月 5 日至 19 日。Alpenglow 此前在开发、monorepo 迁移和内部审计期间一直被排除在 Agave 常设赏金计划之外；此次竞赛标志着它正式进入赏金计划，旨在发现可能逃过早期审查的问题。

Stake 程序从浮点到定点

Agave 4.2 发布周期还包括由功能开关控制的 SIMD-0391: Stake Program Float to Fixed-Point 实现，将 Stake 程序 的预热和冷却计算中的 IEEE-754 浮点运算替换为确定性的定点整数运算。主要动机在于兼容标准 eBPF 工具链——该工具链不支持浮点运算。Solana 的 SBF 工具链可以使用确定性的软浮点例程来模拟它们，但这种方式效率低下，并且阻碍了 Stake 程序向 no_std 实现的迁移。

大多数应用程序不需要更改；不过，独立重现有效、激活中或停用中质押状态的索引器和质押工具，应当在该功能激活后采用新的整数规则。

新的治理工具

Agave 4.2 发布周期还推出了自去年以来一直在开发的新治理工具。该工具为验证者和原生质押者提供了一个链上流程，用于就重大经济和协议级决策表达立场。

其核心组件 svmgov 是一个基于 Anchor 的程序，负责管理提案创建、支持、质押权重投票和定稿。投票权重来自节点共识网络（NCN）生成的特定 epoch 质押快照。独立运营者各自计算快照，就规范的 Merkle 根达成共识，并将其发布到链上；验证者随后借助 Merkle 证明来证实其活跃质押。

活跃质押至少为 100,000 SOL 的验证者可以创建提案，而提案需要获得集群总质押 15% 的支持，才能进入投票流程。治理仓库还包括一个 Rust CLI 和 Web 前端，用于投票和跟踪支持。

完整的提案文档存放在独立的 Solana Governance Proposals 仓库中，并固定到特定的 Git 提交；链上提案账户则存储链接、生命周期状态和投票计数。验证者最初使用委托给他们的所有质押进行投票，但个人委托者对其 SOL 保留主权；质押者可以针对特定质押账户提交覆盖投票，将该质押从验证者的计票中移除，并按质押者自己的投票重新分配。

Solana 治理提案（SGP）旨在补充而非取代 SIMD：SGP 回答的是方向性问题，即网络是否应该推行某项变更；而相关的 SIMD 则规定如何实施该变更。

三个 SGP 均已通过支持阶段，将构成新系统下的第一轮治理投票：

• SGP-0001: The Solana Constitution 提议批准一份规范的治理社会契约，定义开发者、验证者和质押者的角色，并正式确立 SGP 流程。
• SGP-0002: Double Disinflation 请求网络将 SOL 的年通胀衰减率从 15% 翻倍至 30%，同时保持 1.5% 的最终通胀率不变，将到达该最终通胀率的预计时间从约 5.7 年缩短至 2.8 年。
• SGP-0003: Resource and Inclusion Fee 提议将现有的固定基础费用结构替换为支付给领导者的 2,500 lamport 打包费，以及基于请求的交易成本单位的独立资源费用（全额销毁），同时保持优先费分配不变。

结论

Agave 4.2 是 Solana 近年来最具影响力的版本之一。更快的 200ms Slot 使网络更接近实时响应；计划中的 90% 状态债券降低，使账户创建成本大幅下降；而 4,096 字节的 Transaction v1 为复杂指令、加密证明和账户密集型应用释放出更大的空间。总而言之，这些变更让 Solana 对开发者和用户来说都更快、更便宜、更具表现力。

更多资源

• Agave 4.2 发布计划
• 功能开关跟踪器计划
• Agave 4.2 变更日志
• Agave 4.2 Pull Requests

• 原文链接： helius.dev/blog/agave-v4...
• 鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～