Quand je repense au retour des anciennes versions de DUSK depuis Ethereum ou BSC vers le mainnet, la scène la plus facile à provoquer la panique chez les utilisateurs “lambda” est la suivante : le portefeuille a déjà affiché une confirmation une première fois, la chaîne indique aussi un succès — pourquoi le solde de Dusk sur le mainnet ne bouge toujours pas ? Dans le processus officiel de migration, cette première confirmation n’est potentiellement qu’un Approve (autorisation). Le véritable lancement de la migration, lui, correspond au Execute migration (exécution).
J’ai compris ces deux étapes comme une autorisation de prélèvement bancaire. D’abord, vous autorisez une institution à prélever un montant dans une limite donnée, mais cela ne signifie pas que l’argent a déjà été transféré : il faut ensuite une instruction réelle de prélèvement. Côté blockchain, c’est pareil : Approve ne fait que donner au contrat de migration une autorisation suffisante ; Execute, lui, verrouille la quantité sélectionnée et démarre la migration. Si l’autorisation était déjà suffisante au préalable, l’étape Approve peut même être totalement sautée. Du coup, certains signent une seule fois, d’autres doivent signer deux fois : ce n’est pas forcément parce que “quelqu’un” a un problème dans son processus.
C’est très différent de l’intuition qu’on a avec un transfert BTC. Ici, il n’y a pas ce schéma “d’abord donner au contrat du token une capacité, puis exécuter le transfert”. Le piège le plus courant : après le succès de la première autorisation, l’actif original reste généralement encore dans le portefeuille. L’utilisateur voit alors l’état “succès” et commence à attendre l’arrivée sur le mainnet… alors que, en réalité, la migration n’a même pas démarré. Le processus officiel exige de continuer la deuxième étape, et la migration est chronométrée à partir de la confirmation de la transaction d’exécution ; en général, il faut compter environ une heure. Cette étape est cruciale.
Si les actifs proviennent du réseau ETH, l’autorisation et l’exécution sur la chaîne source peuvent générer des frais réseau ; il vaut donc mieux prévoir suffisamment de Gas natif. Dans le sens BSC, c’est avec du BNB. Les officiels rappellent aussi que les comptes d’exchange ne peuvent généralement pas se connecter directement à ce processus de migration : il faut d’abord transférer les tokens vers un portefeuille autogéré compatible. Les étapes supplémentaires viennent du fait que l’autorisation des tokens sur la chaîne source et la migration elle-même sont deux actions distinctes ; ce n’est pas une “double facturation” du mainnet Dusk.
L’analogie a néanmoins des limites : l’autorisation de la blockchain n’est pas un papier “one-shot”. Le montant autorisé peut rester disponible ; lors d’une prochaine migration, si le plafond est suffisant, il n’est plus nécessaire de refaire un Approve. Pour le flux associé à @Dusk , ce que j’aimerais le plus, c’est que l’interface affiche trois états complètement différents : “autorisation terminée”, “migration démarrée” et “mainnet crédité”. Pour l’utilisateur $DUSK , quand la première opération réussit mais qu’il n’y a pas de crédit, il est plus important de vérifier si Execute a vraiment été envoyé sur la chaîne que de rafraîchir inlassablement le solde.
#dusk
J’ai compris ces deux étapes comme une autorisation de prélèvement bancaire. D’abord, vous autorisez une institution à prélever un montant dans une limite donnée, mais cela ne signifie pas que l’argent a déjà été transféré : il faut ensuite une instruction réelle de prélèvement. Côté blockchain, c’est pareil : Approve ne fait que donner au contrat de migration une autorisation suffisante ; Execute, lui, verrouille la quantité sélectionnée et démarre la migration. Si l’autorisation était déjà suffisante au préalable, l’étape Approve peut même être totalement sautée. Du coup, certains signent une seule fois, d’autres doivent signer deux fois : ce n’est pas forcément parce que “quelqu’un” a un problème dans son processus.
C’est très différent de l’intuition qu’on a avec un transfert BTC. Ici, il n’y a pas ce schéma “d’abord donner au contrat du token une capacité, puis exécuter le transfert”. Le piège le plus courant : après le succès de la première autorisation, l’actif original reste généralement encore dans le portefeuille. L’utilisateur voit alors l’état “succès” et commence à attendre l’arrivée sur le mainnet… alors que, en réalité, la migration n’a même pas démarré. Le processus officiel exige de continuer la deuxième étape, et la migration est chronométrée à partir de la confirmation de la transaction d’exécution ; en général, il faut compter environ une heure. Cette étape est cruciale.
Si les actifs proviennent du réseau ETH, l’autorisation et l’exécution sur la chaîne source peuvent générer des frais réseau ; il vaut donc mieux prévoir suffisamment de Gas natif. Dans le sens BSC, c’est avec du BNB. Les officiels rappellent aussi que les comptes d’exchange ne peuvent généralement pas se connecter directement à ce processus de migration : il faut d’abord transférer les tokens vers un portefeuille autogéré compatible. Les étapes supplémentaires viennent du fait que l’autorisation des tokens sur la chaîne source et la migration elle-même sont deux actions distinctes ; ce n’est pas une “double facturation” du mainnet Dusk.
L’analogie a néanmoins des limites : l’autorisation de la blockchain n’est pas un papier “one-shot”. Le montant autorisé peut rester disponible ; lors d’une prochaine migration, si le plafond est suffisant, il n’est plus nécessaire de refaire un Approve. Pour le flux associé à @Dusk , ce que j’aimerais le plus, c’est que l’interface affiche trois états complètement différents : “autorisation terminée”, “migration démarrée” et “mainnet crédité”. Pour l’utilisateur $DUSK , quand la première opération réussit mais qu’il n’y a pas de crédit, il est plus important de vérifier si Execute a vraiment été envoyé sur la chaîne que de rafraîchir inlassablement le solde.
#dusk