Prototype de GVA

Nodes Duniter-v1
122

3 messages ont été scindés en un nouveau sujet : Supprimer les UserID?

123

@tuxmain a implémenté la requête permettant d’obtenir les fiches de peer et les HEADs, j’aurais préféré qu’un autre contributeur y arrive, mais @HugoTrentesaux et @vit n’ont malheureusement pas poursuivi l’exercice après l’atelier :upside_down_face:

image
image1740×802 87.6 KB

5 Likes
124

C’est possible dans l’API de graphql de wotwizard

125

Bravo @tuxmain , gestion des fork au démarrage de Gecko imminente.

2 Likes
126

Pendant le hackathon, @1000i100 à passé une journée en peer programming avec moi pour implémenter la requête GVA « endpoints », cette requête vous retourne tout les endpoints connus pour l’API demandée :

image
image1534×760 106 KB

5 Likes
127

Et du coup, je vois que tu as fait le changement pour mettre endpoints dans network.
aurais-tu le commit de ce changement que je vois comment tu as fait ?

129
130

Merci !

network_db.peers_old().iter(.., |it| {
Je vois à plusieurs endroits peers_old. Pourquoi old ?

131

Pour différencier de la future collection peers qui stockera le nouveau format de fiches de peer, notamment sans les peer partagés et sans les champs obsolètes.

1 Like
132

Ca s’annonce bien tout ca ! :slight_smile:

2 Likes
133

Ajout du champ receivedTime pour les transactions en mempool: il s’agit de la date et heure de première réception du document transaction par le nœud Duniter.

À la demande de @kimamila, cette information à également été ajoutée dans BMA, dans le champ time, ce champ valait null pour les transactions en attente, il contiendra désormais la date de réception du document :slight_smile:

À noter que le champ time contenait déjà la date d’écriture en blockchain pour les transactions écrites en blockchain.

Il semblerait que le code de Cesium n’est même pas besoin d’être modifié, car la date et heure de la transaction est le résultat de l’expression time || blockstampTime

Quant à GVA, il y a déjà depuis plusieurs mois le champ writtenTime pour les transactions en blockchain :wink:

Aujourd’hui j’ai réalisé quelques tests de ce nouveau champ receivedTime et il semble fonctionner. J’ai également testé la bonne valorisation du champ time dans BMA pour les transactions en attentes, là aussi ça semble bien fonctionner :smiley:

6 Likes
134

Énorme !
Ça veut dire qu’on va pouvoir s’appuyer sur des blocs plus ancien pour émettre les TX, et limiter au maximum les risques de pertes de TX a cause de fork. :slight_smile:

La prochaine version de Cesium va être sympa (commentaires chiffrés, scan réseau en tâche de fond, TX lié au bloc HEAD - 100) !
Faut juste que je trouve du temps pour la finir :slight_smile: mais notre bébé va mieux (après des soucis les premiers mois). Je vais pouvoir sortir la tête de l’eau.

5 Likes
135

Je suppose que c’est une typo : written time

1 Like
136

Une requête importante pour plein d’outils est les certifications (liste des certifications d’une identité et toutes les certifications).

@elois penses-tu que je peux m’en occuper ? Il me semble que tous les ingrédients sont là. :man_cook:

Je pense ajouter des champs issued et received à GvaIdtyDbV1. (ou issued_certs ou certs_issued, j’hésite toujours entre l’avantage du préfixage et le respect de la grammaire anglaise)

1 Like
137

Oui tu as les compétences pour. Par contre il faut qu’on prenne bien le temps de réfléchir à quel schéma de DB, et pour cela il faut partir du besoin. Je te propose de commencer par écrire les requêtes graphql que le client doit pouvoir faire, en précisant bien quelles données il doit pouvoir obtenir.

C’est seulement à partir d’une description non-ambigue du besoin qu’on pourra réfléchir à un schéma de DB optimisé pour ce besoin :slight_smile:

1 Like
138

Des outils comme la wotmap et la worldwotmap ont besoin de la liste de toutes les certifications actives :

query {
  certifications() {
    issuer # pubkey
    receiver # pubkey
  }
}

Des clients comme Cesium ont besoin des certifications d’une identité, avec leur numéro de bloc d’écriture, et date d’écriture ou date d’expiration :

query {
  certificationsOfIdty(pubkey: String) {
    issued {
      recipient # pubkey
      block_number # ou blockstamp ?
      written_time # ou expire_time, ou les deux
    }
    received {
      issuer # pubkey
      block_number # ou blockstamp ?
      written_time # ou expire_time, ou les deux
    }
  }
}

Les différents moyens que je vois :

  • ajouter des champs issued et received dans GvaIdtyDbV1, contenant la liste des certifications. Il faudrait juste les ajouter dans la requête idty et créer une requête paginée idties.
  • pareil, mais en stockant non pas les certifications, mais leur hash. Les certifications seraient stockées dans une autre db, par hash.

Comme il faut pouvoir retrouver les certifications d’une identité, je ne vois pas comment faire autrement sans refaire un index par clé publique, et dans ce cas-là on peut utiliser gva_identities.

Avoir les certifications avec les identités rend aussi les choses plus simples pour wotmap et worldwotmap.

2 Likes
139

Ok donc on doit pouvoir :

  • Parcourir toutes les certifications
  • Parcourir toutes les certifications émises par une clé publique donnée
  • Parcourir toutes les certifications reçues par une clé publique donnée
  • Pour chaque certification, avoir comme information: émétteur, receveur, numéro de bloc de création, numéro de bloc d’écriture (toutes dates pouvant être récupérées où calculer à partir de ces données).

De plus, il faut penser aux besoins d’indexation et de revert. On doit donc pouvoir mettre à jour une certification (renouvellement) sans en créer une nouvelle. On doit également pouvoir supprimer une certification lorsqu’elle expire (car cet event n’est pas déclaré dans les blocs).

En vue de ces besoins, voici comment je modifierai la DB :

  1. Ajouter une collection certifications dont la clé est issuer || target et la valeur une struct du genre:
GvaCertDbV1 {
  created_on: BlockNumber
  written_block: BlockNumber
}
  1. Ajouter une collection certs_by_expire avec comme clé U64BE et comme valeur Vec<(Pubkey, Pubkey)>
  2. Ajouter un champ certifiers: Vec<Pubkey> à la struct GvaIdtyDbV1.

Et c’est tout, je te laisse réfléchir à pourquoi c’est suffisant pour répondre correctement à tous les cas :wink:

140

Pour gagner de la place on peut remplacer la clé par un id en u64, sled permet de générer un id garanti unique, il faut juste que je ré-expose cette fonction :slight_smile:

Au lieu d’avoir 6 clés publiques par certification on aurait alors 4 id et 2 clés publiques. Soit 4 x 8 + 2 x 33 = 96 octets par certification au lieu de 5 x 33 = 165 octets par certification.

Ce qui donne :

  1. Ajouter une collection certifications dont la clé est U64BE et la valeur une struct du genre:
GvaCertDbV1 {
  issuer: Pubkey,
  receiver: Pubkey,
  created_on: BlockNumber,
  written_block: BlockNumber,
}
  1. Ajouter une collection certs_by_expire avec comme clé U64BE et comme valeur Vec<u64>
  2. Ajouter les 2 champs certifiers: Vec<u64> et certified: Vec<u64> à la struct GvaIdtyDbV1.
141

Ok, juste une question : pourquoi certs_by_expire ? pour WotWizard ?

Edit: ou c’est parce que l’expiration de la certification n’est pas dans le bloc ?

donc pour ajouter une certification, il faut d’abord vérifier en parcourant les certifications listées dans le champ certified de l’issuer qu’il n’en existe pas une ayant les mêmes issuer et receiver ; si oui, la modifier, si non, la créer.

142

Oui c’est ça, je l’ai dit plus haut :

Exactement, bien vu :slight_smile:

Donc le champ certified ne sera pas un Vec mais un HashSet :slight_smile:

1 Like