Agave v2.2 更新：你需要了解的一切

Agave 2.2 发布周期的重要更新 

• 大规模性能优化
• 区块限制从 5000 万 CU 提升至 6000 万 CU，增幅 20%
• 引入 Accounts Lattice Hash (ALH)
• Secp256r1 签名验证（从 Agave 2.1 发布周期推迟至此）
• 部署和执行 SBPFv1、v2 和 v3 程序
• 解除 CPI 调用方限制
• Loader-v4

本文各章节相互独立，方便读者探索与自己最相关的主题。无论你是验证节点运营者、开发者还是活跃用户，这份全面的 Agave 2.2 指南都将提供充分利用最新改进所需的关键洞察。

功能推出进度

截至撰写本文时，总质押量中已有 19.8% 正在运行 Agave v2.2。* 这表明全网采用该版本获得了强有力的支持。主网功能门控激活已在升级期间暂时停止，预计将在按计划依次激活后很快恢复。

Agave 2.2 引入的大多数主要功能目前仍受门控限制，尚未在主网上激活。在 2.2 发布周期内，这些功能将通过 Solana 的功能门控系统逐步启用。激活时间取决于功能优先级，以及它们在测试网和开发网集群中的推出顺序。请参阅 Agave 功能门控跟踪器获取最新进展。

将区块限制提高至 6000 万 CU

Anza 为 2025 年设定了一个宏伟目标：将 Solana 的可用区块空间翻倍。作为这一计划的一部分，SIMD-0256：将区块限制提高至 6000 万计划纳入即将发布的 Solana 2.2，相比当前区块限制提高 20%。

此前的升级已将区块限制从 4800 万计算单元 (CU) 提高到 5000 万，此后区块时间始终低于 400ms 的目标。近期数据显示，区块经常达到 5000 万 CU 的上限，表明网络已准备好进一步扩容。

注意：由于 Firedancer 仪表板的报告逻辑中存在一个硬编码常量，部分区块显示为 104% 满载。

此次更新中的其他协议限制保持不变：

• 每个区块中单个账户的计算预算保持在 1200 万 CU 不变。
• 单笔交易的最大计算量上限仍为 140 万 CU。
• 每个区块内投票交易的总计算量限制仍为 3600 万 CU。
• 每个区块可分配的新账户数据上限仍为 100 MB。

提高区块限制会直接影响用户体验：更高的网络吞吐量会降低交易费中位数，并提高交易在网络拥堵期间成功上链的概率。

提高区块限制面临的挑战

提升吞吐量时，建议谨慎、逐步提高区块限制，因为必须解决两个关键挑战：

1. 基础设施就绪情况

更广泛的生态系统基础设施必须跟上核心客户端的优化步伐。具体而言，写入层不能超过读取层（例如 RPC 节点、索引器和归档服务）的承载能力，否则用户体验将会下降。

2. 及时传播区块

另一个瓶颈在于如何将区块从领导者节点传递到集群中的其他节点。显著增大的区块可能导致区块分发时间超过 400ms 的目标，尤其是在高负载情况下。

一个迫切的挑战来自交易验证单元 (TVU) 的重传阶段，分片会通过该阶段在集群中分发。由于 Turbine 采用了激进的 200 扇出系数（即每个节点负责向另外 200 个节点中继分片），大型验证节点的每秒出站数据包数 (PPS) 接近 150,000。如果处理效率低下，可能会导致分片积压、领导者交接异常，以及整个网络中的状态视图不一致。

为解决这一问题，Anza 工程师目前正在彻底改造区块分发管线。团队当前正致力于迁移至 XDP (eXpress Data Path)，它通过将数据包处理直接暴露给用户空间来绕过内核。这种方法消除了代价高昂的中间复制，使验证节点软件能够直接与网络接口卡 (NIC) 通信。

Accounts Lattice Hash (ALH)

Solana 要支持数十亿个账户，就需要一种扩展性更强的全局账户状态哈希方法。新引入的 Accounts Lattice Hash (ALH) 将取代此前基于 Merkle 的账户哈希，提供一种基于同态哈希、效率和扩展性更高的替代方案。它可以利用现有哈希创建新哈希，无需从头重新计算。

Solana 目前维护两种账户状态哈希：

• **Epoch Accounts Hash (EAH)：**整个账户状态的 Merkle 根，每个 epoch 计算一次。
• **Accounts Delta Hash (ADH)：**单个区块内已修改账户的 Merkle 根，每个区块都会重新计算。

两者都依赖于按公钥对账户排序并构建 Merkle 树，这会带来性能和扩展性挑战，尤其是在账户集不断增长时。双哈希模型是一种折中方案：EAH 准确（包含所有账户状态），但计算频率较低；ADH 计算频率高，但仅包含部分状态（只有已修改的账户）。理想情况下，每个区块都应包含整个账户状态完整且最新的哈希，同时避免重新计算 Merkle 树的开销。

Accounts Lattice Hash：工作原理

