关于 Agave v2.0 更新你需知道的一切
Agave 2.0 概述
Agave 验证节点客户端 v2.0 的发布是一项重大的成就，标志着 Solana 迈向更加强大、多客户端生态系统。本次更新引入了多个关键改进，以提升网络性能、可靠性和效率。此次更新的主要变化包括：
- 广泛的代码库重构和优化
- 分区纪元奖励
- 将完整的优先费奖励给验证节点
- 新的中央调度器默认启用
- ZK ElGamal 证明程序
- Get-Sysvar 系统调用
- GetEpochStake 系统调用
- MoveStake 和 MoveLamports
- 移除弃用的 RPC 方法
- Crate 重命名
无论你是运行验证节点、在平台上进行开发，还是主动使用 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 上公开追踪。
随着生态系统的迭代，运营者必须适应运行一个或多个客户端。随着这一转变，多个 crate 被重新命名，清理命名空间以支持多个客户端——其中最值得注意的是 Firedancer——由独立的开发团队管理。Anza 维护的 crate 现在将以“agave”作为前缀，使其在多客户端环境中容易被识别为 Anza 专用的依赖项。
受影响的 crates 包括：
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 生命周期内逐步推出，采用功能门控系统。功能将在特定的纪元激活，基于相对优先级以及它们在测试网和开发网上的激活顺序。
将完整的优先费用奖励给验证节点
这一备受期待且广泛讨论的经济更新目前正在实施，依照在 5 月进行的验证节点治理投票通过的提案 SIMD-0096 进行。投票在第 620 纪元结束时完成，参与的质押份额为 51.17%，其中 77.77% 的投票支持通过。这个功能门控更新将从根本上改变网络对优先费用的处理方式。新模型将不再像当前模型那样将费用 50% 销毁，50% 奖励给验证节点，而是将 100% 的优先费用直接分配给验证节点。
上图：Solana 每周优先费（以美元计）（来源）
虽然优先费在技术上是可选的，但随着 Solana 经济活动的增加，它们已成为标准做法。这些费用按照每个计算单元的微 lamport（lamport 的百万分之一）计算，使用以下公式：
优先费用 = 计算单元价格（微lamport） 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 阶段的交易的唯一接收者。它构建一个优先级队列并部署一个依赖图（称为优先图），以更好地管理冲突事务的处理和优先级排序。这种新的调度程序设计提高了可扩展性和灵活性，允许增加线程数量，而不必担心以前会增加锁仓冲突。事实证明，中央调度程序的最初推出可以产生更好的回报，从而提高许多运营商的收入。我们之前关于 Solana v1.18 更新的 Helius 帖子全面介绍了中央调度程序如何工作。
ZK ElGamal 证明程序
最初计划包含在 1.17 版本中的 ZK Token Proof 程序现已弃用，并将由更通用、独立于应用程序的 ZK ElGamal 证明程序所取代。新的 ZK ElGamal 证明程序保留了 ZK 代币证明程序中广泛应用于各个应用程序的部分，例如验证公钥的有效性或 ElGamal 密文中加密的值的范围。但是，它忽略了特定于应用程序的元素，例如 SPL 代币传输指令所需的零知识证明验证。新的 ZK ElGamal Proof 程序将被合并到地址为“ZkE1Gama1Proof11111111111111111111111111111”的内置程序列表中。
要了解有关 ZK 代币证明程序的更多信息，请阅读我们的 Helius 博客上的原始文章。
Get-Sysvar 系统调用
系统调用（Syscalls）是向操作系统内核请求服务的方式。在 Solana 的背景下，系统调用使得在 Solana 虚拟机（SVM）中运行的程序能够与外部资源和服务进行交互。
Sysvars 暴露了集群状态信息，如最近的区块哈希和时代奖励。这些账户存储在已知地址中。程序可以通过 Sysva r账户访问这些 Sysvars，或通过系统调用查询它们。链上程序使用许多 Sysvars 来满足不同的用例，某些 Sysvars 对于网络的正常运行至关重要。
Get-Sysvar 系统调用最初由 Anza 工程师 Joe Caulfield 在 SIMD-127 中提出，它引入了一个统一的系统调用接口，用于访问 Sysvar 数据。这个升级使得能够获取以前无法访问的 Sysvar 数据，包括 SlotHashes 和 StakeHistory。通过这个新接口，开发者可以访问 Sysvar 数据的特定片段——例如调用 SlotHashes::get_slot(slot)和StakeHistory::get_entry(epoch)——而无需重复整个数据结构。
该更新还减少了修改 Sysvar 数据布局或添加新 Sysvar 时的开销。之前，每增加一个新的Sysvar，都需要添加一个相应的系统调用，导致系统调用接口的耦合关系越来越紧密，随着时间推移，接口膨胀且维护变得复杂。现在，单一的 sol_get_Sysvar系统调用将服务于所有 Sysvar 接口，实现从任何 Sysvar 中一致且高效地检索数据。
引入新的系统调用简化了修改和添加新 Sysvars 的过程，显著降低了系统调用接口的复杂性和维护要求。此外，此更新为扩大 BPF 程序对 Sysvar 数据的访问铺平了道路，使链上程序能够读取更多的 Sysvar 信息，而不影响交易大小。
GetEpochStake 系统调用
新的 GetEpochStake 系统调用将引入一个备受请求的功能，用于检索当前时代投票账户的委托股权，提供了一种更高效、直接的方法，以链上获取此信息。
目前，程序无法访问特定投票账户在当前时代委托的实时权益数据，这为验证节点治理和次级共识机制等用例带来了障碍。启用链上查询这些数据将解锁这些应用，并为未来的用例铺平道路。
通过 GetEpochStake，开发者提供一个 32 字节的投票账户地址，系统调用将返回一个 u64 整数，表示当前委托给该投票账户的总活跃权益。如果提供的地址无效或不存在，该系统调用将返回 0。
MoveStake 和 MoveLamports
两个新的权益程序指令——MoveStake 和 MoveLamports——被引入，以促进权益账户之间的价值转移。这些指令最初在 SIMD-0148 中提出，它们允许在具有匹配授权的账户之间转移资金而无需撤回授权，帮助开发者简化了账户间的资金移动。
此前，管理用户权益的协议在将权益拆分到多个验证节点并定期重新委托时，面临着一些挑战。当协议将用户的权益拆分用于停用时，它必须为新账户提供租金豁免的 lamports。但在合并这些拆分账户时，协议无法回收租金豁免的 lamports。
MoveStake：此指令允许在账户之间移动活跃权益，可以将权益从一个活跃账户转移到另一个活跃账户，或从活跃账户转移到非活跃账户，从而重新激活该账户。如果整个源账户的权益被转移，源账户将变为非活跃账户。在所有情况下，租金豁免余额保持不变，活跃账户的最小委托规则也得以保持。
MoveLamports：将多余的 lamports 从一个活跃或非活跃账户转移到另一个活跃或非活跃账户，其中“多余的lamports”指的是既不是委托权益，也不用于租金豁免的 lamports。MoveLamports 支持如回收合并账户中的 lamports 和整合未使用资金等日常维护任务。
为了简化实现，这些更改不支持激活或停用账户，也不影响部分活跃权益账户。这些新的程序指令不会改变现有功能。
额外内容：Solana-SVM Crate
随着 Agave 2.0 的发布，推出了全新的 solana-svm crate，为开发者提供了通过简化的 API直接访问核心 SVM 组件的功能，这一 API 独立于完整的验证节点框架。这为超越验证节点的应用打开了 Solana 高性能交易处理的可能性，例如链下服务、轻量级客户端、状态通道和Rollup。
通过将 API 与其余运行时解耦，该 crate 消除了像 Bank 实例等组件的需求，从而减少了操作开销。开发者现在可以利用与 Solana 主网 Beta 相同的强大组件，构建自定义的 SVM 项目，如轻客户端、状态通道、Rollup 和链下服务。该 API 的核心是 TransactionBatchProcessor结构，它允许应用程序通过完整的下游 Agave 组件（包括 BPF 加载器、eBPF 和虚拟机）处理批量的已清洗 Solana 交易。
上图：交易批处理器（图片来源：Anza）
请阅读关于Anza 新 SVM API 的深度解析，了解这一值得关注的发展详情。
移除的 RPC 端点
多个过时和弃用的 v1 Agave RPC 端点已被移除。Helius Devrel 团队已联系所有使用这些端点的客户。通过内部分析，我们之前已识别出一小部分客户仍在积极使用以下端点，这些端点将被移除：
getRecentBlockhash、getConfirmedSignatureForAddresses2、getConfirmedTransaction、getConfirmedBlock、getStakeActivation、getFees
再次提醒，我们强烈建议所有开发者检查是否有调用这些端点的引用，并根据建议的替代方法进行更新。
上图：即将被移除的过时和弃用的 v1 Agave RPC 端点完整列表
注意：图片中显示的 getAccountInfo的替代方法可在此处找到。
SDK 重大变更包括：
- 移除了对 Borsh v0.9 的支持，请使用 v1 或 v0.10（#1440）
Rent和EpochSchedule不再派生 Copy 特性，请改用clone()方法- solana-sdk：已移除所有弃用的符号)
- solana-program：已移除所有弃用的符号
对于验证节点运营者，Agave v2.0 发布后将移除多个弃用的验证节点参数，完整列表可在此处查看。
结论
Agave 2.0 更新融合了众多新功能实现和运行时优化，是 Solana 的一项重要进步。此版本通过强大的新系统调用（Syscalls）、扩展的功能以及全面的维护工作（包括 crates 重命名、弃用 RPC 方法移除和验证节点参数优化），继续拓宽技术发展。Agave 2.0 不仅拓展了 Solana 的功能，还优化了性能与易用性。无论您是开发者、验证节点运营者，还是活跃用户，Agave 2.0 更新都为 Solana 生态系统的每个人带来了令人振奋的新可能性。
其他资源 / 延伸阅读
免责声明：
- 本文转载自【helius】，所有版权归原作者所有【Lostin】。若对本次转载有异议，请联系 Gate Learn 团队，他们会及时处理。
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。
相关文章
重返 Bonding Curve，我们用对它了吗？
探索 CKB 的发展历程
解析B^2新版技术路线图：比特币链下DA与验证层的必要性
关于 Agave v2.0 更新你需知道的一切
Agave 2.0 概述
将完整的优先费用奖励给验证节点
分区纪元奖励
中央调度程序现在默认开启
ZK ElGamal 证明程序
Get-Sysvar 系统调用
GetEpochStake 系统调用
MoveStake 和 MoveLamports
额外内容：Solana-SVM Crate
移除的 RPC 端点
结论
其他资源 / 延伸阅读
Agave 2.0 概述
Agave 验证节点客户端 v2.0 的发布是一项重大的成就，标志着 Solana 迈向更加强大、多客户端生态系统。本次更新引入了多个关键改进，以提升网络性能、可靠性和效率。此次更新的主要变化包括：
- 广泛的代码库重构和优化
- 分区纪元奖励
- 将完整的优先费奖励给验证节点
- 新的中央调度器默认启用
- ZK ElGamal 证明程序
- Get-Sysvar 系统调用
- GetEpochStake 系统调用
- MoveStake 和 MoveLamports
- 移除弃用的 RPC 方法
- Crate 重命名
无论你是运行验证节点、在平台上进行开发，还是主动使用 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 上公开追踪。
随着生态系统的迭代，运营者必须适应运行一个或多个客户端。随着这一转变，多个 crate 被重新命名，清理命名空间以支持多个客户端——其中最值得注意的是 Firedancer——由独立的开发团队管理。Anza 维护的 crate 现在将以“agave”作为前缀，使其在多客户端环境中容易被识别为 Anza 专用的依赖项。
受影响的 crates 包括：
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 生命周期内逐步推出，采用功能门控系统。功能将在特定的纪元激活，基于相对优先级以及它们在测试网和开发网上的激活顺序。
将完整的优先费用奖励给验证节点
这一备受期待且广泛讨论的经济更新目前正在实施，依照在 5 月进行的验证节点治理投票通过的提案 SIMD-0096 进行。投票在第 620 纪元结束时完成，参与的质押份额为 51.17%，其中 77.77% 的投票支持通过。这个功能门控更新将从根本上改变网络对优先费用的处理方式。新模型将不再像当前模型那样将费用 50% 销毁，50% 奖励给验证节点，而是将 100% 的优先费用直接分配给验证节点。
上图：Solana 每周优先费（以美元计）（来源）
虽然优先费在技术上是可选的，但随着 Solana 经济活动的增加，它们已成为标准做法。这些费用按照每个计算单元的微 lamport（lamport 的百万分之一）计算，使用以下公式：
优先费用 = 计算单元价格（微lamport） 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 阶段的交易的唯一接收者。它构建一个优先级队列并部署一个依赖图（称为优先图），以更好地管理冲突事务的处理和优先级排序。这种新的调度程序设计提高了可扩展性和灵活性，允许增加线程数量，而不必担心以前会增加锁仓冲突。事实证明，中央调度程序的最初推出可以产生更好的回报，从而提高许多运营商的收入。我们之前关于 Solana v1.18 更新的 Helius 帖子全面介绍了中央调度程序如何工作。
ZK ElGamal 证明程序
最初计划包含在 1.17 版本中的 ZK Token Proof 程序现已弃用，并将由更通用、独立于应用程序的 ZK ElGamal 证明程序所取代。新的 ZK ElGamal 证明程序保留了 ZK 代币证明程序中广泛应用于各个应用程序的部分，例如验证公钥的有效性或 ElGamal 密文中加密的值的范围。但是，它忽略了特定于应用程序的元素，例如 SPL 代币传输指令所需的零知识证明验证。新的 ZK ElGamal Proof 程序将被合并到地址为“ZkE1Gama1Proof11111111111111111111111111111”的内置程序列表中。
要了解有关 ZK 代币证明程序的更多信息，请阅读我们的 Helius 博客上的原始文章。
Get-Sysvar 系统调用
系统调用（Syscalls）是向操作系统内核请求服务的方式。在 Solana 的背景下，系统调用使得在 Solana 虚拟机（SVM）中运行的程序能够与外部资源和服务进行交互。
Sysvars 暴露了集群状态信息，如最近的区块哈希和时代奖励。这些账户存储在已知地址中。程序可以通过 Sysva r账户访问这些 Sysvars，或通过系统调用查询它们。链上程序使用许多 Sysvars 来满足不同的用例，某些 Sysvars 对于网络的正常运行至关重要。
Get-Sysvar 系统调用最初由 Anza 工程师 Joe Caulfield 在 SIMD-127 中提出，它引入了一个统一的系统调用接口，用于访问 Sysvar 数据。这个升级使得能够获取以前无法访问的 Sysvar 数据，包括 SlotHashes 和 StakeHistory。通过这个新接口，开发者可以访问 Sysvar 数据的特定片段——例如调用 SlotHashes::get_slot(slot)和StakeHistory::get_entry(epoch)——而无需重复整个数据结构。
该更新还减少了修改 Sysvar 数据布局或添加新 Sysvar 时的开销。之前，每增加一个新的Sysvar，都需要添加一个相应的系统调用，导致系统调用接口的耦合关系越来越紧密，随着时间推移，接口膨胀且维护变得复杂。现在，单一的 sol_get_Sysvar系统调用将服务于所有 Sysvar 接口，实现从任何 Sysvar 中一致且高效地检索数据。
引入新的系统调用简化了修改和添加新 Sysvars 的过程，显著降低了系统调用接口的复杂性和维护要求。此外，此更新为扩大 BPF 程序对 Sysvar 数据的访问铺平了道路，使链上程序能够读取更多的 Sysvar 信息，而不影响交易大小。
GetEpochStake 系统调用
新的 GetEpochStake 系统调用将引入一个备受请求的功能，用于检索当前时代投票账户的委托股权，提供了一种更高效、直接的方法，以链上获取此信息。
目前，程序无法访问特定投票账户在当前时代委托的实时权益数据，这为验证节点治理和次级共识机制等用例带来了障碍。启用链上查询这些数据将解锁这些应用，并为未来的用例铺平道路。
通过 GetEpochStake，开发者提供一个 32 字节的投票账户地址，系统调用将返回一个 u64 整数，表示当前委托给该投票账户的总活跃权益。如果提供的地址无效或不存在，该系统调用将返回 0。
MoveStake 和 MoveLamports
两个新的权益程序指令——MoveStake 和 MoveLamports——被引入，以促进权益账户之间的价值转移。这些指令最初在 SIMD-0148 中提出，它们允许在具有匹配授权的账户之间转移资金而无需撤回授权，帮助开发者简化了账户间的资金移动。
此前，管理用户权益的协议在将权益拆分到多个验证节点并定期重新委托时，面临着一些挑战。当协议将用户的权益拆分用于停用时，它必须为新账户提供租金豁免的 lamports。但在合并这些拆分账户时，协议无法回收租金豁免的 lamports。
MoveStake：此指令允许在账户之间移动活跃权益，可以将权益从一个活跃账户转移到另一个活跃账户，或从活跃账户转移到非活跃账户，从而重新激活该账户。如果整个源账户的权益被转移，源账户将变为非活跃账户。在所有情况下，租金豁免余额保持不变，活跃账户的最小委托规则也得以保持。
MoveLamports：将多余的 lamports 从一个活跃或非活跃账户转移到另一个活跃或非活跃账户，其中“多余的lamports”指的是既不是委托权益，也不用于租金豁免的 lamports。MoveLamports 支持如回收合并账户中的 lamports 和整合未使用资金等日常维护任务。
为了简化实现，这些更改不支持激活或停用账户，也不影响部分活跃权益账户。这些新的程序指令不会改变现有功能。
额外内容：Solana-SVM Crate
随着 Agave 2.0 的发布，推出了全新的 solana-svm crate，为开发者提供了通过简化的 API直接访问核心 SVM 组件的功能，这一 API 独立于完整的验证节点框架。这为超越验证节点的应用打开了 Solana 高性能交易处理的可能性，例如链下服务、轻量级客户端、状态通道和Rollup。
通过将 API 与其余运行时解耦，该 crate 消除了像 Bank 实例等组件的需求，从而减少了操作开销。开发者现在可以利用与 Solana 主网 Beta 相同的强大组件，构建自定义的 SVM 项目，如轻客户端、状态通道、Rollup 和链下服务。该 API 的核心是 TransactionBatchProcessor结构，它允许应用程序通过完整的下游 Agave 组件（包括 BPF 加载器、eBPF 和虚拟机）处理批量的已清洗 Solana 交易。
上图：交易批处理器（图片来源：Anza）
请阅读关于Anza 新 SVM API 的深度解析，了解这一值得关注的发展详情。
移除的 RPC 端点
多个过时和弃用的 v1 Agave RPC 端点已被移除。Helius Devrel 团队已联系所有使用这些端点的客户。通过内部分析，我们之前已识别出一小部分客户仍在积极使用以下端点，这些端点将被移除：
getRecentBlockhash、getConfirmedSignatureForAddresses2、getConfirmedTransaction、getConfirmedBlock、getStakeActivation、getFees
再次提醒，我们强烈建议所有开发者检查是否有调用这些端点的引用，并根据建议的替代方法进行更新。
上图：即将被移除的过时和弃用的 v1 Agave RPC 端点完整列表
注意：图片中显示的 getAccountInfo的替代方法可在此处找到。
SDK 重大变更包括：
- 移除了对 Borsh v0.9 的支持，请使用 v1 或 v0.10（#1440）
Rent和EpochSchedule不再派生 Copy 特性，请改用clone()方法- solana-sdk：已移除所有弃用的符号)
- solana-program：已移除所有弃用的符号
对于验证节点运营者，Agave v2.0 发布后将移除多个弃用的验证节点参数，完整列表可在此处查看。
结论
Agave 2.0 更新融合了众多新功能实现和运行时优化，是 Solana 的一项重要进步。此版本通过强大的新系统调用（Syscalls）、扩展的功能以及全面的维护工作（包括 crates 重命名、弃用 RPC 方法移除和验证节点参数优化），继续拓宽技术发展。Agave 2.0 不仅拓展了 Solana 的功能，还优化了性能与易用性。无论您是开发者、验证节点运营者，还是活跃用户，Agave 2.0 更新都为 Solana 生态系统的每个人带来了令人振奋的新可能性。
其他资源 / 延伸阅读
免责声明：
- 本文转载自【helius】，所有版权归原作者所有【Lostin】。若对本次转载有异议，请联系 Gate Learn 团队，他们会及时处理。
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。
相关文章
重返 Bonding Curve，我们用对它了吗？
探索 CKB 的发展历程