Masse monétaire fausse puis réajusté dans la blockchain

Bonjour,
Je me suis aperçu d’un petit bug dans la blockchain (en fonction des nœuds).
Ceci se produit de temps en temps, j’ai noté les deux plus récent que j’ai trouvé.

Sur le nœud de @cgeek
Bloc → masse monétaire :
Bloc 471 680 → 32 439 798 73 (création du DU du 04/11/2021)
Bloc 471 749 → 32 439 798 73 (en unité tel qu’écrit dans la blockchain)
Bloc 471 750 → 32 478 071 39 (sans que des DU ne soient créé sur ce bloc).
Bloc 471 961 → 32 516 344 05 (Création du DU du 05/11/2021)
Bloc 471 962 → 32 478 071 39 (réajustement, même masse qu’au bloc 471 750).

Dernier bug trouvé :
Bloc 475 031 → 32 903 988 89 (création du DU du 15/11/2021)
Bloc 475 249 → 32 903 988 89
Bloc 475 250 → 32 943 241 03 (sans création de DU)
Bloc 475 302 → 32 982 493 17 (création de DU du 16/11/2021)
Bloc 475 303 → 32 943 241 03 (réajustement → masse idem ligne 2)

Sur les nœuds de @fdrubigny (https://duniter.adn.life/blockchain/block/471749) et de @ofontes (https://duniter.occitanet.fr/blockchain/block/471749) ces bugs n’existent pas (je n’ai vérifié que ces trois là), les masse monétaires affiché sont celle du premier bloc cité puis lors du DU celle du dernier cité.

Ce bug est-il un problème lors d’une synchronisation si celle-ci se fait sur le noeud de @cgeek ?
Le nœud de @cgeek serait-il médium puisqu’il devine la masse monétaire (et donc le nombre de membre) lors du prochain DU? :grin:
Est-ce un problème à ignorer car il sera inexistant sur substrate?

5 « J'aime »

C’est sûrement lié à la synchro en effet, ou bien à la résolution de fork. Donc oui je dirais que l’on peut ignorer, Substrate s’occupe déjà de ces points. Enfin le mieux est encore de rester vigilant comme tu l’as fait, c’est bien vu, merci :slight_smile:

2 « J'aime »

C’est surtout du hasard… :wink:

1 « J'aime »

En fait ce n’est pas un bug de la blockchain puisque les blocs que s’échangent les nœuds ne contiennent jamais la masse monétaire explicitement. Ce bug doit donc toucher seulement les clients utilisant BMA.

Un bug de ce genre qui a mis 5 ans à être détecté ! C’est là qu’on voit que c’est pas mal de systématiser les tests unitaires… :face_with_monocle: :test_tube:

4 « J'aime »

Oui en effet, ce champ n’est pas dans le protocole. C’est du spécifique BMA, je viens de revérifier. Ce n’est donc pas critique comme bug.

Oh mais j’en ai systématiquement écrit :slight_smile: Ce n’est pas un hasard si Duniter tourne depuis bientôt 5 ans. Eloïs disait d’ailleurs à une époque être surpris que Duniter fonctionne malgré son code. Mais j’ai toujours répété que le cœur de la valeur du code de Duniter c’était ses tests, environ 700 sur ce projet.

Ceci dit, d’une part la couverture du code n’est pas de 100%. C’est surtout le protocole qui est balisé par les tests, l’API BMA l’est moins.

Mais d’autre part même couvrir 100% du code n’est pas couvrir 100% des combinaisons de scénarios possibles : ce dernier cas est inatteignable. Donc il faut forcément faire des choix, mettre le curseur à un niveau acceptable, ce qui est subjectif.

Bref, « systématiser les tests », oui, mais ne nous laissons par aveugler par la méthode : elle n’est pas une garantie absolue.

C’est comme un théorème mathématique : qui dit qu’il est vrai ou faux ? C’est la relecture par des humains de la démonstration associée, avec toute la faillibilité qui les caractérise.

En ce bas monde je ne vois pas de preuves, que des observateurs.

Désolé, c’était mon petit moment @Galuel :slight_smile:

6 « J'aime »