V2S: smooth gradual migration (clients and indexers side)

Dans le but de rendre cette migration le plus agréable à vivre pour les utilisateurs, nous pouvons tout à fait anticiper beaucoup d’étapes avant le jour J.

A partir du moment où les clients comme gecko, tikka ou cesium² ouvrent leurs portent aux beta-testeurs sur ĞTest, des fonctionnalités de « pré-réservation » (ce n’est pas le bon terme, ce n’est pas une réservation mais plutôt une déclaration d’adresse) d’adresse v2s peuvent êtres implémentés côté client.

Il suffit pour cela de proposer de réserver un portefeuille de son coffre pour son actuel compte membre Ğ1 ou simple portefeuille Ğ1. Le client signe un document avec les 2 clés (v1 et v2) et envoi ce document quelque part (pas forcément en blockchain, sur un serveur, je sais pas encore, peu importe).

Je vois 2 effets de bords non bloquants:

  • Les prefix ss58 ne seront pas les mêmes entre ĞTest et Ğ1v2. Il suffit alors d’afficher la bonne address avec prefix Ğ1 à l’utilisateur sur l’écran de pré-migration. Ce n’est que de l’affichage, UX.
  • Nous prévoyons une continuité dans l’historique des transactions de chaque pubkey Ğ1. Il suffira de prévoir ces swaps d’adresse côté genesis indexers.

Je suis persuadé qu’ouvrir les beta-tests ĞTest au grand publique le plus tôt possible ne peut qu’être bénéfique pour nous (les dev). Ca nous permettra de nous projeter beaucoup plus facilement, et d’imaginer des choses de ce type dans l’optique de lisser un maximum cette migration dans le temps.

Un autre avantage de faire ça est d’éviter que des milliers de personnes migrent leurs comptes Ğ1 d’un coup juste après la migration, avec réservation de idtyindex et transactions en BC qui peuvent être évités (bon c’est un bien maigre avantage, je veux bien vous l’accorder).

Si cette proposition convient à tout le monde après discutions, je veux bien me charger de:

  • Concevoir (avec vous) ce système, finir de cadrer les effets de bords.
  • Intégrer ce parsing de document côté py-g1-migrator (swap d’adresses genesis à partir de la liste des réservations signés)
  • Implémenter l’écran de pré-migration côté Ğecko

Qu’en pensez-vous ?

2 Likes

Tout à fait d’accord pour procéder comme ça. Ça fait un bon exemple pour avancer sur Ǧ1lib et Ğ1compagnon.

1 Like

Je me demande si ce n’est pas un poil prématuré.
Pour les tests et le debug, je n’hésiterai pas à communiquer ma phrase de récupération, si cela doit être celle de mon compte final, cela me semble problématique.

Ou alors, je n’ai pas compris l’idée du truc…

non non, tu ne dévoiles rien, tu signes un document dans le logiciel client (en qui tu dois avoir confiance car tu lui donnes tes identifiants v1 et v2).

Ce document électronique signé est envoyé sur une base de données.

Lors de la migration, ton compte v2 « réservé » sera automatiquement créé avec ton identité et ton solde issus du compte v1.

Les personnes qui n’ont pas fait cela auront un compte « v1 » sur la v2 avec la même clef publique qu"en v1, ce qui empêche de faire plein de choses (dont les dérivations) et avec les vieux identifiants souvent faibles. Il devront créer un compte v2 puis transférer le compte v1 sur le v2 dans le client, pour bénéficier de la sécurité du mnémonique et des dérivations.

1 Like

Ce que je voulais dire c’est qu’en phase de test et debuging j’ai pu donner ma phrase de récupération à Poka pour qu’il puisse tenter de reproduire un Bug. Parce que je sais que cela ne sera pas ma phrase de récupération réelle.
Cela me semble plus problématique si cette phrase devait être la phrase que j’utiliserais dans la Ğ1V2.
C’est pour cela que je dis que cela me parais prématuré. Mais si c’est possible jusqu’au dernier moment de changer de clé destinataire (au cas où je l’aurais fourni pour un debug), cela me convient.

1 Like

Effectivement, il faudra bien préparer cela, et communiquer sur les adresses à réserver lorsque le système sera en place sur les serveurs et les clients. Et je pense qu’il faut complètement le dissocier des phases de debug pour moins de confusion, avec si possible le numéro dédié à la June en entête de l’adresse v2.

1 Like

Oui vous avez raison, il faut totalement dissocier les alpha-test GDev des bêta-test GTest.

On ne permettra cette pré-migration côté client uniquement quand tout sera carré de notre côté, et claire côté client (plus de mnemonic de test, code secret de production…)


En réalité cet écran de pré-migration pourrait aussi se faire côté Césium V1 dès maintenant.


Après, ça peu aussi ne pas être intégré à Ğecko, mais plutôt dans un outils de migration (une page web connecté à G1Compagnon) dédié à ça uniquement, en microservice.

Ca aurait l’avantage de:

  • Beaucoup moins de boulo d’intégration
  • Ne pas confondre mnemonic de test et de prod
  • Être plus clair en terme de communication, cette page peut détailler tout le truc sans que ça soit trop dense au milieu d’un client complet
  • Cette page pourrait très bien aussi accueillir tout un tas d’informations complémentaires concernant la migration, être tenu à jours avec son évolution, ect …

@ManUtopiK Ğ1Compagnon serait en faite hyper pratique pour ce cas là, car il permettrait de signer directement un document reçus d’une page web avec les 2 clés v1 et v2 en même temps, vue que tu le conçois ainsi de base :slight_smile:

