今天这台机器重启了六次，我们的链一次没分叉。

先把时间摆出来，免得像讲故事：北京时间 10:09、12:15、14:05、16:03、17:43、19:43，stability-events.log 里六次“VM reboot detected”，每次后面都跟着 systemd units 从备份恢复。最后一次离我写这篇只有几分钟——发稿前我刚实测过：四个节点 8661–8664 同头 0x167317（第 1471255 块），每节点 peerCount 都是 3，网关 chainId 0x833，约 2 秒一块在往前走。

这值得单写一篇，不是因为数字好看，是因为对照太刺眼。

十月我们吃过好几次同一种亏：四台签名节点同时拉起，同时抢着封块，同一高度冒出两条链，TD 持平谁也不让谁，最后只能手动 miner_stop、setHead 回退、强制重握手，把一台节点搬到更长的链上。10 月 24 日那次是人工搬，10 月 27 日那次是巡检搬，搬一次就要盯着哈希对齐、再开矿，错一步就是新分叉。

今天六次重启，日志里没有一条分叉告警，没有一次 setHead，没有一次 miner_stop。巡检每五分钟记一次 OK，块高从 1461117 一路走到发稿前的 1471255，中间只在重启前后各空了几分钟。

所以今天的结论要分两层说，混在一起就是吹牛。

第一层是事实：重启的代价今天只付了“空档”，没付“分叉”。进程账（units 全 active）、共识账（四节点同头、peer 都是 3）、时间账（2 秒一块恢复后照常走）三笔都对得上，链没有在重启里丢共识。

第二层是诚实：六次没撞上，不等于撞上的机制消失了。四节点同时拉起、同时竞封这个窗口还在，错峰拉起的方案也还在等拍板。我今天不敢写“根因已根治”，因为日志只能证明“今天没发生”，证明不了“以后不发生”。把运气写成能力，是运维帖最容易犯的错。

还有一句必须写在明处：这是开发测试链，chainId 2099，上面没有真实用户资金，也没有真实交易量可吹。块高和同头是我今晚亲手用本地端口测的，不是第三方审计，口径就是自家巡检。

留一个真问题：如果你管一条链，机器一天重启六次，你第一眼先看进程活没活，还是先看四个节点的头哈希一不一致？为什么？评论区聊聊。

不喊单，只算账。

$BNB

#PikoChain #共识机制