Agave 4.3 更新：你需要了解的一切
简介
随着 Agave 4.3 到来，Solana 正在为可能是有史以来最大规模的协议升级做准备。4.3 发布周期将引入备受期待的 Solana 新共识机制 Alpenglow，并最终迎来“Alpenswitch”：协调主网从 TowerBFT 迁移。
自上线以来，Solana 的共识架构一直以历史证明和 TowerBFT 为基础。验证者通过提交交易进行投票，这些交易会与普通用户交易一同处理并打包进区块。随着投票在 32 个 slot 中不断累积，区块最终获得终局性，因此 Solana 的终局时间约为 12.8 秒（假设 slot 时间为 400 毫秒）。
历史证明（PoH）是 Solana 上线之初具有代表性的架构创新之一，它采用独特方式为事件排序并协调时间。它最终退出历史舞台，既标志着一个时代的结束，也凸显了该协议相较于最初令其脱颖而出的技术已经演进了多远。
Alpenglow 使用 Votor 取代“PoH + TowerBFT”。在该协议中，验证者会在核心交易管线之外交换投票，并将这些投票聚合成加密证书。其设计目标是实现约 150 毫秒的终局时间。
对于提交交易和读取账户状态的用户与应用，几乎不需要进行任何迁移。交易和费用机制保持不变。消费区块、投票、数据流或承诺数据的验证者和基础设施将面临最大的调整。
投票交易将从区块中消失，confirmed 和 finalized 实际上将趋于一致，而流式基础设施会获得新信息，用于区分同一 slot 内相互竞争的 bank。
本文将介绍 Alpenglow 的工作方式，包括 Votor 对区块生产和终局性的改变。我们还会介绍 Agave 4.3 发布周期中即将到来的其他重要变化。
分阶段推出：先 Votor，后 Rotor
Alpenglow 围绕两大核心组件设计：Votor 取代 Solana 的投票和终局机制，Rotor 则重新设计区块在网络中的传播方式。这两种机制将分阶段推出，Votor 会率先上线。
Agave 4.3 引入 Votor，同时保留现有的区块传播协议 Turbine。负责规范 Alpenglow 初始激活的提案 SIMD-0326 明确排除了 Rotor。Rotor 必须先有自己的 SIMD，之后才能部署。初始上线会改变验证者达成共识的方式，但暂时不会改变区块数据在网络中的传输方式。
Votor
Votor 使用更直接的验证者间协议，取代 TowerBFT 的投票交易和锁定系统。在 TowerBFT 下，验证者通过提交打包进区块的交易进行投票，区块最终会累积足够的锁定深度并获得终局性。在 Votor 下，验证者改为直接交换已签名的投票消息，协议再将这些签名聚合为紧凑的证书。
Votor 无需等待投票在 32 个 slot 中累积，而是可以在一轮或两轮投票后让区块获得终局性。该协议的目标终局时间约为 150 毫秒，而 TowerBFT 约为 12.8 秒。
Votor 有两条并行运行的终局路径。
如果至少 80% 的质押权重在第一轮公证某个区块，这些投票便可聚合成 Fast-Finalization Certificate，区块也会立即获得终局性。这是协议的快速路径，只需一轮投票。
如果未达到 80% 的门槛，只要超过 60% 的质押权重投票公证该区块，它仍可继续推进。这会生成 Notarization Certificate，从而允许进行第二轮投票。通过两轮路径投出终局投票的质押权重超过 60% 后，就会形成 Finalization Certificate，使区块获得终局性。
完整协议共有五种投票类型：Notarization、Notarization Fallback、Skip、Skip Fallback 和 Final。这些投票的不同组合会生成公证、回退、跳过或终局证书。这些证书是紧凑的加密证据，证明已有足够的质押权重就某个 slot 的结果达成一致。
Votor 的设计目标是：即使只有 60% 的诚实质押权重能够正常响应，也能继续推进；最多允许 20% 的质押权重进行对抗性行为，同时另有 20% 离线或无响应。这是一项有意为之的权衡：Alpenglow 放弃 BFT 设计传统的三分之一拜占庭容错门槛，换取 20+20 的韧性模型，从而对崩溃或不可用的验证者具备更高容忍度。
Votor 还不再使用历史证明作为共识时钟，验证者会改用本地超时计时器。如果验证者等待足够长时间后仍未收到可接受的区块，便可投出跳过票，让共识继续推进。与 TowerBFT 相比，这简化了计时与共识之间的关系。
Rotor
Rotor 不属于 Agave 4.3，目前也没有公布激活日期。因此，Votor 激活后仍会由 Turbine 传输区块数据。Rotor 及其用于选择中继节点的智能采样机制将在日后通过单独的提案和发布流程推出。
需要强调的是，这并不意味着 Solana 必须等待 Rotor 才能实现亚秒级终局时间。**当前 Alpenglow 发布计划是在保留 Turbine 的同时，通过 Agave 4.3 中的 Votor 实现约 150 毫秒的终局时间。**Rotor 旨在进一步改善区块传播，并提高整体 Alpenglow 架构的效率，但它并不是 Votor 新终局模型的前置条件。
投票交易将成为历史
Alpenglow 最显著的影响之一，是投票交易将从 Solana 区块中消失。验证者需要为这些投票支付交易费，网络也需要消耗带宽、计算资源和账本空间来处理与存储它们。
过去，投票交易约占链上记录的全部交易的四分之三；随着区块容量提高，这一比例已经下降。投票交易成本很低（5,000 lamports），仅占总体计算量的一小部分（约 5%），但它们抬高了网络的原始交易数量和账本占用空间。
在 Alpenglow 下，验证者会改为直接彼此交换使用 BLS 签名的投票消息。Agave 的 ConsensusPool 会追踪其观察到的投票，并将足够的质押权重聚合到 Votor 用于推进共识或确定终局性的证书中。
这并不意味着验证者参与共识的证据会从账本中消失。Alpenglow 区块引入了一个包含共识信息的新区块尾部。在当前 Agave 实现中，BlockFooterV1 可携带最新的终局证书，以及 notar_reward_cert 和 skip_reward_cert。奖励证书包含聚合 BLS 签名，以及用于标识已投票验证者的位图。
目前通过索引 Vote Program 交易来判断验证者是否投票的系统，需要改用 Alpenglow 的证书和投票相关数据。仅过滤投票交易的现有交易管线通常可以继续运行；Alpenswitch 后，过滤器只是不再有内容可移除。
这次切换也会让大家熟悉的 Solana TPS 统计出现断层。Alpenglow 激活后，即使用户活动完全没有变化，包含投票交易的原始 TPS 测量值也会大幅下降。因此，非投票 TPS 才是比较 Alpenswitch 前后活动水平的有效指标。移除投票交易消除了长期以来围绕 Solana 实际吞吐量的一个混淆来源，也将更便于与同类网络进行比较。
移除投票交易会为用户释放一部分容量，但鉴于投票在网络计算负载中的占比较低，不应夸大这一影响。
承诺级别
Alpenglow 还消除了 Solana 长期存在的一项差异：confirmed 与 finalized 承诺之间的差距。
目前，应用可以在三种承诺级别之间选择。processed 提供最新视图，但不附带全网保证。confirmed 表示绝大多数质押权重已为该区块投票，通常会在一两个 slot 内到达。finalized 提供确定性终局保证，但在 TowerBFT 下，需要区块达到最大投票锁定深度，因此从确认到最终确定之间约有 32 个 slot 的间隔。通常建议对延迟敏感的 RPC 请求使用 confirmed，需要更强保证时则使用 finalized。
实践证明，confirmed 非常可靠：从未有过已乐观确认的 Solana 区块随后无法获得终局性的情况。但其协议保证仍然较弱。已确认的区块尚未具备确定性终局性，因此无法容忍此类残余尾部风险的桥、交易所和结算系统等应用，过去必须等待 finalized。
Alpenglow 消除了这一取舍。一旦 Votor 生成快速终局证书或终局证书，区块即获得终局性。当 Votor 选择一个已获得终局性的 bank 作为根时，验证者会同时更新其最高确认 slot、根和最高绝大多数根。
对开发者而言，这意味着 Alpenswitch 之后，confirmed 和 finalized 实际上指向相同的共识状态。**现有应用无需在激活当天更改承诺设置，**因为 RPC 接口仍接受 processed、confirmed 和 finalized，但后两者之间的延迟差异将会消失。
普通 RPC 使用者不会感知 Votor 两条终局路径之间的区别。无论区块在一轮内达到 80% 的快速终局门槛，还是通过门槛为 60% 的两轮路径获得终局性，对外可见的结果都相同。
多个候选区块
Alpenglow 的另一项重要变化会影响 RPC 提供商、索引器和其他消费验证者数据的基础设施。slot 将不再能被视为唯一的区块标识符。
Solana slot 是 leader 可以生成区块的时间窗口。bank 则是验证者对执行特定候选区块所产生状态的本地表示。这两个概念一直有所区别，相互竞争的 bank 也并非新事物，但许多生产基础设施始终将 slot 和区块视为同义词。
Alpenglow 让这一假设变得愈发不可靠。
Agave 4.3 为 Geyser（用于流式传输账户、交易、条目和区块更新的验证者接口）扩展了一个新标识符：bank_id。新增的 bank 感知回调包括 update_account_for_bank、notify_transaction_for_bank、notify_entry_for_bank 和 notify_block_metadata_for_bank，它们会将事件与生成该事件的特定 bank 关联起来。限定于 bank 的状态通知同样会携带 bank_id。旧回调会在 4.3 中保留以确保兼容性，但已被弃用，并计划在下一个 Agave 大版本中移除。
关键在于，bank_id 标识的是本地 bank 实例，而不是全局一致认可的区块。Agave 使用验证者运行时维护的本地原子计数器创建 bank ID，因此不应预期两个重放同一区块的验证者会为其分配相同的 bank_id。基础设施应使用 (slot, bank_id) 区分来自单个验证者的竞争数据流，但在协调来自不同验证者或连接的数据时，应使用区块 ID 或 blockhash。
在 Alpenglow 的后续阶段，同一 slot 存在多个 bank 将成为验证者运行的常态。
最清晰的例子是快速 leader 交接，这是初始 Votor 激活后推出的 Alpenglow 组件之一。leader 可以基于其预期共识会接受的父区块，乐观地开始构建区块。如果 Votor 随后决定应跳过该父区块，leader 可以切换父区块，并在其剩余 leader 窗口内重新构建。对内部系统而言，这意味着需要为同一 slot 将一个 bank 替换为另一个。Agave 已包含表示这种切换所需的 UpdateParent 机制。快速 leader 交接不属于 Agave 4.3 初始 Alpenglow 激活的一部分，预计将在 4.4 期间推出。
leader 双重提议也可能产生大致相同的结果。如果一个 leader 为同一 slot 签署并分发两个不同区块，验证者可能需要暂时保留这两个候选区块并对其进行判断。由于 Votor 是异步的，验证者会在收到区块、投票、证书和本地超时事件时采取行动，因此网络的不同部分可能以不同顺序看到这些候选区块。
最近的一项变更将 MAX_ALTERNATE_BLOCKS_PER_SLOT 从 11 收紧到 6。因此，验证者对于一个 slot 最多需要保留七个候选区块。共识最终会将这些候选区块归并为一段历史。在 Votor 下，公证需要超过 60% 的质押权重。除非大量质押权重同时为两个区块投票，否则两个冲突区块不可能都获得有效的公证证书。根据 Alpenglow 关于行为拜占庭化的质押权重低于 20% 的假设，如果不违反协议的安全假设，就不可能出现相互冲突的公证证书。
对于 Geyser 使用者，实际结论很明确：不要再仅以 slot 作为临时状态的键。在共识确定最终保留的 bank 之前，应按 (slot, bank_id) 分别追踪账户变更、交易、条目和区块元数据。如果同一 slot 出现另一个 bank，其事件属于独立的候选状态，不应静默覆盖第一个 bank 的事件。
验证者准入票
目前，投票交易是运行 Solana 验证者的最大成本。在 TowerBFT 下，验证者每次提交投票都要支付标准交易费，每个 epoch 累计约为 2 SOL。Alpenglow 使用每个 epoch 向获准进入活跃共识集的验证者收取一次的费用，取代交易费。这项费用称为验证者准入票（VAT）。
这次转型的基础已经上线。SIMD-0387 所规定的 BLS 公钥注册已于 7 月在主网上激活，不久后 VAT 功能门控 SIMD-0357 也随之激活。Votor 使用 BLS 签名，因此可以将多个验证者的签名聚合为一份紧凑证书。每个验证者必须先在其投票账户中注册 BLS 公钥，才能参与 Alpenglow。自 VAT 门控激活以来，没有 BLS 公钥的验证者已被排除在投票集之外。
在 Alpenglow 上线前，验证者会继续提交普通投票交易并支付相关费用。在这一阶段，VAT 主要作为准入筛选机制。符合条件的验证者必须拥有 BLS 密钥，并按质押权重排在符合资格的前 2,000 个验证者之内。Alpenglow 启用后，VAT 开始生效，投票交易也随之消失。
Alpenglow 激活后，系统会在 epoch 边界附近重新计算准入资格。验证者的投票账户必须包含已注册的 BLS 密钥，以及足以支付准入票和免租金要求的 SOL。如果符合条件的账户超过 2,000 个，系统会按质押权重对其排序，并接纳质押权重最高的验证者。随后，系统会直接从每个获准验证者的投票账户中扣除准入票费用，并将其发送到 Solana 的销毁账户。因此，验证者需要确保投票账户资金充足；在旧系统中，投票交易费会从验证者的身份账户中扣除。
最初的 Alpenglow 和 VAT 提案规定每个 epoch 的准入票费用为 1.6 SOL，约为验证者此前投票交易支出（约 2 SOL）的 80%。这一数字基于 Solana 过去 400 毫秒的 slot 目标。SIMD-0525 则让 VAT 随 slot 时长一起调整。当 slot 时间为 200 毫秒时，准入成本将为 0.8 SOL。
VAT 还改变了这项费用的去向。目前，投票交易支付的 5,000 lamport 基础费用会分为两部分：50% 被销毁，50% 归区块 leader 所有。相比之下，VAT 会全部发送至销毁账户。不过，VAT 更广泛的目的并不是让 SOL 显著增强通缩属性，而是在投票交易费消失后，继续维持加入共识集所需的经济成本。
安全与准备工作
替换一个正在运行的网络的共识协议，是一项风险极高的操作。因此，与典型的 Agave 功能激活相比，Alpenglow 拥有范围广得多的测试和迁移流程，其中包括专用社区测试集群和漏洞赏金计划。
自 5 月以来，验证者运营者一直在运行专用的 Alpenglow Community Cluster，目前已增长至 100 多个节点。运营者使用真实的验证者硬件和网络配置，让 Alpenglow 能够在地理分散、延迟变化、不同软件配置、重启和操作失误等受控环境难以复现的条件下接受测试。
该集群最重要的用途之一，是测试 Alpenswitch 本身。运营者不只检查集群已经运行 Alpenglow 后 Votor 能否工作，还反复演练了从 TowerBFT 迁移到新共识系统的过程。
Alpenglow 还接受了专门的对抗性审查。8 月，Anza 启动了为期两周的 Alpenglow 漏洞赏金竞赛，奖池最高达 50,000 SOL。与常设的 Agave 漏洞赏金不同，该竞赛专门针对新的共识栈，范围包括 Votor、BLS 签名和证书验证、验证者准入，以及从 TowerBFT 迁移至 Alpenglow 的路径。参与度很高。Anza 报告称收到了 300 多份提交，并表示将发放超过 25,000 SOL 的赏金。
随着 Alpenglow 到来，对 Frankendancer 的支持将终止。Frankendancer 从一开始就定位为过渡客户端，它将 Firedancer 的网络和区块生产组件与 Agave 的执行和共识组件结合在一起。在这种混合架构中支持新共识系统，会增加另一项巨大的维护和安全负担，因此 Firedancer 团队将开发重点转向完整的 Firedancer 客户端。
提供给验证者的指导是，Frankendancer 和完整的 Firedancer 都不会支持 TowerBFT 向 Alpenglow 迁移的短暂窗口。因此，Firedancer 运营者应安排在 Alpenswitch 前故障转移到 Agave 验证者，在交接期间继续使用 Agave，并在集群于 Alpenglow 下恢复正常运行后再切回 Firedancer。
Alpenswitch 实际如何进行
Alpenglow 不会在任意现实时间点同时于所有位置启用。其功能激活后，协议会将 5,000 个 slot 后的位置定义为迁移边界。验证者越过这一边界并寻找确认强度足够高的区块时，TowerBFT 会继续运行。随后，验证者使用 BLS 签署选定的 Alpenglow 创世区块，并直接相互分发这些创世投票。
当至少 82% 的质押权重签署同一个创世区块，生成 Alpenglow 创世证书后，交接便会发生。接收并验证该证书的验证者会在创世区块之后禁用 TowerBFT，并从达成一致的状态初始化 Votor。随后，证书会在验证者集合中传播，使其余节点越过迁移边界。
基础设施运营者可以利用该证书方便地判断集群目前位于 Alpenswitch 的哪一侧。
Agave 4.3 引入了新的 RPC 方法 getAgGenesisCert。迁移前，Agave 4.3 节点返回 null。集群切换后，它会返回 Alpenglow 创世证书，其中包括创世区块和聚合 BLS 签名。不支持该方法的旧节点则会返回 Method not found。CLI 通过以下命令公开相同信息：solana alpenglow-genesis-info。
因此，对于需要响应迁移的验证者、RPC 提供商和其他基础设施而言，检查创世证书比假设 Alpenglow 在某个特定时间戳激活更可靠。
新加密 syscall
Agave 4.3 还扩展了 SVM 的加密工具集，加入新的运行时原语，用于执行直接在 sBPF 中成本高得难以承受的操作。
两项重要新增功能是 SHA-512 哈希和大整数模幂运算。两者均为增量功能且受功能门控控制：现有程序不受影响，选择使用这些功能的程序则可以将计算成本高昂的密码学运算交给验证者运行时内经过优化的原生实现。
大整数模幂运算
SIMD-0529：大整数 ModExp Syscall引入了 sol_big_mod_exp，用于计算：
result = (base ^ exponent) mod modulus模幂运算是 RSA 签名验证、密码学累加器、部分可验证延迟函数和其他数论协议背后的基础操作。直接在 SVM 程序中使用任意精度整数运算实现该操作，会消耗极高的计算资源，在 2048、3072 和 4096 位等常见 RSA 密钥长度下尤其如此。
新的 syscall 会将成本高昂的算术运算移至验证者运行时。程序以小端序无符号整数形式提供底数、指数和模数，并在调用方提供的内存中接收结果。每个操作数最初上限为 512 字节，足以支持最高 4096 位的整数。
最明显的用例是 RSA 验证。例如，验证传统 RSA 签名的程序可以使用常见公钥指数 65537 调用 sol_big_mod_exp，而无需自行实现大整数幂运算。该 syscall 有意仅提供算术原语：程序仍需自行负责哈希、PKCS#1 v1.5 或 PSS 等 RSA 填充、密钥验证，以及任何特定于协议的域分离。
它还可以高效执行大整数模约简。传入指数 1 后，运算将简化为：
base mod modulus这为程序提供了原生原语，可以对大于 SVM 内置机器字长的整数进行约简，而无需承担通用大整数实现的成本。
该设计在理念上类似于 EIP-198 引入的 Ethereum ModExp 预编译，其计算计量模型也遵循 EIP-198 的运算复杂度公式。不过，它与 Ethereum 并非逐字节兼容。Solana 通过原生 syscall ABI 公开该功能，使用小端序输入，并要求模数必须是大于一的奇数；偶数模数会被拒绝。
因此，该 syscall 对互操作性尤其有用，同时又不强迫 Solana 采用 EVM 预编译接口本身。围绕 Ethereum 风格加密假设构建并用于验证证明、签名或证明声明的程序，可以复用相同的底层算术运算，只需调整调用方式。
SHA-512
第二项新增功能要简单得多，但可以立即发挥作用。
SIMD-0512：Sha512 Syscall新增了 sol_sha512，让链上程序可以通过验证者运行时直接使用 SHA-512 哈希函数。其接口与 Solana 现有的 sol_sha256、sol_keccak256 和 sol_blake3 syscall 保持一致，并返回标准的 64 字节 SHA-512 摘要。
值得注意的是，SHA-512 是 Ed25519 使用的核心原语之一，而 Solana 本身也广泛使用这种签名方案。Agave 和 Firedancer 内部都已依赖 SHA-512，但在此次变更前，SVM 程序无法直接使用这一优化实现。需要 SHA-512 的程序只能自行通过软件实现该算法。
从计算成本来看，两者的差异非常显著。SIMD 估计，使用 sBPF 实现对短输入进行哈希需要数千 CU，而通过 syscall 执行相同操作的成本不到 100 CU。sol_sha512 采用与 Solana 现有 SHA-256 syscall 相同的通用计算成本模型。
总体而言，这两个 syscall 延续了 SVM 的一个长期趋势：将常见但计算成本高昂的加密原语从单个程序中移出，转为标准化、可计量的运行时操作。程序仍负责定义上层加密协议，但验证者执行这些高成本基础操作的效率远高于 sBPF 实现。
总结
Agave 4.3 最重要的变化是 Alpenglow。它使用 Votor 取代 TowerBFT，从区块中移除投票交易，将终局时间从秒级压缩至毫秒级，并重塑验证者和基础设施与共识交互的方式。
对于大多数用户和应用开发者，这次迁移的大部分过程都不会被感知。但对于验证者、RPC 提供商、索引器和基础设施团队而言，Agave 4.3 标志着 Solana 达成共识的方式开始发生重大转变。
更多资源
- Alpenglow 白皮书 v1.2（2026 年 7 月）
- Agave 4.3 发布时间表
- 功能门控追踪时间表
- Agave 4.3 变更日志
- Agave 4.3 拉取请求
- Alpenglow 升级 - Solana Foundation
订阅 Helius
及时了解 Solana 开发的最新动态，并在我们发布新内容时收到更新