Quel indexeur utiliser et scan réseau

kimamila · 9 January 2024 06:15

Du coup @HugoTrentesaux tu me conseilles de partir sur quoi comme indexeur, pour Cesium ² ? Squid ?

Et aussi, la question de la cohérence des indexeurs ne va t’elle pas se poser, comme sur les pod Cesium + actuels ? C’est a dire qu’il faudra peut-être scanner le réseau, côté client, pour déterminer quels couples de noeuds Duniter + indexeur utiliser ?
Cela est d’autant plus vrai que dans Duniter v2 une app cliente ne peut quasiment rien faire sans l’indexeur (par exemple : pas d’affichage de l’historique des TX sans indexeur…)

J’ai déjà soulevé ce problème au début de duniterv2s mais on m’avait répondu : “non non il ne peut pas y avoir de problème de désynchronisation. Il faut juste tirer au sort les noeuds dans une liste.” J’ai toujours du mal a le croire… Un client p2p ne peut en principe faire confiance qu’à ce qu’il vérifie… Corrigez moi si je trompe svp.

Si c’est exact alors il faut que les clients implemente un scan réseau. Non ?

HugoTrentesaux · 9 January 2024 09:51

Tu m’a déjà posé la question ici :

Ce à quoi j’ai répondu :

Donc oui, je te conseille de partir sur squid, avec les exemples de requêtes données dans ce sujet. Même si attention, ça peut quand même encore bouger, d’une part parce qu’il va y avoir des évolutions côté Duniter, et d’autre part parce que le schéma actuel n’est pas forcément optimal.

Pour le reste, je réponds là et je déplacerai dans un nouveau sujet pour mieux s’y retrouver.

Les indexeurs ne font qu’indexer la blockchain, donc tant que :

ils ont le même genesis
ils sont sur le même réseau
ils sont sur un noeud synchronisé
leur propriétaire n’a pas altéré les données

ils devraient avoir les mêmes données. Mais évidemment il est possible de ne pas respecter ces règles et de truquer les données de l’indexeur. Deux possibilités : l’omission et l’ajout. Dans le cas de l’omission on peut avoir l’info via un autre indexeur ou en blockchain, mais c’est compliqué de savoir ce qui manque. Dans le cas de l’ajout, comme chaque entrée est identifiée par l’event id (block_number-block_hash-event_number), il suffit de vérifier si l’événement existe en blockchain à ce bloc et si l’info est correcte.

De ce que j’ai compris il y a deux types d’infos sur les pods Cesium+ : des infos venant de la blockchain (comme les DU perçus) et des infos externes (comme le nom d’affichage). Alors que dans duniter-squid, il n’y aura a priori que des infos en blockchain, sauf si on décide d’y intégrer les données hors chaîne.

Oui. À moins d’avoir une liste hardcodée de confiance pour les indexeurs, dont la seule défaillance possible est d’être hors ligne, il faudra toujours à un moment trouver un indexeur qui répond. Mais pour Duniter, il y a l’option light node qui permet d’utiliser directement la synchro p2p pour avoir un unique endpoint local sûr.

Il peut toujours y avoir un problème de désynchronisation, il suffit d’être hors ligne pour que ça se produise.

@poka sait mieux que moi mais il me semble que polkadotjs implémente déjà un “scan réseau”, on peut lui donner une liste de nœuds et il établit la connexion avec un nœud en ligne et à jour.
Et de manière générale, la finalisation permet d’être sûr que les données incluses dans un bloc ne seront pas rollback. Si le dernier bloc finalisé est trop vieux (~ plus de 1 minute) alors soit il y a un problème sur le réseau, soit on est sur un nœud qui n’est plus connecté aux autres. C’est assez différent de Duniter-v1 où le rollback maximum (probabiliste) était de 100 blocs de 5 minutes soit plus de 8h.

kimamila · 9 January 2024 11:36

Merci pour ta réponse, @HugoTrentesaux .

Du coup, vous êtes bien d’accord que rien n’empêche un propriétaire d’indexeur ne le connecte à un noeud qui n’est pas hébergé par lui ? Ou bien tout simplement hébergé par une autre de ses machine ?
Dans ce cas, si le noeud Duniter tombe (ou pb réseau pour y accéder depuis l’indexeur, etc.), bref s’il n’est pas joignable, alors l’app aurait bien accès à un indexeur joignable, mais plus à jour vis à vis du réseau (ddonc en retard). Non ?

Pour moi, rien ne garanti donc qu’un couple de noeuds [Duniter, indexeur] soit cohérent, relié et joignable, sans que l’app ne le teste… C’est donc plus compliqué que pour Duniter v1, car il faut tester chaque élément du couple (dans Duniter V1 le pod n’était pas essentiel : il pouvait donc etre en retard).

Une alternative serait que les indexeurs puissent agir comme des proxy : s’il recoivent un call, par exemple, ils le relaient au noeud Duniter indexé. Si c’est une appel graphQL, alors ils l’executent eux même.

Si le noeud Duniter n’est plus joignable par l’indexeur, alors l’indexeur pourrait avertir le client (par exemple avec une requete hrapQL ou REST status ou health).
Ainsi on aurait un seul type de noeud à scanner côté client : les indexeurs (et une seule API) réputé toujours cohérent avec lui-même.

n’hésitez pas à me dire où je me trompe…

poka · 9 January 2024 12:53

Oui on va définitivement passer sur Squid et lâcher le brave indexer Hasura de manu qui nous aura bien servi pour la phase de développement.
Il y a pas mal de bugs à manager à la main là ou squid automatise des choses et le fait mieux.

Concernant le couple [Duniter, Indexer], pour le moment dans gecko je fais une confiance aveugle aux listes de endpoint renseignés en dur: Je laisse la lib polkadot.js sélectionner un noeud parmis une liste ransomisé que je lui donne, et je me connect au premier indexer renseigner dans la liste ou bien celui qui a été sélectionné par l’utilisateur si il a fait un jour.

Si on veut garantir que l’indexer est bien sync sur le même noeud Duniter que l’app, pour moi le plus simple est de vérifier que le parentHash du bloc babe le plus haut correspond:

Duniter:

Squid:

query {
  blocks(orderBy: height_DESC, limit: 1) {
    height
    parentHash
  }
}

→

{
  "data": {
    "blocks": [
      {
        "height": 579324,
        "parentHash": "0x6835d9bb5d469d2826b84407755122d9bbaeb3b933dc8a000d0edc1ff5644b4e"
      }
    ]
  }
}

Après à déterminer si on ne fait ça qu’au démarrage de l’app, ou régulièrement pendant le cycle de vie de l’app, je ne sais pas.

Squid est censé rollback automatiquement en cas de fork du réseau, mais j’avoue n’avoir aucune idée de comment il gère ça, ça mérite que l’on creuse le fonctionnement de Squid là dessus.