您需要了解的 Agave v2.0 更新内容

加密女士
更新于 2024-12-13 17:18
阅读 210

Agave验证器客户端v2.0的发布标志着Solana迈向更强大的多客户端生态系统的重要里程碑。

## Agave 2.0 总结

Agave 验证器客户端 v2.0 的发布标志着 Solana 迈向更强大的多客户端生态系统的重要里程碑。此更新引入了几项关键改进，以提高网络性能、可靠性和效率。此更新中的关键变化包括：

* 广泛的代码库重构和优化
* 分区周期奖励
* 向验证者奖励全额优先费
* 新的中央调度程序现在默认启用
* ZK **ElGamal 证明**程序
* **获取 Sysvar** Syscall
* **GetEpochStake**系统调用
* **MoveStake**和**MoveLamports**
* 删除弃用的 RPC 方法
* 箱子重命名

无论您运行验证器、在平台上构建还是积极使用 Solana，Agave 2.0 更新的全面概述都将为您提供理解和利用这些最新创新所需的见解。

### 什么使 2.0 成为主要版本更新？

**不再有单一的“Solana 验证器”。Agave** 2.0 拥抱 Solana 的新多客户端世界，并标志着与旧[Solana Labs GitHub 存储库]的彻底决裂。Solana Labs 存储库将被存档，并且将不再接受新的拉取请求或问题。以前，此存储库镜像了 Agave 存储库中的活动。如果开发人员尚未将所有活动迁移到[Anza Agave GitHub 存储库，则应这样做。Solana ][Labs 到 Agave 的迁移过程]于 3 月 1 日开始，并在其 GitHub 上公开跟踪。

随着生态系统的发展，运营商必须适应运行一个或多个客户端。在此转变之后，几个包被重新命名，清除命名空间以支持由独立开发团队管理的多个客户端（最著名的是 Firedancer）。由 Anza 维护的包现在将以“agave”为前缀，使其在多客户端环境中很容易被识别为 Anza 特定的依赖项。

