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

Agave 2.1 发布周期的重要更新 

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

本文每个章节均可独立阅读，方便读者自由浏览并专注于最感兴趣的主题。无论你是验证者运营者、开发者还是活跃用户，这篇 Agave 2.1 深度概览都将为你提供有效利用这些进展所需的信息。

功能推出进度

截至本文撰写时，已有 88% 的质押运行 Agave 2.1.11 版本。主网的功能门控激活已暂时暂停，以等待 v2.1 得到更广泛采用，并且预计很快会按照计划的激活顺序恢复。 

后续章节讨论的大多数完整新功能目前尚未上线，预计将在 2.1 发布周期内通过功能门控系统逐步推出。功能会根据相对优先级以及它们在测试网和开发网集群中的激活顺序，于特定 epoch 激活。

性能提升

验证者和 RPC 运营者报告称，Agave 2.1 在稳定性和性能方面有了明显提升。过去一年，Anza 一直致力于消除瓶颈、优化资源效率并提升整体性能。新客户端版本不仅会引入新功能，同样也着重改进核心基础能力——提高带宽，降低延迟。在深入介绍 2.1 更新的具体内容之前，我们不妨先退一步，量化最近一系列客户端更新带来的显著性能提升。

区块时间

Solana 更快的区块时间正推动平均 slot 时间降至 400ms 以下，近期的 epoch 有望在不到两天内完成，创下网络历史最快纪录。两个客户端都已为更短的区块时间做好准备。这种加速不仅意味着更高的交易吞吐量。由于质押奖励与通胀发行挂钩，而通胀发行使用“epoch 年”而非日历年计算，因此验证者和质押者都将从中受益。按照标准的两天 epoch 长度，一个 epoch 年假设每年有 182.5 个 epoch。当 epoch 缩短后，同一时间范围内可以容纳更多 epoch，从而实际提高质押奖励的发放速率。

正常运行时间

Solana 在 2024 年全年及 2025 年初展现出近乎完美的可靠性，连续一年多保持 100% 正常运行。最近一次有记录的中断发生在 2024 年 2 月 6 日，当时一个已知 bug 暂时影响了主网的区块最终确认。该问题很快得到定位和修复。此后，即使在网络活动极其繁忙的时期——例如近期由特朗普家族代币发行推动的活动激增——Solana 仍能持续顺畅地产出区块，证明了其在高负载下的韧性。

Slot 跳过率

Slot 跳过率用于衡量被指定为某个 slot 领导者的验证者未能在分配时间内生成区块的频率。自 2024 年 11 月大约 epoch 700 起，slot 跳过率大幅下降。此前数年间，该比率一直在 2% 到 5% 之间波动，如今对于大多数经过良好优化的验证者而言，已经降至接近零。  

推动这项改进的一个因素，是在主网 epoch 707 引入了分区式 epoch 奖励。通过将质押奖励分散到多个区块中，这项变更缓解了奖励分配集中在每个新 epoch 的第一个区块所造成的性能瓶颈，使网络运行更加平稳。

此外，于 2024 年 11 月引入的及时投票积分（TVC）会激励验证者及时投票，同时抑制延迟投票。通过减少故意延后投票的验证者数量，TVC 提升了集群收敛速度，从而加快确认和最终确定。这一机制有助于减少分叉并缩短分叉持续时间。由于 TVC 评分如今会影响质押池排名，运营者已开始升级硬件并优化验证者配置，以获得更好的性能。

每秒交易数（TPS）

更高的每秒交易数（TPS）意味着链上吞吐量提升。自 2023 年末以来，Solana 的非投票 TPS（也称“真实 TPS”）一直稳步上升。2025 年 2 月第一周的最新数据显示，网络第 50 百分位的平均值达到 1,228 TPS，第 99 百分位的峰值性能则达到 2,520 TPS。  

TPS 历史最高值出现在截至 2024 年 12 月 23 日的 PENGU 代币空投周。当时第 50 百分位的平均值达到 1,260 TPS，第 99 百分位的峰值达到 3,252 TPS。这种持续增长凸显了 Solana 不断提升的可扩展性和交易处理效率。

