Je me suis remis à relire une ligne de la liste de fonctionnalités de Hedger, car elle ne me paraissait pas immédiatement claire pour moi : un modèle hybride UTXO/Compte, décrit comme prenant en charge la composabilité inter-couches et l’intégration avec des systèmes financiers du monde réel. Je me suis attardé dessus un moment, en essayant de comprendre pourquoi un moteur de transaction confidentielle aurait besoin des deux modèles à la fois, au lieu d’en choisir un seul.

Puis j’ai trouvé le détail qui a fait “tilt”. Dans la configuration Hedger Alpha, un utilisateur opère avec deux adresses distinctes : une adresse EVM classique pour interagir avec des contrats, et une adresse Hedger spécifique destinée à conserver des soldes chiffrés. C’est la partie “hybride” dans la pratique : une adresse de type compte pour les éléments du système qui ont besoin d’un comportement EVM normal, et une structure proche d’un modèle UTXO en dessous pour les éléments qui doivent rester chiffrés et composables entre les couches.

Je ne m’attendais pas à un modèle à deux adresses lorsque j’ai d’abord imaginé comment cela fonctionnerait. J’avais supposé qu’il y aurait un seul wallet, un seul solde, et que la confidentialité s’appliquerait simplement par-dessus. Le fait de le scinder ainsi devient plus logique une fois qu’on se dit que DuskEVM doit pouvoir dialoguer avec les outils EVM standard d’un côté, tandis que la logique confidentielle de Hedger s’exécute de l’autre. Mais cela signifie aussi qu’il y a un peu plus à gérer correctement pour l’utilisateur ou pour l’interface de wallet.

#dusk $DUSK @Dusk $AIO $PORTAL