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.

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.