Aujourd’hui, cette chaîne a été redémarrée 7 fois, sans aucun fork.
De 06:38 à 18:32, la machine virtuelle a été redémarrée 7 fois en une journée. À chaque fois, même procédure : revive-all restaure les units depuis la sauvegarde, toute la pile redémarre et les 4 nœuds producteurs de blocs se reconnectent. Aucun fork lors de ces 7 redémarrages, et la hauteur des blocs a augmenté tout du long, à raison d’un bloc toutes les 2 secondes. J’ai vérifié manuellement celui de 16:23 : deux minutes après le redémarrage, les quatre nœuds étaient sur le même hash, 1678996 ; 12 secondes plus tard, ils étaient sur la même tête, 1679006, et la hauteur continuait d’augmenter. Nouvelle vérification avant publication : les quatre nœuds sont sur la même tête, 0x19b780 (bloc 1,686,656), et le chainId de la passerelle est 0x833.
En ajoutant les 2 fois comptées dans le post d’hier, cela fait 9 redémarrages consécutifs sans fork depuis celui du matin du 7 novembre.
Ne nous réjouissons pas trop vite. La cause du fork n’a pas changé d’un iota : les 4 signers démarrent en même temps et se disputent le scellement du bloc suivant ; dès que la TD est à égalité, ils se bloquent mutuellement. Lors de celui du 7 novembre à 07:25, au bloc 1620285, la TD du bloc hors tour de s1 et celle du bloc dans le tour de s2 ne différaient que de 1, et ça a quand même bloqué pendant une ou deux minutes. La solution consistant à décaler les démarrages attend toujours d’être approuvée et n’a pas été mise en place ; derrière ces 9 redémarrages sans incident, pas une ligne de code ni de configuration n’a été modifiée.
Alors, comment expliquer ces 9 fois ? Trois possibilités, que je ne peux présenter que comme des hypothèses :
Premièrement, la chance. La compétition pour sceller un bloc est aléatoire ; 9 fois sans incident, c’est peut-être simplement 9 piles d’affilée, et la face peut tomber la 10e fois.
Deuxièmement, un décalage des horaires de démarrage. À chaque fois que revive-all restaure les units, l’ordre et les intervalles varient légèrement. Les nœuds ne démarrent donc pas exactement en même temps, ce qui a involontairement décalé la fenêtre de compétition pour sceller le bloc.
Troisièmement, un échantillon trop petit. D’un point de vue statistique, 9 fois ne prouvent rien ; au mieux, cela signifie « pas de problème récemment ».
Mon avis : « redémarrer sans fork » ne signifie pas « le problème de fork est corrigé », mais seulement « il n’y a pas eu de fork cette fois-ci ». Le critère de vérification ne change pas non plus : un processus actif et un port ouvert ne suffisent pas ; il faut que les quatre nœuds soient sur la même tête et que la hauteur des blocs augmente. Continuons à compter : si le prochain redémarrage provoque un fork, le compteur de 9 repartira de zéro.
J’ajoute au passage une note honnête : pour le fork du matin du 7 novembre, les deux journaux ne s’accordent pas sur le fait qu’il ait été « corrigé manuellement ou résorbé de lui-même ». Je ne peux toujours pas réconcilier leurs versions, alors je le note tel quel, sans en inventer une.
Cette chaîne reste une chaîne de développement et de test, sans utilisateurs ni transactions réels. Et nos propres inspections ne constituent pas un audit indépendant. Mais ce chiffre de 9 mérite d’être consigné : il montre au moins qu’un fork n’est pas inévitable à chaque redémarrage.
La vraie question : si vous faites tourner votre propre chaîne, après un redémarrage, vérifiez-vous d’abord le processus ou que les quatre nœuds sont sur la même tête ? Racontez-moi en commentaire.
Pas de conseil d’achat, juste les faits.
$BNB
#PikoChain #MécanismeDeConsensus