ALH 使用支持增量更新的同态哈希函数来实现这一目标。ALH 不会每次都重新构建 Merkle 树，而是在写入账户时直接添加或减去单个账户哈希 (LtHashes)。最终会得到一个 2048 字节的哈希，用于汇总所有账户的状态。关键是，它可以逐区块更新，无需从头重新计算。

这种方法的复杂度为 O(n)，相比 Merkle 树的 O(n log n) 复杂度有了显著改进。它让每个区块都能包含整个账户状态的哈希，而无需进行高成本的重新计算。

集成与停用的哈希

此次推出涵盖三个独立的 SIMD，并将在 Agave 2.2 发布周期内分别激活相应的独立功能门控。

• SIMD-0215：Accounts Lattice Hash
• SIMD-0220：快照使用 Accounts Lattice Hash
• SIMD-0223：移除 Accounts Delta Hash

完成这些更改后，Accounts Lattice Hash 将同时取代 ADH 和 EAH。ALH 将集成到每个区块的 bank 哈希中，使全状态哈希的生成频率从每个 epoch 一次提高到每个区块一次。

性能与权衡

改用 ALH 后，无需再对每个区块执行基于 Merkle 的哈希计算，可显著提升验证节点性能。这将简化共识和快照生成流程。例如，验证节点在区块最终确认或生成快照时，不再需要对账户排序或重建树；ALH 更新只是简单的加法操作。

不过，与 Merkle 树或 Verkle 树不同，这种方法不支持包含证明或排除证明。虽然这会影响轻客户端和简单支付验证 (SPV) 等特定的密码学验证用例，但考虑到效率的显著提升，这种权衡仍被认为是值得的。有关包含证明替代方法的讨论，请参阅此处。

快照集成

由于计算初始 Accounts Lattice Hash 的成本很高，ALH 值现在会持久保存在验证节点快照中，并在启动时从可用快照中恢复。快照将采用更新后的 ALH 格式，而非基于 Merkle 的 Snapshot Hashes，使 Solana 的存储和哈希模型进一步统一到这一新设计上。

原生 Secp256r1 签名验证

Solana 正在添加对 secp256r1 椭圆曲线签名验证的原生支持。这项关键升级使链上应用能够兼容 Passkeys、WebAuthn 标准和包括双因素认证 (2FA) 在内的高级账户抽象模型。此次更新将 Web2 中已经普及的无密码身份验证引入 Web3 领域，提升链上应用的安全性和易用性。

该功能最初计划随 Agave 2.1 发布，但后来推迟到 2.2。有关更多详情，请参阅我们在 Agave 2.1 更新中对 Secp256r1 签名验证的全面解析。

预编译程序对齐漏洞

Agave 2.2 开始推出后不久，Secp256r1 和 Ed25519 预编译程序的实现中发现了一个严重漏洞。该漏洞会在新的 `--transaction-structure` 视图标志下触发。该标志会暴露原始交易布局，但不保证对齐。预编译程序错误地假定指令数据采用 2 字节对齐，导致区块生产者和验证节点的执行结果不一致。这造成 bank 哈希不匹配，迫使领导者中止运行，从而导致可用性下降。该问题于 4 月 9 日首次报告，并在 4 月 11 日前迅速修复。该漏洞未影响用户资金。更多详情请参阅随后发布的根本原因分析。

部署和执行 SBPFv1、v2 和 v3 程序

Solana Berkeley Packet Filter (SBPF) 是一种定制虚拟机，旨在高效、安全地执行 Solana 程序。它是最初为 Linux 构建的扩展 Berkeley Packet Filter (eBPF) 的 Rust 分支。 

升级 Solana 的 Berkeley Packet Filter (SBPF) 对于提升性能、增强安全性和为应用开发者解锁新功能至关重要。Agave 2.2 为 SBPF 虚拟机引入了正式的版本控制系统，最初由 SIMD-0161 提出，为长期可维护性和性能升级奠定基础。这项变更支持部署和执行 SBPFv1（SIMD-0166）、SBPFv2（SIMD-0173、SIMD-0174）和 SBPFv3（SIMD-0178、SIMD-0179、SIMD-0189）程序，建立了一个可持续框架，无需全网重新部署即可分阶段演进程序执行环境。

在此之前，所有 SBPF 升级都必须通过全局功能门控引入，导致运行时演进非常繁琐，部署协调几乎不可能完成。版本控制将程序行为与全局运行时解耦，转而与每个程序的版本标签绑定，从而解决这一问题。该标签编码在可执行与可链接格式 (ELF) 文件头的 e_flags 字段中。这种方法具备以下优势：

明确的运行时行为

每个程序都会声明其预期使用的指令集架构（即 SBPF 版本）。程序运行时将根据该版本调整行为。

可控推出

功能门控将分别启用新版 SBPF 的部署和执行，并随时间推移逐步淘汰旧版本。整套变更会打包到不同的 SBPF 版本中，使升级更简洁、更易于管理。

分阶段弃用

旧版 SBPF 被弃用后，最终可以停止支持，从而简化虚拟机逻辑。弃用过程会缓慢推进，为开发者留出充足时间来迁移或重新部署程序，并适配新版本。

版本判别符

