Solana 更快最终性已上线，用户会感受到哪些变化？

Solana 自 10 月 21 日起已在主网上运行 Alpenglow，用一个旨在以几分之一秒完成最终确认的系统，取代了原先可能需要数秒才能最终确认区块的投票系统。Solana 基金会在 epoch 1064 记录了这次切换，此前 654 个验证者中有 446 个认证了一个创世区块。

发送 SOL 的用户可能会看到一笔支付几乎立刻出现，并想知道这次升级改善了什么。钱包可以在网络将交易最终确认之前就显示该交易已被处理。Alpenglow 缩短了等待更强保证的时间，但应用仍然必须提交支付、从节点收到回执，并决定何时更改自己的显示。交易所可能会在记入账户前再施加一段等待。

基金会的升级记录称，交易格式、程序和费用均未改变。只提交支付并读取账户余额的开发者无需新的交易格式。处理区块流的开发者则有更多工作，因为从提议区块到达成一致区块的路径不同了。现在实际的问题是，哪些服务会将这种更快的最终确认传递给客户，哪些则继续使用其旧的确认时间表。

切换已经发生，但 150 毫秒只是一个目标

Alpenglow 于 10 月 21 日取代了 Solana 旧的共识流程 TowerBFT。在旧系统中，验证者将投票交易上链，一个区块在后续 slot 中收集到足够投票后才会成为最终确认。Votor 是 Alpenglow 已上线的部分，它在验证者之间直接传递投票，并将其合并为证书。一个区块可以在一到两轮投票中完成最终确认。

基金会以 12.8 秒作为旧最终确认时间的参考，并以约 150 毫秒作为新目标。这些数字描述的是一种协议层面的比较，而不是在同一钱包、相同条件下进行的两次测量。10 月 21 日的准备报告警告称，未质押的 RPC 节点获知最终确认的时间可能晚于参与投票的验证者，有时会在另一个区块产生之后才获知。互联网延迟和应用所选择的节点也会增加用户所见的时间。

10 月 23 日发布的一项外部测量显示，在其此前 24 小时内，最终确认时间中位数为 404 毫秒，第 90 百分位为 579 毫秒，第 99 百分位为 765 毫秒。其早先的参考值在 TowerBFT 下约为七秒。按这些数字计算，中位数改善了约 17 倍，计算方法是用七秒除以 0.404 秒。其方法论和观测点与基金会的 12.8 秒基线和 150 毫秒设计目标不同。

基金会的实时仪表盘显示不断变化的最新观测最终确认读数以及多个时间窗口内的趋势。最新值不应被提升为典型的客户体验。有用的序列包括中位数和尾部延迟、中断情况，以及不同提供商报告同一最终确认区块所需的时间。单个特别快的 slot 只能证明协议曾达到过该速度一次；它几乎不能说明商家在繁忙时段的支付情况。

在激活之前，目标与测量之间的区别是验证者就绪问题的核心。此后主网已经提供了一份证书和数日可测量的区块。有一个问题已经得到解答：验证者确实协调完成了切换。典型的 RPC 客户是否能看到接近所宣传目标的表现，现在则是另一个问题，因为基金会和外部监测机构从不同的时间点开始计时。同时报告这两个数字及其各自的起始点，可以让读者比较实际性能，而不会把较慢的观测结果当作共识设计失败的证据。

Solana 的出块速度通过另一个项目在十月得到了提升，该项目将目标出块时间从 400 毫秒缩短至 200 毫秒。该措施涉及的是领导者出块的频率。最终性涉及的是网络何时达成一致，认定某个特定区块在其规则下不可逆转。更快的出块时间和更快的最终性都能帮助用户，但这两个数字不应相加，也不应被视为同一个时钟。

