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

13 min read 2024年11月11日

非常感谢Jacob Creech, Rex St.John, Brooks Prumo 和 0xIchigo对本文早期版本的审阅。

Agave 2.0 概述

Agave 验证者客户端 v2.0 的发布标志着 Solana 在朝着更强大、多客户端生态系统的旅程中迈出了重要的一步。该更新引入了几项关键改进，以提升网络性能、可靠性和效率。本次更新的主要变化包括：

• 广泛的代码库重构和优化
• 分区的纪元奖励
• 将全部优先费用奖励给验证者
• 新的中央调度器默认已启用
• ZK ElGamal Proof 程序
• Get-Sysvar 系统调用
• GetEpochStake 系统调用
• MoveStake 和 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-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

正如我们在之前的 过渡指南 中详细说明的，2.0 更新引入了几个重大变化，最显著的是移除了一些过时和弃用的端点——所有 Solana 开发者现在应该清楚的关键更新。RPC 变更的完整细节包含在本文末尾。

功能推出

在撰写本文时，~20.7% 的验证者正在运行版本 2.0.14。主网的功能门控激活暂时暂停，以便 v2.0 的采用更好地与测试网和开发网的激活对齐。一旦主网集群广泛采用 v2.0，功能门控激活预计将根据 计划激活顺序 恢复。

以下部分讨论的新完整功能当前尚未上线，将在 2.0 生命周期内通过功能门控系统逐步推出。功能在某些纪元激活，具体依据相对优先级以及它们在测试网和开发网集群上被激活的顺序。

将全部优先费用奖励给验证者

这一备受期待且 备受争议的经济更新 现已按照提案 SIMD-0096 进行实施，该提案于 5 月经过验证者治理投票。投票在第620个纪元结束时结束，51.17% 的质押参与了投票，其中77.77% 投票支持。功能门控更新将根本改变网络对 优先费用 的处理。新的模型将 100% 的优先费用直接分配给验证者，而不是当前的 модель，将费用分配为50%被销毁和50%奖励给验证者。

尽管优先费用在技术上是可选的，但随着 Solana 经济活动的增加，它们已经成为了标准实践。这些费用以微 lamports（lamport 的百万分之一）为单位，在计算单元中使用公式进行计算：

‍优先费用 = 计算单元价格（微 lamports）x 计算单元限制

未来，全部优先费用将奖励给区块生产者。这在激励上形成了更强的对齐，降低了验证者参与协议外安排以纳入交易的可能性，而这在过去曾是一个问题。

尽管去除费用销毁稍微提高了 SOL 的净通货膨胀率，但通过质押奖励的新令牌发行具有更为显著的影响。读者可以参考我们早前的 Helius 博文 Solana 的发行和通货膨胀时间表 以获得更详细的分析。

分区的纪元奖励

分区的纪元奖励 旨在跨多个区块分配 质押奖励，缓解与将奖励分配集中在每个新纪元的第一个区块内相关的性能问题。该过程中的主要瓶颈是需要将更新写回到现有约 140 万个活跃的质押账户。

在这种新方法下，在纪元边界的质押奖励计算和分配将被分为两个不同阶段：

• 奖励计算阶段： 在此阶段，将计算所有活跃质押账户的纪元奖励，并将分配按计划划分为多个部分。
• 奖励分配阶段： 针对活跃质押账户的预先计算的纪元奖励将按照计划进行分配。

为了促进和监控这个过程，一个 Sysvar 账户 EpochRewards 将跟踪和验证整个分配阶段的奖励分配。EpochRewards Sysvar 记录当前是否正在进行奖励分配阶段，以及在从快照开始时恢复分配所需的信息。

奖励计算

奖励计算将会在纪元的第一个区块进行。一旦计算完成，奖励将被划分为存储在银行中的分配部分，这些部分将在奖励分配阶段进行分配。

为了最小化奖励分配阶段对区块处理时间的影响，并确保每个区块以确定的方式分配一部分奖励，目标是在每个区块中分配 4,096 个质押奖励。为了防止质押账户数量急剧增加，区块数量限制设定为当前纪元总插槽的 10%。仅当达到该区块上限时，分区内的账户才被允许超过 4,096 的目标。

