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

感谢 0xIchigo 和 Brian Wong 审阅本文的早期版本。

引言

Agave v3.1，Solana Agave 客户端的最新演进版本，已经到来！本次更新引入了一系列广泛的升级，改进了客户端性能、验证器操作和开发者体验。本次更新还包括几个重要的特性门控激活，为链上区块奖励分配、有意义的状态债券（即租金）减少以及最值得关注的即将到来的 Alpenglow 共识升级奠定了基础。

值得注意的 Agave 3.1 更新

• 减少重放期间的磁盘 I/O
• 更快的客户端重启
• 快 2 倍的交易处理速度
• 增加 CPI 账户信息限制*
• 验证器投票账户 V4 和延迟的佣金更新*
• 减少 Turbine ChaCha 轮数*
• 新的指令数据指针*
• RPC 改进

* 特性门控升级

无论你是验证器运营商还是开发者，本指南都为你提供充分利用最新改进所需的更新和见解。本文的每个部分都是独立的，读者可以专注于与自己最相关的主题。

在撰写本文时，Agave 3.1.8 被认为是主网升级候选版本（MUC），Anza 正在寻找志愿者来帮助将该版本推广到 25% 的权益。验证者：是时候升级了！

客户端性能提升

这次主要的 Agave 发布包括一系列性能提升。下面，我们重点介绍几个最重要的改进。

减少重放期间的磁盘 I/O

Agave 3.1 极大地减少了重放期间的磁盘活动。下图显示了使用 Agave 3.0 处理真实主网交易的重放过程中一个 10 秒的分析窗口。磁盘操作（显示为红色标记）超过 1,100 个事件。这是一个问题，因为每次磁盘命中都会引入 I/O 等待时间，从而给 banking 和重放增加抖动。

使用 Agave 3.1，重放期间的磁盘 I/O 显著减少。相同的 10 秒窗口显示少于 80 个磁盘操作，降幅达 93%。这提高了重放稳定性，同时减少了磁盘磨损，有助于延长磁盘寿命。

更快的客户端重启

客户端重启性能持续显著提高，这主要得益于 AccountsDB 的优化。在 Agave 1.* 主要版本中，重启通常需要 30 分钟以上。Agave 2.* 版本将其缩短到 10 分钟以下。在 Agave 3.1 下，重启时间进一步缩短，现在通常不到 1 分钟。展望未来，下一个主要版本 Agave 4.0 有望将重启时间缩短到 30 秒以下，从而进一步提高验证器正常运行时间，并减少维护或意外故障后的恢复时间。

更快的交易处理速度

Agave 3.1 包括关键修复，可显著提高交易处理效率。以前，交易处理管道中的错误导致 banking worker 花费过多的时间与 Proof of History 同步，而不是执行交易，因此在领导者模式下，客户端大约有 61% 的时间没有主动调度交易。

通过在 Agave 3.1 中解决这些问题，banking worker 线程现在花费大约 91% 的时间来处理交易。因此，交易处理速度提高了两倍，从而显着提高了吞吐量，并更好地利用领导者时间。

其他值得一提的性能增强包括默认情况下将账户索引完全保留在内存中。Epoch 边界转换也得到了显著改进，现在在 400 毫秒内完成，而以前超过 2 秒，从而大大减少了 Epoch 轮换期间跳过的插槽数量。

网络加固

Anza 通过持续的压力测试、红队演练和 Agave 客户端的实时状态监控，大力投资于弹性。虽然这项工作的细节之前一直保密，但该计划已经足够成熟，现在可以公开承认这项重要的工作。Anza 的一支专门的 invalidator 团队每小时都会使用一组新的测试主动攻击 Solana 的公共测试网。

测试主要分为两类。第一类侧重于网络层拒绝服务场景，在极端条件下对反压力处理和负载分流进行压力测试。第二种形式的测试包括生成包含不寻常和对抗性交易的精选区块，旨在突破 Solana VM 的限制。

Anza 系统地构建攻击场景并开发防御措施。这项工作基于现实的威胁模型，该模型基于恶意、消息灵通、拥有合理权益的验证者可能做的事情以及外部、资金充足且经验丰富的开发者可能尝试的事情。

