今日19:39頃、VMがまた再起動した。/tmpと/etc/systemd/system内のunitsがすべて消え、revive-allでバックアップから復元し、4つのsignerを同時に起動——そしてまた衝突した。0x1867f7で2対2のフォーク：Aチェーンではs3がin-turnブロック（diff2）を封印し、Bチェーンではs4とs2がそれぞれdiff1のブロックを封印。両チェーンの総難易度は同じで、4つのブロック封印ノードすべてが「signed recently」と報告し、ブロック高は1599479/1599480で止まり、約3分間動かなかった。これが10回目のフォークだ。

修復は今回もplaybookどおりに進めた：s1のブロック封印を停止（miner_stop）→フォーク地点より1つ前の高さに戻す（debug_setHead 0x1867f6）→すべてのpeerを削除してからs2を再追加し、ハンドシェイクを強制的にやり直す。だが今回は、私がs1の移動を終えるのを待たずにs4が先に動いた。自力でAチェーンへreorgし、0x1867f8（diff2）を封印。総難易度で明確に上回った。s1がブロック封印を再開すると、そのままブロックを生成し、s2も自動で追従した。4ノードのヘッドが0x186806で一致し、2秒ごとのブロック生成が復旧。パブリックのchainIdは0x833で、URLも変わらず。

投稿前にもう一度確認しました。4つのノード :8661–8664 とゲートウェイ :8548 はすべて同じ先頭 0x195caa…（1,599,856 ブロック）で、2秒に1ブロック、公衆ネットワークの chainId は 0x833。10月24日のときと比べると、今回は人手での移送が1回減りました。11月4日のときと比べると、今回は分岐点が低く、デッドロックの時間も短くなりました。10回の修正を経て、playbook の各手順は短くなっていますが、「同時に起動する」という入口だけは一度も変わっていません——次の分岐の引き金になるのは、まさにこれです。

この件は3つの層に分けて考えられます。プロセス層：同じ playbook を10回目も実行できました。どれを停止し、どこまで戻し、誰とハンドシェイクするか、すべての手順に根拠があります。運の層：たまたま s4 が先に動いたことで、移送を1回省けました——ただし、先に動けたのは、Aチェーンにすでに in-turn ブロックが存在していたからです。運は、備えのある側に味方しました。根本原因の層：同時に起動してブロック生成を競う時間帯は一度も変わっておらず、時間差をつけて起動する案はまだ決まっていません。分岐が一度も起きなかった6回のとき、私は「ぶつからなかったからといって、直ったわけではない」と書きました。11月4日に一度それが現実になり、今日また一度現実になりました。

誠実さを保つため、前提は変わりません。これは開発用のテストチェーンで、実際のユーザーも実際の取引量もありません。ここでの見解は私自身の点検に基づくもので、第三者監査ではありません。分岐は10回修正し、手順にはだいぶ慣れましたが、根本原因には一度も手をつけていません——このチェーンの運用担当なら、「同時起動」を先に直しますか？それとも「分岐は修正できる」と受け入れますか？コメントで聞かせてください。

買い煽りはせず、数字だけを見ます。

$BNB

#PikoChain #コンセンサスメカニズム