Ancien membre de retour avec seulement 4 certifications

Nodes Duniter-v1
, ,
7

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.

8

Voici le lien pour voir les événements le concernant : https://g1.duniter.fr/#/app/blockchain/search?q=5tp5GZRGfDPm3uBaadWLpJ7x6C1ZP5PkyiZoW3oe7ukH

1 Like
9

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.

1 Like
10

Je ne sais pas si cela a un rapport, mais depuis plusieurs heures la blockchain G1 est complètement bloquée !

11

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.

4 Likes
12

Mon intuition s’est vue confirmée par l’analyse suivante :

:information_source: 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

  1. Lancer une synchro jusqu’au bloc précédent l’anomalie :

    bin/duniter sync g1.cgeek.fr 284604

  2. Puis mettre un point d’arrêt sur la ligne suivante #888 :
    image
    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).

  3. 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

  4. Que voit-on ? Le protocole compte 2 certifications existantes :
    image
    Et 3 certifications entrantes :
    image
    Et bien entendu si j’évalue l’expression :
    image
    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 ? :slight_smile:

5 Likes
13

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.

1 Like
14

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.

15

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.

2 Likes
16

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).

17

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.

18

Voici ma proposition :slight_smile:

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

  1. On concatène les certifications inscrites et pending.
  2. On réduit par (‘issuer’, ‘receiver’)
  3. On compte

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])

6 Likes
19

Le langage protocolaire utilisé dans DUP est définie quelque part ou c’est utilisé que pour et dans DUP ?

20

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:

  • COUNT returns the number of values in a list of values
  • AVG computes the average value in a list of values, floor rounded.
  • MEDIAN computes the median value in a list of values
  • MAX computes the maximum value in a list of values

If values count is even, the median is computed over the 2 centered values by an arithmetical median on them, NOT rounded.

  • UNIQ returns a list of the unique values in a list of values
  • PICK returns a list of the values by picking a particular property on each record
  • INTEGER_PART return the integer part of a number
  • FIRST return the first element in a list of values matching the given condition
  • REDUCE merges a set of elements into a single one, by extending the non-null properties from each record into the resulting record.
  • REDUCE_BY merges a set of elements into a new set, where each new element is the reduction of the first set sharing a given key.
  • CONCAT concatenates two sets of elements into a new one

If there is no elements, all its properties are null .

  • NUMBER get the number part of blockstamp
  • HASH get the hash part of blockstamp
2 Likes
21

C’est tout à fait à cette solution que je pensais. :slight_smile:

1 Like
22

C’est pas du tout compliqué… :smiley:

23

Petit détail :

Dans la mesure où on a déjà sélectionné un seul receiver, est-il utile de réduire par receiver ?

2 Likes
24

En effet on peut simplifier :slight_smile:

Voici la version simplifiée :

ENTRY.enoughCerts = COUNT(REDUCE_BY(CONCAT(GLOBAL_CINDEX[receiver=ENTRY.pub,expired_on=null], LOCAL_CINDEX[receiver=ENTRY.pub,expired_on=null]), 'issuer')) >= sigQty

3 Likes
25

Ok, souhaite tu que je l’ajoute au draft de la RFC v12 ? (la version simplifiée après remarque de gerard94)

26

Oui, c’est bien d’ajouter ce correctif du protocole dans la v12.
Ça ne nécessitera pas de déclenchement par changement de version de bloc.
Juste un correctif du code qui peu être délivré à un moment différent afin de respecter cette version du protocole.

3 Likes