通过 op-node 和 op-reth 引擎/管理 RPC 检查 Base OP-Stack 节点同步状态

直接回答：如何验证您的 Base 节点已同步

要验证您的 Base 节点是否完全同步，您需要同时检查 op-node（共识/汇总客户端）和 执行引擎（op-reth、op-geth 或 op-erigon）。op-node 暴露了一个管理 RPC，报告当前的 不安全头部（最新的排序器区块）、安全头部（从 L1 派生）和 最终确定的头部。执行引擎暴露其自身的同步状态和头部高度。健康的节点显示不安全头部随排序器推进，安全头部从 L1 追赶，引擎头部与不安全目标匹配。如果任何头部停滞或引擎报告同步中，则节点未实时同步。

本指南适用于运行自己的 Base 节点并需要诊断同步问题的节点运营商。它补充了 Base 最终性和安全/最终确定的区块标签 文章，该文章是为读取这些标签的 RPC 消费者编写的，而不是为检查自己节点同步状态的节点运营商。

架构：op-node 和执行引擎

Base 是一个 OP-Stack 汇总。节点由两个主要组件组成：op-node（汇总共识客户端）和 执行引擎（op-reth、op-geth 或 op-erigon）。它们通过 引擎 API 通信，这是一个以太坊 JSON-RPC 命名空间（engine_*），允许共识客户端驱动执行引擎的叉选择和区块生产。

op-node 跟踪三种头部状态：

• 不安全头部：来自排序器的最新区块，通过引擎 API 的叉选择更新获知。这是排序器产生的链的尖端。

• 安全头部：从最终确定的 L1 数据派生的最新区块。随着 op-node 处理 L1 批次而推进。

• 最终确定的头部：在 L1 上最终确定的最新区块，因此在 Base 上也是最终确定的。

执行引擎维护自己的规范链，并通过 eth_blockNumber 或 eth_getBlockByNumber 方法暴露其头部。当节点完全同步时，op-node 的不安全头部应与引擎的头部匹配。

有关权威详细信息，请参阅 Base 文档中的运行节点指南 和 Optimism op-node 文档。

访问 op-node 管理 RPC 和引擎 API

op-node 在单独的端口（默认 9545）上暴露 管理 RPC，提供特定于节点的方法。要启用它，您必须使用 --admin.rpc.enabled 标志启动 op-node，并可选择设置 --admin.rpc.port。管理 RPC 包括 admin_health、admin_logs 和 admin_sync 等方法（取决于版本）。

执行引擎在其 JSON-RPC 端口（op-reth 默认 8545）上暴露引擎 API。要查询引擎方法，您需要使用 JWT 密钥进行身份验证，该密钥通过 op-node 和执行引擎上的 --authrpc.jwtsecret 标志传递。

重要：这些管理和引擎命名空间仅限操作员使用，不得公开暴露。它们可能泄露敏感信息并允许控制节点。始终将它们绑定到 localhost 或专用网络。

有关确切的方法名称和参数，请查阅您的特定 OP-Stack 版本的文档，因为它们可能有所不同。

分步指南：查询同步状态

以下命令假定您已安装 curl 和 jq，并且您的 op-node 管理 RPC 可在 http://localhost:9545 访问，执行引擎的引擎 API 在 http://localhost:8551（带 JWT）。根据需要替换端口和路径。

首先，检查 op-node 的健康端点：

这将返回一个 JSON 对象，包含 healthy 布尔值以及不安全头部、安全头部和最终确定头部的详细信息。健康的节点应显示 "healthy": true，并且头部应推进。

接下来，查询 op-node 的管理 RPC 以获取同步状态。方法名称可能是 admin_sync 或 optimism_syncStatus，具体取决于版本。例如：

这将返回一个对象，包含 unsafe_l2、safe_l2 和 finalized_l2 区块，每个区块包含区块号和哈希。

现在检查执行引擎的头部。使用引擎 API 方法 engine_getPayloadV2 或简单地使用 eth_blockNumber（如果启用）。例如：

将引擎的头部区块号与 op-node 的不安全头部进行比较。它们应相等或非常接近（在几个区块内）。

curl -s http://localhost:9545/health | jq .

curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"admin_sync","params":[],"id":1}' http://localhost:9545 | jq .

curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' http://localhost:8545 | jq -r '.result' | xargs printf "%d\n"

解读输出：健康与降级

健康的节点显示以下内容：

• op-node 健康端点返回 "healthy": true。

• 不安全头部以预期速率推进（在 Base 上通常每 2 秒一次）。

• 安全头部也在推进，尽管可能因等待 L1 确认而落后于不安全头部几分钟。

• 执行引擎的头部与不安全头部匹配。

降级的节点可能显示：

• 健康端点返回 "healthy": false，并带有诸如 "unsafe head is behind" 或 "engine sync not progressing" 的原因。

• 不安全头部未推进，表明排序器馈送已关闭或节点处于回退模式。

• 安全头部卡住，意味着 L1 派生未推进。

• 执行引擎的头部远落后于不安全头部，表明引擎仍在同步或卡住。

如果节点处于 安全模式（排序器馈送不可用），它将仅从 L1 派生区块，这较慢。不安全头部可能不会推进，但安全头部仍应推进。这不一定是一个错误，但意味着节点不在尖端。

检测同步卡住和修剪问题

