Jito Explorer：解读 Solana 上的 Bundle、Tip 与验证者数据

Jito Explorer 实际展示的内容

Jito Explorer 是一个 Web 仪表盘，聚合 Solana 主网上 Jito bundle 的数据。Bundle 是搜索者提交给 Jito 区块引擎的一组有序交易，最多包含五笔交易；该 bundle 要么在一个 slot 中原子性地落地，要么完全不落地。浏览器以图表和表格而非原始交易日志的形式呈现这些活动。

你会遇到的主要视图包括：可选时间窗口（周、月、年）内 bundle 和 tip 总量的概览、最近和最大 tip 的 bundle 表格、每个 slot 的 bundle 统计（包括已落地计算单元百分比和区块 tip）、按签名者排列的最大 bundle 排名，以及配套工具，如费用统计视图、搜索者扫描和实时 tip 底价流。每个视图回答不同的问题，混淆它们是混淆的最常见来源。

本文关注的是解读与复现，而非仪表盘的视觉设计。如果你只需要一个 Solana RPC 端点来运行下面的查询，具体提供商的选择由 RPC Assistant 单独处理；这里的方法论与提供商无关。

• 概览图表：bundle 数量和 tip 总量随时间的变化趋势。
• Bundle 表格：最近和最大 tip 的 bundle，包含资产、打赏者、验证者和 tip 金额。
• Slot 统计：每个 slot 的已落地计算单元、区块 tip 和 bundle 数量。
• 签名者排名：哪些地址在产生最大的 bundle。
• 配套工具：费用统计、搜索者扫描和流式 tip 底价。

假设与前提条件

以下流程假设你有一个 Solana 主网 RPC 端点，支持标准 JSON-RPC 方法，如 getSlot、getBlock、getTransaction 和 getSignaturesForAddress。Jito 特定数据不是 Solana RPC 的原生命名空间；bundle 元数据由 Jito 基础设施生成，并通过 Jito 自己的 API 和仪表盘暴露。你的 RPC 提供链上事实（哪些交易落地、在哪个 slot、使用了多少计算量），而 Jito 界面提供 bundle 级别的上下文。

你还需要一种运行小脚本的方式：用 curl 做快速探测，用 Node.js 或 Python 处理任何需要遍历 slot 的任务。将占位符 RPC_URL 以及（如果你提交 bundle）PRIVATE_KEY 保存在环境变量中，而不是源文件里。本指南中读取数据不需要主网 SOL，但提交 bundle 需要。

心智模型：Bundle、Tip 与 Slot

普通 Solana 交易本身是原子的：其所有指令一起成功或失败。不同交易之间不是原子的，因此需要两个依赖操作都落地的搜索者没有原生保证。Jito bundle 通过让搜索者提交一个有序交易列表来解决这个问题，区块引擎将该列表作为一个单元转发给启用了 Jito 的验证者。如果 bundle 无法在 slot 内按顺序执行，则全部不落地。

经济杠杆是 tip。Bundle 包含一笔向 Jito tip 账户的转账，验证者有动力包含 tip 更高的 bundle。因此 tip 底价是 bundle 包含的实时市场价格，并随拥堵情况变化。Jito Explorer 的 tip 底价视图流式展示该价格的百分位数；bundle 表格显示实际落地 bundle 的实现 tip。

Slot 是比较的单位。每个 bundle 要么在特定 slot 落地，要么被丢弃。这就是为什么浏览器的每 slot 图表（已落地计算单元、区块 tip、bundle 数量）是最具分析价值的视图：它让你看到 bundle 消耗了区块计算预算的多少，以及区块通过 tip 赚取了多少。

正确解读 Bundle 表格

