Agave v2.0 更新：你需要了解的一切
特别感谢 Jacob Creech、Rex St.John、Brooks Prumo 和 0xIchigo 审阅本文的早期版本。
Agave 2.0 概述
Agave 验证者客户端 v2.0 的发布，是 Solana 迈向更稳健的多客户端生态系统的重要里程碑。此次更新引入了多项关键改进，以提升网络性能、可靠性和效率。主要变更包括：
- 大规模代码库重构与优化
- 分区式 epoch 奖励
- 将全部优先费奖励给验证者
- 新的中央调度器现已默认启用
ZK ElGamal Proof程序Get-SysvarSyscallGetEpochStakeSyscallMoveStake和MoveLamports- 移除已弃用的 RPC 方法
- 重命名 crate
无论你是在运行验证者、基于该平台进行开发，还是积极使用 Solana，这份 Agave 2.0 更新的全面概览都将帮助你理解并充分利用这些最新创新。
为什么 Agave 2.0 是一次重大版本更新？
如今已不再只有一个“Solana 验证者”。 Agave 2.0 全面拥抱 Solana 的多客户端新格局，并与旧的 Solana Labs GitHub 仓库彻底分离。Solana Labs 仓库将被归档，不再接受新的拉取请求或问题报告。此前，该仓库会镜像 Agave 仓库中的活动。尚未迁移的开发者应将所有活动转移到 Anza Agave GitHub 仓库。从 Solana Labs 迁移到 Agave 的流程已于 3 月 1 日启动，并在其 GitHub 上公开跟踪。
随着生态系统不断发展，运营者必须适应运行一个或多个客户端。为配合这一转变，多个 crate 正在重命名，以腾出命名空间来支持由独立开发团队维护的多个客户端，其中最受关注的是 Firedancer。Anza 维护的 crate 现在将以 "agave" 为前缀，以便在多客户端环境中轻松识别 Anza 特有的依赖项。
受影响的 crate 包括：
solana-validatorsolana-ledger-toolsolana-watchtowersolana-installsolana-geyser-plugin-interfacesolana-cargo-registry
正如我们在之前的迁移指南中详述的那样，2.0 更新引入了多项破坏性变更，其中最重要的是移除了若干过时和已弃用的端点。所有 Solana 开发者现在都应了解这些关键更新。本文末尾列出了 RPC 变更的完整详情。
功能上线计划
截至本文撰写时，约 20.7% 的验证者正在运行 2.0.14 版本。主网的功能门控激活目前暂时暂停，以便 v2.0 的采用进度与测试网和开发网上的激活进度更好地保持一致。待主网集群广泛采用 v2.0 后，功能门控预计将按照预定激活顺序恢复激活。
以下章节讨论的完整新功能目前尚未上线，将在 2.0 生命周期内通过功能门控系统逐步推出。功能会根据相对优先级，以及它们在测试网和开发网集群上的激活顺序，于特定 epoch 激活。
将全部优先费奖励给验证者
这项备受期待且引发广泛讨论的经济机制更新正根据 SIMD-0096 提案实施。该提案已于 5 月通过验证者治理投票。投票在 epoch 620 结束时完成，51.17% 的质押参与了投票，其中 77.77% 投了赞成票。这项受功能门控控制的更新将从根本上改变网络处理优先费的方式。当前模式会销毁 50% 的费用，并将另外 50% 奖励给验证者；新模式则会将 100% 的优先费直接分配给验证者。
虽然优先费在技术上并非强制，但随着 Solana 上经济活动的增长，它已成为标准做法。这些费用按每计算单元多少微 lamport（百万分之一 lamport）计算，公式如下：
优先费 = 计算单元价格（微 lamport）x 计算单元上限
今后，所有优先费都将奖励给区块生产者。这能让激励机制更趋一致，并降低验证者通过协议外安排来纳入交易的可能性——这在过去曾是一个问题。
虽然取消费用销毁会略微提高 SOL 的净通胀率，但通过质押奖励发行的新代币影响要大得多。读者可参阅我们此前关于 Solana 发行与通胀计划的 Helius 博客文章，深入了解这些机制。
分区式 Epoch 奖励
分区式 epoch 奖励旨在将质押奖励分散到多个区块中，从而缓解把奖励分配集中在每个新 epoch 首个区块所带来的性能问题。该流程的主要瓶颈，是需要将更新写回网络上不断增长的活跃质押账户。目前，这类账户约有 140 万个。
采用新方法后，epoch 边界处的质押奖励计算和分配将分为两个不同阶段：
- 奖励计算阶段： 在此阶段，系统会计算所有活跃质押账户的 epoch 奖励，并将分配任务拆分成按计划执行的多个批次。
- 奖励分配阶段： 按照计划分配为活跃质押账户预先计算的 epoch 奖励。
为了推进并监控这一流程，一个名为 EpochRewards 的 Sysvar 账户将在整个分配阶段跟踪并验证奖励分配。EpochRewards Sysvar 会记录奖励分配阶段是否正在进行，以及从快照启动时恢复分配所需的信息。
奖励计算
奖励将在 epoch 的第一个区块中计算。计算完成后，奖励会被划分为存储在 bank 中的分配批次，并在奖励分配阶段发放。
为了尽量减少奖励分配阶段对区块处理时间的影响，并确保每个区块以确定性方式分配一部分奖励，目标是每个区块分配 4,096 笔质押奖励。为防止质押账户数量大幅增长，区块数量上限设为一个 epoch 中总 slot 数的 10%。只有达到这一区块上限时，每个分区的账户数才可超过 4,096 这一目标。
奖励分配
奖励分配会在奖励计算阶段完成后立即开始，从 epoch 的第二个区块起执行。奖励会在区块顶部、常规交易处理之前分配。
因此，用户可能会比以前晚几个区块看到奖励计入质押账户。不过，整体体验基本不变，因为过去 epoch 边界首个区块耗时较长，同样会延迟用户访问质押账户。这种方法还有一个额外优势：非质押交易可以继续顺畅处理，而以前它们会在奖励分配期间被阻塞。
由于投票账户数量相对较少，约为 1,500 个，因此在 epoch 边界首个区块分配投票奖励的现有机制将保持不变。只有质押奖励会分散到多个区块中。
中央调度器现已默认启用
中央调度器最初作为 v1.18 更新中的一项功能发布，之前称为“调度器”。它过去并未默认启用，运营者必须在启动验证者时使用 --block-production-method central-scheduler 标志将其开启。现在，它已默认启用。之前的调度器实现存在多个可能影响性能的问题。交易处理中的瓶颈经常会导致交易排序和优先级处理出现抖动或不一致。
新的实现取代了此前由四个独立 banking 线程分别管理交易优先级和处理的模式。在新架构中，中央调度器是 TPU 的 SigVerify 阶段发送交易的唯一接收方。它会构建优先队列，并使用名为 prio-graph 的依赖关系图，更好地管理冲突交易的处理和优先级。这种新的调度器设计提高了可扩展性和灵活性，可以增加线程数量，而不必像以前那样担心锁冲突增加。中央调度器的初期部署已被证明可以带来更高的奖励，从而提高许多运营者的收益。我们此前介绍 Solana v1.18 更新的 Helius 文章详细讲解了中央调度器的工作原理。
ZK ElGamal Proof 程序
原计划纳入 1.17 版本的 ZK Token Proof 程序现已弃用，并将由更通用、与应用无关的 ZK ElGamal Proof 程序取代。新的 ZK ElGamal Proof 程序保留了 ZK Token Proof 程序中可广泛用于各类应用的部分，例如验证公钥的有效性，或验证 ElGamal 密文中加密值的范围。不过，它移除了特定于应用的元素，例如 SPL Token 转账指令所需的零知识证明验证。新的 ZK ElGamal Proof 程序将被加入内置程序列表，地址为 ZkE1Gama1Proof11111111111111111111111111111
要进一步了解 ZK Token Proof 程序，请阅读我们最初发布在 Helius 博客上的介绍。
Get-Sysvar Syscall
Syscalls，即系统调用，用于向操作系统内核请求服务。在 Solana 中，Syscall 让运行于 Solana Virtual Machine（SVM）中的程序能够与外部资源和服务交互。
Sysvars 公开集群状态信息，例如最近的区块哈希和 epoch 奖励。这些账户会在已知地址上填充数据。程序可以通过 Sysvar 账户访问 Sysvar，也可以通过 Syscall 查询。链上程序会在广泛的用例中使用许多 Sysvar，其中部分 Sysvar 对网络运行至关重要。
Get-Sysvar Syscall 最初由 Anza 工程师 Joe Caulfield 在 SIMD-127 中提出，它引入了统一的 Syscall 接口来访问 Sysvar 数据。此次升级支持获取此前无法访问的 Sysvar 数据，包括 SlotHashes 和 StakeHistory。借助这一新接口，开发者无需复制整个数据结构，即可访问 Sysvar 数据的特定片段，例如调用 SlotHashes::get_slot(slot) 和 StakeHistory::get_entry(epoch)。
此次更新还将修改 Sysvar 数据布局或添加新 Sysvar 时的开销降至最低。过去，每个新 Sysvar 都需要添加对应的 Syscall，这种紧密耦合的关系会让 Syscall 接口随时间不断膨胀，并增加维护难度。现在，单个 sol_get_Sysvar Syscall 将服务于所有 Sysvar 接口，从任何 Sysvar 中一致、高效地检索数据。
新 Syscall 简化了修改和添加 Sysvar 的流程，显著降低了 Syscall 接口的复杂度和维护要求。此外，此次更新也为扩展 BPF 程序访问 Sysvar 数据的能力铺平了道路，让链上程序无需增加交易大小即可读取更多 Sysvar 信息。
GetEpochStake Syscall
新的 GetEpochStake Syscall 将引入一项呼声很高的功能，用于获取当前 epoch 中委托给某个投票账户的质押，为在链上获取这些信息提供更高效、更直接的方法。
目前，程序无法访问当前 epoch 中委托给特定投票账户的实时质押数据，这阻碍了验证者治理和二级共识机制等用例。支持在链上查询这些数据后，将可解锁这些应用，并为未来的用例铺平道路。
使用 GetEpochStake 时，开发者需要提供一个 32 字节的投票账户地址，syscall 将返回一个 u64 整数，表示当前委托给该投票账户的活跃质押总额。如果提供的地址不是有效的投票账户或并不存在，Syscall 将直接返回 0。
MoveStake 和 MoveLamports
两条新的质押程序指令 MoveStake 和 MoveLamports 正在引入，以支持质押账户之间的价值转移。这些指令最初在 SIMD-0148 中提出，允许开发者在权限匹配的账户之间转移资金，而无需提取权限方控制。
过去，管理用户质押的协议在将质押拆分给多个验证者并定期重新委托时面临诸多挑战。当协议拆分用户的质押以停用时，必须为新账户提供达到租金豁免要求的 lamport。合并这些拆分账户后，协议无法收回用于租金豁免的 lamport。
MoveStake
MoveStake：此指令允许在账户之间移动活跃质押，既可以从一个活跃账户转移到另一个活跃账户，也可以从活跃账户转移到非活跃账户，从而重新激活该账户。如果源账户的全部委托都被移走，源账户将变为非活跃状态。在所有情况下，租金豁免余额都不会受到影响，同时活跃账户仍须遵守最低委托规则。
MoveLamports
MoveLamports：将多余的 lamport 从一个活跃或非活跃账户转移到另一个活跃或非活跃账户。“多余的 lamport”是指既不属于委托质押、也不是租金豁免所必需的 lamport。MoveLamports 支持执行维护任务，例如从已合并账户中收回 lamport，以及整合未使用的资金。
为简化实现，这些变更不支持激活或停用账户，也不会影响部分活跃的质押账户。这些新的程序指令不会改变现有功能。
额外内容：Solana-SVM Crate
Agave 2.0 的发布带来了全新的 solana-svm crate，让开发者能够通过独立于完整验证者框架的精简 API，直接访问核心 SVM 组件。这让验证者之外的应用也能使用 Solana 的高性能交易处理能力，例如链下服务、轻量客户端、状态通道和 rollup。
通过将 API 与运行时的其余部分解耦，此 crate 不再需要 Bank 实例等组件，从而降低运行开销。开发者现在可以利用支撑 Solana mainnet-beta 的同一套稳健组件，构建轻客户端、状态通道、rollup 和链下服务等自定义 SVM 项目。此 API 的核心是 TransactionBatchProcessor 结构体，它允许应用使用完整的下游 Agave 组件处理经过清理的 Solana 交易批次，其中包括 BPF Loader、eBPF 和虚拟机。
阅读对 Anza 新 SVM API 的深入解析，全面了解这项令人振奋的新进展。
已移除的 RPC 端点
多个过时和已弃用的 v1 Agave RPC 端点已被移除。Helius Devrel 团队已联系所有使用这些端点的客户。通过内部分析，我们此前发现一小部分客户仍在使用以下即将移除的端点：
getRecentBlockhashgetConfirmedSignatureForAddresses2getConfirmedTransactiongetConfirmedBlockgetStakeActivationgetFees
我们强烈建议所有开发者检查对这些调用的引用，并使用建议的替代方案进行适当更新。
注：图片中所示的 getAccountInfo 替代方法可在此处查看。
SDK 破坏性变更包括：
- 已移除对 Borsh v0.9 的支持，请使用 v1 或 v0.10（#1440）
- Rent 和 EpochSchedule 不再派生 Copy trait；请改用 clone()
- solana-sdk：已移除弃用的符号
- solana-program：已移除弃用的符号
对于验证者运营者，Agave v2.0 发布时将移除多个已弃用的验证者参数。完整列表可在此处查看。
总结
Agave 2.0 更新是 Solana 的一次重大进步，包含众多功能实现和运行时优化。此版本通过强大的新 Syscall、扩展功能和全面的维护工作继续突破边界，包括重命名 crate、移除已弃用的 RPC 方法，以及精简验证者参数。Agave 2.0 扩展了 Solana 的能力，并进一步提升其性能和易用性。无论你是开发者、验证者还是活跃用户，Agave 2.0 更新都为 Solana 生态系统中的每个人带来了令人期待的新可能。
更多资源
订阅 Helius
及时了解 Solana 开发的最新动态，并在我们发布新内容时收到更新