这种程度的准备在 12 月得到了验证，当时 Solana 遭受了一次持续数周的重大 DDoS 攻击，据报道峰值接近 6 Tbps，使其成为有史以来针对分布式系统的最大攻击之一。尽管规模巨大，网络几乎没有受到可衡量的影响，在整个攻击期间，确认时间不到 1 秒，并且插槽延迟稳定。

增加 CPI 账户信息限制

SIMD-0339：增加 CPI 账户信息限制 计划在 Agave 3.1 发布周期内在主网上激活。这将跨程序调用 (CPI) 帐户信息限制增加了近 4 倍，从 64 个增加到 255 个，从而解决了开发人员构建需要通过 CPI 传递大型帐户列表的程序长期存在的痛点。账户信息是被序列化的账户元数据，传递到 CPI 系统调用中，使被调用程序能够读取调用者提供的账户。

以前，CPI 仅限于每个系统调用 64 个账户信息。此约束强制程序在 CPI 调用之前对账户列表进行重复数据删除和重建，从而增加了复杂性和开销。在实践中，许多实际程序通常会超过此阈值，例如，DFlow 或 Jupiter 等 DEX 聚合器周围的包装器。

除了增加限制之外，此特性门控还引入了 对计算单元成本的更改，该成本与传递给 CPI 的账户信息和指令账户的数量成比例。这保留了程序最小化账户使用的激励措施。

由于仅提高了限制，因此该更改完全向后兼容，并且不会影响现有程序的行为。

验证器投票账户 V4 和延迟的佣金更新

计划在 Agave 3.1 发布周期内激活的两个特性门控更新对于验证器运营商尤其重要。第一个是 SIMD-0185：投票账户 V4，它引入了一个新版本的投票账户状态，以支持即将推出的协议升级，包括 Alpenglow、区块收入分配和佣金改进。

如今，投票账户仅存储单个佣金率。但是，随着即将推出的在 SIMD-0123：区块收入共享 中概述的链上区块收入分配能力，验证器需要能够为不同的收入来源设置单独的佣金率。

此外，包括基本费用和优先级费用在内的所有区块费用收入目前都存入验证器身份账户。这可能会带来运营和安全问题，因为身份账户不能是冷钱包，因为它必须经常为关键网络协议（如 Turbine 和 Gossip）签署消息。

投票账户 V4 通过使用新字段扩展投票状态（请参见下面的代码块）来解决这些约束，这些字段允许验证器配置通货膨胀奖励和区块收入的佣金率和收款人账户。此更新还删除了旧的 prior_voters 字段。

pub struct VoteStateV4 {
    pub node_pubkey: Pubkey,
    pub authorized_withdrawer: Pubkey,

    /// REMOVED
    /// commission: u8,

    /// NEW: the collector accounts for validator income
    pub inflation_rewards_collector: Pubkey,
    pub block_revenue_collector: Pubkey,

    /// NEW: basis points (0-10,000) that represent how much of each income
    /// source should be given to this VoteAccount
    pub inflation_rewards_commission_bps: u16,
    pub block_revenue_commission_bps: u16,

    /// NEW: reward amount pending distribution to stake delegators
    pub pending_delegator_rewards: u64,

    /// NEW: compressed bls pubkey for alpenglow
    pub bls_pubkey_compressed: Option<[u8; 48]>

    pub votes: VecDeque<LandedVote>,
    pub root_slot: Option<Slot>,

    /// UPDATED: serialization structure of the AuthorizedVoters map is
    /// unchanged but will now contain entries for the previous epoch.
    pub authorized_voters: AuthorizedVoters,

    /// REMOVED
    /// prior_voters: CircBuf<(Pubkey, Epoch, Epoch)>,

    pub epoch_credits: Vec<(Epoch, u64, u64)>,
    pub last_timestamp: BlockTimestamp,
}

作为更新的一部分，佣金值将以基点存储。但是，投票程序中现有的 UpdateCommission 指令仅支持整数百分比佣金值。在 SIMD-0291：以基点为单位的佣金率 获得采用之前，佣金率将仍然限制为整数百分比，因此佣金计算现在应继续使用整数百分比值。

现有的读取投票状态的工具或程序（包括 stake 程序）将进行更新，以支持新的投票帐户版本。