优先费

最后，对比 2025 年 1 月 27 日至 2 月 4 日期间 Agave 2.1 与此前 2.0 版本收取的优先费可以发现，Agave 2.1 收取的优先费始终略高。

提高区块限制

SIMD-0207：将区块限制提高至 50M提议提高区块限制，该变更计划在 Solana 2.1 发布周期内实施。目前，协议将每个区块的总计算资源上限设为 4800 万个计算单元（CU）。区块限制通过约束领导者可以打包进区块的工作量，确保节点能够跟上网络速度。创始团队根据验证者为实现 400 毫秒区块时间所能合理处理的工作量，通过实证方式选择了当前限制。 

然而，目前的主网活动并不受执行时间限制，这意味着区块可以容纳更多交易，而不会超过 400ms 的目标。本次更新将小幅提高 4%，逐步扩大网络容量，把每个区块的计算限制从 48M CU 提升到 50M CU。虽然采用更激进的增幅——例如将限制翻倍——可能也可行，但对于首次调整而言，其风险被认为过高。扩大区块限制不仅会影响验证者，也会影响 RPC 节点、索引器和归档服务等关键基础设施，这些系统都必须相应扩容。

其他协议限制保持不变：

• 每个区块中单个账户的计算限制仍为 12M CU。
• 每笔交易的最大计算量仍为 1.4M CU。

预计未来还会进一步提高区块限制，并将通过正式的 SIMD 流程推进。

贪心调度器

背景：中央调度器

上一次重大调度器更新是中央调度器，于去年 5 月随 Agave 1.18 推出。该调度器会为优先级最高的 N 笔交易构建依赖图，目前 N 设为 256。随后，它会尝试按照优先级顺序调度交易，确保不存在冲突的交易优先处理。调度完成后，这些交易会从图中移除，使之前存在冲突的交易得到优先处理。然后，调度器会重新填充依赖图，以维持包含 N 笔交易的队列。

这种方法的主要目标是优化较大的批处理，从而提高整体交易吞吐量。但它有一个主要缺点：构建依赖图和对交易排序需要大量时间，因而形成瓶颈。 

如需更详细地了解 Agave 1.18 和中央调度器的实现，请参阅此前的 Helius 博客文章。

新的贪心调度器

与中央调度器不同，贪心调度器不会构建依赖图。相反，它采用更直接的方法：

• 首先，选择优先级最高的交易。
• 如果该交易与正在处理的批次不冲突，就将其添加到四个工作线程队列之一。
• 如果发生冲突，则完成并分派当前批次，然后将该交易添加到新批次。

这种方法显著加快了交易调度，但会导致批次规模缩小，从而增加每笔交易的开销。不过，在真实的主网环境中，这种取舍是值得的，因为执行时间主要由 BPF 处理而非批处理决定。

中央调度器在网络高负载下表现不佳，主要原因是它需要花时间对交易排序并构建依赖图。通过消除这部分开销，贪心调度器牺牲了部分批处理效率，但提高了响应速度。

假设交易分为三个冲突组：A、B 和 C。当一笔交易要写入的账户同时是另一笔交易要读取或写入的账户时，两笔交易就会发生冲突。A 组交易的优先费高于 B 组或 C 组。

• 中央调度器会将互不冲突的交易 A1、B1 和 C1 一起安排到一个批次中：[A1, B1, C1]。
• 贪心调度器会优先处理费用最高的交易，将 A1 单独安排为一个批次，然后在下一个批次处理 A2。

这种优先级策略可加快调度，但可能产生比中央调度器更小的批次。

用于验证 Secp256r1 签名的原生程序

Solana 正在引入一个用于验证 secp256r1 椭圆曲线签名的新原生程序，为 Passkeys 提供链上支持，同时支持 WebAuthn 标准和新的账户抽象模型，包括双因素认证（2FA）。这项增强功能让已经在 Web2 中广泛应用的无密码认证能够成为链上安全的第二重认证因素。

secp256r1 椭圆曲线是由 NIST 标准化的密码学曲线，并在各种现代设备上得到广泛支持，包括：

