Je profite que @kimamila soit dans le coin pour évoquer à nouveau ce sujet : comment va-t-on réaliser la bascule entre Duniter v1 et Duniter V2S ?
Je souhaite autant que possible une continuité de service, que la chose soit à peu près transparente pour les utilisateurs.
Néanmoins, il y aura forcément un “grand soir” où la blockchain V2S s’appuiera sur l’état de la Ğ1 à un instant donné et bootstrapera dessus pour son block#0. Ce qui signifie que tous les blocs de la blockchain V1 consécutifs au bloc pris en référence seront ignorés par la V2, et que les utilisateurs doivent être accompagnés dans cette transition.
C’est un hard-fork, mais sous stéroïdes : en effet même les clients ne vont plus être compatibles avec la V2, là où un hard-fork classique pourrait conserver cette compatibilité.
Je ne sais pas quelle solution s’offre à nous, je ne me rends pas compte des clients qui sont utilisés. A mes yeux le gros du gros pour un utilisateur non-averti c’est Cesium, tandis que les utilisateurs d’autres clients sont déjà plus proches du développement et sauront gérer la transition tous seuls (installer les nouveaux clients, stopper l’utilisation des anciens sur l’ancienne blockchain). Mais j’aimerais que vous me confirmiez cette vision.
Et si celle-ci s’avère vraie, comment vois-tu la chose @kimamila côté Cesium ?
Côté Duniter V1, c’est assez délicat de faire évoluer le réseau (voir la version 1.8.7) donc je ne sais pas si l’on peut compter sur les nœuds pour apporter un “hard-stop” à tel ou tel bloc par exemple.
Une version de Duniter v1 pourrait être programmée pour s’arrêter à la date de la migration. Ça permet aux admins de nœuds v1 de la faire tourner jusqu’au bout, sans contribuer à faire tenir la “vieille branche”.
L’arrêt de la plupart des meilleurs nœuds BMA (qui sont probablement les mieux maintenus donc les plus susceptibles d’être réactifs pour installer la màj ?) devrait suffire à décourager l’utilisation des clients v1.
Les clients grand-public (Cesium, G1nkgo, superbot) pourraient afficher un avertissement avec les instructions pour installer un client v2 et migrer son compte.
Je crois qu’on avait prévu une fausse migration avant, pour tester et préparer les utilisateurs. Les clients v1 pourraient aussi faire passer ce message, pour que la procédure ressemble le plus possible à celle de la vraie migration.
La difficulté que j’essaye de soulever, c’est que les clients v1 comme Cesium ne sont pas forcément mis à jour non plus. Alors comment alerter les utilisateurs dans ces conditions ?
Il y a peut-être un moyen dans Cesium d’afficher un message d’alerte peu importe la version, mais je ne le connais pas.
Oui bien sûr, même plusieurs ! Un mois avant, deux puis une semaine avant, quelques jours, J-3, J-1 et J.
Mais le point ultime d’accès est bien l’application cliente, ceux qui ne verraient pas les diverses annonces devraient au moins être atteints de cette manière. Notamment à ceux qui sont peu actifs et qui débarqueraient quelques semaines ou mois après la migration.
Si Cesium peut leur dire “passez à la V2”, c’est vraiment top je trouve
Je penses qu’il y a plein de possibilités.
Cesium (je ne sais plus depuis qu’elle version) permet de lire des fichiers au format Json feed depuis la copie github du repo de Césium. Ce n’est donc lié a une version particulière.
La prochaine version Cesium par exemple va se servir de cela pour afficher les nouveautés.
Pour les versions plus récentes de Césium, je peux intégrer un signal quelconque, comme par exemple la détection d’une version 2.
Dès lors que la v2 de Cesium est sortie, l’outil peut se bloquer en mode consultation seule (démo).
Cependant je penses qu’il faudrait aussi faire un mise a jour de Duniter. Les noeuds de cette version pourraient s’arrêter et ne plus communiquer avec des noeuds autres.
Combien de temps prend la génération du genesis v2, y compris l’importation dans l’indexeur ?
Si l’arrêt est programmé au temps t, le genesis devrait être généré à ce temps t pour ne rien perdre de la G1 (ne pas laisser des gens croire que leur transaction est passée, alors qu’elle est passée en v1 après le fork). Il y aura donc un downtime. Même si on peut préparer les nœuds v2 à l’avance, il faudra attendre que le genesis soit prêt et lancer les nœuds et il ne pourra pas y avoir de recouvrement.
Ah ? Si tu as le lien où cela a été discuté je veux bien
Moi je ne vois pas trop l’intérêt, et encore moins la faisabilité.
Dans les systèmes informatiques, les migrations sont parfois plus longues que prévues, à cause de complications par exemple ,mais quasiment jamais suivis d’un retour arrière…
