怎么看 Substrate-style 和 Erigon 的同步日志

新节点最容易让人误判的地方，是“syncing”不是单一状态。同样是同步，可能是在找 peer，可能是在下载 block，可能是在执行，可能是在处理 snapshot，也可能是在做 trie 或 consensus layer 的追赶。看日志时要把这些阶段拆开。

实际运行时，不同客户端的表现可能完全不一样。一个 parachain 节点有 peer，但 parachain 侧推进很慢。另一个 parachain 节点明显快很多。 Erigon archive node 很快显示到较高区块，是因为 Erigon 不是按旧方式从创世块线性重放到现在。

用语说明

用语	含义
parachain	Polkadot 生态里接到 relay chain 的链。Substrate-style parachain 节点日志里会出现这个字段。
relaychain	给 parachain 提供共享安全和共识的 relay 网络。
bootnode	客户端启动时用来发现网络的已知节点地址。
peer	通过 P2P 连接上的其他节点。peer 数影响能不能拿到数据，但不是唯一瓶颈。
snapshot	预构建的链数据，让客户端不用从头重放所有旧区块。
staged sync	Erigon 的同步模型，下载、执行、hash、trie、索引等阶段分开推进。
archive mode	保留历史状态的模式，用来支持旧余额、trace、历史状态查询。

Parachain 日志怎么看

这类日志里有两条流：

[Parachain] Syncing 5.6 bps, target=#13762785, best: #839591, finalized #0
[Relaychain] Syncing 515.8 bps, target=#31798844, best: #6372700, finalized #6372352

几个字段最重要：

字段	怎么读
`Parachain`	parachain 自己的链。应用侧 RPC 通常更关心这个高度。
`Relaychain`	对应 relay chain 的同步。它和 parachain 的速度可能差很多。
`bps`	这一段同步循环里的 blocks per second。
`target`	节点认为应该追到的目标高度。
`best`	节点当前拿到的最高块。
`finalized`	节点已知的最高 finalized 块。快速追赶时可能滞后或停在很早的位置。
`peers`	该组件连接的 peer 数。

某个节点当时 peer 并不少，但 parachain 侧只有个位数 bps。如果还差几百万块，这个速度会变成很多天。 relaychain 侧快很多，所以不能简单判断为节点离线。

另一个 parachain 节点的形状不同。它的 parachain 侧能跑到几十甚至上百 bps，relaychain 也在推进。这仍然是追块状态，但更像一个健康的 catch-up。

Bootnode 帮的是发现网络，不是所有同步瓶颈

bootnode 很容易被高估。它主要帮助节点找到网络。当节点已经有 peer 以后，bootnode 本身通常不会直接让执行吞吐翻倍。

userdata 里也可能有 bootnode 拼接问题，或者残留看起来过期的条目。这个要修，避免以后重建时踩坑。但运行中的节点已经追得很快，所以没有必要为了 bootnode 重启一个正在正常追块的节点。

另一个更慢的节点更适合 live 应用官方 bootnode。做法是保留 /data，重建容器，只改客户端启动参数。这样不会删数据库。重启后节点需要重新建立 peer 状态并继续同步。 parachain 侧速度没有立刻明显改善，也符合预期：bootnode 能改善发现网络，不会把昂贵的 block import 变成免费操作。

Erigon 为什么很快到了较高区块

Erigon 日志容易让人惊讶，因为它很快显示到了较高区块。这不代表它已经从创世块完整重放到最新，也不代表所有 archive state 都构建完成。

Erigon 使用 snapshot 和 staged sync。日志里会看到不同阶段：

snapshots:blocks:retire
Execution
BuildFilesInBackground
computing trie

这些名字要分开看。 block 可用性、执行进度、trie 计算、后台文件构建是不同工作。某个阶段出现较高 block number 是真实信号，但不等于节点已经能在最新高度稳定回答所有历史查询。

更应该问的是：哪些 stage 完成了？哪些历史查询已经可用？

archive 行为怎么抽样

Erigon archive node 先看配置。运行参数里有：

--prune.mode=archive

这说明节点按 archive 意图启动。但只有这个还不够。还要做历史 RPC 抽样。

可以抽这些：

{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xf4240",false],"id":1}
{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","0x989680"],"id":1}
{"jsonrpc":"2.0","method":"trace_block","params":["0xf4240"],"id":1}

抽样返回了旧区块、旧高度余额和旧区块 trace。这就是我想看的实际信号：archive 模式已经配置，历史查询路径在抽样范围内能工作。

边界也要说清楚。只要 eth_syncing 还是 true，这个节点就还不是完整可用的当前 archive endpoint。历史抽样通过，可以发生在所有 stage 和最新高度追平之前。

我现在怎么读这类日志

新节点的前几个小时，我会按问题拆：

问题	信号
进程活着吗	容器 up，日志持续滚动。
连上网络了吗	peer 数非零，P2P 日志有活动。
慢在哪一侧	parachain、relaychain、execution、snapshot、trie 哪一段慢。
RPC 能用吗	本机 RPC 能回答基础调用。
archive 是否可信	启动参数加历史查询抽样。
是否完成	syncing 为 false，并且当前高度跟着网络最新高度走。

慢节点不一定是坏节点。有 peer 的节点不一定快。 Erigon 显示较高 block number，不一定就是完整可用的 archive endpoint。把这些状态拆开，排障会少走很多弯路。