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

简介

Agave 验证者客户端 v2.3 的发布标志着 Solana 再次取得重大进展。与以往更新一样，新版本带来了多项关键改进，旨在提升网络性能和开发者体验。

Agave 2.3 重要更新 

• 新 TPU 客户端 tpu-client-next
• 优化 AccountsDB，减少磁盘 I/O 使用量
• 领导者调度现以验证者投票账户为键
• 可罚没事件验证
• 默认启用贪心调度器
• 快照增强
• gossip 升级
• 更快的 epoch 切换

本文各章节相互独立，读者可以轻松跳转到最相关的主题。无论你是验证者运营者、开发者还是活跃用户，这份 Agave 2.3 全面指南都将为你提供充分利用最新改进所需的关键洞见。

Anza 正在加快 Agave 的发布节奏。距离 2.2 发布不到三个月，2.3 版本便已上线，目前已有占总质押量 13% 的节点运行新版客户端。预计未来几周采用率将快速增长。与此同时，主网功能门控激活已在发布期间暂时暂停，并将很快按照计划的激活顺序恢复。

新 TPU 客户端

Agave 2.3 引入了交易处理单元（TPU）客户端的新实现，取代此前的 ConnectionCache。该 TPU 客户端负责通过 QUIC 协议在网络中向验证者发送序列化交易。这个名为 tpu-client-next 的新设计经过彻底重构，旨在显著提升性能、减少资源占用并简化整体架构。

TPU 客户端主要用于两种场景：一是在 ForwardingStage 中，验证者将交易转发给即将上任的领导者；二是在 SendTransactionService 中，RPC 使用它将交易中继给领导者。

此前的 ConnectionCache 实现需要同时支持 UDP 和 QUIC 协议，因此变得过于复杂。ConnectionCache 依赖内部异步队列而非显式通道来存储交易，并包含通过发送空数据包实现的缓存预热逻辑。此外，它在 Quinn（即 QUIC 的一种 Rust 实现）端点管理方面一直存在问题。

新的 tpu-client-next 通过精简的异步设计解决了这些问题。其内部采用基于代理的模型，由独立工作任务处理每个 QUIC 连接。这些工作任务通过异步通道与集中式 ConnectionWorkersScheduler 通信。 

调度器收到一批交易后，会根据配置的策略将其广播给适当的工作任务组。该架构彻底消除了多流机制，从而减少流量碎片化。连接也会预先建立，因此无需在发送时打开新数据流，消除了由此产生的延迟。

tpu-client-next 展现出明显的性能提升。 

• 在测试网 RPC 实验中，新旧客户端在负载下的平均 TPS 相近，但 tpu-client-next 的抖动明显更低。 
• 在验证者用例中，ForwardingStage 转发的交易量增加了 10%，流量模式更加稳定，CPU 使用量则减少了 30%。
• Anza 的闭源压力测试工具 transaction-bench, 使用最新客户端构建。它每秒生成的交易数是此前基准测试工具 bench-tps 的两倍。

tpu-client-next 完全向后兼容，现已成为 Agave 节点的默认实现。如果出现问题，运营者可以使用 --use-connection-cache 标志启动节点，恢复到此前的实现。

总之，tpu-client-next 带来了：

• 对异步友好的代理式架构
• 更稳定且抖动更低的流量
• 更低的 CPU 和内存使用量
• 可配置的调度与队列策略
• 更简单的集成和更简洁的 API 接口

以投票账户为键的领导者调度

作为 Agave 2.3 发布周期的一部分，Solana 将激活 SIMD-0180：使用投票账户地址作为领导者调度的键。此项变更调整了网络确定哪些验证者负责出块的方式：领导者调度的主键将从验证者身份地址改为投票账户地址。

此次迁移解决了 Solana 协议中一个长期存在的模糊问题：无法可靠地将出块验证者与特定质押关联起来。在当前设计中，领导者调度以验证者身份地址为键。然而，多个投票账户可能委托给同一个验证者身份，因此很难将某个特定 slot 的区块生产追溯到一组具体的委托质押。

改用投票账户地址作为领导者调度的键后，这项变更在委托质押与验证者的领导者角色之间建立了清晰、直接的联系。这个看似微小的调整解锁了多项重要能力。

首先，它为区块奖励分配提供了必要基础，具体见 SIMD-0123。该提案已于 3 月通过正式治理投票。这让验证者可以为区块费用设定佣金比例，并将剩余收入按比例分配给委托者。该系统与通胀性质押奖励已采用的奖励共享模型一致，使验证者与质押者之间的经济激励更加协调。

