IBRL Explorer 简介：衡量验证器模块构建质量

Solana 区块内部的运作机制首次不再是谜。基于 Solana 的公开数据， IBRL.wtf 揭示了验证器区块的构建过程，展现了其时间模式和打包策略，使社区能够以前所未有的方式了解区块打包行为，而这些行为此前从未被公开测量过。

定义最佳 IBRL 性能

“增加带宽，减少延迟”已成为 Solana 的一个强有力的口号，使生态系统参与者朝着同一个目标努力：使 Solana 成为速度最快、吞吐量最高的执行环境。

从验证者的角度来看，我们将最优 IBRL 行为定义为： 快速构建、持续传输数据并尽早传播状态。 因此，最优 IBRL 分数的要求如下：

• 按目标时间构建： 按目标时间构建模块并最大限度地减少时隙内抖动
• 流式执行： 将事务处理分布到整个时隙，而不是集中加载到末尾。
• 尽早投票： 尽早处理和转发选票，以减少确认延迟。

问题：块打包计时游戏

我们在九月份开始研究验证节点区块构建时，预期只会发现个别次优打包的情况。但我们发现，Solana 的大部分验证节点都将交易集中在其时隙的末尾，我们称之为“延迟打包”。我们也注意到投票交易中存在同样的计时问题，这会延迟网络上交易者和用户的确认时间。

Solana 被构建为一个流式系统。验证者需要在整个时隙内打包交易，并通过 Turbine 以碎片形式广播区块数据，以便网络能够立即重建和重放。当打包操作在末尾加载时，该管道就不再像流一样运行；即使时隙按时完成，状态更新也会延迟传播。

为什么延迟打包有害

• 延迟状态传播： 网络在最后阶段才突然了解状态变化，而不是持续地了解，导致应用程序和交易员在大部分时间里都只能使用过时的信息。
• 增加执行波动： 可预测的执行需要可预测的区块构建。延迟打包会引入时间抖动，从而降低清算和拍卖等对时间敏感的操作的可靠性。
• 削弱 Turbine： Solana 的状态传播协议针对连续流进行了优化。延迟打包意味着有用的数据碎片会集中突发到达，从而降低核心网络的效率。

此前，这种行为一直未被发现。虽然 Geyser 中存在相关数据，但尚无公开工具能够对其进行量化或采取行动。IBRL.wtf 通过逐笔交易打包的方式揭示了这些模式，首次使验证器区块构建行为透明化。

老虎机计时游戏

虽然延迟打包问题鲜为人知，但槽位时间问题在验证者社区中却更为人所知。Solana 的默认槽位时间为 360 毫秒，一些验证者修改了其历史证明参数，将槽位时间延长至默认值之外，从而获得更多时间来收集和打包交易。

延迟造成服务器卡顿的危害在于：

• 减缓状态转换速度： 区块到达时间较晚，因此网络状态更新也较晚。这会增加下游所有用户的延迟。
• 增加端到端延迟： 超过目标时隙时间会加剧整个网络的延迟，影响后续验证者和用户体验。
• 降低确定性： 持续的槽时间偏差会增加抖动和方差，使依赖时间的应用程序的执行变得难以预测。
• 降低应用程序可靠性： 报价、交易、清算和拍卖等对时间敏感的流程，在交易时段不一致时，其可预测性会降低。

IBRL 探测器

IBRL 浏览器的第一版侧重于展示深入的块打包指标，衡量 IBRL 最优行为，并基于内部方法提供客观的评分标准。目前的 IBRL 综合评分基于两个关键指标：

1. 槽位时间： 验证器生成区块所需的时间。
2. 交易打包： 验证器如何将交易打包到区块中

如需深入了解方法论，请参阅本文的 附录 。

IBRL 浏览器的后续版本将包含更多信息，并考虑其他指标来生成 IBRL 分数。

现实世界的影响和新出现的模式

