Agave 3.0 更新：你需要了解的一切

简介

Agave v3.0 大版本是 Solana 的又一个重要里程碑，引入了一系列升级，旨在提升网络性能、验证者运营效率和开发者体验。

Agave 3.0 重要更新 

• 缓存全面改造：交易处理速度提升 30–40%
• 提高单账户计算上限：将单账户上限提高到区块 CU 的 40%
• 新的调度器 TransactionView 结构体：提高调度效率
• **用于 Turbine 的 eXpress Data Path (XDP)：**实现 1 亿 CU 区块的先决条件
• 提高 CPI 嵌套深度：将 CPI 嵌套上限从 4 提高到 8
• 放宽条目约束：简化调度逻辑，也是实现异步执行的必要条件
• **更快的启动速度：**节点现在可以更快地重新上线
• **已加载交易数据大小规范：**统一已加载交易数据的计算方式
• **RPC 改进：**为使用 PubSub WebSockets 的 dApp 提供更快、更可靠的实时更新

本文各节相互独立，读者可以专注于与自己最相关的主题。无论你是验证者运营者、开发者还是活跃的社区成员，这份 Agave v3.0 指南都能为你提供充分利用最新改进所需的重要更新和洞察。

客户端相关趋势

在深入了解 Agave v3.0 的新功能之前，我们先来看看近期数据如何体现 Solana 网络和 Agave 客户端取得的进展，包括更快的发布节奏、更广泛的客户端采用，以及在压力下依然稳健的性能。

Agave 发布节奏

Anza 今年显著加快了发布节奏，将 Agave 次要版本之间的间隔缩短至三个月以内。Agave 2.2.* 系列作为绝对多数版本仅维持了 11 周，Agave 2.3 的时间线也与之相近。

多客户端网络

最近几个月，Firedancer 在主网上的采用率显著提升。目前，21.6% 的质押运行着 Jito-Frankendancer 客户端，这一比例全年都在缓慢而稳定地增长（见下图）。预计在完整的 Firedancer 客户端达到可在主网上投入生产的标准之前，采用率将维持在 20% 左右。

这标志着 Solana 的多客户端战略取得了重要进展。该战略是一项长期目标，旨在提高网络的安全性、活性和韧性。更丰富的客户端选择让验证者运营者拥有更多选择，促进客户端团队之间的良性竞争，也让更多人参与审查客户端代码库。它还降低了单个严重漏洞引发全网中断的风险。

另一个值得注意的趋势是，运行原版 Agave 客户端（即没有 Jito 等第三方 MEV 修改的 Agave）的质押量占比，已从年初的约 6% 降至目前的约 2%。与此同时，Paladin-Agave 的采用率近几个月有所上升，目前约占总质押量的 6%。

网络压力测试

10 月 10 日，加密货币市场经历了史上最大规模的清算事件，引发所有主要区块链的剧烈波动。尽管网络活动量创下纪录，Solana 网络和 Agave 验证者客户端仍在压力下展现出卓越的韧性与稳定性。

在峰值期间，Solana 承受了正常水平六倍的流量，leader 每秒接收约 100,000 个交易数据包，同时持续产出达到 6,000 万 CU 上限的满区块。

即使在这种情况下，Solana 在处理高出一个数量级的吞吐量时，仍展现了所有主要网络中最稳定的费用变化。活动高峰期的真实 TPS（非投票交易）超过 3,200。

在约两小时的峰值窗口内，Solana 的交易费中位数（P50）仅升至 0.007 美元，不到 1 美分。平均费用短暂升至 0.10 美元，费用最高的 1% 交易（P99）峰值略高于 1.00 美元。这种情况体现了本地费用市场的有效性：高费用仅限于与争用激烈的热点账户交互的交易，而执行简单转账（例如稳定币支付）的普通用户不受影响。

作为对比，同期 Ethereum 主网和 Arbitrum 的单笔交易费中位数一度飙升至 100 美元以上。由 Coinbase 运营的 L2 Base 也经历了费用激增，中位数峰值超过 3 美元。这些网络缺少本地费用市场，采用全局费用调整机制，因此在网络承压时会统一提高所有用户的成本。

状态增长

Solana 最近在链上状态增长方面跨越了一个重要里程碑，账户总数突破 10 亿。其中近 67% 的账户归 Token Program 所有，其中 89.45% 是关联代币账户，10.55% 是代币铸造账户。

