Agave v2.1 更新：你需要知道的一切

非常感谢0xIchigo、Andrew Fitzgerald和Steven C对本工作的早期版本进行审阅。

Agave验证器客户端v2.1的发布标志着Solana在迈向更具弹性、多客户端生态系统之旅中的一个重要里程碑。此次更新提供了关键改进，以增强网络性能、可靠性和效率。

Agave 2.1发布周期的显著更新

• 大规模性能优化
• 增加区块限制
• 引入贪婪调度器（实验性）
• 原生支持Secp256r1签名验证（更新：推迟到Agave 2.2）
• 禁用租金费用收集和租金重写
• 放宽交易加载失败的限制
• 将配置和地址查找表程序迁移到核心BPF

本文的每个部分都设计为独立存在，允许读者自由导航，关注他们最感兴趣的主题。无论你是验证器操作员、开发者还是活跃用户，这个关于Agave 2.1的深入概述将为你提供有效利用这些进步所需的见解。

特性发布

在撰写本文时，88%的抵押权益现已运行Agave版本2.1.11。主网的特性门激活已暂时暂停，以允许更广泛的v2.1采用，并预计将很快根据计划激活顺序恢复。

在后续部分讨论的大多数新完整特性目前尚未上线，预计将在2.1发布周期内通过特性门系统推出。特性会在特定纪元激活，基于相对优先级和它们在测试网和开发网上的激活顺序。

性能增强

验证器和RPC操作员报告在Agave 2.1中获得了显著的稳定性和性能提升。在过去一年中，Anza优先消除瓶颈、优化资源效率并增强总体性能。新的客户端发布不仅关乎引入新特性，还关乎优化核心基础——增加带宽，减少延迟。在详细了解2.1更新的具体内容之前，回顾一下在最新一系列客户端更新中实现的显著性能改进是值得的。

区块时间

Solana上的更快区块时间使平均时隙时间降至400ms以下，最近的纪元预计在不到两天的时间内完成——这是网络历史上最快的。两个客户端都已经准备好迎接更短的区块时间。这种加速不仅意味着更高的交易吞吐量。由于质押奖励与通货膨胀发行绑定，而通货膨胀是通过“纪元年”而不是日历年计算的，验证器和质押者必然受益。一个纪元年假设每年182.5个纪元，基于标准的两天纪元长度。当纪元缩短，相同时间范围内容纳更多的纪元，从而有效提高质押奖励的分配速率。

在线时间

Solana在2024年及2025年初表现出几乎完美的可靠性，保持了超过一年的100%在线时间。最后一次记录的故障发生在2024年2月6日，当时一个已知的错误暂时中断了主网的区块最终确定。此问题迅速被识别和修复。自此之后，Solana在网络活动高峰期间——如最近由特朗普家族代币发布推动的激增——顺利生产区块，证明了其在高负载下的弹性。

跳过时隙率

跳过时隙率是衡量一位验证器在特定时隙被指定为领导时，未能在分配时间内产生区块的频率。自2024年11月第700纪元以来，跳过时隙率显著下降。过去几年间，这一比例曾在2%和5%之间波动，而目前大多数优化良好的验证器的跳过率已降至接近零。

这一改进的一个因素是在707纪元时在主网上推出的分区纪元奖励。通过将质押奖励分散到多个区块中，此更改减轻了奖励分配集中在每个新纪元第一个区块的性能瓶颈，从而使网络操作更加流畅。

此外，在2024年11月引入的及时投票积分（TVC）激励验证者及时投票，并抑制延迟投票。通过减少故意拖延投票的验证者，TVC提高了集群收敛性，从而加快确认和最终确定速度。这一机制帮助最小化分叉，缩短分叉时间。由于TVC评分现在影响质押池排名，操作员响应性地升级硬件和优化验证器设置以提高性能。

每秒交易数（TPS）

更高的每秒交易数（TPS）表明链的吞吐量增加，Solana的非投票TPS（又称“真实TPS”）自2023年底以来一直稳步上升。2025年2月的最新数据表明，网络记录的50百分位平均为1,228 TPS，99百分位峰值达到2,520 TPS。

在2024年12月23日结束的PENGU代币空投周，观察到的历年来高TPS为50百分位平均1,260 TPS，99百分位峰值为3,252 TPS。这一持续增长凸显了Solana在可扩展性及交易处理效率方面的持续改善。

