Alpenglow上线:Solana(SOL)验证人在第459,653,000个槽切换共识

epoch 1064开启Alpenglow

Solana (SOL)的验证人及其区块索引服务在本周消化了一次共识层面的变更:这条区块链已在epoch 1064激活Alpenglow协议。该epoch于10月21日13:36(UTC)开始,网络先沿用了约5,000个槽的旧有TowerBFT最终性,随后在第459,653,000个槽切换到新共识。Solana基金会的迁移指引把这次切换界定为验证人对交易排序与最终状态达成一致方式的改变,并将最终性目标定在约150毫秒,而旧机制下这一数字约为12.8秒。需要强调的是,150毫秒是目标值而非实测值:激活之后主网的早期最终性实测为6.6秒,目标尚未达成。围绕这次激活,基金会10月22日发布的开发者更新日志列出了一批验证人与开发者所用软件的版本:10月15日发布的Agave v4.3.2、10月21日发布的Firedancer主网客户端v26.10.4,以及10月19日发布的Web3.js v3.1.1,同时还有针对地址查找表和权益质押、系统与代币程序的SDK更新。日志记录显示Firedancer参与了新共识,但仅凭发布日期无法判断哪个客户端率先运行,因为Firedancer的发布与激活恰在同一天。基金会的表述很明确:迁移发生时,Firedancer与Frankendancer并不支持迁移本身,这意味着通过切换期的验证人运行的都是基于Agave的客户端。本次调整的范围刻意收窄:程序执行、交易格式与费用系统均未变动。对于在关注Solana价格与网络基本面的读者来说,这一边界很关键,因为改动只涉及验证方式,不涉及代币经济。

投票交易退出区块

机械层面的变化直接落在统计与索引区块数据的人身上。验证人的投票交易不再出现在区块中,过去标注为已确认与已最终化的两种状态现在描述同一个状态,历史证明(Proof of History)的tick条目也从数据流中移除。凡是汇总区块交易数量或直接索引数据流的开发者,都必须重新核对自己的处理基线,因为包含投票交易的指标在切换前后无法在同一口径下比较。这轮变化贯穿Solana技术栈的每一层,从客户端到工具链。Firedancer v26.10.4的发布说明写明了修复内容:Agave与Firedancer之间曾导致流量与处理负载虚高的gossip表不一致问题已修正,落后节点的恢复算法也做了调整。Agave的更新日志则仍列着进行中的工作:为减少文件系统输入输出中的缺页中断所做的缓冲调优、按质押权重处理gossip、降低对账户质押列表依赖的快照加载,以及在上传前过滤不受支持的sBPF程序版本的命令行检查。基金会的指引还给运营方定了一条硬性余额规则:每个投票账户,即与验证人质押绑定的账户,必须在最低豁免余额之上持有0.8枚Solana (SOL),这笔金额对应基金会使用的验证人准入票据,差额会导致该验证人在下一个epoch被移出投票与出块。代价有多大,Solflare已有先例:其Solana验证人转为失联时质押量达156万枚SOL。Web3.js v3.1.1补丁是10月6日v3版本的后续,此前那版要求存量应用修改异步代码;本次补丁的更新日志讨论了仅支持Transaction V1的前提,这一前提建立在另一项限制旧格式与V0格式的SIMD提案之上,而该废弃进程并未完成。我们此前对槽位裁剪后外部买入占比的核查显示活动持平,为53%对52%;正在配置客户端账户的运营者可参考如何在Solflare上质押SOL了解设置步骤。

索引方仍停留在旧基线

把各份发布说明放在一起看,这一轮工作可以分成三类:已交付、进行中和提案阶段讨论。最显眼的未完成项就是最终性数字本身:实测6.6秒,对照150毫秒的目标。尚未跟上的环节是索引与分析层,仪表盘若仍按旧口径比较切换前后的交易数量,就会误读链上活跃度,除非重新建立基线。这些变化对交易者而言没有方向性指引,它处在Solana技术分析所追踪的支撑与阻力位之外。此外,由于限制旧交易格式的SIMD提案尚未正式提交,旧格式与V0格式目前仍然有效。