10 月 21 日 Solana 激活 Alpenglow 后，其交易计数以及整体每秒交易数（TPS）随之下降。Solana 基金会的升级文档称这一降幅是"会计口径变化，而非吞吐量倒退"。这一说法仍留给所有查看 Solana 图表的人一个问题：究竟是真實活动减少了，还是只有计数减少了？答案超出升级当日本身，因为 TPS 是区块链报道中被引用最多的吞吐量指标之一，而 Solana 在 10 月 21 日之后的计数采用与此前所有已发布数据不同的统计口径。

Alpenglow 从交易列表中移除了什么

在 TowerBFT——Solana 运行至 10 月 21 日的共识系统——之下，验证者以普通交易的形式提交投票。区块在支付、兑换及其他应用流量之外还承载了数百笔此类交易，任何交易总数统计都包含了这些投票流量。由于这些投票来自验证者而非用户，升级前每一份 TPS 数据中都有相当部分反映的是网络的共识机制，而非对其应用的需求。

Alpenglow 用 Votor 取代了这一机制。在 Votor 协议中，验证者直接交换投票并将其打包成证书。这些证书存放在每个区块的尾部而非交易列表中，因此交易计数器从切换那一刻起便不再看到投票流量。

交接区块显示了什么

Coindoo 通过 Solana 的公共主网 RPC（节点暴露的链数据读取接口）及其 getBlock 方法，检查了切换两侧的区块。每个区块占据一个 slot，即约 400 毫秒的时间窗口。TowerBFT 在该 epoch 的前 5,000 个 slot 中运行，随后被 Alpenglow 取代。

最后一个 TowerBFT 区块于 10 月 21 日 13:54:00 UTC 落块，第一个 Alpeng 区块于 13:54:03 接续产生，中间的八个 slot 没有产出任何区块。最后一个 TowerBFT 区块中约五分之三的交易——共 649 笔——是验证者投票；一个区块之后，一笔也没有了。尽管如此，Alpenglow 区块仍是两者中更大的一个。仅凭一对区块无法判断网络活动是升是降；它展示的只是机制本身。衡量趋势需要数千个区块。

投票并非计数中唯一的噪音

失败交易是第二层噪音。通过读取每笔交易元数据中的 error 字段，Coindoo 发现首个 Alpenglow 区块的 1,701 笔交易中有 844 笔遭遇执行错误，成功的是 857 笔。失败交易仍会被收取手续费，也仍然存在于区块中，但没有完成任何支付或交易。"会计口径变化"的说法只覆盖投票这一层，因此即使剔除投票，计数仍需经过错误字段过滤，才能描述实际完成的工作量。

成功交易也并不等同于真实用户。一个自动化交易账户可以发送大量交易，而单笔交易也可能包含多条指令。统计交易实际完成的内容——例如已完成的兑换或代币转账——比任何原始交易总数更接近真实使用情况。

对比数据存放在哪里

Solana 的 getRecentPerformanceSamples 方法会针对每个样本报告交易总数、非投票交易数以及样本时长（秒）。将计数除以时长即可得到该窗口内的平均速率。

该方法最多返回 720 个约一分钟的样本，大致覆盖最近 12 小时。在交接超过半天之后发起的查询已无法回溯到 TowerBFT 时期，因此任何对比中升级前一侧的数据必须来自更早保存的样本或历史区块。

在切换前后以完全相同的方式应用以下三项过滤，才能使对比具有意义：

1. 剔除验证者投票。Alpenglow 在新的一侧已自动完成；旧的一侧需要手动处理。
2. 使用每笔交易的 error 字段剔除失败交易。API 的非投票计数仍包含这些交易。
3. 比较等长时间窗口：一分钟均值对一分钟均值，切勿拿仪表盘峰值对比每日总量。

读取投票的工具需要改造

投票交易的作用不只是推高 TPS。监控工具会从交易列表中读取 Vote 程序指令，以追踪哪些验证者在参与。在 Alpenglow 下这一输入消失了，基金会指引这些工具改读区块尾部的投票证书。仍读取旧数据源的追踪器会显示验证者"沉默"，而实际上他们仍在投票。

对于 Solana 的使用量数据，有用的数字要等到数天的成功非投票交易能够与覆盖相同时段的升级前存储数据进行对比之后才会出现。在那之前，任何跨越 10 月 21 日的整体 TPS 图表都混合了记账口径变化与真实使用量变化。

来源：Coindoo