错过 Agave 4.4.1 升级的 Solana 验证者会怎样？

Anza 给 Solana 节点运营者设定了截止到 epoch 1079 的期限，要求他们安装一个补丁，该补丁改变了网络统计交易加载的账户数据的方式。运行旧版本的机器可以保持在线，但仍会与公认的链脱节，这对赚取质押奖励的验证者和钱包依赖其获取最新数据的服务会产生不同的后果。

Anza 在 epoch 1079 之前警告验证者，运行旧软件的运营者在网络启用新规则时面临被落下的风险。所引用的兼容版本为 Agave 4.4.1 和 Firedancer v26.10.6。

Agave 功能门控跟踪器将相关变更确定为 loader-v3 ProgramData 账户的最小已加载数据大小。其版本下限表将测试网络使用的版本与计划用于主网的版本区分开来。阅读该时间表需要同时检查集群、功能和 epoch。

该截止期限也涵盖不投票的节点。这些机器可以为钱包和交易所提供余额、区块哈希和确认数据。其中一台机器出现问题，可能波及从未委托 SOL 或选择验证者的用户。

该变更的作用

Solana 程序可以使用账户来存放其可执行数据。当一笔交易需要加载程序时，网络会统计与该操作相关的数据。对程序数据账户施加最小值，会改变兼容软件在新规则下处理相关交易的方式。

功能门控的目的是协调参与者何时开始使用新规则。运营者可以提前安装某个版本，而实际的规则变更在约定的时间点生效。因此，一个版本可以在该功能于主网激活之前就支持它。

一旦门控激活，旧版本可能在交易或区块产生的状态上与升级后的软件产生分歧。验证者随后可能停止跟随网络其余部分所认可的链，即使服务器本身仍保持在线。这就是 Anza 关于被分叉出去的警告的实际含义。

节点背后的质押为何重要

一百个小型验证者和少数几个大型运营者未必代表相当数量的投票质押。对于网络的运行而言，相关的问题是有多少质押遵循兼容规则。跟踪器表示，主网次要版本下限的变更通常遵循质押采用阈值和等待期。该一般规则应与 epoch 1079 之前发出的具体警告区分开来。

采用情况检查应将版本信息与活跃质押配对，然后将这些数字与边界之后的投票参与情况进行比较。报告正确版本的节点可能仍在追赶或正经历单独的故障。反之，稳定的汇总数据可能掩盖较小运营者的问题，如果大部分质押仍在线并正常投票。

这一差异对委托者很重要。他们的体验取决于其质押被分配到的验证者，而不是大多数机器是否安装了该版本。如果验证者停止有效投票，错过的参与可能减少归属于该质押的奖励。相关证据将是受影响 epoch 的投票积分和奖励记录。

用户和交易所会注意到什么

发送 SOL 的用户关心的是转账是否被接受，以及是否达到预期的确认级别。这可以通过交易和网络数据来核查。声称多个运营者错过了更新，本身并不能证明确认变慢、网络停止或出现大范围中断。

交易所也可能在监控升级期间暂停充值或提现，即使链上转账仍在继续。其客户余额取决于其自身的基础设施和入账政策。因此，一笔已在链上出现的交易，可能在客户的交易所账户中仍处于待处理状态，直到该平台恢复正常处理。

有用的升级后对比会分别核查三件事。第一，区块是否继续被生产和确认？第二，质押投票的数量是否实际发生了变化？第三，是否有具名的交易所在边界前后暂停或恢复了转账？每个问题都需要不同的记录。

为什么升级截止时间也适用于基础设施

Anza 的 Agave 发布说明将 ProgramData 记账变更列为向后移植。 Firedancer 发布版本包含对同一功能的支持。当两个客户端在激活后处理同一笔交易时，它们必须就加载多少账户数据达成一致。在边界处，共享规则才是关键。