目前，协议会将 0x0020 以外的任何 e_flags 值视为 SBPF v0，这在现有系统下有效。然而，这种方法无法扩展以支持多个 SBPF 版本，因此必须更新。

启用新版 SBPF 的第一个功能门控激活后，协议将改变对 e_flags 的解释方式，把该值直接映射到对应的 SBPF 版本号。在这一系统下，0x0000 表示 SBPF v0，0x0001 表示 SBPF v1，以此类推。

解除 CPI 调用方限制

Agave 2.2 发布周期包含一项期待已久的改进，它移除了跨程序调用 (CPI) 的一项历史限制。目前，通过 CPI 调用任何程序时，调用方都必须将其作为指令账户显式传入。这会增加交易构建的复杂度并带来大量计算开销，尤其是在 CPI 深度嵌套时。然而，这项限制只是历史遗留，在当前协议中已无必要。

SIMD-0163 解除了这项限制，允许 CPI 指令直接引用交易顶层账户列表中的程序账户，不再需要在每一层调用中递归传递这些账户。此项变更带来以下优势：

• 避免对程序账户进行重复序列化和反序列化，从而大幅降低 CU 使用量（可执行文件存储在独立账户中的 loader-v3 程序除外）。由于这些账户体积很大（~10 MB 二进制文件），相关操作的成本尤其高昂。
• 无需通过指令栈层层传递被调用程序账户，简化交易构建。
• 提高可组合性，更易于构建模块化和深度嵌套的程序架构。

向后兼容性

现有程序不会受到影响，除非它们希望利用这项变更。在这种情况下，可以选择以下做法之一：

对于静态硬编码被调用方，并且仅需将其作为任意指令账户来满足运行时限制的程序，可以传入 NativeLoader1111111111111111111111111111111 之类的占位符，以免改变其他指令账户的索引。

所有其他会动态调用特定指令账户中所传内容的现有程序，都必须更新并重新部署，才能从解除限制中受益。

这项优化不会影响安全性。“延迟可见性”功能可确保程序无法调用同一笔交易中新增、修改或移除的其他程序。

Loader-v4

Agave 2.2 引入了对 Loader-v4 的支持。这是一种更精简、更灵活的程序部署机制，旨在取代 Loader-v3。通过 SIMD-0167 启用的 Loader-v4 简化了程序账户管理，改进了升级工作流，并为线上程序引入关键安全功能，尤其适合 DeFi 等高风险环境中运行的程序。

Loader-v4 的主要功能：

**单账户模型：**Loader-v4 不再需要代理账户和独立的程序数据缓冲区。现在，每个程序只需一个账户表示。

维护模式

现在可以将程序置于不可执行的“维护模式”，而无需永久关闭或重新部署。这会保留原始程序地址，让开发者可以暂停执行（例如发生漏洞利用时），同时无需放弃该地址。

任意调整大小

Loader-v4 支持在部署后扩大或缩小程序二进制文件，从而更灵活地分配资源，并回收锁定的资金。

可选使用缓冲区

与重新部署时始终需要外部缓冲区账户的 Loader-v3 不同，Loader-v4 将缓冲区改为可选。程序现在可以直接重新部署到主程序账户中，从而将上传期间需要锁定的资金减半。

部分重新部署

Loader-v3 要求每次升级都重新上传完整的程序二进制文件。相比之下，Loader-v4 支持部分上传，开发者可以只修补程序的特定部分。这对于小规模更新尤其有用。

从 Loader-v3 无缝迁移

使用 Loader-v3 部署的程序可以迁移到 Loader-v4，无需更改程序地址。这通过 Loader-v3 中新增的 Migrate 指令实现。此操作会延迟可见性，这意味着程序在当前 slot 的剩余时间内将不可用。

激活 Loader-v4 后，将触发另一个独立的功能门控，禁止向 Loader-v3 进行新的部署。现有 Loader-v3 程序仍可正常运行，但今后的所有部署预计都将使用 Loader-v4。

最终确认 loader-v4 程序时，可以提示下一个版本的地址，从而可能形成一个链表。这提供了一种无需重新部署程序的替代方案，并允许用户界面向用户提供可供选择的已最终确认程序版本列表。

在 Loader-v4 中，管理权限和关闭账户的机制保持不变。所有这些功能都可通过新的 program-v4 CLI 子命令使用。

总结

Agave 2.2 是 Solana 协议的一个重要里程碑，它带来了关键的运行时增强功能和新能力，拓展了网络的技术边界。此版本引入了多项关键变更：区块容量提高 20%；集成 Accounts Lattice Hash (ALH)，实现可扩展的状态哈希；多项程序开发升级；以及支持 Secp256r1 签名验证，这对实现主流密码学集成至关重要。这些改进共同提高了吞吐量和开发者体验，并增强了网络支持更广泛应用的能力。

无论你是在构建程序、运营验证节点还是与网络交互，Agave 2.2 都能为 Solana 解锁更高的性能、灵活性和韧性。

更多资源

• Agave 客户端代码仓库
• Agave v2.2 发布时间表
• Agave v2.2 变更日志
• 带 Agave v2.2 标签的 Pull Request