Les données migrées de la v1 à la v2 concernant l’aspect monétaire sont uniquement les soldes.
Dans l’écosystème v2, la manière de récupérer l’historique des transferts pour les clients est uniquement via les indexeurs et non via RPC. Est-ce correct ?
Est-il possible d’insérer les transferts dans le bloc #0 ou une autre BDD de Duniter v2s ?
Si non, les insérer (“harcoder” une BDD historique transferts v1) dans les indexeurs me semble caduc.
Il faudrait migrer l’historique des transferts (avec condition de déverrouillage simple avec signature SIG()) en convertissant uniquement les non-UTXO du transfert, car des derniers n’apportent rien dans l’écosystème v2 (qui est un mécanisme de fonctionnement de la v1) :
A envoie 10 à B, il casse une source de 20 et renvoie 10 à lui-même.
A: 10 −> B: 10 (on migre cette information)
A: 10 −> A: 10 (UTXO : information non migrée)
Qu’en pensez-vous ? Est-ce que ça vaut la peine, si possible techniquement, qu’on se donne la peine de migrer l’historique des transferts qui ont eu lieu dans l’ère de la v1 pour pouvoir les afficher avec les clients de l’écosystème v2 ? Une fois la migration faite, aller consulter l’historique avec un client v1 sur une instance Duniter v1, ça fait un peu rédhibitoire. Cela dit, consulter l’historique v1 un an ou deux ans après la migration ne ferait peut-être plus très sens.
On pourrait faire vivre une blockchain substrate de manière totalement artificielle avec un bloc toutes les ~ 5 minutes dans le passé et un timestamp_set correspondant au median_time des blocs v1, puis un runtime upgrade qui retire le sealing manuel et passe à une blockchain “live”. J’y ai pensé au tout début parce que ce serait très satisfaisant d’un point de vue conceptuel, mais vite abandonné l’idée parce que bien trop complexe à réaliser, ça n’en vaut pas la peine à mon avis.
Oui, ça vaut la peine, est c’est précisément ce qu’on fait au niveau de l’indexeur duniter-squid, comme tu le dis (oui, c’est correct) :
Mais ça ne doit bien sûr pas être la seule manière, il faudra conserver une archive exhaustive de la blockchain (au format json par exemple, comme je le fais là) pour pouvoir retransformer à volonté de manière statique les données source dans le format qui nous conviendra, que ce soit dans les indexeurs, ou même une API dédiée semblable à BMA servie par une sous-partie de Duniter.
Pour Gexplore j’avais imaginé faire deux backends DUBP et Substrate respectant chacun leurs propres numéros de blocs, et un troisième capable de chaîner les deux, en adaptant les données. L’indexeur utiliserait ce dernier backend.
Le but de Gexplore est justement d’explorer l’historique donc ce serait dommage d’oublier des années d’états de la TdC.
Ça oblige soit à rendre très génériques les données indexées, soit à adapter les données v1, soit à indexer deux formats différents.
Du point de vue d’un tel indexeur, si on veut que le bloc 0 de la v2 soit bien un bloc 0, il faut trouver une convention pour numéroter les blocs v1, idéalement qui conserve l’ordre lexicographique et l’ordre numérique et qui soit transparente (sans besoin de calculer pour retrouver le numéro v1). Je n’ai pas de solution vraiment satisfaisante (par exemple pour nommer le bloc 123 de la v1 : 100000000123, dubp123, --123). La notation avec préfixe explicite semble plus pérenne (et si on change à nouveau de blockchain dans 10 ans ?).