新消息：Helius 收购 Light Protocol
Agave 4.2 横幅
博客/更新

Agave 4.2 更新：你需要了解的一切

研究员X 上的 Lostin
阅读需 13 分钟
目录

简介

随着 Agave 4.2 发布，Solana 的核心验证者客户端继续开拓新领域。这个重大版本聚焦三项备受期待、由功能门控控制的升级：200ms 时隙、状态保证金降低 90%，以及通过新的交易 v1 格式支持 4,096 字节的交易。此外，该版本提前实现了功能完整的 Alpenglow，计划在后续版本中激活；同时，XDP 传输现已默认启用。

X

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

Brennan Watt
Brennan Watt
Anza CEO

重要更新

  • 采用新交易 v1 标准，交易容量扩大 3.3 倍 *
  • 状态保证金（租金）降低 90% *
  • 时隙时间缩短至 200ms *
  • Alpenglow 功能完整
  • 新治理工具（与 SIMD 相关）

* 由功能门控控制的升级

更大的交易（交易 v1）

Agave 4.2 发布周期包括激活一项功能门控，将交易大小上限从长期沿用的 1,232 字节提高至 4,096 字节。更高的上限在 SIMD-0296：扩大交易大小中正式定义，增幅约为 3.3 倍，并且仅适用于 SIMD-0385：交易 V1 格式引入的新交易 v1 格式。旧版和 v0 交易保持不变，仍受现有 1,232 字节上限约束。

对开发者而言，这不仅意味着指令数据拥有更多空间。过去无法装入单笔交易的加密证明、多签批准、大型账户列表和其他载荷，现在可以通过一次协议原生的原子操作执行。此变更不会提高 Solana 的计算、账户、签名或指令数量限制。

最初的 1,232 字节上限继承自 Solana 早期的网络架构。交易以独立 UDP 数据报的形式传输，需要装入 IPv6 的 1,280 字节最小最大传输单元（MTU）。扣除 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 交易。

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

交易 V1 规范

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

Transaction V1 Specification
VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

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

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

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

交易 v1 使用交易标头中的字段替代计算预算程序配置指令。初始 `TransactionConfigMask` 可以声明交易的：

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

每个置位位都标识一个随附的四字节配置值，其中 64 位优先费占用两个掩码位置。该掩码的设计支持在未来的交易版本中扩展。

状态保证金（租金）降低

较高的状态保证金要求通常称为“租金”，仍是账户密集型应用在 Solana 上面临的最大阻力之一。这个名称有些误导，因为租金并不是周期性存储费用，而是账户在其状态保留于链上期间必须持有的可退还保证金。账户关闭时通常可以收回 lamports，但在此之前，它们代表开发者或用户必须预先提供并冻结的资本。

Agave 4.2 引入了由功能门控控制的 SIMD-0437：逐步将 lamports_per_byte 降至 696 实现，将 `lamports_per_byte` 常量从 6,960 降至 696。这意味着租金降低 90%（更准确地说，是免租最低余额降低 90%），并通过五个独立的功能门控分阶段完成：6,960 → 6,333 → 5,080 → 2,575 → 1,322 → 696。

其中一个门控激活时，Agave 会更新 Bank 的租金配置，并通过 Rent sysvar 发布新值。分阶段推出使网络能够观察应用在各个价格水平下的反应；如果状态增长或验证者资源使用情况令人担忧，可在下一次降低前停止。

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

minimum_balance = (128 + account_data_size) × lamports_per_byte

此次变更不会改变租金机制本身：账户仍需维持最低余额，并且该余额在账户关闭时仍可收回。改变的只是必须作为保证金锁定的 SOL 数量。

标准 SPL Token 账户大小为 165 字节。加上 128 字节开销后，其有效大小为 293 字节。租金降低 90% 后，此类账户所需的 SOL 价值将从约 ~$0.16 降至不到 2 美分。

这对稳定币支付、代币分发、忠诚度系统和直接空投尤为重要。钱包不会直接持有 SPL 代币；通常每种铸币都需要一个关联代币账户（ATA）。如果接收方尚无所需的 ATA，发送方可以在转账时一并创建，但还必须为接收方的免租余额提供资金。对于每个钱包与铸币组合，这通常是一次性的接入成本，而不是每次后续支付都要承担的成本。即便如此，在大规模场景下，这笔费用仍可能高到足以决定企业是补贴接入成本，还是将其转嫁给用户。

Solana 的状态增长

分阶段降低至关重要，因为降低状态保证金也会减少攻击者为创建并保留无用状态而必须冻结的资金。Solana 状态会被复制、索引、纳入快照并由每个验证者维护，因此持久状态的增长最终会影响磁盘要求、AccountsDB 操作乃至运营成本。

根据 Solana Foundation 最近的分析，AccountsDB 存储文件约占 495 GB，而建议分配容量为 1 TB。计划中的租金降低后，攻击者若想耗尽剩余空间，需要投入价值约 1,720 万美元的 SOL。将建议的验证者存储分配翻倍至 2 TB，会把攻击者的资金要求提高至 5,100 万美元。

将新账户创建和旧账户关闭都计入后，状态增长速度约为每天 0.3 GB。

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

