Substrate-style と Erigon の同期ログをどう読むか

新しい node で紛らわしいのは、syncing が一つの状態ではないことだ。 peer discovery、block download、execution、snapshot、trie、consensus layer の catch-up が、同じように sync と呼ばれる。 log はその段階を分けて読む必要がある。

実運用では、client ごとの見え方はかなり違う。 ある parachain node は peer があるのに parachain 側が遅い。 別の parachain node はかなり速く進んだ。 Erigon archive node は staged sync と snapshot により、早い段階で高い block number が見えた。

用語の説明

用語	意味
parachain	Polkadot ecosystem で relay chain に接続する chain。Substrate-style parachain node の log に出てくる。
relaychain	parachain に shared security と consensus を提供する network。
bootnode	client 起動時に peer discovery の入口として使う既知 node address。
peer	P2P で接続された他の node。peer count は重要だが、sync speed の唯一の条件ではない。
snapshot	古い block をすべて replay しなくてもよいように用意された chain data。
staged sync	Erigon の sync model。download、execution、hashing、trie、indexing などが stage ごとに進む。
archive mode	古い balance、trace、state query に必要な history を保持する mode。

Parachain node の log

この系統の log には二つの stream が出る。

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

見る field は次の通り。

Field	読み方
Parachain	parachain 自体の chain。application RPC が見る height は主にこちら。
Relaychain	接続先 relay chain の sync。parachain と速度が大きく違うことがある。
bps	その sync loop の blocks per second。
target	node が追いつくべきと見ている height。
best	node が現在持っている best block。
finalized	node が知っている finalized block。catch-up 中は遅れたり初期値に見えることがある。
peers	その component の接続 peer 数。

ある node は peer が足りないわけではなかったが、parachain 側は一桁 bps だった。 数百万 block の lag がある場合、この速度ではかなり時間がかかる。 一方で relaychain 側は速く進んでいたので、node が単に offline という見方ではなかった。

別の parachain node は違った。 parachain 側が数十から数百 bps で進み、relaychain も進んでいた。 まだ catch-up 中ではあるが、形としてはかなり健康に見える。

Bootnode が効く場所

bootnode は過大評価しやすい。 役割は network discovery の入口を与えることだ。 すでに peer がある node では、bootnode だけで execution throughput が大きく変わるとは限らない。

userdata には bootnode の組み立て方の問題や、古そうな entry が残ることもある。 将来の再作成に備えて直す価値はある。 ただ、動いている node はすでに速く追いついていた。 bootnode 変更のためだけに restart する方がリスクに見えた。

より遅い node では、公式 bootnode を live で適用する判断にした。 /data は残し、container を作り直して client command だけ変えた。 database は消していない。 restart 後、node は peer state を作り直しながら sync を続ける。 parachain 側の遅さはすぐには消えなかった。 bootnode は discovery を助けるが、block import の重さを消すものではない。

Erigon が高い block に早く見える理由

Erigon log は、早い段階で高い block number が見えて驚きやすい。 それは、すべての block を genesis から完全に replay し終わったという意味ではない。 archive state がすべて完成したという意味でもない。

Erigon は snapshot と staged sync を使う。 log には次のような stage が出る。

snapshots:blocks:retire
Execution
BuildFilesInBackground
computing trie

block availability、execution progress、trie computation、background file build は別の仕事だ。 ある stage で高い block number が見えても、node が tip で全 historical query に安定して答えられるとは限らない。

見るべきなのは、どの stage が終わり、どの historical query が返るかだ。

Archive mode の確認

Erigon archive node では、まず起動 command を見た。

--prune.mode=archive

archive mode の意図はこれで確認できる。 ただし、起動 option の確認だけで終わりにはしない。 historical RPC も sampling する。

例えば次の query を使う。

{"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}

old block、old height の balance、old block の trace が返った。 archive mode が設定され、少なくとも sampling した historical path は動いている。

ただし eth_syncing が true の間は、current archive endpoint として完成しているとは言わない。 historical sample が通ることと、全 stage が終わって tip に追いつくことは別だ。

ログを読む順番

新しい node の最初の数時間は、次の順番で見る。

Question	Signal
process は生きているか	container が up で log が進む。
network に繋がっているか	peer count が 0 ではなく、P2P log が動く。
どこが遅いか	parachain、relaychain、execution、snapshot、trie のどこか。
RPC は使えるか	local RPC が basic call に答える。
archive mode は妥当か	command flag と historical query sample。
完了したか	syncing が false で、current height が network に追随する。

遅い node が壊れているとは限らない。 peer がある node が速いとも限らない。 Erigon の高い block number は、完成した archive endpoint と同じではない。 この違いを分けるだけで、かなり読みやすくなる。