所宣传的数字取决于哪些参与者能及时收到提议的区块并进行投票。一条快速路径可以迅速认证一个区块，而一条备用路径则容纳较慢的通信。一轮较慢的回合本身并不意味着升级失败：当某个验证者错过一条消息，或某个领导者的提案与另一个提案竞争时，共识仍然必须达成一致。中位数可以大幅改善，而少数出块时间则会更长。处理大额转账的服务会像关注头条目标一样关注慢速尾部。

公共观察者应当询问最终性计时器从何处开始。从验证者收到提议区块时开始计时，排除了钱包广播其交易的时间。从商家点击“收费”时开始计时，包含了人工操作和多个软件系统。从 RPC 服务器看到证书时开始计时，包含了验证者与服务器之间的延迟。每个时钟回答的是不同的问题。10 月 23 日的外部测量之所以有用，是因为其方法和分布可以与基金会的设计声明分开审视。

钱包不止一个时钟

想象一下用 Solana 钱包买一杯咖啡。用户首先在本地批准一笔交易。钱包通过 RPC 服务将其发送出去，网络将其纳入一个候选区块，验证者对该区块进行认证。商家的系统收到状态更新，并决定是否交出咖啡。Alpenglow 改变的是认证阶段，而不是打开钱包所需的时间或商家自身的政策。

许多应用在 TowerBFT 最终性之前就已经显示成功消息。它们使用的是较弱的最终性承诺级别，因为大多数零售支付在更改屏幕之前并不等待最强的共识保证。更快的最终化状态可以让应用以接近其先前早期状态的速度提供更强的保证。只有当服务更新其等待规则并且其提供商及时交付结果时，这一改进才会显现。

交易所存款说明了这一限制。一笔转账可以在 Solana 上最终确定，而交易所仍在检查发送方、将地址与账户关联、进行风险筛查并应用内部入账政策。链上新的最终性时间无法强制交易所立即释放余额。跨链桥需要消息中继、目标链执行，并且通常还有自己的保障措施。因此，跨两个系统的结算仍然比仅源链的最终性更慢。

九月的测试网说明在发布前就阐明了这一区别。它描述的是一个全新的投票流程，而不是一种签署普通支付的新方式。现在有了主网记录可供核查。提供商可以比较客户端提交交易的时间、验证者认证交易的时间以及其 API 报告最终性的时间。如果没有这些独立的时间戳，关于 150 毫秒用户支付的声明就会掩盖那些未被测量的部分。

“即时”一词在营销中仍将充满诱惑。站在柜台前的顾客关心的是商家在转身离开之前是否获得了可信的接受确认，这是一种端到端的服务衡量。交易者关心的是交易场所是否在下一个市场机会之前更新了余额。即使钱包从未显示明确的最终性状态，两者都可能受益。但不应向任何一方承诺每一次交互都能在 150 毫秒内完成。

销售点运营商做出两个独立的决定。它选择何时一笔支付足够安全以释放商品，以及选择如何处理中断的连接。快速的共识证书改善了第一个决定，但并不会使离线终端收到响应。处理器可以发送临时的成功消息并在之后进行对账，或者等待最终化状态。在结账时真正重要的是实际政策，包括重复提交和延迟响应在屏幕上如何呈现。

金融应用还有其他理由将速度与策略区分开来。借贷应用可能在处理转账时记录抵押品，但只有在最终确定后才允许借款。中心化交易场所可能关注已最终确定的余额，同时实施自己的提现冻结。跨链桥除了要处理 Solana 的风险外，还必须处理接收链的风险。更快的证书为缩短每个工作流中依赖链的部分创造了机会。公布服务时间的前后对比将显示提供商在哪些地方利用了该机会。

图表上更少的交易可能意味着相同的使用量

在 TowerBFT 下，验证者投票是链上交易流的一部分。Alpenglow 的验证者直接通信，并将认证信息放入区块页脚，因此这些投票交易不再出现在普通区块交易计数中。一个显示每秒所有交易的仪表盘在切换后可能会下降，而用户进行的转账、兑换或支付并没有减少。