未质押的 RPC 节点可以为应用提供服务，而不向投票贡献质押。这使得钱包用户很容易遇到局部问题，即使投票验证者仍在继续生产区块。从滞后端点读取数据的应用可能显示旧状态或返回错误。将其响应与通过另一端点发出的相同请求进行对比，有助于确定中断发生在哪里。

Solana 的 10 月 Alpenglow 迁移为运营者如何为协调变更做准备提供了背景。那次迁移涉及共识协议。11 月的补丁涉及账户加载。两者都为运营者提供了一个需要验证的版本，但必须根据具体变更的规则来评估其影响。

是什么让截止时间不同于发布日期

Anza 于 11 月 5 日发布了 Agave 4.4.1。其随后向 运营者发出的警告称，该变更计划在 epoch 1079 生效，预计于 11 月 6 日 UTC 约 13:30 开始。版本号指明了运营者所需的软件，而 epoch 则指明了网络计划何时开始应用该规则。

epoch 边界取决于链的进度。警告中的时间为运营者提供了实际估计，但链向新 epoch 的过渡才是重要事件。运营者不能将更晚的本地时间或例行维护窗口视为时间表的延长。

发布版本可能包含尚未改变网络处理交易方式的代码。运营者先安装软件，然后网络在计划的时间点激活该功能。这一顺序让运营者能够做好准备，而节点不会立即对同一区块应用不同的规则。

即使对于已经迁移到 Agave 4.4.0 的运营者来说，这个窗口也很短。补丁号只改变了一位，但较早的版本缺乏新规则所需的支持。因此，最近安装并不能替代对确切构建版本的检查。

Firedancer 26.10.6 发布版本支持同一功能。运营者可以使用不同的客户端实现，但在现行规则下执行交易时，两者都需要计算相同的账户数据。

软件与激活之间的区别已经出现在 crypto.news 对 Alpenglow 测试网上线的报道中。Alpenglow 改变了共识，而 11 月的补丁涉及交易处理。在这两种情况下，构建版本可用与网络要求其行为是两个独立的里程碑。

ProgramData 在交易中的介入之处

一笔交易会列出其指令所需的账户。验证者会加载与这些账户关联的数据以执行指令。网络限制了单笔交易可以加载的账户数据量，从而为验证者在执行前或执行期间所执行的一类工作设定了上限。

Solana 的可升级加载器使用一个程序账户和一个单独的 ProgramData 账户。后者存储可执行程序数据以及加载器的相关信息。用户调用程序时无需手动考虑该可执行数据的大小。验证者的运行时会处理这一部分。

该补丁为加载 loader-v3 ProgramData 账户时计入其名下的数据量设定了一个下限。如果旧的计费方式计入的量低于该下限，新规则将至少按最低值计入交易的已加载数据限制。远低于该限制的交易在变更后会产生相同的结果。

差异在边界处才显现出来。一笔组合了多条指令或使用了多个程序的交易可能已经加载了大量账户数据。如果新的最低值使合计数量超过限制，那么即使指令相同、签名者相同，旧规则和新规则也可能产生不同的结果。

已加载数据限制与计算预算不同。计算衡量的是执行工作量。一笔交易可以拥有足够的计算量来执行指令，却仍然无法通过一项管辖其可加载哪些账户的限制。仅提高计算配额并不会改变计入已加载数据限制的数量。

该规则也不会改变应用程序已部署的指令。程序可以位于同一地址并拥有相同的代码，而验证者对其 ProgramData 账户的计费方式却不同。应用程序团队有理由重新检查接近限制的交易，即使他们自己并未进行任何部署。

两个节点如何会对同一个区块产生分歧

验证者执行交易以检查区块产生的状态。如果两个节点从相同的状态出发，并对其中一笔交易应用不同的规则，它们就可能得出不同的结果。除非差异得到解决，否则它们无法同时将同一结果状态视为有效。

这就解释了 Anza 关于旧节点会掉队的警告。一个旧节点可以保持在线并继续响应请求，却无法跟踪兼容验证者所接受的链。其进程处于运行状态，这一测试比它是否是最新的、是否与集群保持一致要弱得多。