状态的持续扩张会对 Solana 客户端和基础设施提供商产生长期影响。随着账户数量增加，存储空间、快照大小和账户索引的需求也会增长，这些因素都可能影响性能和硬件要求。ZK Compression 等解决方案为长期减少状态膨胀提供了一条前景可观的路径。

Agave 3.0 发布周期更新

缓存全面改造

Agave 3.0 大幅减少了冗余的运行时操作。程序缓存的全面改造消除了每批交易中数百次多余的账户查询。内部基准测试显示，交易处理速度因此提升了约 30–40%。

将账户上限提高到区块 CU 的 40%

在 Agave 3.0 发布周期内，Solana 将激活 SIMD-0306：提高账户 CU 上限。这会将每个账户的 CU 上限从固定的 1,200 万提高到区块 CU 上限的 40%。目前，每个账户在每个区块中最多可消耗 1,200 万 CU。如下方 Anza 的图表所示，争用最激烈的账户经常触及这一上限。

此次变更后，每个账户的上限最初将从 1,200 万 CU 提高到 2,400 万 CU，并在 SIMD-0286（1 亿 CU 区块）激活后最终提高到 4,000 万 CU。结合引入 P-token 程序等更新，这项升级将显著提高每个区块中频繁访问的热点账户的吞吐量。

其他约束将保持不变，包括：

• **最大投票单元数：**每个区块中投票交易 CU 总量的上限，为 3,600 万 CU
• **区块账户数据大小最大增量：**每个区块中账户数据变更总量的上限，为 100 MB。

提高每个账户的 CU 上限可以提升热点状态的吞吐量，但也可能增加最坏情况下的串行执行时间，从而在高负载场景中延长区块验证时间或时隙持续时间。

最后，近期提出的 SIMD-0370：移除计算单元区块上限也值得关注。该提案探讨了彻底取消基于 CU 的区块上限，这一方向很可能会在 Alpenglow 升级后重新讨论。

用于 Turbine 的 eXpress Data Path (XDP)

eXpress Data Path (XDP) 是一种面向高性能网络的 Linux 内核技术。它让应用绕过内核的大部分标准数据包处理路径，减少中间数据复制，以及用户空间与内核空间之间的上下文切换。通过在用户空间中直接借助网卡（NIC）处理数据包，XDP 可大幅降低每个数据包的开销。

Turbine 对 XDP 的支持最早在 Agave v2.3.8 中引入，并将从 Agave 3.1 起默认启用。随着区块上限提高到 1 亿 CU，Turbine 成为主要的可扩展性瓶颈。leader 会将其 shred 中继给 200 个对等节点，从而产生巨大的网络负载。拥有更多 leader 时隙的大型验证者，在当前条件下每秒发送的数据包数量可能接近 150,000。XDP 直接解决了这一瓶颈，可将数据包分发速度提高多达 100 倍，让验证者能够更高效地传播更大的区块。 

希望深入了解 Agave 中 XDP 实现方式的读者，可以参阅验证者设置指南，以及我们此前对 Anza 工程师 Alessandro Decina 的采访。他主导了 XDP 与 Agave 客户端的集成。

已加载交易数据大小规范

作为持续简化和统一 Solana 执行模型的一部分，SIMD-0186：已加载交易数据大小规范计划在 Agave 3.0 发布周期内于主网上激活。

该规范引入了一种共识安全的方法，用于计算每笔交易加载的账户数据总量。其目标是确保所有验证者客户端计算出完全一致的交易数据大小，消除可能导致共识分歧的细微差异。

目前，Solana 的交易数据大小计算逻辑过于复杂。现有实现在处理 LoaderV3 和 BPF Upgradeable Loader 程序时采用了特殊逻辑，而这两者经常低估实际加载的程序数据大小。这些差异导致独立客户端团队难以实现兼容逻辑。

根据 SIMD-0186，大小计算规则现在清晰明确，也更容易理解：

• 每个已加载账户只计算一次
• 使用 BPF Upgradeable Loader 的程序需计入其关联的程序数据
• 每个已加载账户的大小定义为交易执行前其数据的字节长度，并额外增加 64 字节的元数据
• 每个地址查找表（ALT）统一增加 8,248 字节

该规范统一了所有客户端的交易大小计算方式，也让开发者更容易预测交易行为。

已加载数据大小上限与单笔交易 CU 上限的作用类似，可为验证者节点提供可预测的资源核算。默认情况下，每笔交易最多可加载 64MB 的账户数据。每加载 32KB 会消耗 8 个计算单元（CU），相当于 16,000 CU 的基础成本，即使实际加载的数据更少也是如此。开发者可以通过 setLoadedAccountsDataSizeLimit 指令降低这一上限，从而减少计算成本并提高调度效率。

