GerardSiegle (5tp5GZRGfDPm3uBaadWLpJ7x6C1ZP5PkyiZoW3oe7ukH) vient de revenir dans la toile au bloc 284605. Le problème, c’est qu’il n’a que quatre certifications valides (et une en attente, de RoselyneBinesse). Bug ?
J’ai vérifié sur plusieurs nœuds, la situation est chaque fois la même.
Le nœud de cgeek, qui a calculé le bloc, est injoignable par Cesium.
il a pu redevenir membre juste avant qu’une certification soit devenue obsolète ?
Ce n’est pas le cas. Mais, de toutes façons, avec quatre certifications, il ne peut pas le rester.
Cas d’étude intéressant. Merci de remonter le potentiel problème.
Il faudrait des preuves tangibles montrant que l’identité a peu entrer de nouveau dans la toile avec quatre certifications. Qu’il n’y en avait pas cinq lors du renouvellement de l’adhésion. A-t-on cette information (les anciennes certifications expirés) dans les bases de données des nœuds (peu importe l’implémentation) ?
Autrement, oui, il y a un bug, il devrait être exclu immédiatement, étant donné qu’il ne respecte pas la règle du nombre de certifications. Il me semble qu’à chaque bloc est vérifié que chaque membre respecte les conditions pour maintenir le statut de membre. Autrement, c’est exclusion.
Bug à explorer… et à corriger.
La capture d’écran de Cesium ci-dessus en est déjà une. Les mêmes informations sont affichées (aujourd’hui encore) par WotWizard (qui m’a permis de détecter le problème). Sans doute que Silkaj doit pouvoir afficher des informations semblables. Sinon, on peut décortiquer la blockchain à la main.
Le problème devrait être régularisé ce soir à partir de 20h35 (BCT) puisque c’est l’heure où la certification supplémentaire de RoselyneBinesse devrait passer, en cinquième position. Si on y arrive, car, pour l’instant, on a un joli fork sur G1.
Voici le lien pour voir les événements le concernant : https://g1.duniter.fr/#/app/blockchain/search?q=5tp5GZRGfDPm3uBaadWLpJ7x6C1ZP5PkyiZoW3oe7ukH
Merci @kimamila.
À partir des données de Cesium fournies ci-dessus, et de celles de WotWizard concernant les entrées/sorties de la toile, j’ai pu reconstituer les mouvements suivants concernant l’adhésion de GerardSiegle :
↑ Entrée ↓ Sortie C Certification
↑ 74673 03/12/2017 15:59:47
C auroremengual
C NadineBlanchard
C Aude49
C AlainLebrun
C AnneAmbles
C RoselyneBinesse
96857 21/02/2018
C CharlesAbecassis
106456 27/03/18
C loanblanchard
↓ 168097 05/11/2018 01:53:16
↑ 177452 08/12/2018 14:33:33
↓ 270491 10/11/2019 03:10:06
↑ 284605 30/12/2019 19:16:00
C AlainLebrun
C AnneAmbles
C CharlesAbecassis
Le 30/12/2019, GerardSiegle disposait encore d’une ancienne certification de loanblanchard et des trois nouvelles certifications d’AlainLebrun, AnneAmbles et CharlesAbecassis. Par contre les certifications d’auroremengual, de NadineBlanchard, d’Aude49 et de RoselyneBinesse, qui n’avaient pas été renouvelées étaient invalides. Mais il est bien revenu dans la toile avec quatre certifications valides au total.
Je ne sais pas si cela a un rapport, mais depuis plusieurs heures la blockchain G1 est complètement bloquée !
Intuitivement je dirais que c’est la certification de CharlesAbecassis qui a été comptée en double amenant le total à cinq au bloc 284605. En effet, c’est la seule certification qui était encore valide avec celle de loanblanchard.
Pour vérifier j’aurai besoin de meilleures conditions de concentration, donc je verrai ça au mieux dimanche après-midi, sinon plus tard dans la semaine.
Mon intuition s’est vue confirmée par l’analyse suivante :
N.B.: Opérations à réaliser depuis l’environnement de développement, c’est-à-dire après
git clone https://git.duniter.org/nodes/typescript/duniter.git -b dev yarn
Lancer une synchro jusqu’au bloc précédent l’anomalie :
bin/duniter sync g1.cgeek.fr 284604
Puis mettre un point d’arrêt sur la ligne suivante #888 :
Ce code est la partie que je soupçonnais de mal compter le nombre de certifications lors de l’entrée / le renouvellement de l’adhésion du membre. Ce code reflète le protocole (regarder la règle BR_G27).
Et enfin exécuter la commande qui “pull” (tire vers le nœud local) le bloc suivant #285605 :
bin/duniter pull g1.cgeek.fr 285605
Que voit-on ? Le protocole compte 2 certifications existantes :
Et 3 certifications entrantes :
Et bien entendu si j’évalue l’expression :
Bingo ! GerardSiegle rentre parce que le protocole compte 2 fois la même certification (celle entrante existe déjà dans la blockchain). On obtient 2 + 3 >= 5 => true.
Bref, tout cela est parfaitement conforme au protocole. De ce point de vue il n’y a pas de bug.
Oui mais, relativement à la licence, il y a bien un soucis. Manifestement GerardSiegle est rentré avec 4 certifications.
Du coup, des avis pour patcher le protocole ? 
Ne pas compter soit l’actuelle soit le rejeu d’une certification de A vers B.
Ce bug du protocole a été introduit lors de l’ajout du rejeu des certifications.
Ce code l’a fait entré, et d’autre part, une autre partie du code essayait de l’exclure.
En effet, il y a bien un rapport.
Oui bien sûr, mais la difficulté c’est de traduire ces idées en langage du protocole.
Est-ce que compter les certifications au global peu importe leurs statuts (existing, pending) simplifierait la règle du protocole ? Ça permettrait de déduire les mêmes certifications (A −> B) entre l’actuelle et le rejeu.
On compare l’émetteur des certifications existantes et en attente, il n’y en a pas beaucoup. Si un émetteur est le même, on ne compte pas la certification existente (ou en-attente, au choix). On peut aussi vérifier que la date de péremption de la première ne se confond pas avec celle d’arrivée de la deuxième (je dirais à 5 minutes près, date moyenne entre deux blocs successifs ; c’est l’approximation que j’utilise dans WotWizard; la probabilité de se planter est alors très faible).
Ou alors, annuler d’abord l’existante et attendre le bloc suivant pour inscrire la nouvelle. Ça paraît simple, mais finalement il y a plein de conséquences possibles.
Voici ma proposition
ENTRY.enoughCerts = COUNT(REDUCE_BY(CONCAT(GLOBAL_CINDEX[receiver=ENTRY.pub,expired_on=null], LOCAL_CINDEX[receiver=ENTRY.pub,expired_on=null]), 'issuer', 'receiver')) >= sigQty
REDUCE_BY est déjà utilisé avec 3 paramètres dans la BR_G39 :
ENTRY.stock = COUNT(REDUCE_BY(GLOBAL_CINDEX[issuer=ENTRY.issuer], 'receiver', 'created_on')[expired_on=0])
Le langage protocolaire utilisé dans DUP est définie quelque part ou c’est utilisé que pour et dans DUP ?
C’est défini au début de la RFC ici :rfc/0009_Duniter_Blockchain_Protocol_V11.md · master · nodes / common / doc · GitLab
Extrait :
Function references:
If values count is even, the median is computed over the 2 centered values by an arithmetical median on them, NOT rounded.
If there is no elements, all its properties are
null.