运营者可以将节点报告的 slot 与一个独立参考进行比对。参与投票的验证者还必须检查其投票是否在被接受的链上被计入。错误日志可能会在重放区块时识别出问题，而这些问题在正常运行时间检查中是不可见的。

该警告描述的是不兼容所带来的后果。截止日期之后的评估仍然需要显示哪些运营者运行的是过时的构建版本，以及他们的节点发生了什么。在运营者恢复之后收集的版本快照可能会遗漏该验证者掉队的那段短暂时期。

激活日期与观察者注意到问题的时间点也可能不同。一条范围狭窄的规则只会影响触发它的交易。在边界之后紧接着的一段没有可见分歧的时期，并不能说明某个节点是否能够处理接近受影响限制的交易。

为什么验证者数量只能说明部分情况

一个参与投票的验证者的重要性部分取决于它所代表的质押量。少数大型运营者所代表的投票权重可能超过许多较小的运营者。因此，对受影响机器数量的统计所回答的问题，与继续参与的有效质押百分比所回答的问题并不相同。

未质押的节点有着不同的角色。它们可以为应用程序、交易所和钱包提供数据，或中继已签名的交易。一个热门服务的中断可能影响许多用户，即使该服务对共识不贡献任何质押。

相关指标可以各自独立变化。区块生产可以继续进行，而某个特定的 RPC 提供商却在提供过时的数据。验证者可以漏掉投票，而其面向公众的网站仍然可用。交易所可以暂停 Solana 存款，而链上仍在继续确认转账。

此前关于 Solana Alpenglow 截止日期的报道描述了一次需要验证者和应用程序协调准备的交接。那里的目标是更快的最终性。ProgramData 门槛的技术影响范围更窄，但运营者仍然必须根据自己在网络中的位置来判断是否准备就绪。

委托者可以从投票和奖励记录中确认什么

即使网络保持可用，委托者也有一个经济层面的问题。他们想知道代表自己赚取奖励的验证者是否持续参与。一次错过的补丁本身不会将委托的 SOL 移出质押账户，但投票中断可能会减少相关期间内获得的奖励。

首先要查看的是验证者的投票账户。比较边界前后各个 epoch 的投票信用，可以确定其参与情况是否发生了变化。奖励记录则提供了对特定质押账户所受影响的另一项核查。

较低的奖励本身并不能将升级认定为原因。佣金、验证者此前的表现以及质押账户的状态都可能影响记录的金额。如果有证据表明投票在边界处停止、并在客户端变更后恢复，那将比单次较低的奖励提供更有力的解释。

流动性质押代币又增加了一层。一个资金池可以将其质押分散到多个验证者。某个运营者的问题可能只构成资金池奖励变化的一部分，具体取决于其委托份额以及资金池的记账方式。

交易所质押增加了一种服务关系。交易所可能运营自己的验证者，也可能使用其他提供商，然后按照其条款为客户入账。用户需要交易所的记录，才能将链上投票的变化与记入个人账户的奖励联系起来。

过期的 RPC 端点会对钱包造成什么影响

许多钱包通过 RPC 端点获取余额、区块哈希和交易结果。落后的节点可能会报告先前的余额，或无法返回最近的交易。即使用户遇到这些症状，其他节点也可能正在正常处理网络。

区块哈希可以在网络执行交易之前影响该交易。获取到过时区块哈希的钱包可能构造出一笔交易，而当其到达健康节点时该交易已不再有效。症状是提交失败，但原因可能是过时的信息，而不是余额或指令发生了变化。

模拟依赖于同样的关系。运行旧规则的节点可能报告某笔交易符合已加载数据限制，而执行新规则的节点却得出不同结果。如果状态在模拟与打包之间发生变化，那么在兼容节点上的模拟仍可能与最终执行结果不同。

在单一端点后部署多个节点的应用面临另一种可能性。请求可能因接收它们的机器不同而成功或失败。提供商必须检查整个节点池是否为最新状态，然后才能将间歇性问题归因于链本身。