安全措施

要安全降低状态保证金，必须确保能够反向调整。如果不对运行时进行额外变更，未来提高免租最低余额会立即使现有账户低于新门槛。对这些账户进行写锁定的交易即使没有分配任何额外状态，也可能失败，进而造成大范围中断。

为此，SIMD-0392：调整运行时以适应租金上涨修改了执行后的最低余额规则，使现有账户可以在租金上涨时沿用旧规则。如果账户已存在、大小未增加且所有者保持不变，其允许的最低余额将取以下两者中的较低值：

  1. 按当前租金费率计算的最低余额
  2. 账户执行前的余额

新账户仍必须满足当前的免租最低余额要求。增加分配大小或更改所有者的账户同样如此。余额为零仍表示账户关闭。这样，现有状态可以继续按原有保证金额运行，同时确保新分配的状态按最新费率支付。

SIMD-0438：免租最低余额提高保障措施增加了一个独立的保护性功能门控，可将 `lamports_per_byte` 恢复为旧值 6,960。仅当租金降低导致状态过度增长或出现其他重大运营问题时，才会激活该门控。由于门控在租金开始降低前就已存在，核心开发者无需在状态增长事件发生期间临时设计、审查和部署新的共识变更。

五个降低门控、SIMD-0392 中的旧规则保留机制，以及 SIMD-0438 中的回退方案，共同使此次推出能够在协议层面逆转。网络可以逐步降低保证金，观察活跃状态和验证者存储的表现，在中间值暂停，或恢复原始要求，而无需强制所有现有账户立即补足余额。

时隙时间缩短至 200ms

Solana 最受期待的性能升级之一，是将目标时隙时间从 400ms 缩短至 200ms。主要收益是降低延迟。在 200ms 时隙下，Solana 的四时隙领导者窗口将从 1.6 秒缩短至 800ms，从而缩短确认时间，并限制恶意领导者延迟、重排或选择性纳入交易的时间。更短的时隙还能为预言机使用方和做市商等应用提供粒度更细的链上计时。

该提案旨在维持 Solana 现有的经济模型和吞吐量。通胀参数、Alpenglow 下的 Validator Admission Ticket 成本，以及每时隙工作量上限都会按比例调整。不过，如果 200ms 时隙先于 Alpenglow 推出，验证者投票成本可能大致翻倍，因为验证者需要以两倍频率投票。

要深入了解 200ms 时隙，请阅读我们此前对 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 一直不在常设 Agave 赏金计划范围内；此次竞赛标志着它开始具备赏金资格，旨在发现早期审查可能遗漏的问题。

Stake Program 从浮点数转为定点数

Agave 4.2 发布周期还包括由功能门控控制的 SIMD-0391：Stake Program 从浮点数转为定点数实现，在 Stake Program 的预热和冷却计算中，以确定性的定点整数运算取代 IEEE-754 浮点运算。主要动机是兼容不支持浮点运算的标准 eBPF 工具链。Solana 的 SBF 工具链可以使用确定性软浮点例程模拟这些运算，但效率较低，并会阻碍 Stake Program 迁移至 `no_std` 实现。

大多数应用无需更改，但独立复现有效、激活中或停用中质押状态的索引器和质押工具，应在该功能激活后实现新的整数规则。

新治理工具

Agave 4.2 发布周期还将推出自去年起一直在开发的新治理工具。该工具为验证者和原生质押者提供链上流程，使其能够就重大经济和协议层决策表达立场。

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

活跃质押至少达到 100,000 SOL 的验证者可以创建提案，而提案在进入投票流程前需要获得集群总质押量 15% 的支持。治理代码仓库还包含用于投票和跟踪支持情况的 Rust CLI 与 Web 前端。

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

Solana Governance Proposals（SGP）旨在补充而非取代 SIMD：SGP 回答网络是否应该推进某项变更这一方向性问题，相关 SIMD 则说明应如何实施该变更。

已有三个 SGP 通过支持阶段，它们将成为新系统下的首轮治理投票：

  • SGP-0001：Solana 宪章提议批准一份规范的治理社会契约，定义开发者、验证者和质押者的角色，并正式确立 SGP 流程。
  • SGP-0002：双倍通缩要求网络将 SOL 的年度通胀递减率从 15% 提高一倍至 30%，同时保持 1.5% 的最终通胀率不变，把达到该最终比率的预计时间从约 5.7 年缩短至 2.8 年。
  • SGP-0003：资源费与纳入费提议用支付给领导者的 2,500 lamport 纳入费，以及根据请求的交易成本单元计算并全部销毁的独立资源费，取代现有的固定基础费用结构，同时保持优先费分配方式不变。

结论

Agave 4.2 是 Solana 近年来影响最深远的版本之一。更快的 200ms 时隙让网络更接近实时响应；计划将状态保证金降低 90%，大幅降低账户创建成本；4,096 字节的交易 v1 则为复杂指令、加密证明和账户密集型应用释放了更多空间。这些变更共同让 Solana 对开发者和用户而言更快、更便宜，也更具表达能力。

更多资源

相关文章

订阅 Helius

及时了解 Solana 开发的最新动态，并在我们发布新内容时收到更新

放大图片