web3-infra
Astar と Shiden の catch-up log をどう読むか
Astar/Shiden の archive RPC node を追うときのメモ。parachain と relaychain、finalized #0、warp sync、pruning flag、snapshot、version 選択を整理する。
Astar と Shiden の catch-up log は読み違えやすい。 同じ stream に parachain と relaychain の進捗が出るが、この二つは別の仕事をしている。 長い初回 sync では、片方が健康に見えても、もう片方に不自然な値が残ることがある。
不安になりやすいのは、だいたいこの形だ。
[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 は悪く見える。
ただし、catch-up の初期段階では、この field だけで node が壊れているとは言えない。
best が進んでいるか、peer が維持されているか、relaychain 側の finalized が進んでいるかを見る。
用語の説明
| 用語 | 意味 |
|---|---|
| parachain | Polkadot ecosystem で relay chain に接続する chain。Astar と Shiden は parachain。 |
| relaychain | parachain に shared consensus と finality を提供する chain。 |
| collator | parachain 側で candidate block を作り、relaychain validator に渡す node role。 |
| archive node | old block、storage、RPC query のために historical state を保持する node。 |
| full node | network を追えるが、設定された window より古い finalized data を prune する node。 |
| warp sync | relaychain 側の sync mode。finality proofs と state を優先し、relay 側を早く使える状態にする。 |
| Frontier | Substrate EVM chain で Ethereum-style RPC data を扱う compatibility layer。 |
Full node、collator、archive RPC を分ける
Astar docs はこれらの role を分けている。 full node page は、full node が古い finalized blocks を prune すること、古い履歴 data が必要なら archive node を使うべきことを説明している [1]。
collator guide の例では --state-pruning 1000 と --blocks-pruning 1000 が使われており、次の step に進む前に node が fully synchronized になるまで待つよう書かれている [2]。
これは collator 向けの設定で、archive RPC endpoint とは目的が違う。
archive RPC node の command reference では、次のような flag に変わる。
--state-pruning archive
--rpc-methods Safe
--sync warp
同じ page では、EVM RPC methods を使う場合に追加 flag が必要だとも説明されている [3]。 ここを混ぜない方がよい。 historical RPC が目的なら、pruned collator command と archive RPC command は別物だ。
Log field の読み方
catch-up line は次の順番で見る。
| Field | 運用上の意味 |
|---|---|
Parachain | Astar または Shiden 自体の chain。application-facing RPC では主にこの height を見る。 |
Relaychain | parachain の下にある relay network。速度と finality は parachain と違ってよい。 |
bps | その sync loop の blocks per second。上下に揺れる。 |
target | node が現在追いつくべきと見ている height。 |
best | local に import 済みの best block。 |
finalized | client がその側で知っている finalized block。catch-up 中は大きく遅れることがある。 |
peers | 接続 peer 数。0 ではないことは必要だが、それだけで速さは決まらない。 |
healthy catch-up は、きれいな表示ではなく進捗で判断する。
parachain best が増え、relaychain finalized も増えているなら、parachain finalized が #0 のままでも node は仕事をしている。
finalized #0 が残る理由
Astar と Shiden の finality は relaychain を通る。 node が古い parachain blocks を高速に import している間、parachain log には早い finalized value が残ることがある。 relaychain 側では finalized block が進んでいても、parachain 側の view が追いつくまで差が出る。
finalized #0 は単体ではなく、他の signal と合わせて見る。
| 状態 | 判断 |
|---|---|
best が増え、target も少しずつ更新され、peer が安定している | 観察継続。 |
relaychain finalized は増えるが、初期 catch-up 中の parachain finalized が #0 | 多くの場合まだ許容範囲。 |
best が何度見ても止まり、peer が低いか 0 | P2P、bootnodes、firewall、client health を見る。 |
best が target に近く、sync が完了しているのに parachain finality が全く動かない | client state と version を調べる。 |
起動直後の一時間で、finality field 一つだけを見て判断しない。 trend を見る。
Bootnode は discovery 用
bootnode は node が peer を見つけるための入口だ。 すでに安定した peer がある場合、bootnode だけで block import throughput が上がるとは限らない。
判断はこう分ける。
peer が低い、または不安定 -> bootnodes、P2P port、listen address、firewall を見る。
peer は安定しているが bps が低い -> CPU、disk I/O、memory、client version、sync stage を見る。
15 peers ある node が遅いことはある。 peer discovery と block execution は別の bottleneck だからだ。
Warp sync と snapshot
Astar の snapshot page では、database snapshot は通常推奨されず、scratch から sync するのが基本とされている。 同じ page は、Astar と Shiden の archive DB snapshot が third-party provider から提供されていること、ただし archive snapshot は pruned node では使えないことも説明している [4]。
relaychain 側では --sync warp が使われる。
見る点は、これは relaychain path の話だということだ。
warp sync は finality proofs と state を優先し、relay 側を早く使える状態にする。
parachain database の import work が消えるわけではない。
GitHub issue #1110 も覚えておきたい。
過去に Astar で warp sync が state download 後に OOM を起こすという報告があった [5]。
これは warp sync を使うな、という意味ではない。
startup 中の memory を見るべき、という運用上の注意だ。
Version は sync behavior の一部
Astar README では、v5.45.0 以降、client release と runtime release が分かれたと説明されている [6]。
node operator から見ると、floating latest は扱いづらい。
client version は運用上の入力になる。
v5.49.2 release notes は upgrade priority を critical とし、slot-based Aura における RPC node gap resync の修正を含んでいる [7]。
PR #1638 でも、Polkadot SDK dependencies の bump と RPC nodes gap syncing の修正が説明されている [8]。
だから、latest より明示的な client tag を使いたい。
sync behavior が変わった時に、どの binary が変わったか追えるからだ。
最初に見る command
Docker node なら、まず破壊的な操作は避けて sample を取る。
docker logs --tail=200 <container>
df -h /data
free -h
uptime
RPC の sync state はこう見る。
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 を有効にし、network boundary を決めた後で確認する。 official docs でも EVM RPC は opt-in 扱いなので、public RPC は明示的な access policy の後ろに置く。
運用上の読み方
Astar や Shiden で best が進み、peer が安定し、relaychain finalization も進んでいるなら、node は catch-up 中だ。
parachain line の finalized #0 は見るべき signal だが、それ単体で restart 理由にはしない。
介入するのは、次のような trend が出た時だ。
- peer count が落ちる。
bestが止まる。- disk や memory pressure が出る。
- client が追いついた後も RPC が使えない。
- 現在の version に sync や RPC gap の既知問題がある。
それまでは、node を動かし続け、metrics を取り、時間の推移で判断する。