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.