其次，使用投票账户地址作为领导者调度的键，是实现程序化罚没的必要条件。程序化罚没会惩罚提交重复区块或在多个分叉上投票、违反网络规则的验证者。这正好引出下一项更新。

可罚没事件验证

罚没是一种惩罚恶意验证者的机制：它在链上验证违规行为，并销毁其部分委托质押。它是遏制威胁网络安全或稳定性行为的关键手段。

罚没主要有两种模式：

社会化罚没（Solana 当前采用的系统）

Solana 目前采用一种由社区推动的手动共识方式，称为社会化罚没。在这种模式下，如果验证者存在恶意行为，例如破坏网络活性或安全性，诚实参与者可以在链下协调发起硬分叉，重启网络并罚没违规者的质押。虽然这种方式可以根据具体情况灵活判断，但协调成本很高，而且本质上属于事后响应。

程序化罚没（协议内罚没）

相比之下，程序化罚没完全在链上执行。如果验证者违反协议规则，可以将违规行为的加密证明提交给专用程序，随后自动触发罚没。这种模式减少了对人工协调的依赖，并能在不中断网络运行的情况下处理轻微违规，为可扩展、去中心化的问责机制奠定基础。

罚没包含两个关键步骤：

• **故障检测与归因：**识别不当行为及其责任验证者。
• **处罚执行：**通过罚没质押对违规者施加经济惩罚并追究责任。

作为 Agave 2.3 发布周期的一部分，Solana 将按照 SIMD 中的说明，为 Slashing Program 激活功能门控：SIMD-0204：可罚没事件验证。这标志着 Solana 向启用程序化罚没迈出的第一步，重点是故障检测与归因。它引入了一个链上程序，允许任何人报告并记录可罚没行为，为未来的自动执行奠定基础。

该程序不会改变质押或奖励，只负责验证并记录违规行为，作为验证者不当行为的链上记录。早期程序原型已部署到测试网（例如，DuplicateBlockProof 示例交易）。 

该程序最初将重点检测并记录重复出块，未来计划支持双重投票等其他违规行为。关键在于，程序化罚没仅适用于可明确证明的不当行为。因此，故意缓慢出块或提取 MEV 等更主观或系统性的问题很难执行处罚，Slashing Program 也不太可能处理这些问题。

提交的证明包含同一 slot 中两个相互冲突的 shred，且均由同一个验证者签名。Slashing Program 会验证这些 shred 是否构成有效的重复区块证明，确认它们属于同一 slot，并由违规验证者正确签名。该逻辑与 Solana 的 gossip 协议在分叉选择过程中处理重复区块证明的方法一致。 

证明成功验证后，结果会存储在程序派生地址（PDA）中，以供日后查阅。只需对 Slashing Program 运行 getProgramAccounts，便可轻松构建展示罚没相关数据的仪表板。验证者可以借此检查自己是否因违规而被举报，并根据需要采取纠正措施。

未来的 SIMD 将处理罚没的经济执行问题，包括各类违规行为的质押处罚参数。由于这些决定会影响运行 Solana 验证者的经济模型，任何拟议变更都必须通过完整的治理投票批准。

更快的 Epoch 切换

Agave 2.3 对 epoch 切换速度进行了重大改进。Epoch 奖励计算现在可在 500 毫秒内完成。这减少了跳过的 slot，并提高了 epoch 边界附近交易上链的可靠性。

此外，如果新 epoch 的第一个领导者 slot 被跳过，Agave 2.3 会确保不再重新执行奖励计算，而是复用之前算出的结果。这消除了冗余计算，让新 epoch 的启动更加顺畅。

AccountsDB 优化

此版本显著提升了存储效率。磁盘 I/O 使用量降低约 75%，修复请求量减少约 85%。这些优化共同带来了更稳定、更可靠的节点性能，尤其是在网络高负载期间。

默认启用贪心调度器

Agave 2.3 现在默认启用贪心调度器。此前的中央调度器需要花费大量时间排序交易并构建依赖关系图，因此在网络高负载下经常成为瓶颈。新的贪心方法通过简化逻辑并减小批次规模，显著加快了交易调度。

读者可以通过我们之前的 Helius 博客文章进一步了解贪心调度器。

Gossip Shred 版本

Agave 2.3 对 gossip 网络中的 shred 版本匹配实施了更严格的规则。现在，只有节点的 shred 版本与集群一致时，才允许建立入站 gossip 连接，从而更早拒绝配置错误的节点。

