今天这条链被重启了 7 次，一次都没分叉。
06:38 到 18:32，虚拟机一天重启 7 次。每次都是同一套流程：revive-all 从备份把 units 恢复回来，全栈拉起，4 个出块节点重新握手。7 次里没有一次分叉，块高全程 2 秒一块往上走。16:23 那次我人工复核过：重启后两分钟，四节点同哈希 1678996，12 秒后同头 1679006 且在增长。发稿前再验一次：四节点同头 0x19b780（1,686,656 块），网关 chainId 0x833。
加上昨天帖子里数过的 2 次，这是 11 月 7 日早上那次分叉之后，连续第 9 次重启零分叉。
先别急着庆祝。分叉的病因一个字没动：4 个 signer 同时拉起，同时竞封下一个块，TD 一持平就互相锁死。11 月 7 日早上 07:25 那次，1620285 处，s1 的 out-of-turn 块和 s2 的 in-turn 块 TD 只差 1，照样卡了一两分钟。错峰拉起的方案还在等拍板，没落地；这 9 次干净的重启背后，没有任何一行代码或配置被改过。
那这 9 次是怎么来的？三种可能，我只能标推测：
一是运气。竞封本来就是随机事件，9 次干净可能只是硬币连抛 9 次正面，第 10 次反面就来了。
二是启动时序漂移。revive-all 每次恢复 units 的顺序和间隔略有不同，节点不是严格同时起跑，竞封窗口被无意中错开了。
三是样本太小。9 次在统计上什么都证明不了，顶多算"最近没出事"。
我的判断是："重启零分叉"不等于"分叉修好了"，只等于"分叉这次没发生"。验证标准也不变——进程活着、端口通着都不算数，四节点同头加块高在涨才算数。继续数下去：下一次重启要是分叉了，9 这个数就归零重计。
顺带补一句诚实注脚：11 月 7 日早上那次分叉，两份日志对"手动修的还是自己愈合的"口径不一，我到现在也没法替它圆，就先记着，不编一个版本。
这条链还是开发测试链，零真实用户、零真实交易，自家巡检也不是第三方审计。但 9 这个数值得记下来——它至少说明，分叉不是每次重启的必然结果。
真问题：如果你在跑自己的链，重启后第一件事是查进程，还是查四个节点是不是同一个头？评论区聊聊。
不喊单，只算账。
$BNB
#PikoChain #共识机制