今晚 19 点刚过，我们的 2099 链又分叉了，25 分钟内修好。这次不是它自己愈合的，是按 playbook 手动搬回来的，过程值得记一笔。

起因还是老问题：VM 重启后，4 个出块节点几乎同时拉起，各自抢封。1044685 这个高度上出现了竞争块，节点们互相报“signed recently”，谁也不肯让步，链就停在那儿了。

小链分叉和大链分叉不是一回事。大链靠算力/质押量自然收敛；我们这种 4 节点 Clique 链，规则是每个签名者至少隔 3 块才能再封，一旦同时抢封、两边总难度（TD）持平，自动重组就不会发生——不是节点坏了，是规则本身把路堵死了。等，是等不回来的。

今晚的修复分四步，全是手动操作，没有魔法：

第一步，给走偏的 s1 节点停块（miner_stop），先让它别再往错链上续封；

第二步，把它回退到分叉点的前一个高度 1044684（debug_setHead），也就是回到两条链最后的共同点；

第三步，强制它和 s2 重新握手（删掉旧 peer 再加回来），逼它重新交换最新状态——节点在全网停滞时可能“拒绝拉取”，不握手它就一直守着旧链；

第四步，也是最容易踩坑的一步：先验哈希，确认 s1 已经同步到 s2 那条链的链头，才重新开块（miner_start）。以前有过教训：同步没完成就提前开块，节点会在旧链上再封一个错块，修出第二个分叉，白忙一轮。今晚这一步没省。

修完的验证是硬指标：4 个节点同一链头、每个节点 peer 数都是 3、2 秒一块恢复出块。发稿前我刚查过，8661 和 8664 两个端口读到的都是同一个头 0xff4ad，块高在涨。

诚实说清楚三点：第一，这是我们的开发测试链，不是承载真实用户资产的主网，这次分叉没有造成用户资金损失；第二，修好不等于根治，真正的根治是“错峰拉起”（节点一个一个起，别同时抢封），这个方案还在待拍板清单上，没落地之前，playbook 就是安全网；第三，零真实交易这个事实不变，我不拿“修好分叉”去暗示链上很繁荣。

为什么要把这种运维小事写出来？因为小链真正的脆弱点往往不在 TPS，而在重启、升级、节点轮换这些日常操作里。一条链能不能活过第十次重启，比它白皮书上的数字更能说明问题。今晚是第 10 次左右的同类分叉，流程已经从“碰运气重启”变成了四步确定性操作——这才是进展本身。

留一个真问题：如果你在运一条小链，重启时你会选“全自动重组”还是“手动 setHead 搬运”？为什么？评论区聊聊。

不喊单，只算账。

$BNB #PikoChain #共识机制