对独立端点进行比较有助于区分这些问题。如果多个当前端点结果一致而某一服务不同，则该差异可能仅存在于该服务本地。如果独立观察者也报告区块生产或确认发生了变化，则有更强证据表明存在网络问题。

十月的共识过渡有其自身的基础设施变化。Crypto.news 报道称，Alpenglow 移除了此前的链上投票交易。应用团队必须将他们所观察到的变化与验证者能否遵循新系统区分开来。十一月的账户加载规则再次使答案取决于观察者的角色。

为什么交易所入账可能滞后于链上

交易所只有在其系统识别到转账并应用其确认政策后，才能为存款入账。因此，一笔成功的链上交易并不能决定客户在交易所内部余额何时发生变化。

交易场所可能在更新基础设施时暂停存款或取款。它也可能在其存款队列等待健康节点确认的同时，继续在链上接收转账。交易场所的公告和区块浏览器可能都是准确的，即使一个显示服务中断，另一个显示转账成功。

对于取款，延迟可能发生在交易所签署或广播交易之前。在此期间没有链上记录，几乎不能说明一旦提交，网络是否会接受该交易。交易场所的处理状态说明了时间线中的这一部分。

一份关于多家交易所暂停运营的报告仍然需要指明哪些服务受到影响以及每家给出的原因。例行维护通知或由另一问题引起的队列可能与升级落在同一时间窗口内。这种巧合是比较记录的理由，而不是衡量网络参与度的标准。

什么能表明运营者是否错过了补丁

Anza 功能门跟踪器将最低发布底线与各个激活分开。crypto.news 此前关于Alpenglow 推出和主网底线的报道描述了同样的区别。一个构建可以在某一时点满足底线，却缺少计划在稍后 epoch 生效的更改。

最有用的激活后记录会在同一窗口内比较活跃功能、软件分布和运营者参与情况。功能记录标识规则何时开始适用。软件记录标识哪些构建正在服务中。投票和区块显示网络和各个运营者的行为是否有所不同。

跳过的槽位是一种可能的观察。它们也可能因与补丁无关的原因而增加，包括被分配领导的验证者的普通性能表现。比较多个窗口并将跳过与各自的领导者匹配，可以为观察提供背景。

失职质押提供了不同的视角。当一个大型验证者停止参与时，该金额可能变动，即使失职节点的总数几乎没有变化。比较需要考虑到升级前已经失职的运营者。

RPC 和交易所的影响必须单独记录。这些提供商可以在不出现在质押比较中的情况下为大量用户提供服务。它们的公告、服务指标以及节点何时恢复到当前槽位的记录，将描述投票数据无法捕捉的中断。

为什么分阶段推出仍然需要激活测试

稳定的客户端版本可以在新功能激活前逐步部署。这让运营者看到软件是否正确启动、追赶并按照当前规则处理交易。它还有助于在更多节点使用之前揭示部署问题。

激活前成功的推出无法检验活跃功能的每一个后果。接近已加载账户数据限制的交易需要在两套规则下测试，以准确显示结果在哪里发生变化。这与观察二进制文件是否保持在线是不同的测试。

Crypto.news 此前报道称，Alpenglow 针对最终性采取了不同的方法。其成功标准包括确认速度发生了什么变化。ProgramData 补丁更好的评判标准是客户端是否对遇到新限制的交易达成一致，以及门开启后基础设施是否保持可用。

回滚在激活时也会改变含义。在边界之前，较旧的受支持版本可能仍会处理已经生效的规则。在边界之后，返回到缺少该功能的构建可能会带回运营者试图解决的完全相同的兼容性问题。回退必须保留对活跃门的支持。

拥有闲置容量的运营者可以启动一个已打补丁的节点并在分配流量之前进行验证。较小的运营者可能不得不重启其唯一节点并等待其追赶。截止时间是共享的，但用户等待的时间可能取决于提供商的冗余程度。