2 Likes

Je trouve que c’est une fausse bonne idée, sauf à inviter seulement les utilisateurs les plus avertis et uniquement sur les forums voir uniquement le forum technique.

La communication “tout utilisateur” doit rester la plus simple possible, avec un seul appel à l’action à la fois. Toute complexité supplémentaire dans ce que l’on demande à l’utilisateur lambda doit être justifié par une nécessité technique non contournable. Or ici l’étape supplémentaire proposée n’est pas du tout requise techniquement (sauf pour les forgerons au genesis).

Ca ne sert à rien de vouloir éviter ce traffic blockchain tout à fait absorbable, il y aura de toute façon bien pire dans la vie de la G1v2 :wink:

C’est une très mauvaise idée, qui amène de nombreux inconvénients pour rien, ne perdez pas plus de temps de conception là-dessus, vous avez déjà bien assez de boulot :stuck_out_tongue:

Qu’est-ce qui te fait dire ça ? De quoi parles-tu exactement, je vois que ce n’est pas clair de ton côté.

Oui, et donc ?

Dans ce cas j’arrête gecko, les gens n’auront cas utiliser polkadot.js directement.
C’est con parce-que le but de tout ça est justement d’effacer la complexité pour l’utilisateur, tu ne te rends pas compte de ce que tu demandes aux gens en disant “Créer un coffre à gecko, vous avez une nouvelle address, maintenant migrer votre ancien compte g1 vers cette address”.

Moi je propose beaucoup plus simple ici.

Et oui, et oui.

Propos tronqué.

Peux tu nous citer au moins 1 inconvénient à cette idée avant de dire ça ? Je n’en vois absolument aucun dans ta réponse très vague.

Veux-tu qu’on s’appel pour que je t’explique plus en détail ce que tu n’as pas compris ?
Rien de rhétorique là dedans, vraiment, je suis pas du tout faché contrairement à ce que mes écrits pourraient laisser croire :slight_smile:
Juste fatigué de devoir répéter toujours les même choses, surtout quand on se prends ce genre d’invective infondé dans la tronche, sans aucune volonté d’essayer de mieux comprendre le point de vue en face. Plus simple et rapide à l’orale.

Sinon attends quelques semaines que ce soit en place, je comprends qu’on puisse avoir besoin de voir pour comprendre, je suis pareil parfois.
Par contre ce n’est pas dans le top de mes priorités actuelles donc tu vas attendre un peu.

Sinon quelqu’un d’autre veut bien expliquer à @elois ce qu’il ne semble pas avoir compris ?
J’ai déjà perdu trop de temps à essayer de lui expliquer, c’est trop chronophage pour moi.
Rien d’urgent hein, pas pressé tout ça.

1 Like

D’après ce que je comprend l’utilisateur lamba pourrait
. réserver à l’avance sa clé Ğ1V2
Cela implique qu’il se crée une phrase de restauration, qu’il devra utiliser au moment de l’installation de son client Ğ1V2 pour récupérer son compte
. Se connecter avec cette phrase de restauration/récupération et son id et mdp Ğ1V1 pour signifier le transfert entre les deux pour la future migration.

Après la migration, il vas devoir utiliser la phrase de récupération préalablement mémorisée, il faudra insister sur le fait que cette phrase est celle définitive (même si on est encore enphase de test). Avec le risque que certain ne l’ayant pas bien compris ai oublié perdu cette phrase, avec le risque que les personnes ayant fait plusieurs fois la manip ne sachent plus quelle est la bonne phrase.
Avec le risque que pendant la phase de test, l’utilisateur communique sa phrase de récupération pour aider au débug.
L’utilisateur lambda ne fait pas la différence entre alpha-test, bêta-test et pré-prod…

Je trouve que cela fait beaucoup de risques, pour le seul avantage que je vois : éviter la surcharge du réseau juste après la migration. Et comme le fait remarquer Elois j’espère que le futur réseau sera assez solide pour absorber cette surcharge, s’il doit durer dans le temps, il faut qu’il soit capable “d’encaisser”. Maintenant, je ne sais pas de quel niveau de surcharge on parle, donc je vous laisse discuter entre spécialiste.

Mais je ne vois pas en quoi cette “pré-migration” soulage le travail des développeurs, puisque de toute façon l’outil de transfert de compte devra exister après la migration.
La question est plutôt faut-il que cet outil de transfert de compte soit intégré dans les applis de gestion de wallet ou totalement à part, car quelques années après la migration, il sera devenu inutile.

Comme d’hab, ceci est le point de vue d’un utilisateur benêt qui ne connait peut-être pas tous les enjeux du truc.

1 Like

Merci @Maaltir

Non il n’a jamais été question de soulager le travail des dévellopeurs :slight_smile:
Mais celui des utilisateurs, qui une fois la migration effectué, n’auront juste aucune action a effectuer :slight_smile:

Et niveau taf côté dev, c’est 3 jours grand max, pas grand chose :wink:

Oui ça ça vaut avec ou sans prémigration.
Il ne faut pas demander aux gens de mémoriser leurs phrases de restauration @Maaltir , mais bien demander de la noter précieusement, comme l’app le suggère.

Tout à fait, à partir du lancement de gecko mobile, finit les mnemonic de tests et le code “triche” :slight_smile:

Il faudra communiquer dès lors sur le fait que les phrases de restauration, ça se garde précieusement, c’est de la prod.