此前，即使 shred 版本与集群不一致，侦察节点也能加入网络。此项变更实施后，包括侦察模式节点在内的所有节点都必须获取正确的 shred 版本，可以从集群入口点获取，也可以通过命令行显式设置。

此项更新延续了近期减少 gossip 开销的工作。近几个月来，由于弃用了三种 gossip 消息类型，并移除了未质押验证者的 epoch slot 广播，入站 gossip 流量已减少约 61%。

RPC 模拟包含资源使用情况

为提高交易资源使用情况的可见性，默认 `simulateTransaction` RPC 方法中新增了字段：`loadedAccountsDataSize`。该字段报告模拟期间加载的账户数据总字节数。

此项新增功能让开发者能够更准确地估算交易成本并微调优先费。加载账户数据会消耗计算单元（CU），每 32 KB 消耗 8 CU，这一数值基于 Solana 的堆页分配大小。通过公开此项指标，开发者可以在构建和发送交易时更好地优化成本效率。

快照增强

快照充当定期保存点，让节点可以恢复状态。节点会持续生成这些快照，并随着时间推移用新版本替换旧版本。

此版本对快照行为进行了多项易用性改进：

• **更新默认间隔：**完整快照的默认间隔已从 25,000 个 slot 增加到 50,000 个 slot，降低了快照创建频率。
• **用于禁用快照的新标志：**新增 `--no-snapshots` 标志，用于显式禁用快照生成。此前使用 `--snapshot-interval-slots 0` 的方法现已弃用。
• 改进 Geyser 行为：从快照恢复时，通过 Geyser 发送的账户通知将不再去重。

延长快照间隔还能带来一项额外优势：使磁盘性能更加平稳，减少 IOPS 峰值（每秒输入/输出操作次数）。

SBPF 工具链改进

Agave 2.3 为使用 SBPF 工具链的开发者带来了多项易用性升级：

• **版本指定：**开发者现在可以在编译程序时显式指定特定的 BPF VM 版本（v0–v3），从而获得更大的控制权。
• **SBPFv3 仅支持 Rust：**从 SBPFv3 开始，仅支持基于 Rust 的工具链。旧版 C 工具链将不再兼容未来版本。
• **新优化标志：**新增 `--optimize-size` 构建标志，用于生成体积更小的程序二进制文件以供部署。这有助于减少存储占用，但可能会略微增加计算单元（CU）用量。

其他变更

此版本还包含以下更新：

• **自动集群恢复：**新增集群恢复功能 `wen-restart`，可在链崩溃时自动触发集群重启。
• 更新日志 ABI：`TimedTracedEvent` 日志 ABI 已更新，加入了一些新的诊断信息。因此，验证者必须更新所有依赖这些日志的外部追踪或分析工具，以确保兼容性。升级后应清除现有追踪数据，避免格式不匹配。
• **CLI 改进：**新增 withdraw-stake AVAILABLE，可简化所有未质押 lamport 的提取操作；同时更新 solana-test-validator，默认将 RPC 服务绑定到 localhost（127.0.0.1），以提高安全性。
• 更快启动：验证者启动时间已显著缩短。节点现在大约需要 3 分钟启动并加载账本，约 5 分钟追上链顶端。不过，fastboot 现在要求使用新的 --wait-for-exit 标志正常关闭。运营者必须等待验证者进程自行完全终止后再重启，而不能立即发出重启命令。

总结

Agave 2.3 标志着 Solana 协议的又一个重要里程碑。主要亮点包括推出新 TPU 客户端（`tpu-client-next`）、通过优化 AccountsDB 显著减少磁盘 I/O、增强快照性能、改进 gossip 网络，以及加快 epoch 切换和启动速度。这些更新共同增强了网络的稳健性，同时改善了开发者和验证者运营者的体验。

Solana 正在稳步迈向稳健的多客户端网络，目前已有超过 8% 的总质押量运行 Firedancer，且这一比例仍在上升。近一年半的不间断运行，体现出网络核心软件日益成熟和稳定。与此同时，主要版本和次要版本的发布节奏都在加快。

下一站：Agave 3.0！

更多资源

• Agave 2.3 发布计划
• Agave 2.3 变更日志
• Agave 2.3 拉取请求
• Agave 2.3 补丁说明 - Anza 博客 
• tpu-client-next 演示 - Solana 核心社区会议，2025 年 6 月 20 日