由于新的大小计算方法会根据交易结构产生不同的值，开发者可能需要调整其计算预算指令中指定的已加载账户数据大小上限。

调度器 TransactionView 结构体

在 Agave 3.0 中，调度器引入了一种名为 TransactionView 的新型轻量级数据结构，用于简化交易的解析和处理方式。旧版 SDK 交易类型需要反序列化和多次内存分配，而 TransactionView 可以直接查看序列化交易。它无需真正执行反序列化，即可解析并缓存有关交易布局的元数据。

更快的启动速度

Agave v3.0 进一步提升了客户端启动性能，为验证者和 RPC 运营者带来了显著的易用性改进。无论是崩溃、升级还是计划维护后重启，节点现在都可以更快地重新上线。

从快照归档启动时，启动时间已缩短至三分半以内，不到 Agave v2.2 所需时间的一半（见下图）。这是一项关键的性能提升，因为缩短节点重新加入共识所需的时间，可以直接增强网络韧性并提高验证者在线率。

展望未来，Agave v3.1 将通过取消后台账户验证进一步简化这一流程，让验证者能够在重放开始后立即投票。

提高 CPI 嵌套上限

SIMD-0268：提高 CPI 嵌套上限将跨程序调用（CPI）的最大深度从 4 提高到 8。这实际上让 Solana 程序在单笔交易中调用其他程序的次数翻倍。

CPI 是一个 Solana 程序调用另一个程序的机制。它是 Solana 运行时的一项基础功能，让程序可以基于彼此的逻辑进行构建。

永续合约、智能钱包和交叉保证金系统等复杂的链上协议，通常依赖多层程序交互来管理仓位、清算和风险。此前 4 层的 CPI 上限限制了这些设计，在某些情况下迫使开发者将逻辑拆分到多笔交易中。

现有应用将继续像以前一样运行（除非其逻辑依赖旧上限来使交易失败）。总体而言，这项呼声很高的变更拓宽了开发者的设计空间，并增强了 Solana 的可组合性。

放宽条目约束

计划在 Agave 3.0 期间激活的 SIMD-0083：放宽条目约束，取消了区块条目内的交易不得相互冲突这一规则。此前，任何包含冲突交易的条目（即两笔交易都写入同一账户，或一笔读取而另一笔写入同一账户）都会导致整个区块无效。

此次更新后，这类冲突将被允许。发生冲突时，交易只需按照出现顺序依次执行。这项变更简化了区块打包规则，让 leader 在交易排序和区块构建方面拥有更大的灵活性。它也是 Solana 实现异步执行所必需的变更。

RPC 改进

Agave v3.0 提升了订阅服务器的响应速度。服务器现在会优先处理订阅请求和 PING 等传入消息，而不是传出通知。这项变更为使用 PubSub WebSockets 的 dApp 提供了更快、更可靠的实时更新。

此外，epoch 奖励错误数据中新增了时隙属性，改善了开发者的调试体验和可观测性。

其他变更

• 从 Agave v3.0.0 开始，Anza 已停止发布预构建的 agave-validator 二进制文件。验证者运营者现在必须按照提供的构建说明，从源代码编译二进制文件。
• 在 Agave v3.0 中，默认快照间隔已延长至每 100,000 个时隙一次，高于 v2.3 的 50,000 个和 v2.2 的 25,000 个。延长间隔可显著改善磁盘性能，减少创建快照期间 IOPS（每秒输入/输出操作次数）的峰值。
• 已移除大量弃用的旧 CLI 参数和标志（完整列表见此处）。
• 目前，交易中的 advance nonce 指令可以将交易内的任意账户指定为要推进的账户。在 SIMD-0242：仅限静态 Nonce 账户的功能门激活后，advance nonce 指令将只能推进静态包含的账户。

总结

Agave v3.0 是一次重大的客户端升级，带来了更快的交易处理、更高的计算上限、更高效的调度器，以及一系列验证者和 RPC 优化。这些更新共同增强了网络性能和开发者体验。

近期数据进一步印证了这些进展：更快的发布节奏、日益丰富的客户端生态，以及峰值需求下出色的网络稳定性，都体现出 Solana 正在不断成熟。随着 Agave 3.0 开始为网络提供支持，Solana 继续证明其扩展能力。

更多资源

• Agave 3.0 发布计划
• 功能门跟踪计划
• Agave 3.0 变更日志
• Agave 3.0 拉取请求