Solana Agave v2.2 更新：你需要知道的一切
- Helius
- 发布于 1天前
- 阅读 85
Agave v2.2 版本是 Solana 在多客户端生态系统中向前迈出的重要一步，显著提升了网络性能及开发者体验。 主要更新包括：区块容量提升 20%（计算单元从 50M 增加到 60M）、引入账户格哈希（ALH）以优化状态哈希、支持 Secp256r1 签名验证以增强密码学集成，以及多个程序开发升级，包括 SBPF 虚拟机版本控制和 Loader-v4 的引入。
Agave v2.2 更新：你需要知道的一切
非常感谢 Alexander Meißner, 0xIchigo, 和 Will Hickey 审阅了本文的早期版本。
Agave 验证器客户端 v2.2 的发布，标志着 Solana 在迈向更具弹性的多客户端生态系统道路上的又一个重要里程碑。此更新提供了一些关键改进，旨在增强网络性能和开发者体验。
值得注意的 Agave 2.2 发布周期更新
- 广泛的性能优化
- 区块限制从 50M CU 增加 20% 至 60M CU
- 引入账户格哈希（ALH）
- Secp256r1 签名验证（从 Agave 2.1 发布周期推迟）
- 部署和执行 SBPFv1、v2 和 v3 程序
- 取消 CPI 调用者限制
- Loader-v4
- 贪婪调度器 默认激活
本文的每个部分都是独立的，方便读者探索与自己最相关的主题。无论你是验证器运营商、开发者还是参与用户，这份关于 Agave 2.2 的综合指南都提供了充分利用最新改进所需的关键见解。
功能推出
在撰写本文时，总质押量的 19.8% 正在运行 Agave v2.2.*，这表明了对全网采用的强力支持。在升级期间，Mainnet 功能门激活已暂时暂停，预计将在计划的激活顺序后不久恢复。
Agave 2.2 中引入的大多数主要功能当前都已门控，尚未在主网上激活。这些功能将在整个 2.2 发布周期中通过 Solana 的功能门系统逐步启用。激活时间由功能优先级及其在测试网和开发网集群上的推出顺序决定。请参阅 Agave 功能门跟踪器 获取最新更新。
将区块限制提高到 60M CUs
Anza 为 2025 年设定了一个雄心勃勃的目标：将 Solana 上可用的区块空间增加一倍。作为这项工作的一部分，SIMD-0256: 将区块限制提高到 60M 计划包含在即将发布的 Solana 2.2 版本中，与当前区块限制相比提高了 20%。
此前进行了一次升级，将区块限制从 4800 万个计算单元 (CU) 增加到 5000 万个 CU，此后区块时间持续保持在 400 毫秒目标以下。最新数据显示，区块经常达到 50M CU 上限，表明已准备好进一步扩展。
注意：由于 Firedancer 仪表板报告逻辑中的硬编码常量，某些区块显示为 104% 满。
此更新中其它协议限制保持不变：
- 每个区块的每个账户计算预算 保持在 1200 万 CUs 不变。
- 每次交易的最大计算量 仍然上限为 140 万 CUs。
- 每个区块的投票交易的aggregate计算限制 保持在 3600 万 CUs。
- 每个区块的最大新账户数据分配 仍然限制为 100 MB。
提高区块限制直接影响用户体验：更高的网络吞吐量可降低平均交易费用，并提高在拥塞期间成功登陆交易的可能性。
提高区块限制的挑战
在提高吞吐量时，建议采取谨慎且循序渐进的方法来提高区块限制，因为必须解决两个关键挑战：
1. 基础设施准备情况
更广泛的生态系统基础设施必须与核心客户端优化保持同步。具体来说，写入层不能超过读取层（例如，RPC 节点、索引器和存档服务），否则会降低用户体验。
2. 及时传播区块
另一个瓶颈在于将区块从leader节点传递到集群的其余部分。更大的区块可能会导致区块分发时间超过 400 毫秒的目标，尤其是在高负载条件下。
一个紧迫的挑战是交易验证单元 (TVU) 的重传阶段，通过该阶段，碎片在集群中分发。由于 Turbine 激进的 200 的扇出因子（即，每个节点负责将碎片中继到 200 个其他节点），大型验证器的传出数据包速率接近每秒 150,000 个数据包 (PPS)。如果处理效率低下，可能会导致碎片积压、不稳定的leader切换以及整个网络中不一致的状态视图。
为了解决这个问题，Anza 工程师目前正在彻底改革区块分发管道。该团队目前正在努力过渡到 XDP（eXpress Data Path），这使得绕过内核成为可能，从而将数据包处理直接暴露给用户空间。这种方法消除了代价高昂的中间副本，允许验证器软件直接与网络接口卡 (NIC) 通信。
账户格哈希 (ALH)
Solana 支持数十亿个账户的道路需要一种更可扩展的方法来哈希全局账户状态。新引入的账户格哈希 (ALH) 将用基于同态哈希的更高效且可扩展的替代方案替换以前的基于 Merkle 的账户哈希，同态哈希允许从现有哈希创建新哈希，而无需从头开始重新计算。
Solana 目前维护两个账户状态哈希：
- Epoch 账户哈希 (EAH): 整个账户状态的 Merkle 根，每个 epoch 计算一次。
- 账户增量哈希 (ADH): 在单个区块中修改的账户的 Merkle 根，每个区块重新计算。
两者都依赖于按公钥对账户进行排序并构建 Merkle 树，这会导致性能和可扩展性挑战，尤其是在账户集增长时。双哈希模型作为一种折衷方案出现：EAH 是准确的（包括所有账户状态）但频率较低，而 ADH 频率较高但部分（仅修改的账户）。理想情况下，每个区块都将包含整个账户状态的完整且最新的哈希，而无需重新计算 Merkle 树的开销。
账户格哈希：它是如何工作的
ALH 通过使用允许增量更新的同态哈希函数来实现此目标。ALH 不会每次都重建 Merkle 树，而是在将账户写入时简单地添加或减去各个账户哈希（LtHashes）。最终结果是一个 2048 字节的哈希，用于总结所有账户的状态。至关重要的是，这可以逐个区块地更新，而无需从头开始重新计算。
想象一下，你有一个装满Coin的巨大罐子。如果你添加或移除一些Coin，你不会把所有东西都倒出来从头开始计数——你只会更新你的总数。这就是 Solana 最近合并的 SIMD-0215 的本质：账户格哈希 使管理数十亿个账户成为可能。
Ben Hawkins
Solana 基金会质押生态系统负责人
这种方法提供 O(n) 复杂度，与 Merkle 树的 O(n log n) 复杂度相比有了显着改进。它允许每个区块都包含整个账户状态的哈希，而无需代价高昂的重新计算。
集成和退役的哈希
该推出跨越三个独立的 SIMD，并在 Agave 2.2 发布周期中具有相应的独立功能门激活。
通过这些更改，账户格哈希取代了 ADH 和 EAH。ALH 将集成到每个区块的 Bank Hash 中，从而实现区块频率下的全状态哈希，而不是 epoch 频率。
性能和权衡
切换到 ALH 通过消除每个区块上基于 Merkle 的哈希来提供显着的验证器性能优势。这将简化共识和快照生成。例如，验证器不再需要在区块最终确定或快照生成期间对账户进行排序或重建树——ALH 更新是简单的加法运算。
但是，与 Merkle 或 Verkle 树不同，此方法不支持包含或排除证明。虽然这会影响某些加密验证用例，例如轻客户端和简单支付验证 (SPV)，但考虑到巨大的效率提升，这种权衡被认为是值得的。有关包含证明的替代方法的讨论可以在这里找到。
快照集成
由于计算初始账户格哈希的成本很高，因此 ALH 值现在保存在验证器快照中，并在启动时恢复（如果可用）。快照将反映更新的 ALH 格式，而不是基于 Merkle 的快照哈希，从而进一步使 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 Hash不匹配，迫使leader中止，导致可用性损失。该问题于 4 月 9 日首次报告，并于 4 月 11 日迅速得到修复。该错误对用户资金没有影响。更多详细信息可以在 根本原因分析 中找到，该分析在发布后不久发布。
部署和执行 SBPFv1、v2 和 v3 程序
Solana Berkeley 包过滤器 (SBPF) 是一种自定义虚拟机，旨在高效安全地执行 Solana 程序。它是基于 Rust 的扩展 Berkeley 包过滤器 (eBPF) 的分支，最初是为 Linux 构建的。
Solana 的 Berkeley 包过滤器 (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%、集成用于可扩展状态哈希的账户格哈希 (ALH)、多个程序开发升级以及支持 Secp256r1 签名验证，这对于启用主流加密集成至关重要。总而言之，这些改进提高了吞吐量，改善了开发人员体验，并增强了网络支持更广泛应用程序的能力。
无论你是构建程序、运行验证器还是与网络交互，Agave 2.2 都为 Solana 释放了更高的性能、灵活性和弹性。
更多资源
- 原文链接： helius.dev/blog/agave-v2...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
