Utilisation d'Hydra pour extraire des données typées

Nodes lc-core-substrate
#1

A la demande d’@elois j’ai commencé à brancher Hydra sur le nœud rust. Je crée ce sujet pour le suivi et les questions que cela fait émerger. Je mettrai à jour cette description pour que ça reste une synthèse à jour de ce sous-projet.

Hydra est un framework pour extraire des données d’un nœud substrate et les mettre à disposition via une API GraphQL. Cela permet de récupérer des données qui ne sont pas accessible dans l’état actuel de la blockchain donc qui nécessite de reparcourir les blocs pour extraire ces données. Ex : liste des DU reçus par un utilisateur.

Hydra est composée de plusieurs éléments, regroupées en 2 grandes parties :

  • « l’indexer » : l’indexation des données de la blockchain au fil de l’eau que l’on peut ensuite interroger avec une interface GraphQL
  • « le processor » : la création de vues (views) à partir de ces données bas niveau et de fonctions de mapping pour les convertir en données métier, qui sont elles aussi accessible via une (autre) interface GraphQL.

Ces 2 parties sont autonomes. Le processor a besoin d’un indexer mais il n’a pas besoin forcément d’en avoir un dédié. On doit fournir à l’indexer la définition des events qu’il va rencontrer sur la chaîne (sinon il plante) et qu’il va ainsi pouvoir référencer. Donc l’indexer est spécifique à une blockchain. Dans notre cas de figure, je pense qu’un processor aura son propre indexer, pour ne pas dépendre d’un composant distant pour pouvoir extraire des données.

Dans un premier temps, je vais essayer de permettre la récupération des infos suivantes (défini par @elois ici) :

  • L’historique des transactions d’un compte (émises et reçues)
  • L’historique des DU créé par un compte
  • La liste des certifications émises et reçues par une identité, avec les méta-données qui vont bien (notamment date d’expiration de la certif).
8 « J'aime »
#2

@elois je rencontre des problèmes de version de polkadot/api : d’après mes recherches, il faudrait au moins la version 5.2.1 pour pouvoir extraire les metadonnées « V13 » ce qui semble nécessaire pour éviter une erreur (après recherches). Tu confirmes que les metadonnées sont en version « V13 » (je sais à peine de quoi je parle :laughing:) ? Est-ce que tu as eu ce problème et défini une autre version minimale pour polkadot/api ?

Le problème donc c’est qu’hydra et ses nombreux composants utilisent une version sensiblement plus ancienne (4.16.2) et qui semble limité au niveau des métadonnées.

CHANGELOG de polkadot/api : https://github.com/polkadot-js/api/blob/master/CHANGELOG.md

J’ai forcé l’utilisation de cette version dans package.json et à part quelques warning inquiétants, la génération de types semble fonctionner. Par contre, l’indexer utilise une image Docker qu’il va falloir que je modifie pour tenter le même hack

[edit] je vais chercher la version la plus basse qui fonctionnerait pour la commande typegen déjà, mais je crains que ça soit une 5.* qui impliquerait pas mal de modifications côté hydra et vu les stats du repo, cette modif me semble assez peu probable à court terme.

[edit2] bonne nouvelle ! La version 4.16.2 est suffisante et elle devrait éviter les problèmes de compatibilité. Donc problème résolu pour la commande typegen. A l’indexer maintenant

[edit3] je tente autre chose pour résoudre ce pb de compatibilité et ça semble fonctionner : j’utilise la version alpha de Hydra ; du coup l’indexer semble fonctionner

1 « J'aime »
#3

@elois autre problème/question : tu peux m’en dire un peu plus sur le fichier types-bundle/types_definition.json ? Si j’ai bien compris si c’est la source de vérité pour la partie « typage » de ce que je suis en train de faire.

Est-ce qu’il est complet ?
Est-ce qu’il est utilisé par le noeud duniter lui-même ? Par autre chose ?

J’ai plusieurs erreurs qui pourraient s’expliquer par le fait qu’il manquerait des données dans ce fichier :

  • si j’ajoute l’event « identity.IdtyLostRight » la commande typegen plante avec l’erreur Error: Cannot resolve import for type IdtyDid
  • au niveau de l’indexer j’ai des erreurs pour les blocs contenant l’event universalDividend.NewUdCreated :
    RPC-CORE: getStorage(key: StorageKey, at?: BlockHash): StorageData:: Unable to decode storage system.events:: createType(Vec<EventRecord>):: Vec<EventRecord>:: Decoded input doesn't match input, received 0x04020700e803000000000000030000000000000000 (21 bytes), created 0x04020700e80300000000000003000000000000000000000000000000000000000000000000 (37 bytes)
#4

Super @slaivyn ! Tes avancés me ravissent ! :grin:

J’ai hâte de tester ces requêtes GQL, peut être que les changements dans Gecko ne seront pas si importants que ça dans un premier temps finalement si les requêtes ressemblent grosso-modo à ce que Elois et @tuxmain ont fait avec GVA.

As-tu fais un dépot pour tester et suivre ton travail là dessus ?

1 « J'aime »
#5

Il n’y a pas encore de dépôt (j’ai pas regardé si j’avais les droits pour en créer un).
Je pense que je publierai dès que j’aurai quelque chose de fonctionnel de bout en bout avec un event simple (probablement universalDividend.NewUdCreated).

Et à ce moment là je pourrai aussi t’en dire un peu plus sur la partie GraphQL

1 « J'aime »
#6

Je ne suis pas sûr pour Hydra, mais pour les clients il faut importer ce fichier. C’est ce que fait @elois dans la vidéo de présentation de la POC à 1:30.

Il faut également l’importer pour utiliser la librairie python avec ces noeuds POC-substrate.

Je suppose qu’un import similaire doit exister dans Hydra. En espérant que ça peut aider…

#7

merci pour ces précisions !
Est-ce qu’il se pourrait que ce fichier soit en décalage avec le contenu généré par le noeud en dev ?

Cette erreur me laisse penser que ça pourrait être le cas. Et si c’est pas le cas, ça veut dire qu’il faut que je cherche ailleurs.

Et cette erreur me laisse penser qu’il pourrait manquer des infos dans ce fichier. Mais là aussi j’aurais besoin qu’on me le confirme ou non, pour que je sache s’il faut que je cherche une autre cause.

En attendant je suis un peu bloqué…