Binance Square
#pikochain

pikochain

3 Aufrufe
3 Kommentare
pikocoin
·
--
„Heute Mittag hat unsere Chain eine Fork von selbst geheilt“Heute Mittag um 12:51 Uhr wurde bei Blockhöhe 909460 eine 2v2-Aufspaltung von der Überwachung entdeckt: s1/s2 auf dem Kopf 0xa60fb1b4ae6b, s3/s4 auf der anderen Seite (s4 hatte bereits bis 909461 weiter versiegelt). Im gesamten Netzwerk gab es etwa 13–14 Minuten lang keine neuen Blöcke. Unserem eigenen Wiederherstellungsplan zufolge hätte als Nächstes miner_stop folgen sollen, dann ein Rollback mit debug_setHead auf den Punkt vor der Aufspaltung und schließlich das Versetzen des für den Turnus berechneten In-turn-Sealers auf die Mehrheitskette, damit dieser dort weiter versiegelt. Über die kumulative Schwierigkeit (TD) sollte die Mehrheitskette dann die andere überholen und das gesamte Netzwerk zu einem Reorg zwingen. In den letzten anderthalb Monaten haben wir mit diesem Playbook bereits mehrmals eigenständig Fehler behoben. Am knappsten war es, als zwei Forks exakt die gleiche TD hatten und die Knoten in einer permanenten Blockade festsaßen, weil sie nie automatisch einen Reorg durchführen.

„Heute Mittag hat unsere Chain eine Fork von selbst geheilt“

Heute Mittag um 12:51 Uhr wurde bei Blockhöhe 909460 eine 2v2-Aufspaltung von der Überwachung entdeckt: s1/s2 auf dem Kopf 0xa60fb1b4ae6b, s3/s4 auf der anderen Seite (s4 hatte bereits bis 909461 weiter versiegelt). Im gesamten Netzwerk gab es etwa 13–14 Minuten lang keine neuen Blöcke.
Unserem eigenen Wiederherstellungsplan zufolge hätte als Nächstes miner_stop folgen sollen, dann ein Rollback mit debug_setHead auf den Punkt vor der Aufspaltung und schließlich das Versetzen des für den Turnus berechneten In-turn-Sealers auf die Mehrheitskette, damit dieser dort weiter versiegelt. Über die kumulative Schwierigkeit (TD) sollte die Mehrheitskette dann die andere überholen und das gesamte Netzwerk zu einem Reorg zwingen. In den letzten anderthalb Monaten haben wir mit diesem Playbook bereits mehrmals eigenständig Fehler behoben. Am knappsten war es, als zwei Forks exakt die gleiche TD hatten und die Knoten in einer permanenten Blockade festsaßen, weil sie nie automatisch einen Reorg durchführen.
Übersetzung ansehen
今晚链又分叉了,这次是手动把它搬回来的今晚 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 #共识机制

今晚链又分叉了,这次是手动把它搬回来的

今晚 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 #共识机制
Anmelden und weiter Inhalte entdecken
Krypto-Nutzer weltweit auf Binance Square kennenlernen
⚡️ Bleib in Sachen Krypto stets am Puls.
💬 Die weltgrößte Kryptobörse vertraut darauf.
👍 Erhalte verlässliche Einblicke von verifizierten Creators.
E-Mail-Adresse/Telefonnummer