一个常见的故障是节点看似在运行，但卡在初始同步或落后于过时的快照。例如，从快照启动的存档节点可能无法到达尖端，因为快照已过时。类似地，op-node 可能在 op-reth 修剪时挂起，如 GitHub 问题中所报告。

要检测这些问题：

• 检查 op-node 日志中是否有诸如 "engine sync not progressing" 或 "unsafe head is behind" 的错误。

• 检查执行引擎的同步状态。对于 op-reth，您可以使用 reth_sync 方法（如果启用）或检查日志以获取同步进度。

• 如果引擎仍在同步，它将在引擎 API 中报告 syncing 状态。您可以查询 engine_getPayloadV2 并检查 latestValidHash 和 finalizedBlockHash。

• 如果节点卡在过时的快照后面，您可能需要从更新的快照重新同步或使用检查点同步。

例如，要检查 op-reth 的同步状态：

这将返回一个对象，包含 current_block、highest_block 和 stage 字段。如果 current_block 未增加，则同步卡住。

curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"reth_sync","params":[],"id":1}' http://localhost:8545 | jq .

操作员故障排除清单

使用此清单诊断和修复 Base 节点上的同步问题：

1. 检查 op-node 健康：运行 curl -s http://localhost:9545/health | jq . 并验证 healthy 为 true。

2. 检查 op-node 同步状态：查询 admin_sync 并记录不安全、安全和最终确定的区块号。

3. 检查执行引擎头部：查询 eth_blockNumber 并与不安全头部进行比较。

4. 检查引擎同步状态：对于 op-reth，查询 reth_sync 并确保 current_block 在推进。

5. 检查日志：查找 op-node 和 op-reth 日志中的错误。常见错误包括 "engine sync not progressing"、"unsafe head is behind" 和 "pruning" 消息。

6. 验证排序器馈送：如果不安全头部未推进，检查排序器馈送是否可达。您可能需要使用正确的 --l1.beacon 和 --l1.rpc 端点重新启动 op-node。

7. 检查 L1 连接：确保 op-node 可以到达 L1 节点，并且 L1 已同步。

8. 重启服务：如果所有其他方法都失败，请重启 op-node 和执行引擎。有时简单的重启可以解决暂时性问题。

9. 必要时重新同步：如果节点卡在过时的快照后面，请考虑从更新的快照重新同步或使用检查点同步。

可复现的测量脚本

以下脚本查询 op-node 和执行引擎，并打印头部高度表。运行两次，间隔一段时间，以查看头部是否在推进。

运行脚本两次，间隔 30 秒，然后在下面的表格中填写结果：

如果不安全和引擎的增量为零，则节点未同步。如果安全头部也为零，则 L1 派生卡住。

#!/bin/bash
# Save as check_sync.sh and run with: bash check_sync.sh

OP_NODE_ADMIN="http://localhost:9545"
ENGINE_RPC="http://localhost:8551"

# Get op-node sync status
sync_status=$(curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"admin_sync","params":[],"id":1}' $OP_NODE_ADMIN)
unsafe=$(echo $sync_status | jq -r '.result.unsafe_l2.number')
safe=$(echo $sync_status | jq -r '.result.safe_l2.number')
finalized=$(echo $sync_status | jq -r '.result.finalized_l2.number')

# Get engine head (assuming eth_blockNumber is enabled)
engine_hex=$(curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' $ENGINE_RPC | jq -r '.result')
engine=$((16#${engine_hex#0x}))

# Print table
echo "Head type | Block number"
echo "----------|--------------"
echo "Unsafe    | $unsafe"
echo "Safe      | $safe"
echo "Finalized | $finalized"
echo "Engine    | $engine"

限制和权衡

所描述的方法需要操作员级别的访问权限才能访问节点的管理 RPC 和引擎 API。这些端点不适用于公共 RPC 提供商，如 OnFinality 的 Base RPC 节点。如果您使用托管节点，则无法直接查询这些命名空间；相反，您可以通过公共端点（如 eth_blockNumber）监控同步状态，并与区块浏览器上的最新区块进行比较。

确切的方法名称和参数可能因 OP-Stack 版本和执行客户端而异。始终查阅您的特定版本的文档。例如，op-node 的管理 RPC 方法可能是 admin_sync 或 optimism_syncStatus，而 op-reth 的同步方法可能是 reth_sync 或 admin_peerInfo。

公开暴露管理或引擎 RPC 端点是一个安全风险。它们可能允许攻击者控制您的节点或提取敏感信息。始终将它们绑定到 localhost 或使用防火墙。

有关监控节点健康的更多信息，请参阅 监控 RPC 端点和节点健康。

后续步骤和进一步阅读

既然您可以检查 Base 节点的同步状态，您可能想探索相关主题：

• Base RPC 延迟 – 了解节点的延迟预期。

• 运行和查询 Base 存档节点 – 如果您需要历史数据。

• Base 最终性和安全/最终确定的区块标签 – 适用于读取这些标签的消费者。

• OnFinality Learn 中心 – 更多面向节点运营商和开发者的指南。

• API 服务 – 如果您更喜欢托管 RPC 服务。

• RPC 定价 – 了解扩展时的成本。

如果您使用 OnFinality 的托管 Base 节点，则无需自行执行这些检查；我们的基础设施处理同步和健康监控。有关更多信息，请参阅 Base RPC 节点（RPC 助手）。