• **WebAuthn：**由 W3C 制定的基于公钥密码学的身份认证标准，得到所有主流 Web 浏览器的支持。
• **Apple Secure Enclave：**一种基于硬件的可信执行环境（TEE），用于签署消息，且只能通过生物识别认证访问。
• **Android Keystore：**用于管理私钥和签名方法的 API，可利用设备的 TEE 安全存储密钥。
• **Passkeys：**由 FIDO 联盟和 W3C 制定的标准，以密码学密钥对取代密码，并兼容椭圆曲线密码学。

其他多个网络也探索了集成 secp256r1 曲线支持，其中包括 Ethereum（EIP-7212）。

Secp256r1 程序详情

新程序将部署在以下 ID 下：Secp256r1SigVerify1111111111111111111111111

指令结构：

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

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

本次更新源自 Bunkr 团队提出的 SIMD-0048：Secp256r1 Sigverify 原生程序。Secp256r1 SigVerify 预编译程序的工作方式将类似于 Solana 目前对 secp256k1和 ed25519 签名的支持。

停用租金费用收取并跳过租金重写

SIMD-0084：停用租金费用收取和 SIMD-0183：跳过租金重写提出了两项相关更新，将消除与支付租金的账户有关的大部分遗留开销。

收取租金费用是 Bank 中的一个复杂组件。将其停用可以简化验证者客户端代码库，并精简所有验证者客户端实现的开发流程，因为它们将不再需要复制租金收取逻辑。系统将不再从账户中扣除租金，收取的租金费用也不再分配给验证者。目前已经无法创建新的租金支付账户，任何此类尝试都会导致交易错误。

目前，租金收取流程每个 epoch 至少检查一次所有账户，即使账户没有变化，也会加载并存储这些账户。由于所有 Solana 账户都已免除租金，继续维持这一流程只会产生不必要的计算工作。

与租金相关的账户重写将被取消，从而减少每个 slot 存储的账户数量。因此，验证者将获得性能提升，因为账户增量哈希和增量账户哈希计算所包含的账户会更少。这项变更还会缩小增量快照的大小，进一步减少资源消耗。

放宽交易限制：加载失败

目前，Solana 交易受到严格限制，可能在被纳入区块前就失败。这些区块前失败会浪费验证者的计算资源，因为资源已经投入，却无法获得交易费，相当于无偿执行工作。

区块生产还需要过滤调用无效程序或超过 64 MiB（~67.11 MB）已加载账户数据上限的交易，因此变得更加复杂。这些限制增加了区块组装的复杂度，也让区块有效性更难确定。通过放宽这些限制，交易可以被纳入区块并收取费用，而无需预先加载和验证程序数据。此项调整旨在消除区块验证对账户状态的依赖。

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

将 Config 和地址查找表程序迁移至 Core BPF

作为持续从原生内置程序向 Berkeley Packet Filter（BPF）程序迁移的一部分，Config 和地址查找表程序将迁移为 Core BPF 程序。此项调整将这些关键程序与验证者运行时解耦，使更新更加灵活，维护更加轻松。

BPF 程序比其原生版本更简单，可简化不同验证者客户端的开发和维护。实施这项变更后，Firedancer 和 Anza 团队将不再需要分别在各自的运行时中跟踪和实现程序变更。相反，更新会统一应用到所有客户端。 

重新实现的程序将保持与原生版本完全一致的 ABI，确保全面兼容，唯一的差异是计算资源使用量。

总结

Agave 2.1 更新是 Solana 向前迈出的重要一步，引入了关键功能增强和运行时优化。此版本通过扩展功能、改进性能并突破 Solana 的能力边界，进一步增强了网络。凭借对 Secp256r1 签名验证的原生支持、更高的区块限制、大规模性能改进，以及最终将推出的贪心调度器，Agave 2.1 同时提升了效率和可扩展性。无论你是开发者、验证者还是活跃用户，这次更新都会解锁新的可能性，让 Solana 比以往更快、更灵活、更强大。

更多资源

• Agave 客户端代码库
• Agave v2.1 发布时间表
• 标记为 Agave v2.1 的 Pull Request