延迟的佣金更新

对于验证器运营商来说，第二个重要特性门控更新是 SIMD-0249：延迟佣金更新。此更改允许验证器随时提交佣金更新，同时确保这些更新至少在一个完整的 epoch 过去后才会生效。

投票程序将被修改为删除当前阻止在 epoch 的前半部分增加佣金的限制。协议不会限制提交佣金变更的时间，而是强制执行一个延迟，然后该延迟才会生效。这意味着验证器可以自由调整佣金率，但必须等待至少一个完整的 epoch，然后新的费率才会生效。

此延迟还有利于 stake 委托人，他们有整整一个 epoch 的通知时间来响应即将到来的佣金变更。至关重要的是，它可以阻止“佣金 拉高出货”，这是一种恶意验证器在 epoch 边界前不久暂时将其佣金提高到 100% 以获取奖励，然后迅速恢复正常的做法。

状态债券（租金）减少

高状态债券要求（通常称为“租金”）仍然是 Solana 开发人员最重要的长期扩展限制之一。如今，主网上的状态债券费用很高，存储成本约为每 GB 100 万美元。例如，创建一个新的单个通证帐户 (ATA) 仅需略高于 0.002 SOL，按当前价格计算约为 0.25 美元。这使得大规模直接通证空投的成本高得令人望而却步，并为小额支付和稳定币支付应用程序带来了摩擦，这些应用程序必须补贴通证账户创建成本或将该成本转嫁给最终用户。

减少此负担的第一步是 SIMD-0194：弃用租金豁免阈值，该阈值计划在 Agave 3.1 发布周期内激活。这标志着开始更广泛地努力，以有意义地降低和简化存储成本，使应用程序能够扩展到数百万用户，而无需过高的与状态相关的资本要求。此外，目前还有三个 SIMD 正在开发中，以直接解决状态债券成本并进一步降低租金。

SIMD-0194 简化了未来的租金更新。如今，对于链上程序来说，计算账户是否获得租金豁免的成本相对较高。当前 `Rent::minimum_balance` 计算使用浮点 (f64) 数学，每次调用的计算单元消耗大约 256 个。在 SIMD-0194 下，通过从租金豁免逻辑中删除浮点运算，这减少到仅 8 个 CU。

这是通过弃用 exempt_threshold (f64) 字段来实现的，从而消除了程序在确定租金豁免状态时执行浮点计算的需要。

作为更改的一部分，lamports_per_byte_year 重命名为 lamports_per_byte，默认值从 3480 翻倍到 6960，这反映了租金豁免历来被定义为持有两年租金价值的事实。重要的是，此更新不会更改账户获得租金豁免所需的金额；它只会简化和标准化值的表示和计算方式。

该更新完全向后兼容，并且现有已部署的程序不会受到影响。

展望未来：SIMD-0437

在今年晚些时候预计发布的其他与租金相关的 SIMD 中，最重要的是 SIMD-0437：逐步将 `lamports_per_byte` 降低到 696。该提案概述了一个结构化的时间表，通过逐步将 `lamports_per_byte` 从 6960 降低到 696（降低 10 倍）来降低长期状态债券成本。

SIMD-0437 取代了早期的 SIMD-0436，该提案提议一次性降低 50%。相反，SIMD-0437 引入了一个更精细的五步降低时间表：6333 → 5080 → 2575 → 1322 → 696。

将更改分为多个阶段，可以使网络随着时间的推移观察和评估状态增长，同时还可以将最具争议的降低分为不同的步骤，以便进行更清晰的讨论和治理。

其他值得注意的 Agave 3.1 发布周期更新

严格执行 32 个数据和 32 个编码切片

如今，Turbine 接受每个 FEC 集合的可变数量的切片。此行为增加了不必要的复杂性，而没有提供有意义的好处。验证切片索引变得更加困难，因为接收者需要编码切片来确定索引边界。即将推出的 SIMD-0317：强制执行 32 个数据 + 32 个编码切片 的特性门控激活通过要求每个 FEC 集合正好有 32 个数据切片和 32 个编码切片来标准化此行为。此更改还加强了等同检测，这将稍后通知强制机制，例如 削减惩罚。

