pikochain

Aujourd’hui à 12 h 51, une bifurcation 2v2 à la hauteur 909460 a été détectée lors d’une inspection : les têtes de s1/s2 étaient à 0xa60fb1b4ae6b, tandis que s3/s4 étaient sur l’autre branche (s4 avait déjà scellé le bloc suivant, à la hauteur 909461). Aucun nouveau bloc n’a été produit sur l’ensemble du réseau pendant environ 13 à 14 minutes.
D’après notre propre procédure de réparation, il aurait fallu ensuite exécuter miner_stop, revenir à un point précédant la bifurcation avec debug_setHead, puis déplacer le scelleur dont c’était le tour, choisi selon le calendrier de rotation, vers la chaîne majoritaire pour y sceller le bloc suivant. La difficulté cumulée (TD) aurait ainsi dépassé celle de l’autre chaîne et forcé une réorganisation sur tout le réseau. Au cours du dernier mois et demi, nous avons réparé nous-mêmes plusieurs incidents de ce type avec cette procédure. Le cas le plus périlleux était un blocage permanent : les deux branches avaient exactement la même TD, et les nœuds ne réorganisaient jamais automatiquement la chaîne.

今天 19:39 左右，VM 又重启了一次。/tmp 和 /etc/systemd/system 里的 units 全清空，revive-all 从备份恢复，四个 signer 同时拉起——然后又撞上了。0x1867f7 处 2v2 分叉：A 链 s3 封 in-turn 块（diff2），B 链 s4、s2 各封一个 diff1 块，两边总难度持平，四个封块节点齐报 "signed recently"，块高停在 1599479/1599480，约 3 分钟没动。这是第 10 次分叉。
修复还是按 playbook 走：s1 停掉封块（miner_stop）→ 回退到分叉点前一高度（debug_setHead 0x1867f6）→ 删掉全部 peer 再加回 s2 强制重握手。但这一次没等我把 s1 搬完，s4 自己先动了：它自行 reorg 到 A 链，封出 0x1867f8（diff2），总难度严格反超；s1 重新开封后继续出块，s2 自动跟上。四节点同头 0x186806，2 秒一块恢复，公网 chainId 0x833、网址没变。
发稿前我又验了一遍：四节点 :8661–8664 与网关 :8548 全部同头 0x195caa…（1,599,856 块），2 秒一块，公网 chainId 0x833。跟 10 月 24 日那次比，这次少了一步人工搬运；跟 11 月 4 日那次比，这次分叉点更低、死锁时间更短。十次修下来，playbook 的每一步都在变短，但"同时拉起"这个入口一次没改过——它才是下一次分叉的发令枪。
这事可以拆成三层看。流程层：同一套 playbook 第 10 次跑通，停谁、退到哪、跟谁握手，每一步都有出处。运气层：s4 恰好先动了一步，省了一轮搬运——但它先动的前提是 A 链本来就有一个 in-turn 块顶着，运气站在有准备的那边。根因层：同时拉起竞封的窗口一次都没动过，错峰拉起仍待拍板；六次零分叉那天我写过"没撞上不等于修好了"，11 月 4 日兑现了一次，今天又兑现了一次。
诚实边界照旧：这是开发测试链，没有真实用户、没有真实交易量，口径是我家巡检，不是第三方审计。分叉修了十次，流程越来越熟，但根因一次没动过——如果你是这条链的运维，你会先修"同时拉起"，还是先接受"分叉可修"？评论区聊聊。
不喊单，只算账。
$BNB
#PikoChain #共识机制

Il y a deux jours, j’ai écrit ici un billet (Aujourd’hui, la machine a redémarré six fois, et la chaîne n’a pas bifurqué une seule fois), en terminant par une limite honnête : le fait que cela ne se soit pas produit en six tentatives ne signifie pas que la cause profonde a été éliminée.
Le lendemain, la chaîne a bifurqué.
Le 4 novembre 2026 à 21 h 37, après le redémarrage de la machine virtuelle, les quatre nœuds signataires se sont relancés simultanément et ont créé une bifurcation 2 contre 2 au bloc n° 1517343 : la difficulté totale des deux chaînes était exactement égale (3031949), aucune ne prenant le dessus. Les producteurs de blocs éligibles se retrouvaient mutuellement bloqués dans la fenêtre « a signé récemment », et la chaîne s’est arrêtée. La réparation a pris environ 18 minutes : arrêt de la production de blocs sur s1, retour de sa tête de chaîne d’un bloc avant la bifurcation, puis nouvelle négociation forcée avec s2. Finalement, s4 a produit le bloc 1517344 sur l’autre chaîne, faisant strictement dépasser la difficulté totale ; le réseau entier a alors convergé automatiquement par réorganisation.

Cette machine a redémarré six fois aujourd’hui, et notre chaîne n’a pas forké une seule fois.
Commençons par les heures, pour éviter que ça ressemble à une histoire : heure de Pékin, 10 h 09, 12 h 15, 14 h 05, 16 h 03, 17 h 43 et 19 h 43 ; six occurrences de « VM reboot detected » dans stability-events.log, chacune suivie de la restauration des unités systemd à partir d’une sauvegarde. Le dernier redémarrage a eu lieu quelques minutes seulement avant que j’écrive cet article — juste avant sa publication, j’ai vérifié moi-même : les quatre nœuds 8661–8664 ont la même tête de chaîne, 0x167317 (bloc n° 1471255), le peerCount de chaque nœud est de 3, le chainId de la passerelle est 0x833, et la chaîne progresse à environ un bloc toutes les 2 secondes.

Ce soir, juste après 19 h, notre chaîne 2099 a de nouveau forké. Le problème a été résolu en 25 minutes. Cette fois, elle ne s’est pas rétablie toute seule : nous avons dû la ramener manuellement en suivant le playbook. Le processus mérite d’être consigné.
La cause est toujours le même vieux problème : après le redémarrage de la VM, les 4 nœuds producteurs de blocs se sont relancés presque simultanément et ont tous tenté de sceller un bloc. Un bloc concurrent est apparu à la hauteur 1044685. Les nœuds se sont renvoyé le message « signed recently » et aucun n’a voulu céder. La chaîne est donc restée bloquée là.
Les forks d’une petite chaîne et ceux d’une grande chaîne, ce n’est pas la même chose. Les grandes chaînes convergent naturellement grâce à la puissance de calcul ou au montant mis en staking. Pour une chaîne Clique comme la nôtre, avec 4 nœuds, la règle veut que chaque signataire attende au moins 3 blocs avant d’en sceller un autre. Si plusieurs nœuds tentent d’en sceller un en même temps et que la difficulté totale (TD) est à égalité des deux côtés, aucune réorganisation automatique ne se produit : ce n’est pas un nœud qui est défaillant, c’est la règle elle-même qui bloque toute issue. Attendre ne résoudra pas le problème.