为什么 SOL 的价格无法衡量升级的影响

SOL 可能在运营者安装补丁的同一时段内下跌或上涨。它与其他加密资产一样，与许多相同的货币和资金池进行交易。利率、比特币的走势和杠杆变化可能在同一窗口内影响价格。

如果技术问题中断了转账或使应用程序不可用，那么它就可能对交易产生影响。支持这一解释的证据包括交易场所的公告、存款或取款的变化，或与相关账户关联的链上执行数据。仅凭代币价格无法识别这一渠道。

单笔交易失败也与失去对账户的控制不同。钱包可能使用旧信息构建了交易，或通过过时的节点提交了交易。即使用户仍能控制账户，应用程序也可能难以连接到当前网络。

因此，截止日期之后最直接的检验是在服务层面进行的。投票节点应当处于最新状态并记录投票。RPC 服务应当能够响应来自被接受链的请求。交易所应当能够说明其是否处理了在切换前后提交的转账以及处理的时间。

即使价格因无关原因发生变动，这些证据也能支持评估。它还为委托者提供了一种评估自身验证者表现的方法，而无需将网络范围的版本要求视为对每个运营者结果的陈述。

运营者重新上线时会发生什么

安装修补后的软件只是恢复节点的一步。随后，运营者需要观察该进程是否追上被接受的链，并在当前规则下跟随它。服务器可以成功重启，同时仍在重放区块或返回落后于链尖的数据。

投票节点还需要表明其参与已经恢复。其运营者可以将当前投票与节点恢复的时间进行比较。之后阅读奖励数据的委托者便可以将恢复时间点与补丁安装时间区分开来。

服务提供商可以将已修补的节点从轮换中移除，直到它追上进度并通过检查。运营者可以将槽位、近期交易的结果以及模拟的结果与单独的参考进行比较。如果提供商在这些检查之前就让节点恢复流量，就可能使软件升级看起来已经完成，而客户仍然遇到旧数据。

在评估影响时，时间线很重要。一个发生分叉并在同一 epoch 内恢复的节点，在之后的目录中可能看起来是健康的。但其错过的参与对运营者或委托者仍然可能有影响。公开的事件时间线需要足够详细，以显示服务何时停止以及正常活动何时恢复。

应用程序团队还可以检查仅通过特定后端失败的交易。如果通过当前节点重新提交后问题得到解决且指令没有变化，那么先前的端点就成为可能的故障来源。如果同一笔交易在当前节点上持续失败，且接近账户数据限制，那么交易本身可能需要重建。

这种重建可能涉及减少交易加载的数据，或在应用程序能够容忍多笔交易的情况下拆分指令。拆分交易可能会改变其保证，因为原本应当一起成功或失败的指令可能不再如此。因此，这一变更属于应用程序自身的设计，与其账户加载要求并列。

对用户的影响取决于不兼容发生在何处。运营者可能错过参与，RPC 可能返回过时信息，应用程序可能构建出不再适合的交易。前两者可以通过恢复兼容的基础设施来解决，而第三者则取决于交易和当前生效的规则。

对 Solana 恢复情况的检查应当将这些观察结果分开。它应当比较运营者的投票记录、提供商的服务记录以及受影响应用程序的执行结果。这样做使得即使网络在整个过程中持续出块，也有可能识别出范围有限的影响。

11 月的截止日期为运营者提供了一个具名版本和一个 epoch 边界。其影响的持久记录将来自节点在该边界前后的行为以及它们在此之后能够提供的服务。

关注要点

• 兼容版本：Anza 的时间安排和发布说明可以确立主网底线及其在各客户端中的对应版本。
• 投票参与度：活跃质押和投票积分可以显示投票参与度在边界前后是否发生变化。
• 网络确认：区块和确认记录可以显示网络在变更前后是否继续处理交易。
• 交易所运营：交易场所公告可以确立某交易所是否暂停了其自身的 Solana 充值或提现。

常见问题