静态指令限制

如今，具有超过 64 个顶级指令的交易通过了初始清理检查，但在运行时失败。这允许保证失败的交易进入管道并消耗调度器资源，从而创建了不必要的调度器工作。

即将推出的 SIMD-0160：静态指令限制 的特性门控激活通过在交易清理期间强制执行 64 个指令的限制来解决此问题。在此更改下，任何超过 64 个顶级指令的交易（包括 CPI 调用）将无法通过清理并立即被拒绝。

减少 Turbine ChaCha 轮数

SIMD-0332：将 Turbine 的 ChaCha 轮数从 20 减少到 8 在 Turbine 传播区块数据的能力方面提供了小但有意义的性能改进。如今，Turbine 在构建区块传播树时使用 ChaCha20 来确定性地洗牌 stake 加权的验证器。这种随机排序对于防止审查攻击很重要，但它带来了额外的计算开销。

ChaCha 轮数充当确定性加扰器，其中每轮应用转换以进一步随机化输出。更多的轮数提供更强的加密安全性，但也增加了计算成本。

随着 Agave 过渡到 XDP，重传发送几乎变得即时，这意味着加权洗牌步骤现在主导了运行时。在大约每个切片 1 微秒的情况下，将洗牌从 ChaCha20 减少到 ChaCha8 使该过程充分随机化以实现抗审查，同时防止其成为瓶颈。

新的指令数据指针

如今，sBPF 程序必须解析序列化输入区域的账户部分，才能找到指令数据。由于序列化布局将账户置于指令数据之前，因此程序必须迭代每个账户条目才能到达指令数据段，这给主要（或专门）处理指令数据的程序带来了不必要的工作。

即将推出的 SIMD-0321：VM 寄存器 2 指令数据指针 的特性门控激活通过在程序入口点的 VM 寄存器 r2 中提供指向指令数据的 64 位指针来改进此问题。此指针直接引用输入区域中指令数据部分的开头，使程序可以立即访问指令数据，而无需首先解析账户部分。这通过消除解析开销来减少计算单元消耗。

兼容性说明： 此功能仅向后兼容当前未在入口点从 r2 读取的程序。任何错误地依赖于先前在入口点 r2 中存在的未初始化/垃圾值的程序将在激活此功能后中断。

RPC 改进

现在，当提供格式错误的过滤器时，getProgramAccounts RPC 端点会返回正确的 JSON-RPC 错误。以前，无效的过滤器被静默忽略，导致 RPC 调用回退到未过滤的查询，这通常会触发意外的昂贵请求和 RPC 节点上不必要的负载。通过此改进，错误的过滤器现在会返回清晰的错误，从而防止意外的资源密集型查询并使调试变得更加容易。

此外，simulateTransaction() 中的签名验证失败和 sendTransaction() 的预检阶段现在将作为模拟结果的 err 字段上的 TransactionError::SignatureFailure 返回，而不是作为 JSON-RPC API 错误 (-32003) 抛出。

因此，以前依赖于捕获 JSON-RPC 异常以进行签名验证失败的应用程序现在应该期望这些错误直接出现在模拟响应中。已经在模拟结果中实现和处理 TransactionError 值的应用程序现在可以期望在这些验证点接收 TransactionError::SignatureFailure。

结论

Agave v3.1 是一项重大的客户端升级，可提供一系列性能提升和优化，包括减少磁盘 I/O、更快的交易处理和改进的 RPC 错误处理。Agave 在网络加固方面取得了显著进展，在不利条件下具有更强的弹性。此版本还标志着朝着有意义地减少状态债券迈出的第一步。

Anza 继续将自己定位为业内唯一的核心开发团队，能够在整个堆栈中交付改进，包括 向 Linux 内核提交补丁。随着 Agave 3.1 即将为网络提供动力，Solana 继续证明其扩展能力。

展望未来，下一个里程碑是 Agave 4.0 和 Alpenglow 的测试网启动，目前计划于 5 月初进行。

更多资源

• Agave 3.1 发布时间表
• 特性门控跟踪器时间表
• Agave 3.1 变更日志
• Agave 3.1 拉取请求

• 原文链接： helius.dev/blog/agave-v3...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～