奖励分配

奖励分配在奖励计算阶段结束后立即开始，从纪元的第二个区块开始。奖励分配发生在正常交易处理之前的区块顶部。

因此，用户可能会发现奖励比以前慢几块记录到他们的质押账户。然而，整体体验保持类似，因为纪元边界在第一次区块时的延迟曾经使用户访问质押账户的能力被延缓。这种方法的另一个好处是非质押交易可以继续顺畅处理，而之前它们在奖励分配期间被阻塞。‍

由于投票账户的数量相对较少，约 1,500 个，现有的在纪元边界的第一个区块分配投票奖励的机制将保持不变。只有质押奖励将在多个区块中分配。

中央调度器现在默认为启用

首次作为 v1.18 更新中的功能发布，中央调度器（之前称为“调度器”）以前不是默认启用的，启动验证者时必须使用 --block-production-method central-scheduler 标志手动启用。现在已默认启用。先前的调度器实现存在几个可能对性能产生不利影响的问题。交易处理中的瓶颈常常导致交易排序和优先级的不稳定或不一致。

更新后的实现取代了先前的模型，使用四个独立的银行线程，各自管理其交易优先级和处理。在这一修订结构中，中央调度器是 TPU 的 SigVerify 阶段接收交易的唯一接收者。它构建了一个优先级队列并部署了一个依赖图，被称为 prio-graph，以更好地管理冲突交易的处理和优先级。这一新调度器设计提高了可扩展性和灵活性，使得线程数量的增加不再受到增加锁冲突的担忧。中央调度器的初步推出已显示出能带来更好的奖励，从而改善了许多运营者的收益。我们之前的 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 系统调用

Syscalls，或系统调用，向操作系统内核请求服务。在 Solana 的上下文中，Syscall 使在 Solana 虚拟机（SVM）中运行的程序能够与外部资源和服务互动。

Sysvars 公开集群状态信息，例如最近的区块哈希和纪元奖励。这些账户在已知地址中填充。程序可以通过 Sysvar 账户访问 Sysvars，或通过系统调用查询它们。链上程序使用许多 Sysvars 来满足各种用例，其中某些 Sysvars 对网络的运行是必不可少的。

Get-Sysvar 系统调用，最初在 SIMD-127 中由 Anza 工程师 Joe Caulfield 提议，引入了一个统一的 Syscall 接口以访问 Sysvar 数据。此升级使得能够检索先前无法访问的 Sysvar 数据，包括 SlotHashes 和 StakeHistory。借助这一新接口，开发者可以访问 Sysvar 数据的特定片段——例如调用 SlotHashes::get_slot(slot) 和 StakeHistory::get_entry(epoch)——而无需重复整个数据结构。

该更新在修改 Sysvar 数据布局或添加新 Sysvars 时也减少了开销。以前，每个新的 Sysvar 都需要添加一个相应的 Syscall，这导致这种紧密耦合的关系随时间推移膨胀了 Syscall 接口并复杂化了维护。现在，一个单一的 sol_get_Sysvar 系统调用将为所有 Sysvar 接口服务，使得从任何 Sysvar 中一致、高效地检索数据成为可能。

引入新的 Syscall 简化了修改和添加新 Sysvars 的过程。它显著减少了 Syscall 接口的复杂性和维护要求。此外，该更新为扩展 BPF 程序对 Sysvar 数据的访问铺平了道路，使链上程序能够在不影响交易大小的情况下读取更多的 Sysvar 信息。

GetEpochStake 系统调用

新的 GetEpochStake 系统调用 将引入一个备受期待的功能，用于检索投票账户在当前纪元内的委托质押，提供了一种更高效、直接的方法在链上检索此信息。

目前，程序无法访问实时数据，无法了解当前纪元内特定投票账户的委托质押，这为用于验证者治理和辅助共识机制等用例带来了障碍。启用链上查询这些数据将解锁这些应用并为未来用例铺平道路。

