Agave 4.1 更新：你需要了解的一切
引言
随着 Agave 4.1 发布，Solana 核心验证者客户端继续稳步演进，在带来当前性能提升的同时，也为更大的区块、200ms 时隙时间以及 Alpenglow 的最终推出奠定基础。
4.1 发布周期的重要更新
- 加快发布节奏，现在每六周发布一次重大版本
- 继续推进 Alpenglow 就绪工作，包括 BLS 公钥管理*、Validator Admission Tickets* 和社区测试集群
- XDP 采用率突破关键网络阈值
- 使用 Pinocchio 重写更多程序，包括 p-memo 和 p-ATA
- 降低验证者 RAM 使用量
- 为 200ms 时隙时间做准备**
* 由功能门控控制的升级
** 预计在 Agave 4.2 中推出
除核心客户端工作外，Anza 和更广泛的生态系统也在并行推进多项重大计划：
- Constellation：Constellation 提议在大规模生产区块链上首次正式实现协议级 Multiple Concurrent Proposers (MCP)。Constellation 不再赋予单一领导者决定是否纳入交易的广泛自由裁量权，而是引入提议者和证明者，限制领导者可以从有效区块中排除的内容。
- **量子安全加固：**Anza 的研究团队已开始探索如何保护 Solana，使其能够抵御未来的量子对手，包括研究后量子签名、账户迁移、共识签名、区块传播和链上签名验证。
- **经济机制升级：**新一轮代币经济学提案也已进入筹备阶段。SIMD-550 提议将 Solana 的通胀递减率提高一倍，从 -15% 提高至 -30%；而 SIMD-553：资源费与纳入费提议将当前的签名费拆分为支付给领导者的基础纳入费，以及根据请求成本单元计算并销毁的资源费。
- **新的治理工具：**下一轮经济提案也将借助改进后的治理基础设施来推进。新工具不仅允许验证者，也允许质押者直接参与 Solana 治理，让更多人能够对核心协议变更发表意见。
目前正在发生的事情实在太多了。
无论你是验证者运营者还是开发者，本指南都会提供必要的更新和洞见，帮助你充分利用最新改进。本文各章节彼此独立，读者可以专注于与自己最相关的主题。
截至撰写本文时，Agave v4.1.0-rc.1 已推荐在主网上普遍使用。验证者们，是时候升级了！
Alpenglow 就绪工作
Alpenglow 共识升级的大量基础工作将在 Agave 4.1 发布周期内落地。这些变更将为网络从 Tower BFT 迁移至 Alpenglow 做好准备，包括投票程序中的 BLS 密钥管理、Validator Admission Tickets 和 Fast Leader Handover 标记。
社区测试集群
Alpenglow 距离主网激活的剩余工作现在很大程度上依赖广泛的真实环境测试。自 5 月以来，一个由约 100 个分布在不同地理位置的验证者组成的社区测试集群一直在实时网络环境中运行此次升级，并在主网激活前测试 Solana 当前基于 Tower BFT 的共识与 Alpenglow 之间的切换。
目标是让启动过程尽可能平稳。集群中的验证者一直在 Tower BFT 和 Alpenglow 之间切换，在真实运营环境下检验迁移路径，而不是仅依赖受控的内部测试。相关讨论正在 Solana Tech Discord 的 `ag-community-cluster` 频道中进行，你还可以通过 Valid Blocks、Staking Facilities 和 Noders 提供的社区仪表板追踪集群的实时活动。
BLS 公钥管理
SIMD-0387：投票账户中的 BLS 公钥管理将在 Agave 4.1 发布周期内激活。它添加了必要的投票程序底层支持，使验证者能够在 Alpenglow 推出前，将 BLS 公钥注册到投票账户中。Alpenglow 使用 BLS 聚合签名来降低投票聚合和验证成本，但 BLS 公钥不同于当前使用的 Ed25519 投票授权密钥。
验证者可以将 BLS 公钥添加到投票账户，同时继续使用现有的 Ed25519 投票授权密钥运行。Alpenglow 激活后，未注册 BLS 公钥的投票账户将无法参与新的投票流程。
Alpenglow Validator Admission Tickets (VAT)
Agave 4.1 发布周期还将包括 SIMD-0357 的主网激活，该提案实现了 Validator Admission Tickets (VAT)。随着 Solana 摆脱 Tower BFT 当前的投票交易模型，VAT 旨在维持相近的验证者成本结构。
目前，验证者会在持续投票时不断支付投票交易费。对于稳定投票的验证者，每个 epoch 的费用合计约为 ~2.1 SOL。在 Alpenglow 下，这些投票交易将被新的共识设计取代，因此 SIMD-0357 改为引入每个 epoch 一次的准入成本。每个有资格参与 Alpenglow 投票的验证者每个 epoch 支付 1.6 SOL 的 VAT，在维持相近经济门槛的同时，降低 Alpenglow 上线后验证者集合立即失控扩张的风险。
具体实现发生在 epoch 边界。进入新 epoch 时，运行时会计算下一个 epoch 的验证者集合，筛选出既注册了 BLS 公钥、又有足够 lamports 支付 VAT 和租金的投票账户，然后从获准验证者的投票账户中扣除 VAT。这些 lamports 会直接发送到销毁账户。如果符合条件的验证者超过 2,000 个，投票集合将按质押权重设定上限，并选择排名靠前的合格验证者。
从运营角度看，这会改变验证者运营者需要存放资金的位置。目前，投票交易费由验证者身份账户支付，该账户必须是用于正常验证者运营的热密钥对。采用 VAT 后，准入成本将改为从投票账户中扣除。
Fast Leader Handover 标记
最后，SIMD-0337：Alpenglow Fast Leader Handover 标记激活后将添加新的区块标记，使 Alpenglow 领导者可以在区块开始时声明其父区块，并在流式传输区块期间根据需要更新该父区块。这些标记支持 Fast Leader Handover，旨在减少领导者之间的同步延迟。
提高 XDP 采用率并迈向 1 亿 CU
XDP (eXpress Data Path) 是 Agave 用于加速 Turbine 的高性能网络路径。它允许 Agave 在靠近网卡的位置加载 eBPF 程序，使 shred 流量绕过大部分标准 Linux 数据包处理路径。采用 XDP 对网络实现长期以来的 1 亿 CU 区块目标至关重要。
采用率现已跨过一个重要门槛。本月早些时候，网络迎来了“反超时刻”，运行 XDP 的领导者数量首次超过未运行 XDP 的领导者。目前，超过三分之二的网络已经激活 XDP。Agave 4.1 反映了其成熟度，移除了 XDP 支持的实验性标签，并用 `--xdp-interface`、`--xdp-cpu-cores` 和 `--xdp-zero-copy` 取代旧的 `--experimental-retransmit-xdp-*` 标志。Agave 4.2 计划默认启用 XDP。
对于仍未完成切换的验证者运营者，Solana Foundation 的升级页面和 Anza 的设置指南提供了实用的兼容性检查清单，涵盖内核支持、网络硬件、验证者能力、启动标志和验证步骤。下面是一份实用的驱动程序和 NIC 兼容性指南。
使用 Pinocchio 重写更多程序
p-token 最近的成功上线证明，针对 Solana 最常用程序进行重写，可以显著节省整个网络的计算资源。作为 SPL Token 程序的直接替代方案，p-token 将计算单元 (CU) 消耗降低约 95%，使标准代币交易的效率提升约 ~19 倍。此前，Token 程序指令约占整个区块 CU 使用量的 10%。通过将这些指令的成本降至原来的约 5%，p-token 释放了接近 9.5% 的区块总容量。
p-token 中的“p”代表 Pinocchio，这是由 Anza 开发的优化型、高性能、零依赖 Solana 程序开发库。Pinocchio 可替代标准的 solana-program crate，后者大量使用零拷贝类型处理指令和账户数据。
Anza 目前正在使用 Pinocchio 重写其他核心程序。目标不是引入新标准或强制应用迁移，而是大幅降低现有常用程序的执行成本。
p-memo 程序
第一个例子是 p-memo，它是使用 Pinocchio 对 SPL Memo 程序的重新实现，目前已在主网上线。Memo 程序虽然很小，但效率提升仍然十分显著。在没有签名者的情况下，p-memo 消耗 287 CU，而当前 Memo 程序消耗 2,022 CU，仅约为现有成本的 14%。存在签名者后，差距更加明显：一个签名者时，p-memo 使用 513 CU，而当前程序使用 13,525 CU；两个签名者时为 628 CU，对比 25,111 CU；三个签名者时为 743 CU，对比 36,406 CU。这意味着在签名者较多的情况下，p-memo 可将计算消耗降至当前程序成本的 2–4%。
p-ATA 程序
p-ATA 的开发也在进行中，它是使用 Pinocchio 对 Associated Token Account 程序的重新实现。ATA 程序定义了钱包、代币铸币地址和用于持有该代币的 Token 账户之间的标准映射。它提供了一种确定性方式来派生用户的关联 Token 账户，并允许任何人在该账户尚不存在时为接收方创建账户。
ATA 程序是网络上调用次数排名第五的程序。根据 Anza 团队的估算，它出现在全部交易的 ~11.9% 中，占 CU 总消耗的 ~13.3%。此次重写可将加权平均 CU 使用量降低 80.9%，而与 p-ATA 一同添加的新指令有望进一步节省资源。按当前网络使用量计算，这相当于在整个主网上节省约 10% 的 CU。在 Anza 的抽样测试中，p-ATA 每个区块释放了超过 278 万 CU。
p-token、p-memo 和 p-ATA 不太可能是这项工作的终点。Token-2022 程序是另一个呼声很高的项目。更广泛地说，Anza 让核心程序实现 `no_std` 的工作，为以更少依赖、更低计算成本重写更多 Solana 基础程序奠定了基础。
降低程序入口点开销
Agave 4.1 发布周期内计划激活的另一项相关变更是 SIMD-0449：程序输入中的直接账户指针，它将优化程序入口点。目前，ABIv1 sBPF 程序必须解析程序输入中的序列化账户部分，才能找到账户边界并构建传递给程序的账户切片。SIMD-0449 改为让 VM 在程序输入后附加直接账户指针切片，使用 VM 在准备调用时已经掌握的边界信息。
这对 Pinocchio 风格的程序尤其重要，因为账户解析占入口点成本的很大一部分。有了直接账户指针，入口点无需遍历完整账户部分即可访问账户，因此无论账户数量多少，入口点的计算成本实际上都保持恒定。
在更新后的基准测试中，包含 64 个账户的 Pinocchio 入口点从 504 CU 降至预计 7 CU，较小的账户集合也都趋近于同样低的 7 CU 成本。
将时隙时间缩短至 200ms
最受期待的性能改进之一，是将 Solana 的目标时隙时间从 400ms 缩短至 200ms。这项改进不太可能在 Agave 4.1 发布周期内推出，更可能随 Agave 4.2 进入主网。不过，推动这一重要升级尽快登陆主网的势头正在增强。
SIMD-0525：缩短时隙时间提议分阶段推出：先将时隙时间从 400ms 缩短至 350ms，再依次缩短至 300ms、250ms，最终达到 200ms。每个阶段都由功能门控控制，让客户端团队和运营者有机会先观察网络在更短时隙时间下的表现，再进入下一阶段。Anza 已在内部测试 200ms 时隙数月，团队认为网络已经能够承受大幅缩短时隙时间。重放阶段的改进让这项变更更加可行：现在重放完整的 400ms 时隙大约只需 40ms。
动机很直接。更短的时隙可以降低用户的确认和最终确认延迟，也会缩短每个领导者窗口。目前，Solana 的领导者跨度是连续四个时隙，在 400ms 时隙下，领导者拥有 1.6 秒的窗口。在 200ms 时隙下，这一窗口将缩短至 800ms。这样可以改善市场结构，减少恶意领导者在下一位领导者有机会生成区块前，延迟、重新排序或选择性纳入交易的最长时间。
更短的时隙还能让应用更精细地观察链上时间。这对于需要判断时隙新鲜度的系统十分重要，包括预言机数据使用方和专有 AMM 风格的做市商。
该提案经过精心设计，以避免改变 Solana 的经济机制。`slots_per_year` 将按反向比例提高，从而保持 SOL 的通胀计划不变。在 Alpenglow 下，Validator Admission Ticket (VAT) 成本也会随时隙时间阶段调整，使准入成本维持在预期的每天约 ~0.8 SOL。此外，每个时隙的工作上限会按目标时隙时间缩短的比例降低，因此网络每秒可处理的工作量大致保持不变。
多项核心假设保持不变。领导者跨度仍为四个时隙，epoch 仍固定为 432,000 个时隙，每个时隙仍包含 64 个 tick。由于 epoch 的时隙数量保持固定，200ms 时隙会将一个 epoch 的长度从约两天缩短至一天。
一个争议点是，如果在 Alpenglow 之前激活更短的时隙时间，会对验证者投票成本产生什么影响。更快的时隙意味着每天需要投更多票，因此验证者的每日投票成本也会更高。投票交易成本是验证者运营者最大的一项单独成本。投票交易统一定价为 0.000005 SOL，每天的交易成本合计约为 ~1.086 SOL。采用 200ms 时隙后，这些成本将大致翻倍。
其他重要更新
Agave 4.1 发布周期还将激活多项规模较小但值得关注的改进，包括更精确的验证者佣金率、新的密码学原语，以及移除可升级加载器中的一个拒绝服务攻击向量。
提高验证者佣金率精度
在 Agave 4.1 发布周期内，由功能门控控制的 SIMD-0291：以基点表示佣金率升级将在主网上激活。目前，验证者佣金率只能设置为整数百分点。这意味着验证者可以将佣金设置为 5% 或 6%，但不能设置为 5.5%、5.25% 或 5.01%。
通过此次更新，验证者可以使用基点设置佣金率，从而实现更精细的控制，其中 100 个基点等于 1%。投票程序将添加新的 `UpdateCommissionBps` 指令，允许投票账户的授权提款方以更高精度更新验证者的通胀奖励佣金。这将使验证者的佣金设置更加灵活，更具竞争力。
这项变更是与新 Vote Account V4 相关的多项更新之一。它还有助于网络为预期激活的 SIMD-0123：区块收入分配做好准备，该提案将允许在协议内分配区块奖励。
SHA-512 系统调用
SIMD-0512：Sha512 系统调用引入了一项新的系统调用，使链上程序可以通过运行时直接使用 SHA-512 哈希，并采用与 `sol_sha256`、`sol_keccak256` 和 `sol_blake3` 等现有哈希系统调用一致的接口。
SHA-512 是 Ed25519 签名验证使用的核心原语，并且已经作为 Agave 和 Firedancer 验证者客户端的内部依赖存在。但在此之前，它尚未向链上程序开放。直接在链上对短消息进行哈希的成本很高，会消耗数千 CU，而通过系统调用执行则不到 100 CU。
借助 `sol_sha512`，程序可以按系统调用成本计算 SHA-512 哈希，并直接获得标准的 64 字节摘要。该变更为增量添加且由功能门控控制，因此不使用新系统调用的程序不会受到影响，现有哈希系统调用也保持不变。
加固可升级加载器
Agave 4.1 发布周期还将推出由功能门控控制的 SIMD-0431：Loader V3 的最小程序扩展大小，为 Loader V3 的 `ExtendProgram` 指令添加最小扩展大小。激活后，程序每次必须至少扩展 10,240 字节 (10 KiB)，除非程序数据账户距离 10 MiB 的账户大小上限已经不足 10 KiB。
这项变更解决了当前可升级加载器中一个隐蔽的拒绝服务攻击向量。`ExtendProgram` 无需权限，这意味着任何人都可以扩展可升级程序的数据账户，哪怕只扩展一个字节。由于每次扩展都会使程序在当前时隙中的缓存条目失效，成本低廉的单字节扩展可能暂时中断对程序的访问。
该变更没有为 `ExtendProgram` 添加权限，而是在保留其无需权限设计的同时，让滥用行为在经济上失去吸引力。采用新的 10 KiB 最小值后，每次扩展需要支付约 0.072 SOL 的免租 lamports。
对于合法的程序升级，影响应该有限。需要额外空间不足 10 KiB 的程序必须按完整的最小值进行扩展，但多出的容量仍可用于未来升级。该 SIMD 也不会改变指令账户、签名者要求、CPI 限制和现有多签工作流。
结论
Agave 4.1 是一次重大的客户端升级，汇集了广泛的性能改进和优化。展望未来，Agave 4.2 的影响可能更加深远，它将带来更大的 4096 字节交易大小、缩短至 200ms 的时隙时间，以及可能期待已久的 Alpenglow 共识升级。
更多资源
订阅 Helius
及时了解 Solana 开发的最新动态，并在我们发布新内容时收到更新