Ğ1-test bloquée : bloc généré mais refusé de part sa taille


#41

Bon mon nœud est bloqué depuis ce matin minuit.

J’ai repéré une source potentielle de fork :

|   block |  gentime  |  mediantime  |    hash    |   uid    |
|---------+-----------+--------------+------------+----------|
|  314712 | 23:54:36  |   23:23:22   | 0001FA6EC6 |   Elois   |
|  314711 | 00:05:43  |   23:20:21   | 0004784CF4 | inso2018  |
|  314710 | 23:45:40  |   23:18:08   | 0000DC8C15 |   Elois   |
|  314709 | 23:56:48  |   23:14:39   | 00008D423B | inso2018  |
|  314708 |*23:41:24* |   23:12:16   | 00001B658C |   Elois   |
|  314707 |*23:52:48* |   23:08:50   | 00014D0841 | inso2018  |
|  314706 | 23:38:39  |   23:06:28   | 000188DB4D |   Elois   |
|  314705 | 23:49:31  |   23:03:08   | 00007ACDC6 | moul-test |
|  314704 | 23:36:02  |   23:00:45   | 0002B70CDD |   Elois   |
|  314703 | 23:46:44  |   22:57:24   | 00007C5272 | moul-test |

La date de génération du bloc 314708 est inférieure à celle du bloc précédent.
À priori le nœud d’inso a suivit cette branche, mais pas le mien.
J’ai vérifé que ça n’est pas la cause du fork majeur que vit actuellement la Ğ1-test au bloc 312709.


#42

Bon, je me suis synchronisé et a fait tourné mon nœud sur les deux branches :

  • sur la branche de cgeek-2 et Jyt ça fonctionne bien.
  • sur la branche de inso2018 et Elois, je ne reçois pas les nouveaux blocs, du coup, mon nœud s’isole.

#43

Par contre je n’arrive pas à créer de blocs… il va falloir que j’investigue car j’ai fait des changements réseau, mais je vais devoir trouver le temps…


#44

Il y a trois branches actuellement :


#45

Et au passage, l’adhésion d’ inso2018 viens d’expirer.


#46

Merci pour ces précisions, Moul. Cgeek nous expliquera sans doute comment 3 branches distinctes ont bien pu se créer…


#47

D’après les éléments dont je dispose, c’est en réalité ce nœud qui est sur la mauvaise chaîne, tandis que g1-test.cgeek.fr est sur la bonne.

Pour affirmer cela, et sachant que le recalcul du DU est intervenu 727 blocs plus tôt (bloc#311981, donc), j’ai tenté de synchroniser les versions 1.6 et 1.7 jusqu’au point de fork (bloc#312708), à la fois avec une fenêtre de fork :

  • courte (= 100 blocs, valeur par défaut), afin de voir la valeur du DU calculée par l’algo de synchro rapide
  • longue (= 5000 blocs en l’occurrence), afin de voir la valeur du DU calculée par l’algo normal d’ajout de bloc

Dans la version longue, on peut donc même constater le passage de l’ancienne valeur à la nouvelle, cela fait partie de la table b_index du protocole et cela va bien nous aider à comprendre quelle valeur est légitime.

Résultat :

  • version courte Duniter 1.6 et 1.7 : le DU est de 28,46 ĞT[base 1]
  • version longue Duniter 1.6 et 1.7 : le DU est de 29,69 ĞT[base 1]

Et même plus profondément, Duniter 1.6 et Duniter 1.7 sont totalement d’accord sur l’intégralité des valeurs de la table b_index. Mais au sein d’une même version, l’algorithme de synchronisation rapide ne produit pas le même b_index. C’est là le bug :confused:

Au final, le DU est bien de 29,69 ĞT[base 1] et non pas de 28,48 ĞT[base 1].

Je peux l’affirmer car la formule DUĞ = DU(t) + c²*M/N nous indique que pour que le DU stagne (cas de la branche du nœud legacy.g1test.nordstrom.duniter.org), il aurait fallu une violente augmentation de N (ce qui n’est pas le cas), et même dans ce cas Duniter utilise un arrondi supérieur qui fait que le DU aurait au moins dû prendre +0,01ĞT[base 1].

Je n’ai pas encore été voir où se situait précisément le bug, mais ça ne sera pas très difficile de trouver. Ticket#1338 créé. Une amélioration évidente serait que la sychro n’ai plus son propre code et utilise le même que l’ajout normal de bloc. Maintenant que la base de données est plus rapide, ça s’envisage, je vais voir.

En attendant, je vous conseille donc synchroniser sur g1-test.cgeek.fr et délaisser celle du nœud “legacy”.


#48

+1000. Si on remonte l’historique une grande partie des bug survenues en prod étaient liés a cette différence de code entre l’apply de la synchro rapide et l’apply normal.

Dans DURS je suis parti sur un seul code d’apply pour les 2 cas et j’ai une synchro en 15s donc je pense que le temps de synchro de Duniter devrait rester très raisonnable en appliquant les blocs de façon “normale” :slight_smile:


#49

Oui, même en étant 20 fois plus lent ça ferait 5 minutes ce qui est largement acceptable. Je ne vois pas encore bien ce qui coûte, mais 200k blocs, 350k sources, 15k transactions, 14k certifications, 1,6k identités … ça n’a rien d’insurmontable pour une machine de nos jours.


#50

J’invite @elois, @jytou et @bobvador à rejoindre la bonne branche sur g1-test.cgeek.fr.


#51

C’est en cours de synchro…


#52

j’ai sync, mais je ne sais pas si je suis sur la bonne branche


#53

Le bloc 312709 de ta blockchain doit avoir pour hash :

"hash": "000082D0D8C9B8B08100A6360F8DAE63893EB1A1C7417028E9B7E0FB0BAB988D"

Exemple sur mon nœud : https://g1-test.cgeek.fr/blockchain/block/312709


#54

j’ai du mal faire quelque chose car j’ai Cannot GET /blockchain/block/312709

ça peut s’interroger dans le terminal du serveur ?


#55

As-tu activée l’API BMA, c’est elle qui permet d’interroger ainsi le nœud.


#56

Ben moi je comprends plus rien. Je me suis sync à ton noeud cgeek, mais je crois pas que ça marche. Je vais laisser le truc tourner, et quand on y verra plus clair je me raccrocherai au bon :slight_smile:


#57

La dernière fois que j’ai regardé, tu étais sur la bonne branche


#58

Pour moi, sur cesium, y’a que Bobvador qui calcule. Mon noeud est dans les limbes. Mais bon, s’il est sur la bonne branche, c’est déjà ça !


#59

Bonne question, dès que je peux me connecter au serveur je le relance en mode web pour vérifier.

quand je regarde sur Césium aussi je vois que plus rien ne bouge depuis le 31/01, doit surement y avoir un problème avec ça.


#60

non, ce n’était pas activé, j’essaie de trifouiller quelques options pour débloquer l’accès