以前は、目に見えてネットワークから遅れた Dusk ノードは、すでに復旧（リカバリ）の問題だと思っていました。けれども、オペレーターのフローを詳しく見るとそれが変わりました。Dusk は「遅れている（behind）」ことと「停止している（stalled）」ことを明確に分けており、この違いによって、そのノードに介入が必要かどうかが決まるからです。

状態を置き換える前に、オペレーターは選択したチェーンとピアの接続性を確認し、そのうえで `ruskquery block-height` を複数回サンプルして、ローカルの高さがまだ進んでいるかどうかを確かめられます。このローカルの動きは、対応するパブリック・ネットワークのティップとも比較できます。ノードが遅れているものの前進を続けているなら、Dusk のガイダンスは本質的には「遅れそのものを、状態が壊れている証拠とみなして直ちに扱う」のではなく、「監視を続ける」ことです。

この区別が気に入っています。復旧アクションにはそれ自体の運用コストがかかります。証拠が、ノードが通常どおり追いつき中であることを示しているなら、ブロック高のあらゆるギャップをすべて“修復作業”にする必要はありません。

有益なのは、診断による安心です。

まず、実際に進捗が本当に止まっているかを確認し、そのうえで復旧が正当化されるかを判断します。

インフラを保守する人にとって、健全な状態に触らない判断のタイミングを知ることは、それを復元する方法を知ることと同じくらい価値があります。

@Dusk $DUSK #dusk