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

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

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

介绍

Agave v3.0 主要版本标志着 Solana 的又一个里程碑，它引入了一系列升级，旨在提高网络性能、验证者操作和开发者体验。

值得注意的 Agave 3.0 更新

• 缓存大修：提供快 30-40% 的交易处理速度
• 更高的单账户计算限制：将单账户限制提高到区块 CU 的 40%
• 新的调度器 TransactionView 结构体：提高调度效率
• Turbine 的 eXpress 数据路径 (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% 的 stake 运行的是 Jito-Frankendancer 客户端，这个数字在今年全年都在缓慢而稳定地增长（见下图）。 预计在完整的 Firedancer 客户端准备好用于主网部署之前，采用率将保持在 20% 左右的阈值。

这标志着 Solana 多客户端战略的一个重要里程碑，这是一个旨在提高网络安全性、活跃性和弹性的长期目标。 增加的客户端多样性为验证者运营商提供了更多选择，促进了客户端团队之间的良性竞争，并为客户端代码库带来了更多的关注。 它还降低了单个关键错误触发全网中断的风险。

同样值得注意的是，运行 vanilla Agave 客户端的 stake，即没有第三方 MEV 修改（如 Jito）的 Agave，已从今年年初的 6% 左右下降到今天的 2% 左右。 同时，Paladin-Agave 的采用率在最近几个月有所上升，目前约占总 stake 的 6%。

网络压力测试

10 月 10 日，加密货币市场经历了历史上最大的清算事件，引发了所有主要区块链的极端波动。 尽管网络活动创纪录地激增，但 Solana 网络和 Agave 验证者客户端在压力下表现出了非凡的韧性和稳定性。

在高峰期，Solana 承受了六倍于正常水平的流量，领导者每秒摄取大约 100,000 个交易数据包，同时以 6000 万 CU 的限制生成完整的区块。

即使在这些条件下，Solana 也表现出所有主要网络中最稳定的费用动态，同时处理了高一个数量级的吞吐量。 在活动高峰期，真正的 TPS（非投票交易）超过了 3,200。

在大约两个小时的高峰窗口期内，Solana 的中位数 (P50) 交易费用仅升至 0.007 美元，不到 1 美分。 平均费用短暂达到 0.10 美元，前 1% 的交易 (P99) 峰值略高于 1.00 美元。 这种模式证明了本地费用市场的有效性，本地费用市场将高费用仅限于与有争议的热账户交互的那些交易，而执行简单转账（例如，稳定币支付）的普通用户未受到影响。

相比之下，以太坊主网和 Arbitrum 在同一时期看到中位数费用短暂飙升至每笔交易 100 美元以上。 Coinbase 运营的 L2 Base 也经历了费用飙升，中位数费用峰值超过 3 美元。 这些网络缺乏本地费用市场，而是应用全局费用调整，在网络压力期间统一提高所有用户的成本。

状态增长

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

这种状态的稳步扩展对 Solana 客户端和基础设施提供商具有长期影响。 随着账户数量的增长，对存储、快照大小和账户索引的需求也会增加，所有这些都会影响性能和硬件要求。 诸如 ZK 压缩之类的解决方案为减少状态膨胀提供了一条有希望的长期途径。

Agave 3.0 发布周期更新

缓存大修

Agave 3.0 显着减少了冗余的运行时操作。 对程序缓存的全面改造消除了每个交易批次中数百个多余的帐户查找，从而在内部基准测试中使交易处理速度提高了约 30-40%。

将账户限制增加到区块 CU 的 40%

作为 Agave 3.0 发布周期的一部分，Solana 将激活 SIMD-0306：提高账户 CU 限制。 这将每个帐户的 CU 限制从 12M 的静态固定常量提高到区块 CU 限制的 40%。 目前，每个帐户每个区块最多可以消耗 1200 万个 CU。 如下面的 Anza 图表所示，争用最激烈的帐户经常达到此上限。

通过此更改，每个帐户的限制最初将从 1200 万个 CU 增加到 2400 万个 CU，并且一旦 SIMD-0286 (1 亿个 CU 区块) 被激活，最终将达到 4000 万个 CU。 结合诸如 P-token 程序 的引入之类的更新，此升级将显着提高每个区块中经常访问的热账户的吞吐量。

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

• 最大投票单元：每个区块的总投票交易 CU 的上限，为 3600 万个 CU
• 最大区块账户数据大小增量：每个区块的总账户数据更改的限制，为 100 兆字节。

虽然提高每个帐户的 CU 上限可以提高热状态的吞吐量，但它也可能会增加最坏情况下的序列化执行时间，从而在高负载情况下可能会延长区块验证或 slot 持续时间。

最后，值得注意的是最近的提案 SIMD-0370：删除计算单元区块限制，该提案探讨了完全消除基于 CU 的区块限制，这一方向可能会在 Alpenglow 升级后重新审视。

Turbine 的 eXpress 数据路径 (XDP)

eXpress 数据路径 (XDP) 是一种为高性能网络设计的 Linux 内核技术。 它使应用程序能够绕过内核的大部分标准数据包处理路径，从而减少了中间数据副本以及用户空间和内核空间之间的上下文切换。 通过在用户空间中使用网卡 (NIC) 直接处理数据包，XDP 显着降低了每个数据包的开销。

对 Turbine 中 XDP 的支持首先在 Agave v2.3.8 中引入，并将从 Agave 3.1 开始默认启用。 随着区块限制增加到 1 亿个 CU，Turbine 是主要的可扩展性瓶颈。 领导者将其分片中继到 200 个对等点，从而产生繁重的网络负载。 在当前情况下，拥有更多领导者 slot 的大型验证者可以接近每秒 150,000 个出站数据包。 XDP 直接解决了这个瓶颈，使数据包调度速度提高了 100 倍，从而使验证者能够更有效地传播更大的区块。

有兴趣更深入了解 Agave 中 XDP 实现的读者可以参考 验证者设置指南 和我们之前对 Anza 工程师 Alessandro Decina 的 采访，他领导了 XDP 集成到 Agave 客户端中。

加载的交易数据大小规范

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

这引入了一种共识安全的方法，用于计算每个交易加载的总帐户数据。 目标是确保所有验证者客户端计算出相同的交易数据大小，从而消除可能导致共识不同的细微不一致。

目前，Solana 的交易数据大小调整逻辑过于复杂。 现有的实现方式在处理 LoaderV3 和 BPF 可升级加载程序时非常特殊，这两种加载程序经常低估加载的程序数据的实际大小。 这些差异使得独立客户端团队难以实现兼容的逻辑。

在 SIMD-0186 下，大小调整规则现在明确且易于推理：

• 每个加载的帐户只计算一次
• 使用 BPF 可升级加载程序的程序包括其关联的程序数据
• 每个加载帐户的大小定义为其数据在交易执行之前的字节长度，并为元数据添加了 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 的可组合性。

放宽条目约束

SIMD-0083：放宽条目约束 计划在 Agave 3.0 期间激活，它删除了区块条目中的交易不得相互冲突的规则。 以前，任何包含冲突交易的条目（即，同时写入同一帐户或一个读取而另一个写入的条目）都会使整个区块无效。

通过此更新，现在允许发生此类冲突。 发生冲突时，交易只需按它们出现的顺序依次执行。 这种更改简化了区块打包规则，使领导者在交易排序和区块构建方面具有更大的灵活性。 这也是 Solana 实现异步执行 的必要更改。

RPC 改进

Agave v3.0 为订阅服务器引入了响应能力升级，该服务器现在优先处理传入消息（例如订阅请求和 PING）而不是传出通知。 此更改为使用 PubSub WebSockets 的 dApp 提供了更快、更可靠的实时更新。

此外，slot 属性已添加到 epoch 奖励错误数据中，从而提高了开发人员的调试和可观察性。

其他更改

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

结论

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

最近的数据进一步加强了这一进展：更快的发布节奏、不断增长的客户端多样性以及在峰值需求下卓越的网络稳定性都突显了 Solana 的成熟。 随着 Agave 3.0 现在为网络提供支持，Solana 继续证明其扩展能力。

更多资源

• Agave 3.0 发布时间表
• 功能门跟踪器时间表
• Agave 3.0 更改日志
• Agave 3.0 拉取请求

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