Astar 和 Shiden 追块日志怎么看

Astar 和 Shiden 的追块日志很容易误读。同一个输出流里会同时出现 parachain 和 relaychain，但这两部分做的不是同一件事。第一次长时间追块时，一边看起来正常，另一边还显示奇怪状态，并不罕见。

最容易让人紧张的是这种行：

[Parachain] Syncing 240.0 bps, target=#15173806, best: #3057834, finalized #0
[Relaychain] Syncing 325.6 bps, target=#34075714, best: #6517931, finalized #6517760

parachain 侧的 finalized #0 看起来像坏了。早期追块时，单看这个字段还不能判断节点坏了。更应该看 best 是否持续增长、peer 是否稳定、relaychain 侧 finalized 是否推进。

用语说明

用语	含义
parachain	Polkadot 生态里接到 relay chain 的链。Astar 和 Shiden 都是 parachain。
relaychain	给 parachain 提供共享共识和最终性的链。
collator	parachain 节点角色，负责产生候选区块并交给 relaychain validator。
archive node	保留历史状态的节点，可以支持旧区块、storage 和 RPC 查询。
full node	可以跟随网络，但会按配置窗口裁剪较老 finalized 数据的节点。
warp sync	relaychain 侧的同步模式，优先下载 finality proofs 和 state，让 relay 侧更快可用。
Frontier	Substrate EVM 链中提供 Ethereum 风格 RPC 数据的兼容层。

先分清 full node、collator、archive RPC

Astar 官方文档把这些角色分开写。 full node 页面说明，full node 默认会裁剪旧 finalized blocks；如果需要旧历史数据，应该使用 archive node ^[1]。

collator 指南里的示例使用 --state-pruning 1000 和 --blocks-pruning 1000，并且要求节点完全同步后再继续后续步骤 ^[2]。这是 collator 场景，不是 archive RPC endpoint 的完整答案。

archive RPC 的命令参考会切到这些参数：

--state-pruning archive
--rpc-methods Safe
--sync warp

同一页还说明，如果需要 EVM RPC 调用，需要额外开启对应 flag ^[3]。这个区别很重要。如果目标是历史 RPC，pruned collator 命令和 archive RPC 命令不是一回事。

日志字段怎么读

这类追块日志，我会按这个顺序看：

字段	运维含义
`Parachain`	Astar 或 Shiden 自己的链。应用侧 RPC 通常更关心这个高度。
`Relaychain`	parachain 下面跟随的 relay 网络。它的速度和最终性可以和 parachain 不同。
`bps`	这一段同步循环的 blocks per second，会波动。
`target`	节点当前认为应该追到的高度。
`best`	节点本地已经 import 的最高块。
`finalized`	客户端这一侧已知的 finalized 块。追块时可能严重滞后。
`peers`	已连接 peer。非零 peer 不保证快，但 0 peer 是真实问题。

健康追块看的是移动，不是每个字段都漂亮。如果 parachain best 每次采样都在涨，同时 relaychain finalized 也在涨，即使 parachain finalized 还是 #0，节点也在做有效工作。

为什么 `finalized #0` 会停在那里

Astar 和 Shiden 的最终性来自 relaychain。节点快速导入旧 parachain blocks 时，parachain 日志可能一直打印很早的 finalized 值。 relaychain 已经看到 finalized blocks，但 parachain 侧还在重建自己的视图，这种状态尤其明显。

我会把 finalized #0 放到组合信号里看：

状态	判断
`best` 持续增长，`target` 缓慢刷新，peer 稳定	继续观察。
relaychain `finalized` 增长，但早期追块时 parachain `finalized` 仍是 `#0`	通常还能接受。
`best` 多次采样不动，同时 peer 很低或为 0	查 P2P、bootnodes、防火墙或客户端健康。
`best` 已接近 `target`，同步也显示结束，但 parachain finality 仍完全不动	查客户端状态和版本。

节点刚启动的一小时，不适合只拿一个 finality 字段判断。看趋势更可靠。

Bootnode 解决发现网络，不解决所有导入瓶颈

bootnode 的作用是帮助节点找到网络。当节点已经有稳定 peer 以后，bootnode 本身通常不会直接提高 block import 吞吐。

我会这样分：

peer 低或不稳定 -> 查 bootnodes、P2P 端口、listen address、防火墙。
peer 稳定但 bps 低 -> 查 CPU、磁盘 I/O、内存、客户端版本和当前同步阶段。

一个节点可以有 15 个 peer，但 import 仍然慢。这并不矛盾。发现 peer 和执行区块是两个不同瓶颈。

Warp sync 和 snapshot

Astar snapshot 页面说，通常不鼓励使用数据库 snapshot，从头同步是更常规的做法。页面也提到第三方提供 Astar 和 Shiden 的 archive DB snapshot，但这些 snapshot 是 archive snapshot，不能用于 pruned node ^[4]。

relaychain 侧则推荐使用 --sync warp。这里要注意：warp sync 主要帮助 relaychain 路径。它会优先处理 finality proofs 和 state，让 relay 侧更快可用。它不会消除 parachain 数据库自己的导入工作。

GitHub 上还有一个值得记住的 issue：Astar #1110 曾记录过 warp sync 在下载 state 后触发 OOM 的情况 ^[5]。这不代表不能用 warp sync。它提醒我们，启动阶段要看内存，尤其是客户端或依赖刚升级以后。

版本也是同步行为的一部分

Astar README 说明，从 v5.45.0 开始，client release 和 runtime release 分开 ^[6]。对节点运维来说，floating latest 不是好默认值。客户端版本本身就是运维输入。

v5.49.2 的 release notes 把升级优先级标成 critical，并包含 slot-based Aura 下 RPC node gap resync 的修复 ^[7]。对应的 PR #1638 也写到，依赖升级用于修复 RPC nodes gap syncing ^[8]。

所以我更倾向于显式固定 client tag。如果同步行为变化，至少能知道是哪一个 binary 变了。

我会先跑哪些检查

Docker 节点先不要做破坏性操作，先采样：

docker logs --tail=200 <container>
df -h /data
free -h
uptime

RPC 同步状态可以看：

curl -s http://127.0.0.1:9944 \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"system_syncState","params":[]}'

EVM RPC 要在确认已开启对应 flag，并且网络边界已经收口后再测。官方文档把 EVM RPC 视为 opt-in，公网 RPC 也应该放在明确的访问策略后面。

我的判断口径

Astar 或 Shiden 如果同时满足这几个条件：best 快速推进、peer 稳定、relaychain finalized 推进，那就是在追块。 parachain 行里的 finalized #0 需要观察，但单独看不构成重启理由。

真正需要介入的是这些趋势：

peer 数掉下去；
best 不再增长；
磁盘或内存出现压力；
客户端追平后 RPC 仍不可用；
或者当前版本已知有 sync/RPC gap 问题。

在此之前，最无聊的答案通常是对的：继续跑，继续采集 metrics，用时间趋势判断。