![66cec83bb17ca6be7d3c312f_AD_4nXdsR9MQUNDpsL_JQs4sjefy6YNVG_XntMmjwWl7EhtXHEm47QQAZlS51Aakv1kNmW3EY6si2oLJ9DK3ShIbQy6kACKhdH4gZvhcHgA5pDeF1XWdCVFm4SkJiT6MmtPJRb28fIjpu4ZJ-bFvC_y02gpCiSg.png](https://img.learnblockchain.cn/attachments/2024/12/tONi5TfC675947bf2c090.png)

受影响的板条箱包括：

**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 上的经济活动的增加，它们已成为标准做法。这些费用以每个计算单位的微 Lamport（Lamport 的百万分之一）为单位计算，公式如下：

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

未来，所有优先费用都将奖励给区块生产者。这将创造更强的激励机制，并降低验证者参与协议外交易纳入安排的可能性，这在过去一直是一个问题。

虽然取消费用销毁会略微提高 SOL 的净通胀率，但通过质押奖励发行新代币的影响要大得多。读者可以参考我们之前关于[Solana 发行和通胀计划]的 Helius 博客文章，以更详细地了解这些动态。

## 分区 Epoch 奖励

[分区周期奖励]旨在将[质押奖励]分配到多个区块中，从而缓解将奖励分配集中在每个新周期的第一个区块内所带来的性能问题。此过程中的主要瓶颈是需要将更新写回到网络上日益增多的活跃质押账户中，目前总数约为 140 万个。

在这种新方法下，epoch 边界上的权益奖励计算和分配将分为两个不同的阶段：

* **奖励计算阶段：**在此阶段，将计算所有活跃质押账户的时代奖励，并将其分配分成预定的部分。
* **奖励分配阶段：**对活跃质押账户的预先计算的时代奖励进行相应分配。

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

### 奖励计算

奖励计算将在每个纪元的第一个区块进行。计算完成后，奖励将被分成多个分配块，存储在银行中，并在奖励分配阶段进行分配。

为了最大限度地减少奖励分配阶段对区块处理时间的影响，并确保每个区块以确定性的方式分配一部分奖励，每个区块将分配 4,096 个质押奖励。为了防止质押账户数量急剧增长，区块数量上限为一个时期内总时隙的 10%。只有达到此区块上限，每个分区的账户数量才允许超过 4,096 个目标。

### 奖励分配

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

因此，用户可能会比以前晚几个区块看到奖励记入他们的质押账户。然而，总体体验仍然相似，因为在纪元边界延长的第一个区块时间之前延迟了用户对质押账户的访问。这种方法的另一个好处是非质押交易可以继续顺利处理，而以前，它们在奖励分配期间被阻止。

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

## 中央调度程序现在默认启用

中央调度程序（以前称为“调度程序”）最初作为 v1.18 更新中的一项功能发布引入，默认情况下未启用，必须由操作员在启动验证程序时使用**--block-production-method central-scheduler**标志来启用。现在它默认启用。以前的调度程序实现存在几个问题，可能会对性能产生不利影响。交易处理中的瓶颈通常会导致交易排序和优先级的抖动或不一致。

较新的实现取代了以前的四个独立银行线程模型，每个线程管理自己的交易优先级和处理。在这个修订的结构中，中央调度器是来自 TPU 的 SigVerify 阶段的交易的唯一接收者。它构建一个优先级队列并部署一个依赖关系图（称为 prio-graph），以更好地管理冲突交易的处理和优先级。这种新的调度器设计提高了可扩展性和灵活性，允许增加线程数量，而无需担心之前增加的锁冲突。中央调度器的初始推出已被证明可以产生更好的回报，从而为许多运营商带来更高的收入。我们之前关于 Solana v1.18 更新的 Helius 帖子广泛介绍了[中央调度器的工作原理]。

## ZK ElGamal 证明程序

最初计划包含在 1.17 版本中的 ZK Token Proof 程序现在已被弃用，并将由更通用、独立于应用程序的[ZK ElGamal Proof 程序]取代。新的 ZK ElGamal Proof 程序保留了 ZK Token Proof 程序中广泛适用于各个应用程序的部分，例如验证公钥的有效性或 ElGamal 密文中加密的值的范围。但是，它省略了特定于应用程序的元素，例如 SPL Token 转移指令所需的零知识证明验证。新的 ZK ElGamal Proof 程序将被纳入地址为 \`ZkE1Gama1Proof1111111111111111111111111111111111\` 的内置程序列表。

## 获取 Sysvar Syscall

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

**Sysvars**公开集群状态信息，例如最近的区块哈希和纪元奖励。这些帐户位于已知地址。程序可以通过 Sysvar 帐户访问 Sysvars，或通过 Syscall 查询它们。链上程序使用许多 Sysvars 来实现广泛的用例，并且某些 Sysvars 对于网络的运行至关重要。

Get **-Sysvar** Syscall 最初[由 Anza 工程师 Joe Caulfield 在 SIMD-127]中提出，它引入了一个用于访问 Sysvar 数据的统一 Syscall 接口。此升级允许检索以前无法访问的 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 系统调用

新的[**GetEpochStake** Syscall]将引入一个备受要求的功能，用于检索当前时期投票账户的委托权益，从而提供一种更有效、更直接的方法来在链上检索此信息。
‍

目前，程序无法访问当前时期委托给特定投票账户的权益的实时数据，这为验证者治理和二级共识机制等用例设置了障碍。启用此数据的链上查询将解锁这些应用程序并为未来的用例铺平道路。
‍

使用**GetEpochStake**，开发人员提供一个 32 字节的投票账户地址，系统调用将返回一个 u64 整数，表示当前委托给该投票账户的总有效权益。如果提供的地址与有效的投票账户不对应或不存在，系统调用将仅返回 0。

## MoveStake 和 MoveLamports

引入了两个新的质押程序指令[**MoveStake**和**MoveLamports**][ ，以促进质押账户之间的价值转移。这些指令最初在SIMD-0148]中提出，通过允许在具有匹配权限的账户之间转移资金（不受提款人权限的控制）来帮助开发人员。

以前，管理用户质押的协议在将质押分给多个验证者并定期在他们之间重新委托时面临挑战。当协议分拆用户的质押以停用时，它必须为新账户提供免租 Lamport 资金。协议无法在合并这些分拆账户后收回免租 Lamport。

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

**MoveLamports**：将多余的 Lamport 从一个活跃或不活跃的账户转移到另一个活跃或不活跃的账户，其中“多余的 Lamport”是指既不是委托权益也不是免租所需的 Lamport。MoveLamports可以执行**一些**管理任务，例如从合并账户中回收 Lamport 以及整合未使用的资金。

为了简化实施，这些更改不支持激活或停用帐户，也不会影响部分活跃的权益帐户。这些新的程序说明不会改变现有功能。

## 奖励：Solana-SVM 板条箱

随着 Agave 2.0 的发布，一个[全新的**solana-svm 包**]也随之而来，它让开发人员可以通过独立于完整验证器框架的精简 API 直接访问核心 SVM 组件。这为验证器以外的应用程序（例如链下服务、轻量级客户端、状态通道和汇总）打开了 Solana 的高性能交易处理。
‍

通过将 API 与运行时的其余部分分离，此 crate 消除了对 Bank 实例等组件的需求，从而降低了运营开销。开发人员现在可以利用支持 Solana 主网测试版的相同强大组件来构建自定义 SVM 项目，例如轻客户端、状态通道、汇总和链下服务。此 API 的核心是**TransactionBatchProcessor**结构，它允许应用程序使用全套下游 Agave 组件（包括 BPF Loader、eBPF 和虚拟机）处理批量清理的 Solana 交易。

## 已删除的 RPC 端点

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

**getRecentBlockhash、getConfirmedSignatureForAddresses2、getConfirmedTransaction、getConfirmedBlock、getStakeActivation、getFees**

**再次，我们强烈建议所有开发人员检查这些调用的引用，并使用建议的替换进行适当的更新。**

SDK 重大变更包括：

* 已删除对 Borsh v0.9 的支持，请使用 v1 或 v0.10 ( [#1440]
* [Copy 特征不再]从 Rent 和 EpochSchedule 中派生；改用 clone()
* solana-sdk：已删除 [弃用的符号]
* solana-program：已删除弃用的符号

对于验证器操作符，Agave v2.0 发布后将删除几个已弃用的验证器参数。完整列表可[在此处]找到。

## 结论

Agave 2.0 更新标志着 Solana 的重大进步，它整合了大量功能实现和运行时优化。此版本继续突破界限，提供强大的新 Syscall、扩展功能和全面的管理功能，包括 crate 重命名、弃用的 RPC 方法删除和简化的验证器参数。Agave 2.0 扩展了 Solana 的功能并改进了其性能和可用性。无论您是开发人员、验证者还是活跃用户，Agave 2.0 更新都会为 Solana 生态系统中的每个人带来令人兴奋的新可能性。

作者：https://t.me/+P3Z7P_xQxbNlZWZl
来源：https://www.fabipingtai.com

Agave 2.0 总结

广泛的代码库重构和优化
分区周期奖励
向验证者奖励全额优先费
新的中央调度程序现在默认启用
ZK ElGamal 证明程序
获取 Sysvar Syscall
GetEpochStake系统调用
MoveStake和MoveLamports
删除弃用的 RPC 方法
箱子重命名

无论您运行验证器、在平台上构建还是积极使用 Solana，Agave 2.0 更新的全面概述都将为您提供理解和利用这些最新创新所需的见解。

什么使 2.0 成为主要版本更新？

不再有单一的“Solana 验证器”。Agave 2.0 拥抱 Solana 的新多客户端世界，并标志着与旧[Solana Labs GitHub 存储库]的彻底决裂。Solana Labs 存储库将被存档，并且将不再接受新的拉取请求或问题。以前，此存储库镜像了 Agave 存储库中的活动。如果开发人员尚未将所有活动迁移到[Anza Agave GitHub 存储库，则应这样做。Solana ][Labs 到 Agave 的迁移过程]于 3 月 1 日开始，并在其 GitHub 上公开跟踪。

受影响的板条箱包括：

solana-validator、solana-ledger-tool、solana-watchtower、solana-install、solana-geyser-plugin-interface、solana-cargo-registry

功能推出

向验证者奖励全额优先费

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

未来，所有优先费用都将奖励给区块生产者。这将创造更强的激励机制，并降低验证者参与协议外交易纳入安排的可能性，这在过去一直是一个问题。

分区 Epoch 奖励

在这种新方法下，epoch 边界上的权益奖励计算和分配将分为两个不同的阶段：

奖励计算阶段：在此阶段，将计算所有活跃质押账户的时代奖励，并将其分配分成预定的部分。
奖励分配阶段：对活跃质押账户的预先计算的时代奖励进行相应分配。

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

奖励计算

奖励计算将在每个纪元的第一个区块进行。计算完成后，奖励将被分成多个分配块，存储在银行中，并在奖励分配阶段进行分配。

奖励分配

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

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

中央调度程序现在默认启用

中央调度程序（以前称为“调度程序”）最初作为 v1.18 更新中的一项功能发布引入，默认情况下未启用，必须由操作员在启动验证程序时使用--block-production-method central-scheduler标志来启用。现在它默认启用。以前的调度程序实现存在几个问题，可能会对性能产生不利影响。交易处理中的瓶颈通常会导致交易排序和优先级的抖动或不一致。

ZK ElGamal 证明程序

最初计划包含在 1.17 版本中的 ZK Token Proof 程序现在已被弃用，并将由更通用、独立于应用程序的[ZK ElGamal Proof 程序]取代。新的 ZK ElGamal Proof 程序保留了 ZK Token Proof 程序中广泛适用于各个应用程序的部分，例如验证公钥的有效性或 ElGamal 密文中加密的值的范围。但是，它省略了特定于应用程序的元素，例如 SPL Token 转移指令所需的零知识证明验证。新的 ZK ElGamal Proof 程序将被纳入地址为 `ZkE1Gama1Proof1111111111111111111111111111111111` 的内置程序列表。

获取 Sysvar Syscall

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

Sysvars公开集群状态信息，例如最近的区块哈希和纪元奖励。这些帐户位于已知地址。程序可以通过 Sysvar 帐户访问 Sysvars，或通过 Syscall 查询它们。链上程序使用许多 Sysvars 来实现广泛的用例，并且某些 Sysvars 对于网络的运行至关重要。

Get -Sysvar Syscall 最初[由 Anza 工程师 Joe Caulfield 在 SIMD-127]中提出，它引入了一个用于访问 Sysvar 数据的统一 Syscall 接口。此升级允许检索以前无法访问的 Sysvar 数据，包括 SlotHashes 和 StakeHistory。借助这个新接口，开发人员可以访问 Sysvar 数据的特定片段（例如调用“SlotHashes::get_slot(slot)”和“StakeHistory::get_entry(epoch)”），而无需复制整个数据结构。

此更新还可最大限度地减少修改 Sysvar 数据布局或添加新 Sysvar 时的开销。以前，每个新的 Sysvar 都需要添加相应的 Syscall，从而形成紧密耦合的关系，随着时间的推移，Syscall 接口会变得臃肿，维护也变得复杂。现在，单个sol_get_Sysvar Syscall 将服务于所有 Sysvar 接口，从而实现从任何 Sysvar 进行一致且高效的数据检索。

GetEpochStake 系统调用

新的[GetEpochStake Syscall]将引入一个备受要求的功能，用于检索当前时期投票账户的委托权益，从而提供一种更有效、更直接的方法来在链上检索此信息。 ‍

使用GetEpochStake，开发人员提供一个 32 字节的投票账户地址，系统调用将返回一个 u64 整数，表示当前委托给该投票账户的总有效权益。如果提供的地址与有效的投票账户不对应或不存在，系统调用将仅返回 0。

MoveStake 和 MoveLamports

引入了两个新的质押程序指令[MoveStake和MoveLamports][ ，以促进质押账户之间的价值转移。这些指令最初在SIMD-0148]中提出，通过允许在具有匹配权限的账户之间转移资金（不受提款人权限的控制）来帮助开发人员。

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

MoveLamports：将多余的 Lamport 从一个活跃或不活跃的账户转移到另一个活跃或不活跃的账户，其中“多余的 Lamport”是指既不是委托权益也不是免租所需的 Lamport。MoveLamports可以执行一些管理任务，例如从合并账户中回收 Lamport 以及整合未使用的资金。

为了简化实施，这些更改不支持激活或停用帐户，也不会影响部分活跃的权益帐户。这些新的程序说明不会改变现有功能。

奖励：Solana-SVM 板条箱

随着 Agave 2.0 的发布，一个[全新的solana-svm 包]也随之而来，它让开发人员可以通过独立于完整验证器框架的精简 API 直接访问核心 SVM 组件。这为验证器以外的应用程序（例如链下服务、轻量级客户端、状态通道和汇总）打开了 Solana 的高性能交易处理。 ‍

通过将 API 与运行时的其余部分分离，此 crate 消除了对 Bank 实例等组件的需求，从而降低了运营开销。开发人员现在可以利用支持 Solana 主网测试版的相同强大组件来构建自定义 SVM 项目，例如轻客户端、状态通道、汇总和链下服务。此 API 的核心是TransactionBatchProcessor结构，它允许应用程序使用全套下游 Agave 组件（包括 BPF Loader、eBPF 和虚拟机）处理批量清理的 Solana 交易。