J’ai passé bien trop de temps la nuit dernière à fouiller les docs d’architecture de Dusk. Honnêtement, mon cerveau s’est accroché sur un point.
Ils ont Zedger (de type UTXO, axé confidentialité pour les titres) et DuskEVM (un EVM de l’OP Stack pour les développeurs Solidity). Sur le papier, c’est propre : la logique de règlement reste séparée de la logique applicative.
Mais Zedger a cette fonctionnalité particulière, plutôt cool : le destinataire doit explicitement approuver un transfert avant qu’il ne soit réellement finalisé. C’est énorme pour les actifs régulés. Votre token de sécurité ne peut pas simplement être transféré d’un coup vers un portefeuille aléatoire.
Maintenant, imaginez que vous enveloppez cet actif et que vous le faites passer du côté EVM. L’EVM ne dispose pas nativement de cet état « approbation en attente » : ce n’est que des transitions d’état standards.
Alors, qui applique la règle de l’autre côté ?
Les docs publiques n’expliquent pas vraiment les mécanismes du pont ici. Peut-être qu’ils transportent ce contexte de conformité, mais franchement, ça revient à reconstruire la logique de Zedger à l’intérieur de Solidity. Du coup, pourquoi les garder séparés ?
C’est probablement pour ça que DuskVM (la couche de confidentialité WASM) est extraite pour devenir un composant à part : isoler le cœur vraiment régulé du Far West de l’EVM.
Trois environnements d’exécution. Deux ponts. C’est ambitieux, mais je reste là à me demander si ces « coutures » sont vraiment étanches. J’ai l’impression qu’il pourrait y avoir des incohérences d’état bizarres quand un actif change de couche.
Je n’essaie pas de faire du FUD — j’aime vraiment l’approche. Je suis juste curieux : est-ce que quelqu’un sait comment ils comptent garder cette synchronisation d’état entre couches solide dans la pratique.
@Dusk #dusk #DUSK $DUSK
Ils ont Zedger (de type UTXO, axé confidentialité pour les titres) et DuskEVM (un EVM de l’OP Stack pour les développeurs Solidity). Sur le papier, c’est propre : la logique de règlement reste séparée de la logique applicative.
Mais Zedger a cette fonctionnalité particulière, plutôt cool : le destinataire doit explicitement approuver un transfert avant qu’il ne soit réellement finalisé. C’est énorme pour les actifs régulés. Votre token de sécurité ne peut pas simplement être transféré d’un coup vers un portefeuille aléatoire.
Maintenant, imaginez que vous enveloppez cet actif et que vous le faites passer du côté EVM. L’EVM ne dispose pas nativement de cet état « approbation en attente » : ce n’est que des transitions d’état standards.
Alors, qui applique la règle de l’autre côté ?
Les docs publiques n’expliquent pas vraiment les mécanismes du pont ici. Peut-être qu’ils transportent ce contexte de conformité, mais franchement, ça revient à reconstruire la logique de Zedger à l’intérieur de Solidity. Du coup, pourquoi les garder séparés ?
C’est probablement pour ça que DuskVM (la couche de confidentialité WASM) est extraite pour devenir un composant à part : isoler le cœur vraiment régulé du Far West de l’EVM.
Trois environnements d’exécution. Deux ponts. C’est ambitieux, mais je reste là à me demander si ces « coutures » sont vraiment étanches. J’ai l’impression qu’il pourrait y avoir des incohérences d’état bizarres quand un actif change de couche.
Je n’essaie pas de faire du FUD — j’aime vraiment l’approche. Je suis juste curieux : est-ce que quelqu’un sait comment ils comptent garder cette synchronisation d’état entre couches solide dans la pratique.
@Dusk #dusk #DUSK $DUSK
