#dusk @Dusk Démontage des nœuds et des contrats de Dusk : le maillon faible de la chaîne de conformité et de confidentialité ne se situe pas dans le consensus, mais dans la chaîne d’outils
J’ai fait tourner les nœuds du réseau de test de Dusk pendant deux jours et j’en ai profité pour déployer un contrat de transfert confidentiel. Le processus n’a pas été fluide : dans la documentation, quelques versions des adresses RPC ne concordent pas, et il m’a fallu fouiller dans l’historique de Discord pour reconstituer la configuration correcte. En se limitant au consensus et au blocage, Dusk n’a rien de particulièrement critiquable ; les preuves PLONK prennent aussi un temps dans des limites acceptables, mais la maturité de la chaîne d’outils accuse clairement un retard. En tant qu’actif de gas et de mise des nœuds, DUSK vérifie pour l’instant surtout la discipline du réseau ; la demande externe n’est pas encore forte.
Ce qui me met réellement en difficulté, c’est la frontière entre confidentialité et conformité. Dusk emprunte la voie des contrats confidentiels avec une interface d’audit : elle est plus répressive que la politique par défaut de Secret Network, et plus proche de la couche “actifs” que ne l’est Concordium, qui ancre l’identité hors-chaîne. En pratique, les champs que le rôle d’audit peut voir sont bien contrôlables ; toutefois, le modèle d’autorisation reste assez grossier, avec une granularité de permissions insuffisante. Les équipes qui veulent émettre des jetons de type “valeurs mobilières” ont justement besoin de cette configurabilité. $DUSK a été réglé comme seuil d’accès à la gouvernance et à la conformité : la logique est bonne, mais la mise en œuvre n’a pas encore tout à fait atteint son niveau.
Par rapport à Polymesh, Dusk ne s’est pas figé dans le scénario unique des valeurs mobilières. Le système de comptes de Polymesh et ses règles de règlement sont très rigides : le calcul général est pratiquement impossible à exploiter. Dusk conserve au contraire un espace contractuel plus large ; en échange, les développeurs doivent gérer eux-mêmes pas mal de détails de conformité. Je trouve au fond que c’est une différenciation, à condition de compléter l’offre SDK et la documentation. Le rendement de mise de $DUSK peut couvrir une partie de l’inflation ; quand les applications de l’écosystème sont trop peu nombreuses, ce taux de rendement reste surtout un chiffre “sur le papier”.
Si, par la suite, on revoit et réorganise le déploiement des nœuds, les outils d’audit et la documentation développeur, alors Dusk a une vraie longueur d’avance sur la piste RWA orientée confidentialité. Pour l’instant, il se trouve dans une phase où le protocole tourne, mais où l’écosystème n’est pas encore arrivé. Le DUSK est donc plus adapté à l’observation qu’à un pari précipité.
J’ai fait tourner les nœuds du réseau de test de Dusk pendant deux jours et j’en ai profité pour déployer un contrat de transfert confidentiel. Le processus n’a pas été fluide : dans la documentation, quelques versions des adresses RPC ne concordent pas, et il m’a fallu fouiller dans l’historique de Discord pour reconstituer la configuration correcte. En se limitant au consensus et au blocage, Dusk n’a rien de particulièrement critiquable ; les preuves PLONK prennent aussi un temps dans des limites acceptables, mais la maturité de la chaîne d’outils accuse clairement un retard. En tant qu’actif de gas et de mise des nœuds, DUSK vérifie pour l’instant surtout la discipline du réseau ; la demande externe n’est pas encore forte.
Ce qui me met réellement en difficulté, c’est la frontière entre confidentialité et conformité. Dusk emprunte la voie des contrats confidentiels avec une interface d’audit : elle est plus répressive que la politique par défaut de Secret Network, et plus proche de la couche “actifs” que ne l’est Concordium, qui ancre l’identité hors-chaîne. En pratique, les champs que le rôle d’audit peut voir sont bien contrôlables ; toutefois, le modèle d’autorisation reste assez grossier, avec une granularité de permissions insuffisante. Les équipes qui veulent émettre des jetons de type “valeurs mobilières” ont justement besoin de cette configurabilité. $DUSK a été réglé comme seuil d’accès à la gouvernance et à la conformité : la logique est bonne, mais la mise en œuvre n’a pas encore tout à fait atteint son niveau.
Par rapport à Polymesh, Dusk ne s’est pas figé dans le scénario unique des valeurs mobilières. Le système de comptes de Polymesh et ses règles de règlement sont très rigides : le calcul général est pratiquement impossible à exploiter. Dusk conserve au contraire un espace contractuel plus large ; en échange, les développeurs doivent gérer eux-mêmes pas mal de détails de conformité. Je trouve au fond que c’est une différenciation, à condition de compléter l’offre SDK et la documentation. Le rendement de mise de $DUSK peut couvrir une partie de l’inflation ; quand les applications de l’écosystème sont trop peu nombreuses, ce taux de rendement reste surtout un chiffre “sur le papier”.
Si, par la suite, on revoit et réorganise le déploiement des nœuds, les outils d’audit et la documentation développeur, alors Dusk a une vraie longueur d’avance sur la piste RWA orientée confidentialité. Pour l’instant, il se trouve dans une phase où le protocole tourne, mais où l’écosystème n’est pas encore arrivé. Le DUSK est donc plus adapté à l’observation qu’à un pari précipité.