优先费用

最后，对Agave 2.1和2025年1月27日到2月4日的前2.0版本的优先费用收集的比较显示，Agave 2.1持续地收取略高的优先费用。

提高区块限值

在SIMD-0207: 将区块限值提高到50M中提出的区块限值提升，计划在Solana的2.1发布周期中实施。目前，该协议将每个块的总计算资源上限设定为4800万个计算单元（CUs）。区块限值确保节点能够跟上网络的步伐，限制领导者在一个区块中的工作量。创始团队基于验证者能够合理处理的负载选择了目前的限制，以便实现400毫秒的区块时间。

然而，如今主网的活动并不受执行时间的限制，这意味着区块可以容纳更多交易，而不超过400ms目标。此更新引入4%的适度增加，以逐步扩展网络容量，将每个区块的计算限制从4800万提高到5000万CUs。虽然更激进的增长，例如将限制翻倍，可能是可行的，但已被认为对于初步更改风险太大。扩展区块限值不仅影响验证者，还影响关键基础设施，如RPC节点、索引器和归档服务，这些服务必须相应扩大。

其他协议限制保持不变：

• 每个账户每个块的计算限制仍为1200万CUs。
• 每笔交易的最大计算仍然为140万CUs。

预计还会有进一步的区块限制增加，并将通过正式的SIMD流程推进。

贪婪调度器

免责声明

新的贪婪调度器目前是实验性的，仅可通过Agave客户端CLI自愿启用。截至本文撰写时，它尚未回归到2.1主干中。Anza建议在进一步测试完成之前，避免在生产环境中运行贪婪调度器。

背景：中央调度器

最后一次主要的调度器更新——中央调度器——是在去年的5月进行的Agave 1.18中引入的。此调度器构建了顶级N优先交易的依赖图，目前N设定为256。然后，它试图按优先顺序调度交易，确保先处理不冲突的交易。一旦调度，这些交易就会从图中移除，从而允许先前冲突的交易优先处理。调度器随后会重新填充图，以保持N个交易的队列。

这种方法主要设计用来优化较大的批处理，提高整体交易吞吐量。然而，一个主要缺点是构建依赖图和排序交易需要大量时间，从而形成瓶颈。

参考我们之前的Helius博客文章以获取更详细的Agave 1.18和中央调度器实施的概述。

新的贪婪调度器

与中央调度器不同，贪婪调度器不构建依赖图。相反，它遵循更简单的方法：

• 首先，选择优先级最高的交易。
• 如果交易不与正在进行的批处理冲突，则将其添加到四个工作线程队列中的一个。
• 如果出现冲突，则当前批处理被最终确定并分发，冲突的交易将添加到一个新批中。

此方法显著加快了交易调度速度，但导致了较小的批处理规模，增加了每笔交易的开销。然而，针对现实中的主网环境，这种折衷是值得的，因为执行时间主要受BPF处理而不是批处理的支配。

考虑一个场景，其中交易分为三个冲突组：A、B和C。当一个交易试图写入一个账户而另一个交易试图读取或写入该账户时，交易便会发生冲突。A组的交易的优先费用高于B组或C组的交易。

• 中央调度器将非冲突的交易A1、B1和C1安排成一个批处理：[A1, B1, C1]。
• 贪婪调度器优先调度费用最高的交易，首先将A1安排为一个独立的批处理，然后在下一个批处理移动到A2。

这种优先化确保了更快的调度，但可能导致比中央调度器更小的批处理。

原生程序用于验证Secp256r1签名

更新

此功能门已推迟到Agave 2.2发布周期

Solana正在引入一个新的原生程序，用于验证secp256r1椭圆曲线签名，从而实现对Passkeys、WebAuthn标准以及包括双因素身份验证（2FA）在内的新账户抽象模型的链上支持。此增强为无密码身份验证铺平了道路，已在Web2中广泛使用，以作为链上安全的第二因素。

secp256r1椭圆曲线是一种NIST标准的加密曲线，并在现代设备中得到了广泛支持，包括：

• WebAuthn: 一种W3C标准的基于公钥加密的身份验证，受所有主要网络浏览器支持。
• Apple的安全单元: 一种基于硬件的可信执行环境（TEE），用于签名消息，仅可通过生物识别认证访问。
• Android密钥库: 管理私钥和签名方法的API，利用设备的TEE进行安全密钥存储。
• Passkeys: 一种FIDO联盟和W3C标准，用加密密钥对替代密码，并与椭圆曲线加密兼容。