最近和最大 tip 表格列出 bundle，包含截断的签名、涉及的资产、打赏者地址、落地该 bundle 的验证者、以 SOL 计的 tip 金额以及相对时间戳。有两点需要注意。首先，“最大 tip”是实现 tip 的排名，而非盈利能力的排名；大 tip 对搜索者来说仍可能是亏损交易。其次，资产列反映 bundle 内的代币流动，这对于发现套利模式很有用，但并不代表意图。

当你将表格中的 bundle 与链上数据比较时，请使用完整签名，而不是截断形式。浏览器的截断哈希是显示上的便利；下面的 RPC 方法需要完整的 base58 签名。

用 curl 复现 Slot 级别的 Bundle 指标

对你在浏览器中看到的 slot 进行事实核查的最快方法是拉取区块并检查其交易和计算使用量。以下探测返回当前 slot，然后返回你选择的 slot 处的区块。将 RPC_URL 和 SLOT 替换为你的端点和浏览器每 slot 图表中的 slot 编号。

响应包括每笔交易的签名、消耗的计算单元和费用。对区块中所有交易的计算单元求和，即可得到与浏览器图表相同的已落地计算量，你可以将签名与 bundle 表格交叉引用。

curl -s RPC_URL -X POST -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBlock",
  "params": [
    SLOT,
    {
      "encoding": "json",
      "transactionDetails": "full",
      "rewards": false,
      "maxSupportedTransactionVersion": 0
    }
  ]
}'

一个可运行的 Bundle 活动聚合脚本

对于单个 slot 之外的任何任务，请编写循环脚本。下面的 Node.js 示例遍历一系列 slot，获取每个区块，并打印每个 slot 的交易数量和总计算单元。它仅使用标准 JSON-RPC，因此适用于任何 Solana 主网端点。设置 RPC_URL 并调整 START_SLOT 和 END_SLOT 为你想要研究的窗口。

输出是一个可以粘贴到电子表格的表格。将其与同一窗口的浏览器每 slot 图表比较；如果形状出现分歧，最可能的原因是你的窗口包含被跳过的 slot，这些 slot 从 getBlock 返回 null，应单独计数，而不是视为零活动区块。

const RPC_URL = process.env.RPC_URL;
const START_SLOT = 0; // set to your start slot
const END_SLOT = 0;   // set to your end slot

async function rpc(method, params) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
  });
  const json = await res.json();
  if (json.error) throw new Error(JSON.stringify(json.error));
  return json.result;
}

async function main() {
  for (let slot = START_SLOT; slot <= END_SLOT; slot++) {
    const block = await rpc('getBlock', [
      slot,
      { encoding: 'json', transactionDetails: 'full', rewards: false, maxSupportedTransactionVersion: 0 }
    ]);
    if (!block) {
      console.log(`${slot}\tskipped`);
      continue;
    }
    const txs = block.transactions || [];
    const cu = txs.reduce((sum, t) => sum + (t.meta?.computeUnitsConsumed || 0), 0);
    console.log(`${slot}\t${txs.length}\t${cu}`);
  }
}

main().catch((e) => { console.error(e); process.exit(1); });

在链上验证特定 Bundle

当 bundle 出现在浏览器中但你想要确认其内容时，按签名获取交易。以下调用返回带有元数据的交易，包括日志消息和内部指令，tip 转账和交换指令就出现在那里。

成功的验证有三个属性：交易存在于浏览器报告的 slot，其 meta.err 为 null，并且内部指令包含一笔向 Jito tip 账户的转账，其 lamport 金额与表格中显示的 tip 匹配。如果其中任何一项失败，请将仪表盘行视为过时或错误归属，并在得出结论前重新检查。

curl -s RPC_URL -X POST -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getTransaction",
  "params": [
    "SIGNATURE",
    { "encoding": "json", "maxSupportedTransactionVersion": 0 }
  ]
}'

结果表：应记录的内容

由于 tip 底价和 bundle 数量持续变化，指南中不应包含固定数字。相反，请使用以下列在你自己的表格中记录测量结果，以便结果在多次运行和不同端点之间具有可比性。针对两个 RPC 端点运行相同的窗口并填写两行；slot 覆盖或计算总量的差异是端点一致性的信号，而非 Jito 本身的问题。