Solana 联合创始人 Anatoly Yakovenko 在激活前不久讨论了投票交易的移除，当时对头条 TPS 的更改正引起关注。分析人士在比较 10 月 20 日与 10 月 21 日之后的流量时，应隔离双方的 非投票交易。否则，一项会计变更看起来就像是需求流失。反向的错误则是声称投票流量的降低本身创造了同等数量的额外有用用户交易；闲置容量和实际使用是不同的东西。

无需发明新的吞吐量估算即可核对算术。如果升级前的计数将用户交易 U 和验证者投票 V 合并，其总数为 U + V。在投票离开区块后，类似的图表可能大致显示 U，即使用户提交的转账数量相同。差值 V 是图表所计内容的变化。计算实际增长需要可比较的仅用户序列，而不是前后的头条总数。

这对费用和收入评论也很重要。投票交易费用消失，而验证者改为支付验证者入场券。用户交易费用机制保持不变。与失去的投票类别相关的总费用收入变化不能简单地呈现为消费者交易意愿的变化。仔细的比较会将投票相关费用、入场费和用户为发送或优先处理自己交易而支付的费用区分开来。

区块浏览器和数据供应商面临相关任务。曾经从投票程序指令中读取的参与信息现在必须从证书和页脚数据中读取。继续解析旧字段的供应商可能会显示缺失的验证者投票，即使网络正在正常最终确定区块。Solana 文档警告说，一些流式接口尚未转发证书元数据的每一项，这使得提供商文档成为任何严肃性能比较的一部分。

每秒交易图表在协议变更期间很脆弱，因为它通常聚合不同类别。一个声称激活后用户活动立即下降的交易场所需要在两个日期都提供仅用户计数，最好细分为成功转账、兑换和失败尝试。交易不是唯一的人或已完成的购买。机器人可以生成许多指令，而不成功的指令仍可能出现在已提交交易序列中。验证者投票的减少本身并不能说明商家接受 Solana 的情况。

这一区别对网络经济也很重要。投票费用的消失减少了验证者的一种链上支付。入场券按不同时间表从另一个账户销毁。用户费用取决于客户提交的内容及其支付的优先级。将这三者合并为单一收入趋势会掩盖需求是否变化或会计是否转移。10 月 21 日前后一致的类别为解读费用图表提供了更可靠的基础。

数据服务必须跟随获胜区块

快速的投票决定并不会使每个提议的区块都成为赢家。Solana 更新后的数据流可能会为一个槽位暴露多个候选 bank，而 Agave 4.3 用 bank_id 标记事件，以便客户端将候选分开。将所有数据按槽位编号分组的索引器可能会意外地将竞争候选的交易混入一个从未以那种形式存在的区块记录中。

基金会指示流式消费者按槽位和 bank 标识符对进行缓冲，并保留达到确认的 bank。如果他们合并来自不同提供商的馈送，标识符仅在每个连接内有意义；区块哈希是跨提供商的参考。在 Agave 4.4 中预计会出现一些更频繁的多 bank 行为，因此在它变得普遍之前有时间调整，但处理当前区块流的应用现在就应该做好准备。

大多数钱包用户永远不会看到银行标识符。一个投资组合应用或交易所如果从有故障的数据源重建存款，可能会过早显示一笔付款、漏掉一笔付款，或将一笔转账附加到错误的区块候选上。一个对早期流事件做出反应交易系统必须知道这些事件是否属于最终区块。协议可以快速最终确定，而索引器的错误仍会延迟或扭曲人们看到的内容。

基金会的主网迁移说明称，已确认和已最终确定的承诺级别现在描述的是同一状态，尽管前者目前仍然可用，并将在后续版本中移除。建议开发者将新工作指向已最终确定，并审查针对旧等待时间调整的超时或重试设置。一个习惯性等待12秒的服务，尽管链快得多，可能仍然很慢。