通过 GetEpochStake，开发者可以提供一个 32 字节的投票账户地址，系统调用将返回一个 u64 整数，表示当前委托给该投票账户的总活跃质押。如果提供的地址不对应有效的投票账户或不存在，该系统调用将简单地返回 0。

MoveStake 和 MoveLamports

两个新的质押程序指令，MoveStake 和 MoveLamports，正在被引入，以促进在质押账户之间进行价值转移。这些指令最早在 SIMD-0148 中提出，允许开发者在匹配的权威之间转移资金，而无需控制提款者权威。

之前，管理用户质押的协议在跨多个验证者划分质押并在其间定期重新委托时面临挑战。当协议将用户的质押分割以进行停用时，它必须为新的账户提供租金豁免的 lamports。协议无法在合并这些已分割的账户时收回租金豁免的 lamports。

MoveStake

MoveStake：这一指令允许在账户之间移动活跃质押，将其从一个活跃账户转移到另一个活跃账户或从一个活跃账户转移到一个非活跃账户，从而重新激活该账户。如果整个源账户的委托被转移，源账户将变为非活跃。在所有情况下，租金豁免余额保持不变，并维护活跃账户的最小委托规则。

MoveLamports

MoveLamports：将多余的 lamports 从一个活跃或非活跃到账户转移到另一个活跃或非活跃到账户，其中“多余的 lamports”指既不是委托质押也不用于租金豁免的 lamports。MoveLamports 使得诸如从合并账户中回收 lamports 和整合未使用资金等维护任务得以实现。

为了简化实施，这些改动不支持激活或停用账户，亦不影响部分活跃的质押账户。这些新程序指令不更改现有的功能。

附加内容：Solana-SVM Crate

伴随着 Agave 2.0 的发布，推出了一款全新的 solana-svm crate，为开发者提供了通过基于核心 SVM 组件独立于完整验证者框架的简化 API 的直接访问。这使得 Solana 的高性能交易处理能够为验证者以外的应用打开大门，如链下服务、轻量客户端、状态通道和汇总。

通过将 API 与其余运行时解耦，该 crate 消除了诸如 Bank 实例等组件的需求，降低了运营开销。开发者现在可以利用同样强大的组件，支持 Solana 的主网测试版，以构建自定义 SVM 项目，如轻量客户端、状态通道、汇总和链下服务。该 API 的核心是 TransactionBatchProcessor 结构，它允许应用处理经过充分清理的 Solana 交易批次，并使用完整的下游 Agave 组件套件，包括 BPF Loader、eBPF 和虚拟机。

阅读深入分析 Anza 的新 SVM API，以获取关于这一激动人心的发展所有细节。

移除的 RPC 端点

多个过时和弃用的 v1 Agave RPC 端点已被移除。Helius Devrel 团队已联系所有使用这些端点的客户。通过内部分析，我们以前识别了一小部分客户正在积极使用以下将被移除的端点：

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

注意：

我们强烈建议所有开发者检查这些调用的引用，并相应地用建议的替代方案进行更新。

注：图中展示的 getAccountInfo 的替代方法可以在 这里 找到。

SDK 破坏性变更包括：

• Borsh v0.9 支持已移除，请使用 v1 或 v0.10 ( #1440)
• Copy trait 不再导出 在 Rent 和 EpochSchedule 上；请切换到使用 clone()
• solana-sdk： 已弃用符号) 被移除
• solana-program：已弃用符号被移除

对于验证者运营者，多个弃用的验证者参数将在 Agave v2.0 发布时被移除。完整列表可在 这里 找到。‍

结论

Agave 2.0 更新标志着 Solana 的重大进步，结合了众多功能实现和运行时优化。该发布继续推动边界，提供强大的新系统调用、扩展的功能和全面的维护，包括 crate 重命名、弃用 RPC 方法移除和验证者参数简化。Agave 2.0 扩展了 Solana 的能力，并提升了其性能和可用性。无论你是开发者、验证者还是活跃用户，Agave 2.0 更新为 Solana 生态系统中的每个人打开了激动人心的新可能性。

附加资源

• Agave v2.0 发布计划
• Agave v2.0 更改日志
• Agave 发布版本

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