#dusk $DUSK Hier soir, en parcourant la documentation de Dusk, j’ai eu un petit frisson dans le dos.
L’EVM compatible, ça sonne plutôt bien. Mais en regardant de près le mécanisme de sortie, je me suis senti nerveux—ce n’est pas un racket, c’est une architecture trop profonde.
Sur le côté EVM, on exécute des applications ; le L1 se charge de la validation des règlements. La sortie implique trois étapes : attendre la soumission de la proposition de sortie, attendre le dépôt de la preuve, puis attendre que la fenêtre de contestation se termine. La validation d’état à travers les couches : à chaque couche, il faut débourser du Gas. Ce n’est pas une double facturation : c’est comme si chaque porte nécessitait son propre ticket. Si à n’importe quelle étape le solde est insuffisant, les actifs restent bloqués en pleine route—impossible d’aller de l’avant ou de revenir en arrière.
Ce qui m’inquiète le plus, c’est que pour l’instant, tout repose sur des données de testnet.
Le fait que le flux fonctionne ne prouve que que le code peut s’exécuter. Une fois sur le mainnet, après le lancement de @Dusk , l’ensemble des validateurs, la fréquence des contestations, la volatilité des prix du Gas—n’importe quel paramètre peut transformer « sortir » en « ne pas réussir à sortir ». L’équipe du projet dit soutenir la sortie, mais elle n’a jamais publié de médiane de temps de sortie sur le mainnet, ni détaillé les mécanismes de récupération en cas d’échec. Si jamais un problème survient, qui vous aidera à récupérer vos actifs ? La documentation n’en dit rien.
Un pont inter-couches mature n’est jamais seulement « moins de boutons » : c’est surtout permettre aux utilisateurs de comprendre chaque étape—ce qui se passe exactement, où vont les actifs, et pourquoi il faut attendre. Avec le DuskEVM actuel, la logique de stratification technique est claire, mais pour l’utilisateur, c’est une boîte noire : on appuie sur « sortir », puis commence une longue attente ; à l’écran, il n’y a que quelques statuts pending incompréhensibles.
Cette industrie manque rarement d’ambitions techniques ; ce qui manque, c’est : si ça déraille, que fait-on ? Quand le protocole n’a même pas clairement expliqué les mécanismes de récupération en cas d’échec, pariez-vous sur la technologie, ou sur la chance ?
L’EVM compatible, ça sonne plutôt bien. Mais en regardant de près le mécanisme de sortie, je me suis senti nerveux—ce n’est pas un racket, c’est une architecture trop profonde.
Sur le côté EVM, on exécute des applications ; le L1 se charge de la validation des règlements. La sortie implique trois étapes : attendre la soumission de la proposition de sortie, attendre le dépôt de la preuve, puis attendre que la fenêtre de contestation se termine. La validation d’état à travers les couches : à chaque couche, il faut débourser du Gas. Ce n’est pas une double facturation : c’est comme si chaque porte nécessitait son propre ticket. Si à n’importe quelle étape le solde est insuffisant, les actifs restent bloqués en pleine route—impossible d’aller de l’avant ou de revenir en arrière.
Ce qui m’inquiète le plus, c’est que pour l’instant, tout repose sur des données de testnet.
Le fait que le flux fonctionne ne prouve que que le code peut s’exécuter. Une fois sur le mainnet, après le lancement de @Dusk , l’ensemble des validateurs, la fréquence des contestations, la volatilité des prix du Gas—n’importe quel paramètre peut transformer « sortir » en « ne pas réussir à sortir ». L’équipe du projet dit soutenir la sortie, mais elle n’a jamais publié de médiane de temps de sortie sur le mainnet, ni détaillé les mécanismes de récupération en cas d’échec. Si jamais un problème survient, qui vous aidera à récupérer vos actifs ? La documentation n’en dit rien.
Un pont inter-couches mature n’est jamais seulement « moins de boutons » : c’est surtout permettre aux utilisateurs de comprendre chaque étape—ce qui se passe exactement, où vont les actifs, et pourquoi il faut attendre. Avec le DuskEVM actuel, la logique de stratification technique est claire, mais pour l’utilisateur, c’est une boîte noire : on appuie sur « sortir », puis commence une longue attente ; à l’écran, il n’y a que quelques statuts pending incompréhensibles.
Cette industrie manque rarement d’ambitions techniques ; ce qui manque, c’est : si ça déraille, que fait-on ? Quand le protocole n’a même pas clairement expliqué les mécanismes de récupération en cas d’échec, pariez-vous sur la technologie, ou sur la chance ?