数据流还有其他变化。历史证明不再以同样的方式为区块生产定节奏，因此tick条目离开shred流。读取Clock时间戳的程序可能会看到与以前不同的来源。这些细节并不是用户交易格式已改变的迹象。它们是围绕旧账本时序构建的软件在网络的新速度到达屏幕之前可能需要工作的地方。

对于索引器来说，问题不仅仅是一个新字段名。它可能通过两个连接收到同一个slot，并按到达顺序处理交易。如果数据流携带来自竞争bank的事件，而其数据库仅按slot键控记录，后来的记录可能会覆盖先前的记录或创建不可能的混合。迁移指南中的slot-and-bank键在单个数据流内防止了这种情况；最终获胜的区块哈希协调了各提供者。客户只有在余额或交易历史变得更可靠时才会注意到这项工作。

重试逻辑值得再看一眼。每秒轮询一次的客户端可能会错过几百毫秒共识改进的大部分好处。另一个客户端可能会再次提交同一笔付款，因为回复在其超时后到达。设计良好的客户端会区分慢响应和未处理的交易，并在重试之间保留标识符。运营者需要在承诺固定结账时间之前，用新的承诺流测试这些行为。

验证者有一笔新的经常性账单

移除链上投票交易改变了验证者成本。Solana基金会表示，投票此前每epoch花费约1 SOL的交易费，从验证者的身份账户支付。新的验证者入场券每epoch从其投票账户销毁0.8 SOL，此外还有免租金最低额。在一个epoch开始时购买的入场券允许验证者在下一个epoch参与。

未能将足够的SOL保留在正确账户中的验证者无法在下一个epoch投票或出块，并失去在那里赚取奖励的机会。将金额发送到旧身份账户不会支付新费用。运营者可以将区块收入路由到投票账户，尽管基金会表示该变更需要两个epoch，且佣金收入在某个边界可能不足。

大约1 SOL与0.8 SOL之间的比较并不是普遍净节省。收入、质押、软件成本、佣金以及每笔费用的时间因验证者而异。可靠的事实是哪个账户支付、固定入场费是多少，以及如果错过会发生什么。长期集中度将取决于较小的运营者能否在保持竞争力的同时维持运营和财务要求。

启动需要Agave 4.3.2或兼容的Jito-Solana或Harmonic Salsa客户端。根据基金会的运营者页面，Firedancer和Frankendancer不支持迁移。Alpenglow的激活证明了网络可以与参与的验证者一起切换；它并未表明每个替代验证者客户端都为同一天做好了准备。客户端多样性仍然是一个单独的韧性问�题。

治理批准在迁移之前到来。早先的推出计划描述了测试期间Agave 4.2中的代码，但仅安装从来不是主网切换。创世证书和slot 459,653,000处的共识启动是激活的证据。第一份证书的446个签名者代表了一个具体的协调事件，而不是关于之后每小时所有654个验证者的出席或性能的承诺。

固定入场券按规模以不同方式改变验证者经济。大型运营者和小型运营者支付相同的0.8 SOL入场费，因此该费用占小型运营者总奖励的比例更大。它是否会赶走任何人取决于委托质押、佣金、运营成本和其他收入。运营者指南确立了支付机制；它并未预测会有多少验证者离开。一个有用的后续工作将比较多个epoch中的活跃独立运营者和质押集中度。

即使对于健康的运行状态，账户切换也可能造成本可避免的中断。票据会提前从投票账户中支出，而运营者此前在发送投票时是从身份账户中支付旧的投票费用。一个总体上拥有足够 SOL、但在各账户之间分配不当的验证者可能会错过准入。正常运行时间报告应将这一迁移问题与新投票协议中的故障区分开来。它们是各自独立的运营故障，需要不同的补救措施。

此次升级解决的问题比支付应用所解决的问题更窄

