#dusk $DUSK @Dusk

‎‎Mon père a tenu deux registres distincts pour sa petite boutique pendant des années : l’un pour les ventes au comptant, l’autre pour les comptes à crédit. Je lui ai demandé une fois pourquoi ne pas les fusionner. Il m’a répondu que l’argent comptant devait rester simple et immédiat, que le crédit devait permettre de suivre les échéances et d’effectuer les relances, et que contraindre un seul système à faire les deux finirait par empirer les choses pour chaque tâche.
‎
‎J’ai supposé que Dusk finirait par converger vers un seul modèle de transactions, comme la plupart des chaînes qui finissent par adopter une approche unique. Cette hypothèse s’est effondrée dès que j’ai retracé pourquoi Moonlight et Phoenix coexistent.
‎
‎Moonlight est basé sur les comptes, public et direct — la documentation de Dusk le décrit comme le modèle des soldes et de la logique d’application qui n’a pas besoin d’être protégée. Phoenix adopte l’approche UTXO, et il existe précisément pour prendre en charge des flux orientés confidentialité : transferts protégés, divulgation sélective, les éléments que la finance réglementée a réellement besoin lorsque la transparence totale n’est pas acceptable.
‎
‎Les fusionner en un seul modèle signifierait soit forcer chaque transaction à traverser une surcouche de confidentialité inutile, soit retirer aux personnes qui en ont besoin les options de protection.
‎
‎Le vrai test pour DUSK, c’est de savoir si garder ces deux modèles sert réellement les développeurs qui ont besoin de garanties différentes pour des flux différents — plutôt que d’ajouter une charge conceptuelle supplémentaire que la plupart des utilisateurs ne touchent jamais.
‎
‎Ce que je n’ai trouvé documenté nulle part, c’est à quelle fréquence une application unique a effectivement besoin des deux modèles en même temps, dans la pratique.
‎
‎