数据揭秘：Solana转账变慢，竟是验证者在“搞事情”？

作者：Carlos 、 Luke Leasure

原标题：Solana’s block-building wars

编译及整理：BitpushNews

2026年1月5日，JITO 推出了一款名为 IBRL Explorer 的公共工具，旨在衡量 Solana 上验证者的区块打包行为，并揭露区块构建中以往不可见的 “时机博弈”。

首先，我们需要了解一些关于 Solana 市场结构的背景。Solana 被设计为一个流式处理系统：在理想情况下，当区块正在构建时，领导者会持续不断地传播数据碎片（即小型数据包）。这种行为旨在最小化 交易落地延迟（即验证者接收到一笔交易到该交易被处理之间的时间间隔）。然而，Solana 的交易流水线是否真正连续，实际上取决于验证者们如何组装他们的区块。

Jito 从验证者角度定义了最优的区块打包行为：快速构建、连续流式传输、及早传播状态。Jito 的 IBRL 分数是这三个变量的加权混合：

• Slot 时间（35%）：如果验证者的区块在以下阈值内构建完成，则得分较高：从另一个验证者接手的交接 slot 小于 550 毫秒，或作为连续 slot（即领导者在轮值中剩余的任一 slot）则小于 380 毫秒。
• 非投票交易打包（40%）：当交易均匀分布在 slot 的 64 个 tick 中时（而非将大部分非投票交易塞入 slot 的最后几个 tick，即“延迟打包”），验证者会获得分数奖励。这是 IBRL 分数中最具争议的变量，后文会详细解释。
• 及早投票（25%）：当至少 90% 的投票交易在前 32 个 tick 内被处理时，验证者获得满分。如果投票被推后到区块更晚的部分，分数会递减。

IBRL Explorer 显示，许多验证者存在非投票交易延迟打包的情况，在某些情况下甚至延长了 slot 时间。延迟打包会推迟状态传播，增加执行结果的方差，破坏 Solana 的流式设计，从而降低网络延迟。你得到的不是持续的数据流，而是一次突发性的数据喷发。

在一个最优区块中，如下面来自 Helius 验证者的示例，大多数投票交易在区块的前半部分被处理（“及早传播状态”），而非投票交易则在 slot 的 64 个 tick 中相对均匀地分布（“连续流式传输”）。

相比之下，有意的延迟打包在下图 Galaxy 的示例区块中很明显，大部分非投票交易被塞入了 slot 的最后几个 tick。这样做，验证者通过将状态转换延迟到最后一刻，优先考虑了提取性价值，而非网络健康。

据 Jito Labs 联合创始人兼首席执行官 Lucas Bruder 称，验证者被激励等到 slot 的最后时刻，以观察更多传入的交易，选择支付最高费用的交易，从而最大化奖励。

但用户为什么要在乎呢？虽然对单个验证者来说，最大化利润是理性的行为，但这种行为会引入隐性的审查、延迟状态传播，并迫使下一个领导者去“追赶”，从而拖慢整个网络。

更重要的是，延迟打包也与 Solana 新兴的“订单流支付”（PFOF）动态直接相关，Benedict Brady 在此文中已概述过。因为钱包和应用程序通常会生成预先路由的已签名交易（即带有滑点限制的市价单），所以订单中嵌入了有价值的“后置运行”期权。对用户有利的做法是将此后置运行权卖给交易公司，而提取性的做法则是进行“三明治攻击”。无论哪种方式，都有动机通过减慢交易落地速度来增加后置运行的价值，这正是延迟打包所能实现的。

这种激励将 Solana 推向了对应用程序和用户更为对抗的市场结构。它还削弱了做市商所依赖的关键保证，特别是区块内取消和确定性执行方面的保证，从而导致买卖价差扩大。没有流式传输，无论应用逻辑多么优秀，真正的实时市场对 Solana 来说仍然遥不可及。

Temporal 与 Jito 的辩论

在深入探讨 Solana 如何解决此问题之前，必须承认，关于什么是“良好”的区块构建甚至存在着一场积极的辩论。Harmonic 的核心贡献者 Temporal 对 Jito 的框架和 IBRL 评分方法提出了异议。他们的批评是，该分数嵌入了一套特定的设计偏好，这些偏好有利于 Jito 的区块构建方式，并默认使 Harmonic 看起来更差，这反映在运行 Harmonic 的验证者持续获得较低的分数上。

据 Harmonic 联合创始人称，Harmonic 的区块是连续执行而无延迟的，但数据碎片只在约 300 毫秒的拍卖完成后才释放。这种方法给了区块构建者足够的竞争时间，也给了网络其他部分足够的时间来重放 Harmonic 的区块。下面的可视化图展示了来自运行 Harmonic 的验证者 Temporal Emerald 的同一个 slot (391,822,619)。

从区块如何传播的上下文来看（上图），Harmonic 的执行看起来是均匀间隔的。换句话说，区块构建者通过并行区块构建持续构建区块，而交易之所以只集中在最后的 tick 中（下图），是因为那是拍卖决议的时刻。

在过去 30 天里，Harmonic 在每区块平均和中位数总收入（优先费 + 小费）方面都优于 Jito 和 Firedancer，从而为验证者和质押者带来了更高的奖励。悬而未决的问题是，这种优越表现是否是通过上文所述的时机博弈，以牺牲用户利益为代价实现的。

来源：https://reports.firedancer.io/

多并发提议者（MCP）与 BAM

在阐述双方观点后，有一点仍然成立：连续流式传输至关重要。

Harmonic 的主张并非认为流式传输不重要，而是认为 IBRL 未能捕捉 Harmonic 如何实现它，并可能将其拍卖机制错误分类为“时机博弈”。在现阶段，我尚未掌握足够的技术背景或数据来形成明确观点，但 Solana 已经在开发一项旨在解决底层激励问题的协议内解决方案。

该解决方案是 多并发提议者，由 Anatoly Yakovenko 和 Max Resnick 开发的架构。动机很简单：在当今的单领导者模型下，一个提议者控制排序，并且实际上可以比其他人更晚行动，从而实现了延迟打包并强化了上述 PFOF 式的动态。MCP 通过让多个提议者并行独立地构建候选区块，消除了单领导者的垄断。这种架构可以防止单个领导者单方面压制交易或延迟执行以提取利润。

也就是说，MCP 的一个先决条件是 Alpenglow 在主网上线。Alpenglow 预计在 2026 年推出，但时间表仍不确定。与此同时，Jito 的 BAM 可能通过使排序逻辑可审计来推动改变。BAM 旨在扩展 Solana 的微结构设计空间，使需要更精细控制排序的应用程序（例如，优先处理永续合约交易场所的取消订单）成为可能，同时有助于减轻负面的 MEV 外部效应，如前置交易。下图概述了 BAM 的交易流水线。

BAM（Agave-BAM）目前已是 Solana 上按质押份额计算的第三大客户端（约 12%），仅次于 Agave-Jito 和 Frankendancer-Jito。大约已有 205 个验证者在运行 BAM，这突显了其在 Solana 验证者群体中的快速采用。相比之下，Harmonic 的规模仍然相对较小，仅占有略高于 3% 的质押份额和大约 20 个验证者。

值得关注未来几个月区块构建的竞争动态将如何演变，以及这对 Solana 的市场结构意味着什么。