Alpenglow 正在 Solana 的测试网络中运行,而主网仍然依赖其现有的共识机制。拟议的切换将改变验证者如何就一个区块是最终确认达成一致。150 毫秒的目标是在特定条件下的性能声明,而不是承诺每个用户的支付都能在这段时间内完成清算。
摘要
- 在 Anza 的验证者时间表中,SIMD-0326 仍被列为待主网激活。
- 跟踪器将 Alpenglow 列为 Agave 4.3.0,主网版本下限较低,为 4.2.2。
- 初始提案引入了 Votor 共识,但保留了 Turbine 数据传播。
- Alpenglow 的提案描述了一个 20% 对抗性加 20% 无响应权益的模型。
- 9 月 28 日的功能激活窗口本身并未安排 Alpenglow 的主网切换。
Solana 最具影响力的共识变更正在通过一系列验证者测试推进。Anza 的 功能门控跟踪器 将 SIMD-0326(即 Alpenglow)列在待主网激活项中。它记录了测试网和开发网的激活位置,并指出 Agave 4.3.0 是与该功能相关的软件版本。同一快照中显示的主网版本下限为 4.2.2,而 4.3.0 被列为下一个预期下限。计划中的版本下限和实际运行的共识功能是不同的里程碑。
此前的 测试网报道 描述了向更广泛验证者测试的转变。后来的 开发网报道 提到了两个测试网络,而主网继续使用其当前共识。这就是评判任何承诺的速度提升所依据的状态。
9月28日是一个日历陷阱
一个日程条目称主网功能激活将于 9 月 28 日恢复。它并没有说 Alpenglow 本身会在那天切换。跟踪器单独将 Alpenglow 列为待定。将恢复功能门控队列的日期视为计划中的协议切换,把流程标记变成了错误的截止日期。9 月 29 日的 更正 追溯了这种混淆,并表示 Anza 已否认所声称的启动日期。
这种区别至关重要。验证者可以采纳包含休眠代码的软件版本,而不激活该功能。在权益阈值和纪元通过后,版本下限可能会提高。一个单独的功能门控可以启用新行为。在仪表板上看到版本号变化的用户,并不因此就看到更快的最终性协议上线。
正确的新闻切入点在于,在广泛传播的日期之后,测试和激活过程仍然开放。最终的主网窗口需要明确的日程、运营者准备以及公开测试的证据。这些步骤都不会被一条将升级描述为即将到来的社交帖子所取代。
Votor 改变投票,而 Rotor 仍在等待
SIMD-0326 提案 将初始举措主要围绕 Votor 这一新共识机制定义。它明确将拟议的数据传播替代方案 Rotor 留作单独变更,并最初保留现有的 Turbine 传播。对完整 Alpenglow 堆栈的营销描述可能会模糊这一范围。
共识回答的是,当足够多的验证者就一个区块达成一致,根据协议应将其视为最终确认。数据传播回答的是,该区块如何到达这些验证者。执行回答的是,交易是否成功运行。应用程序还会等待其 RPC 提供商报告结果。更快的投票无法消除该路径中的所有其他延迟。
150毫秒这一数字最好被理解为在有利网络条件下、在共识层测量的最终性目标。它并不是用户端到端结账的时间——用户的钱包必须签名、提交、到达领导者、被打包进区块、执行并通过RPC服务返回。一个有用的公开基准测试应当明确其起点和终点。从区块提议时启动的秒表,与客户按下发送时启动的秒表,两者不可相提并论。
该提案用一种不同的安全性与活性权衡取代了原有的投票安排。它描述了一种20加20模型,在既定假设下可以容忍一个对抗性份额和一个单独的不响应份额。作者明确指出,单轮投票无法达到两轮设计所能实现的33%拜占庭阈值。这一承认应当与速度声明并列,而不是放在脚注里。
双列表测试可防止误导性基准
第一列应从验证者视角测量协议最终性:从区块被提议到最终性证书的经过时间,包括慢速结果的分布。第二列应测量用户确认的交易:从提交到执行、打包、最终性和RPC响应。这两列之间的差异,正是共识头条数字所没有衡量的工作。
假设一项测试报告提议后最终性为150毫秒,但交易打包要等待一个350毫秒的时隙,RPC交付又要再花100毫秒。在这些示例性假设下,客户至少会看到600毫秒,还不包括签名或重试。计算方式是350加150加100。这些是假设性时间,并非Alpenglow在生产环境中的测量值。它们说明了为什么亚秒级共识数字不一定等同于亚秒级支付体验。
中位延迟可能掩盖运营者最关心的情况。一个验证者如果受困于糟糕的网络路由、临时分区、投票缺失或繁重的重放工作,可能会看到长尾。交易所和支付提供商通常会针对罕见的恶劣情况制定最终性策略,而不仅仅是基准中位数。一次可信的推出应当公布百分位结果、恢复行为以及领导者失败的后果。
时隙时间提案是另一个变量。它寻求从400毫秒目标分阶段降低到200毫秒。时隙间隔和最终性相关但不同;声称每个更短的时隙都证明Votor有效,是把两项升级混为一谈。早前的验证者测试账户在这次更广泛推出之前跟踪了协议测试。
验证者必须测试失败情况
网络的顺利路径是产生快速数字最容易的环境。主网候选方案必须经受住验证者迟到加入、跨区域消息延迟、软件重启、领导者失败以及链视图冲突。Alpenglow迁移提案处理从旧投票状态到新投票状态的交接。一个正确的稳态协议仍可能因糟糕的过渡而暴露问题。
测试应显示集群在分区恢复后是否达成一致且唯一的最终决定,如果有相当份额的质押离线,它能多快恢复,以及运行不同兼容版本的节点是否报告相同结果。测试网很有价值,因为拥有不同基础设施的验证者会遇到受控实验室可能遗漏的情况。它无法精确复现实时网络的经济激励和流量。
客户端组合很重要。在观察到的快照中,Anza的跟踪器将Firedancer和Frankendancer标记为不支持Alpenglow行。这是特定时间表中的兼容性状态,而不是对任一客户端的永久性声明。生产迁移必须考虑运行每种实现的质押,或说明这些运营者需要改变什么。
验证者激励也是测试的一部分。运行新的投票协议可能会改变带宽、硬件需求和参与成本。如果较小的运营者因为无法满足要求而退出,更快的网络最终可能拥有更少的独立参与者。激活后的实际运营者数量和质押分布将检验这一权衡。
快速证书和慢速证书服务于不同的条件
该协议并不依赖于一条总是在150毫秒内完成的路径。SIMD-0326定义了快速最终性,即当代表80%权益的验证者在一轮中对一个区块进行公证时。其较慢的路径依赖于两轮,涉及60%的权益,并且需要公证和最终性证书。领导者可能无法及时交付有效区块,在这种情况下,验证者可以投票跳过该时隙。该设计包括跳过时隙的证书和回退路径。仅测量80%快速路径的标题基准将恰好遗漏那些使最终性有价值的情况。
这种区别可以付诸实际测试。对于一天中每个提议的时隙,统计使用快速证书最终化的份额、使用较慢路径的份额以及跳过的份额。为每个类别分别给出中位数以及第95和第99百分位数。快速中位数很有用,但运营者需要知道网络离开快速路径的频率以及随后恢复需要多长时间。一个每天处理数千笔收据的支付服务可能会经历长尾事件,即使该事件对于单笔转账来说很罕见。
证书是权益加权共识的紧凑、可验证记录。它不是由固定数量机器进行的投票。十个小型验证者不能仅仅通过数量优势来替代一个代表大量权益的验证者。因此,报告验证者数量而不报告权益分布会错误地描述安全测试。正确的数字是每轮参与的权益、离线的权益以及不同意的权益。这些数字需要时间戳,因为权益分配和运营者可用性会变化。
该提案指出,直接最终化的区块也决定了其祖先:其链中的先前区块变为最终化,被省略的时隙被视为跳过。这意味着仪表板可以显示在缓慢期后最终性成组到达。将这些祖先的表观完成时间平均成一个有吸引力的数字的测量方法,将难以与经历了暂停的用户进行比较。测试应保留每个区块的原始提议时间和证书观察时间。
协议作者并未声称与每个竞争设计具有相同的对抗性阈值。他们的20加20框架接受了拜占庭故障和无响应权益之间的不同平衡,以换取更短的正常路径。这种权衡是否可接受是一项治理判断,需依据威胁建模和性能证据,而不是由单一最快案例演示所决定。SIMD-0326中异常坦率的安全部分使得可以在不归因于任何一方动机的情况下报告这种权衡。
切换共识需要一个共享的起始区块
迁移文档解决了一个速度图表无法显示的问题。在切换后,新旧共识不能安全地作为独立历史运行。验证者必须就最终的旧区块达成一致,该区块成为第一个Alpenglow区块的父区块。文档将那个共享点称为Alpenglow创世区块。如果运营者对其意见不一,他们随后的最终性证书将指向不兼容的历史。
提议的交接在功能激活时隙之后开始,但用于迁移的边界位于5000个时隙之后。额外的间隔旨在避免一个epoch的开始。然后该过程等待一个满足强乐观确认条件的区块,其投票在提案指定的模式中代表至少82%的权益。验证者为共同祖先区块签署创世投票。82%的创世证书为他们提供了切换的证据。这些阈值的算术是迁移设计的一部分,与切换后Votor的80%快速最终性路径分开。
收到创世证书的验证者根据相关epoch的BLS密钥验证其签名并广播。然后该计划从所选区块初始化Votor,并停止后续时隙的TowerBFT。它回滚所选创世点之后的区块,并在处理新区块之前重置相关状态。文档认为这种回滚是安全的,因为用户交易未打包到那些临时区块中。这一主张值得在实际集群上进行测试;这不是应用运营者仅从最终性标题就能验证的事情。
节点在交接期间可能离线。文档描述了返回的验证者如何从快照中学习创世证书,或在观察到有效的Alpenglow最终性证书后赶上。这是发布工程与共识理论相遇的地方。如果迟到的节点错误地解释了过渡,即使大多数集群继续运行,它也可能呈现过时或不一致的数据。交易所和RPC提供商应演练重启和快照恢复场景,而不仅仅是观察初始切换成功。
存在明确的活性成本。迁移提案指出,交接可能会中断进度,乐观估计为边界之外的一个时隙。一个时隙的预期并非最大服务级别保证。激活后的公开事后分析应说明跳过了多少个时隙、用户交易打包是否暂停,以及外部服务恢复正常确认报告用了多长时间。快速的稳态无法让过渡间隔从用户体验中消失。
这就是为什么主网日期不能从通用的软件日历中推断出来。安全的切换需要兼容的 BLS 密钥注册、已采用的功能门控、共享的起始区块、证书分发、回滚行为以及对滞后节点的恢复。这些是运营者可观察到的任务。迁移规范为他们提供了一份清单,而实际的网络演练将显示这份清单是否足够。
验证者成本可能改变参与者的构成
此次升级既有经济设计,也有延迟目标。在当前的投票机制下,运营者发送投票交易并支付相关费用。SIMD-0326 提出了一种验证者入场券,即 VAT,用以替代这种费用模式。该文件给出了初步估算,约为每天 0.8 SOL,或每个 epoch 1.6 SOL,并表示全部付款将被销毁。这一数字是提案中的初始参数,而非针对每个验证者的实时账单。
固定的入场成本可以简化一项开支,但对委托质押较少的小型运营者来说负担更重。大型验证者和小型验证者获得的奖励并不相同。问题在于,在计入节省的投票费用、硬件成本、带宽和 VAT 之后,它们的净经济效益是否有所改善。提案称运营者在迁移后应看到资源使用量降低。这是一种预期效果,而非在实时验证者集合中测得的结果。
有用的前后对比应跟踪同一批运营者经历整个升级过程。对于每个质押区间,比较切换前的每日投票费用与切换后的 VAT 及运营成本。统计停止产生投票或离开活跃集合的独立运营者所占比例。如果离开的验证者质押量微不足道,机器数量的下降本身并不能证明去中心化程度受损,但它会是一个需要调查的警示信号。质押集中度和地理多样性将提供必要的背景信息。
提案称,资金不足的验证者将被移出活跃集合。这使得入场券余额管理成为一个正常运行时间问题。运营者需要在资金耗尽前收到警报,委托者需要了解如果他们选择的验证者变为非活跃状态会发生什么。实验室中可行的共识协议与日复一日运行的网络之间的区别,包括平凡的账户资金管理。此前关于 Solana 验证者治理的报道描述了正式决策路径;实施后的持续参与则是一项单独的考验。
生产环境的问题不仅仅是 150 毫秒是否可实现。而是足够广泛的验证者集合能否在不出现未报告的成本上升或运营脆弱性的情况下实现这一性能。更快的最终性与更窄的运营者基础,将与提案的完整承诺产生不同的结果。延迟和参与度都需要在切换前取得基线。
交易可以已最终确定,而服务仍然滞后
交易所存款说明了链上最终性与用户可用余额之间的差距。首先,客户提交一笔签名交易。转账到达领导者并被包含在一个区块中。验证者投票并形成最终性证书。RPC 服务观察到该证书并报告它。交易所的存款监控器识别地址和资产,执行其策略检查,并将款项记入账户。共识变更主要缩短了该序列中的一个间隔。
交易所可能出于自身选择而等待更长时间。它可能对大额存款要求额外检查,在多个 RPC 提供商之间比对结果,或在事件期间延迟入账。这并不意味着链未能实现其最终性目标。这意味着链的基准不能宣传为客户保证的入账时间。公平的产品声明应区分区块最终性、RPC 可见性和机构自身的入账决定。
反向的错误也有可能发生。一个应用可能在其 RPC 节点看到区块后立即显示待处理的成功状态,而此时最终性证书尚未到达。用户可能会看到一个快速的绿色对勾,尽管协议最强的保证稍后才到来。在迁移期间,一个继续以相同方式标记其升级前承诺状态的应用,应当针对新的语义进行测试。一个视觉上未变的钱包界面可能掩盖了已经改变的风险模型。
对于去中心化应用而言,最终区块并不保证一笔有利的交易。一笔交易可能执行后因应用规则而失败、支付费用,或以用户在其提交参数中未预料到的价格成交。共识最终性意味着账本已经决定了该结果。它并不证明智能合约是安全的,也不证明预言机输入是正确的。该升级应因其旨在改进的更窄属性而受到肯定。
为了使这一主张可被证伪,基础设施提供商可以针对一批样本交易发布成对的时间戳:到达其服务的时间、首次被纳入的时间、观察到证书的时间、RPC 响应时间以及客户可见的入账时间。它们应当披露缺失的观测和重试。在相似负载和费用条件下比较激活前后的这些时间间隔,将显示 Alpenglow 实际上缩短了整个旅程的多少。这将是比重复白皮书目标更强的证据。
最有力的论据是对结算的真实改进
支持者可以提出一个实质性的论点。Solana 当前的确认路径长期以来在快速出块与更强最终性之间留下了差距。如果 Votor 能可靠地缩小这一差距,交易所可以更早地为存款入账,交易者可以在执行后减少不确定性,支付提供商可以以更少的等待完成结算。该协议提案是一项严肃的工程设计,验证者已经在主网之外花费时间对其进行测试。
此前的治理报道记录了该提案背后的验证者决定。验证者治理路径也意味着这一变更不仅仅是一家公司的承诺。运营者必须采用软件并参与激活。分阶段的功能门控为网络提供了在生产环境之前暴露问题的机会。这些优势并不能证明最终的服务水平,但它们使测试阶段变得至关重要。
反对方的论点是作者自己披露的一种权衡:更快的投票设计伴随着不同的故障假设。运营者还必须管理迁移和客户端兼容性。在平静的测试集群上获得的 150 毫秒中位数,无法回答当有意义的质押离线或网络链路不稳定时协议会如何表现。这就是为什么证据应当出现在故障案例报告中,而不仅仅是速度演示中。
主网就绪有若干道相互独立的关卡
第一道是软件采用:足够多的质押运行兼容版本。第二道是测试网和开发网上的协议验证:投票和证书在正常和不利条件下都保持正确。第三道是运营准备:交易所、RPC 提供商、区块浏览器和钱包知道如何观察新的最终性信号。第四道是计划中的功能激活本身。
Anza 的追踪器表明,在 95% 的质押采用新的次要版本并经过两个完整 epoch 后,主网版本下限可以提高。该规则管理的是最低支持版本;不应被转述为在 95% 时自动激活 Alpenglow。独立的功能行仍然是查看实际待处理变更的地方。
没有任何已报告的测试能够确立 SOL 价格必须以某种特定方式作出反应。代币价格在部署前就纳入了宏观条件、资金、供应、应用需求以及对升级的预期。此前的激活展望涵盖了为什么共识里程碑具有相关性,而不将其定义为价格催化剂。
公开证据仍然缺少什么
一份带有日期的最终激活计划,以及一组可比的、在不同负载下进行的最终性测量公开数据,将使读者能够判断该网络距离其宣传的承诺还有多近。测试结果应明确说明软件版本、参与的质押量、客户端类型、消息条件、交易包含情况和百分位延迟。仅有一个最佳情况下的最终化时间是不完整的。
最具决定性的报告将在切换之后出现:对主网最终性和应用可见结算的反复观察,以及对任何恢复事件的披露。在此之前,验证者测试表明所提议的系统正在被演练。它并不能证明每个用户都将体验到150毫秒的结算。
值得关注的内容
- 功能门控:Anza明确的Alpenglow主网状态和激活槽位,区别于一般的版本下限日期。
- 质押采用:运行支持该功能的版本的验证者质押占比。
- 客户端兼容性:当前跟踪器行中列为不支持的验证者实现的更新。
- 故障测试:在分区、重启和投票缺失情况下公布的恢复和长尾延迟。
- 用户计时:从提交到最终性和RPC通知的主网测量,而不仅仅是证书时间。
常见问题
Alpenglow已在Solana主网上线了吗?
为本专题查阅的Anza跟踪器将SIMD-0326列为待主网激活。测试网和开发网活动并非主网激活。
Alpenglow是在9月28日启动的吗?
没有经过验证的Alpenglow主网启动源自一般的9月28日功能激活窗口。其自身的功能门控仍然是一个单独的待处理事项。
什么是Votor?
Votor是初始Alpenglow提案中的新共识投票组件。它旨在改变验证者最终确定区块的方式。
Rotor包含在初始切换中吗?
SIMD-0326表示,初始范围将Rotor对数据传播的替换留待另一项单独提案。该网络起初保留Turbine。
150毫秒意味着每笔支付都能那么快完成吗?
不是。共识最终性目标不包括签名、提交、等待包含、执行以及从RPC提供商处收到回复所花费的一些时间。
20加20模型是什么意思?
该提案描述了在涉及对抗性质押和单独无响应质押的假设下的韧性。它明确讨论了与两轮协议不同的拜占庭权衡。
什么是版本下限?
它是集群上支持的最低软件版本。提高它可以为某项功能准备好节点,而不会自动激活该功能。
什么能证明性能声明?
可重复的主网数据,显示在真实流量下具有快速最终性和可接受的尾部行为,并定义了起点和终点。这是教育性分析,不是投资建议。