自内部推出 IBRL.wtf 以来，该工具已被证明对 Solana 网络的性能调优和瓶颈发现至关重要。通过持续监控，我们发现了一些有趣的现象，并不断扩展我们收集和分析的数据。

虽然有些验证者会故意延迟打包投票，但我们观察到一些意想不到的模式，揭示了更广泛的网络问题。过去一个月，东京、新加坡和其他亚洲地区的多个数据中心出现了一种新趋势：非故意延迟打包投票。虽然我们尚未找到根本原因，但我们认为这与影响区域连接的海底电缆系统故障有关。这种趋势体现在受影响的验证者的投票打包得分中，但遗憾的是，这完全超出了他们的控制范围。我们强调这一点是为了说明，并非所有低分都代表故意行为，有些低分反映了单个验证者无法解决的基础设施挑战。

我们还发现，延迟打包非投票交易会产生连锁反应：与在整个时隙内打包交易的验证者相比，延迟打包交易的验证者会持续增加集群的投票延迟。当验证者延迟打包交易时，它们会在其时隙末尾集中发送区块数据碎片（即区块数据的片段）。其他验证者会延迟收到这些碎片，并且必须重放所有交易才能对区块进行投票。由于重放操作发生较晚，它通常会延续到下一个时隙的时间窗口。这意味着验证者最终的投票时间会比预期晚，这并非由于它们自身的处理延迟，而是因为它们在等待区块生产者延迟到达的数据。

最后想说的话

IBRL.wtf 的存在是为了使验证者的行为可衡量、透明和可审计。它旨在为验证者、质押者和应用程序提供一个共享的真实数据源，以前所未有的详细程度展现区块生产层实际发生的情况。

目前的 IBRL 评分版本为 v1 。我们正在积极迭代评分方法和数据，任何单一评分都不应被视为对验证者意图或质量的最终判断。部分评分可能反映出验证者无法控制的基础设施限制或网络状况。随着我们纳入更多数据，并根据实际观察和社区反馈不断完善评分模型，评分将会持续改进。

如果您是验证者、应用程序开发者或 Solana 社区成员，并且有反馈意见（或希望在网站上看到的数据），请通过 Jito Developers Discord 或发送电子邮件至 [email protected] 与我们联系。

附录：IBRL 评分方法

IBRL 评分由三个独立的部分组成，分别衡量区块生产行为的不同方面。

• 老虎机时间得分
• 选票打包得分
• 非投票打包得分

每个组成部分都根据其对 IBRL 整体性能的相对影响进行加权，同时保持各组成部分贡献的合理平衡。

IBRL 评分的计算公式如下：

IBRL 得分 = (0.40 * 非投票打包得分) + (0.35 * 时段得分) + (0.25 * 投票打包得分)

老虎机时间得分

该分数衡量区块生成速度。阈值的设定取决于该区块是否为来自其他验证者的交接区块，或者是否为领导者轮换中的剩余区块。

• 切换槽位： 构建时间不超过 550 毫秒即可获得满分
• 续期时隙： 验证器有 380 毫秒的时间来完成完美得分

如果未达到阈值，随着模块构建时间的增加，分数将呈指数级衰减至 0。

选票打包得分

该评分衡量投票交易处理的及时性。

• 当至少 90% 的投票交易在前 32 个历史证明周期内得到处理时，该区块即可获得满分。
• 如果未达到此阈值，则随着投票处理在区块中被推迟，得分会逐渐下降。

非投票打包得分

该分数衡量的是整个区块内事务处理的公平性，而不是延迟打包或突发事务处理。

该分数由两个贡献相同的子因素构成：

1. 早期计算阈值： 我们预期在前 32 个历史验证周期内，至少 50% 的区块总计算单元会被使用。随着该百分比的下降，该因子呈指数级下降。
2. 计算分布的 基尼系数 ：衡量计算资源在槽位 64 个历史证明周期内的分布情况。如果每个周期消耗的计算资源量相同，则基尼系数为 0。随着计算资源的聚集和局部化，基尼系数上升，因子下降，导致非投票打包得分降低。

#sol #IBRL