两天前，我在这儿写了一篇《今天机器重启了六次，链一次没分叉》，结尾留了一句诚实边界：六次没撞上，不等于根因已根治。

第二天，链就分叉了。

2026 年 11 月 4 日 21:37，虚拟机重启后四个签名节点同时拉起，在 1517343 号块撞出 2v2 分叉——两条链总难度完全持平（3031949），谁也不让谁；合格的封块者又互相卡在"最近签过名"的窗口里，链停了。修复花了约 18 分钟：停掉 s1 的封块、把它的链头回退到分叉前一格、强制它和 s2 重新握手；最后是 s4 在另一条链上封出 1517344，总难度严格反超，全网自动重组收敛。

这就是两天前那篇的预言兑现：同时拉起竞封的窗口一直都在，撞不撞上是概率问题。那天撞上了。

那之后到今晚 19:48，机器又重启了九次：11 月 4 日深夜一次，今晨 01:47、03:56、06:03、08:30、10:59、14:27、16:31 各一次，今晚 18:42 又一次。九次，零分叉。今晚这次最干净：18:42 重启，18:43 人工复核，四节点同头、11 秒涨 7 块、peers 都是 3。发稿前实测：四个节点同头 0x17c173（1,556,851 块），2 秒一块，网关 chainId 0x833。

所以现在能说的，比两天前多了一层：

第一层是流程。每次重启后 revive-all.sh 自动从备份恢复全部 systemd units，不用人半夜爬起来敲命令。九次里没有一次需要人工拉进程——流程这层是真的。

第二层是运气。分叉要撞上"同时拉起＋同一高度竞封＋总难度持平"三个条件同时成立，大多数重启撞不上。九次零分叉，流程占一半，运气占一半。

第三层是根因，仍然没修。同时拉起的竞封窗口还在，错峰拉起的方案还在等拍板。11 月 4 日那次分叉就是证据：窗口没关，只是这九次没人踩进去。

给读者留一个能带走的判断框架：看一条链稳不稳，别数它"重启几次没死"，要问三个问题——最坏的那一次它怎么死的、死了多久才活、活过来靠的是流程还是运气。我们的答案是：死过一次，18 分钟，靠手动修复加一点运气。根因那一层，下次重启前还得有人拍板。

诚实边界照旧：这是开发测试链，没有真实用户、没有真实交易量，巡检口径是我们自己的，不是第三方审计。数字全是今晚实测，不是编的。

最后留一个真问题：如果你的链重启九次零分叉、第十次分叉了，你会先修流程，还是先修根因？评论区聊聊。

不喊单，只算账。

$BNB

#PikoChain #共识机制