cnode: 修复节点分叉

前言

节点稳定运行在版本 10.1.2 数个星期，尽管官方发布了 10.1.4 且 release note 第一段就加粗提示

It is recommended that all other node users upgrade to this version. Node users who do not upgrade put themselves at risk of a potential DoS attack following the hard fork.

我想着版本差距不大偷个懒，没跟进。然后就出事了。

今天一看节点全部不同步而且 P2P 下全部发现的周边节点都变成了Cold Peers， 而 Hot Peers 只剩下一个，而且一直处于无法同步满的状态。

完了。

• 是新版本脱更主动排斥我的 10.1.2
• 还是因为我所在的地区因为节点太稀少，或者被有意孤立（在 relays map 上我的节点确实是这96万平方公里独一份）
• 还是因为如更新日志所说，我被攻击或意外分叉了呢

仔细想了想，前两项都是自己吓自己 ，按分叉的可能性做假设去求证，还好现在又deepseek ，一切处理起来轻松了许多，仿佛有几个大牛带着我干活。不用自己苦苦刨文档刷源码或者到各个国外论坛群组里跪求大佬解答。

好了，不啰嗦..开始正片

排查确认

把日志喂给 DS 让它给分析可能存在的问题，它给出了下述的排查操作建议

0. 筛查日志，查找是否有区块数据错误的提示

grep "InvalidBlock" $CNODE_HOME/logs/node.json

果然有若干块报错与其他节点冲突

1. 检查版本和环境是否与最新版本要求一致，版本是我最新更新的这项操作排除

2. 查询当前节点 Tip

cardano-cli query tip --mainnet --socket-path $CNODE_HOME/sockets/node.socket

{
    "block": 11548542,
    "epoch": 543,
    "era": "Conway",
    "hash": "072b093376688780f155515cc99953f66e26f6e79e0ead110160aeff6056631c",
    "slot": 149401076,
    "slotInEpoch": 188276,
    "slotsToEpochEnd": 243724,
    "syncProgress": "99.98"
}

去区块浏览器查询 slot 149401076, 比对 hash
https://cexplorer.io/block/f52e3f12d232487cec24b187f58d5fba305014714b0232238716b9668d06bf6b

f52e3f12d232487cec24b187f58d5fba305014714b0232238716b9668d06bf6b 与本地值不同，可以确认是分叉了

从slot信息可知这个区块产生于 10h19m ago， 也就是从这个时间以前开始分叉的。
把这个时间之前的本地区块数据进行丢弃

其实，日志中还有更早前的错误提示：

"kind":"Error","reason":"InvalidBlock (At (Block {blockPointSlot = SlotNo 149295494

同样对照查询，发现是 1d17h7m ago

修正区块数据

1. 关停节点，

关停本地所有节点（因为local node 是 trust 状态，如果不全停，会导致互相污染错误数据持续反复分叉

systemctl stop cnode

2.删除错误数据

根据已知分叉的块 锁定 日期，删除对应的 区块文件

cd $CNODE_HOME/db/immutable
ll
rm -f 06909.*
rm -f 06908.*
rm -f 06907.*
rm -f 06906.*
rm -f 06905.*

列出的文件把最近3天生成的全部删除（选范围宽一点，保险）

3.清理无效的临时文件

rm -rf $CNODE_HOME/db/volatile/*
rm -rf $CNODE_HOME/db/ledger/*

4.以防数据污染了 MagicId 手动写入主网值

echo "764824073" > $CNODE_HOME/db/protocolMagicId

重启节点

systemctl start cnode

等待漫长的初始化，校验，和同步。然后再检查新同步的块是否与线上的hash一致。

（等待更新..发blog此刻在同步中）