Solana 对 Alpenglow 的论证很有说服力：如果最终性能够大幅提前到来，需要不可逆结算的服务就可以不再等待数秒的不确定性。10 月 23 日的外部测量结果支持主网上出现了实质性改进，尽管其中位数 404 毫秒慢于设计目标。商户和交易所可以选择依赖这一更强、更快的状态。

服务仍可能保留一个缓冲。它可能使用多个 RPC 提供商、要求进行反欺诈筛查，或仅在其自身账本核对存款后才向客户入账。一笔低价值支付可以在已处理状态下放行，使得 Alpenglow 在其当前界面中几乎不可见。一笔大额转账可能使用已最终确定状态，从而获得数秒的收益。此次升级并不会使谨慎的服务变得不理性；它为服务提供了一个更快的网络信号，供其纳入决策。

第一个可衡量的变化可能是确认背后承诺的可靠性，而不是钱包中壮观的动画。已经看到快速确认的用户未必知道该确认是否可逆。提供商现在可以决定是否在同一时间窗口内展示或要求更强的最终性。公布从客户批准到商户接受的时间，将比仅宣传共识数字更清晰地解决面向用户的主张。

Alpenglow 的第二部分 Rotor 仍计划在后续版本中发布，尚无激活日期。Votor 改变了投票和最终性；区块分发仍使用旧的 Turbine 方法。这个包名称可能给人一种印象，即所有提议的组件是一同到来的。基金会的当前状态表清楚地说明了这种分离。在当前主网数据中将任何性能提升归因于 Rotor 都会弄错时间顺序。

当数据在网络中不均衡地传输时，区块分发仍然具有相关性。更快的投票无法帮助验证者认证一个它尚未收到的提案。计划中的 Rotor 组件将处理与 Votor 证书不同的阶段。目前，缓慢的观测结果可能反映传播、投票、公共 RPC 交付或其中多项共同作用。记录每个阶段将告诉运营者其下一步改进应属于验证者软件、数据分发还是客户基础设施。

初始发布只是一个短暂的性能样本。客户端版本、提供商迁移工作和验证者出席情况决定了当前条件。后续版本可能会改变外部服务获知证书的一致性，即使没有另一次共识切换。跨多个独立 RPC 提供商、包括高峰时段在内的连续一周观测，对商户而言将比单次快速演示更有价值。

仍有待衡量的内容

没有任何单一的最终性数字能够涵盖每个用户的等待时间。验证者证书、公共 RPC 观测、钱包状态和交易所入账时间衡量的是不同的步骤。基金会仪表板提供实时网络读数，而外部监测器则从自己的节点进行观测。跨多种方法和提供商在数天内达成一致，将显示这些快速结果能否在发布周之后持续，以及缓慢尾部出现的频率。

主网记录已经比测试网承诺更加强有力。Alpenglow 已激活，投票交易已离开区块，开发者已发布集成变更。现在就将更多应用用户、更高的代币价格或每次结账的特定改进归功于共识升级还为时过早。此类主张需要交易队列、服务前后测量以及可比较的仅用户数据。

对于钱包或支付服务提供商而言，接下来的决定是具体的：及时使用最终确定的信号，在用户看到时发布，并保留其产品所需的额外检查。这条链已经改变了一个步骤。当围绕它的软件改变其余旅程时，人们会注意到。

值得关注的事项

• 观测到的最终性：比较基金会仪表盘和独立节点上的滚动中位数和最慢百分位读数，并说明观测点。
• 钱包和交易所时间：测量从客户批准到可见确认或入账余额的间隔，而不仅仅是验证者证书。
• 可比流量：追踪10月21日前后非投票用户交易，以免被移除的投票交易扭曲趋势。
• 流式传输错误：检查RPC和索引器提供商是否支持银行感知的区块重建和及时的最终确定状态。
• 验证者准入：随着每个epoch重复收取0.8 SOL费用，关注投票账户资金、活跃验证者和支持的客户端多样性。

常见问题