• 窗口（起始 slot、结束 slot、UTC 时间戳）。
• 端点标签（RPC_URL 别名，而非原始 URL）。
• 请求的 slot 数、返回的 slot 数、跳过的 slot 数。
• 总交易数和消耗的总计算单元。
• 同一窗口在浏览器中观察到的 bundle 数。
• 捕获时 tip 底价视图的中位数和 p90 tip。
• 关于你的总计与仪表盘不一致的任何 slot 的备注。

排查常见差异

围绕 Jito Explorer 的大多数困惑来自四种反复出现的情况。在假设仪表盘错误之前，请按顺序逐一排查。

第一，跳过的 slot。没有区块的 slot 返回 null，将其视为零活动会使你的聚合值看起来低于图表。第二，时区和窗口边界：浏览器的周/月/年选择器使用自己的边界逻辑，因此手动 slot 范围很少能完全对齐。第三，截断的签名：从表格复制缩短的哈希将导致 getTransaction 失败。第四，tip 归属：显示的 tip 是 bundle 内的实现转账，可能与提交时的 tip 底价不同，因为底价在提交和落地之间发生了变化。

• 在比较总计之前，确认该 slot 确实产生了区块。
• 将你的 slot 窗口与浏览器显示的范对齐，而非凭直觉的挂钟时间。
• 每次 RPC 查询都使用完整的 base58 签名。
• 在推理包含时，区分实现 tip 和实时 tip 底价。

仪表盘优先分析的局限与权衡

公共浏览器针对探索而非可重复研究进行了优化。其聚合很方便但不透明：你无法确切看到百分位数是如何计算的、失败的 bundle 如何计数，或签名者排名如何处理地址聚类。对于一次性问题这没问题。对于任何你将引用、发布或据此制定策略的内容，请从原始 RPC 数据复现指标并保留脚本。

还存在依赖权衡。依赖单一仪表盘意味着你对市场的看法仅与该仪表盘的数据摄取一样新鲜和完整。针对可靠的 RPC 端点运行你自己的 slot 级聚合可以给你独立的检查，并让你扩展分析，例如将 bundle 签名与你自己的搜索者日志连接。成本是工程时间和 RPC 吞吐量；好处是你的数字由你辩护。

从探索到可重复的流水线

一旦你能复现 slot 级总计，自然的下一步是安排聚合并存储结果。一个简单的流水线定时运行 Node.js 循环，将每个 slot 一行写入数据库，并计算滚动 tip 和计算利用率摘要。这为你提供了一个你控制的历史序列，对于调整 tip 策略来说，这比阅读实时图表有用得多。

如果你以更高量级运营，专用节点可以消除共享端点的可变性并保持 slot 覆盖一致。在承诺之前查看可用的网络和节点选项，并将端点选择与分析代码分开，以便在不重写脚本的情况下更换提供商。

• 安排 slot 循环，并持久化结果，附带时间戳和端点标签。
• 计算滚动中位数而非单 slot 快照。
• 当你的总计与公共仪表盘出现突然分歧时发出警报。
• 将 RPC 凭证保存在环境变量中并定期轮换。

下一步

如果你的目标是提交 bundle 而不仅仅是观察它们，接下来的主题是 bundle 构建、tip 账户选择和区块引擎提交流程；这些与浏览器解读分开，值得单独处理。如果你的目标是可靠的数据收集，请从满足你吞吐量需求的 Solana 端点开始，然后针对它构建上述 slot 聚合。

具体到端点选择，请使用 RPC Assistant 而非从列表中猜测。对于基础设施规划，根据你预期的请求量比较共享和专用选项，并在任何提供商变更后重新查看测量表，以便确认你的 slot 覆盖保持一致。