包括以太坊在内的多个其他网络，EIP-7212也已探索集成对secp256r1曲线的支持。

Secp256r1程序详细信息

新程序将在ID下部署：Secp256r1SigVerify1111111111111111111111111

指令结构：

• 一个u8计数器用于指定要验证的签名数量。
• 随后是一个单字节的填充。
• 对于每个签名，使用以下序列化结构：

代码

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // 64字节secp256r1签名的偏移量  
    signature_instruction_index: u16,  // 查找签名的指令索引  
    public_key_offset: u16,            // 32字节公钥的偏移量  
    public_key_instruction_index: u16, // 查找公钥的指令索引  
    message_data_offset: u16,          // 消息数据开始的偏移量  
    message_data_size: u16,            // 消息数据的大小  
    message_instruction_index: u16,    // 获取消息数据的指令数据索引  
}

此更新源自于Bunkr团队提出的 SIMD-0048: 原生程序用于Secp256r1签名验证。Secp256r1 SigVerify预编译程序的功能类似于Solana现有的secp256k1支持和ed25519签名。

禁用租金费用收集和跳过租金重写

在SIMD-0084: 禁用租金费用收集和SIMD-0183: 跳过租金重写中提出的两个相关更新，将消除与支付租金账户相关的大部分遗留开销。

租金费用收集是银行中的一个复杂组件。禁用它将简化验证器客户端代码库，并精简所有验证器客户端实现的开发，因为它们将无需复制租金收集逻辑。租金将不再从账户中扣除，收取的租金费用也将不再分配给验证器。创建新的支付租金账户已不再可能——任何尝试将导致交易错误。

目前，租金收集每个纪元至少检查每个账户一次，即使它们没有改变，也会加载和存储账户。由于所有Solana账户均已免于租金负担，维护此过程是不必要的计算工作。

与租金相关的账户重写将被消除，减少每个时隙存储的账户数量。因此，验证者将看到性能提升，因为包含在账户增量哈希和增量账户哈希计算中的账户减少。此更改还减少了增量快照的大小，进一步降低了资源消耗。

放宽交易约束：加载失败

目前，Solana交易受到严格的约束，这可能导致其在被包括在块之前失败。这些预块失败会造成验证器计算的浪费，因为在不赚取交易费用的情况下消耗了资源——有效地是在无报酬的情况下工作。

区块生产还受到过滤无效程序调用或超出64 MiB（约67.11 MB）加载账户数据最大限制的需求的复杂化。这些限制增加了块组装的复杂性，并使确定块有效性变得更难。通过放宽这些约束，交易可以被包括在区块中，并收取费用，而无需事先加载和验证程序数据。此转变旨在消除对账户状态的依赖以确保块的有效性。

这些变更，在SIMD-0191中提出，可能会影响工具，例如假设所有交易都尝试执行的区块链浏览器。此外，用户必须确保其交易是可执行的，以避免不必要的费用支出。

将配置和地址查找表程序迁移到核心BPF

作为从本地封装程序向伯克利数据包过滤器（BPF）程序持续过渡的一部分，Config和地址查找表程序将迁移到核心BPF程序。这一转变将这些关键程序与验证器运行时脱钩，从而实现灵活性更新和更轻松的维护。

BPF程序的复杂性低于其本地对应物，从而简化了不同验证器客户端的开发和维护。通过此更改，Firedancer和Anza团队将无需分别跟踪和实施程序变更。相反，更新将普遍适用于所有客户端。

重新实现的程序将与其本地版本保持相同的ABI，确保完全兼容，唯一区别在于计算使用。

结论

Agave 2.1更新标志着Solana的一个重大进步，引入了关键功能增强和运行时优化。这次发布通过扩展功能、完善性能并推动Solana所能实现的极限，增强了网络的力量。凭借对Secp256r1签名验证的原生支持、增加的区块限制、大规模的性能改善以及最终引入的贪婪调度器，Agave 2.1提高了效率和可扩展性。无论你是开发者、验证者还是活跃用户，此次更新都为你开启了新可能，使Solana比以往更加快速、灵活和强大。

进一步资源

• Agave客户端代码仓库
• Agave v2.1发布计划
• Agave v2.1标记的拉取请求

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