#dusk $DUSK @Dusk
J’ai continué à revenir sur un détail de la norme XSC qui paraissait mineur jusqu’à ce que je vérifie ce que cela signifiait réellement dans la pratique. $DUSK et #DuskNetwork sont généralement présentés comme offrant une « conformité programmable », comme s’il s’agissait d’un seul système partagé qui s’ajuste au fur et à mesure que la réglementation évolue, mais les règles ne sont pas du tout régies au niveau du protocole. Elles sont définies par l’émetteur individuel au moment où un jeton de sécurité est créé. L’émetteur contrôle la liste blanche, peut forcer le transfert d’actifs pour se conformer à une injonction légale, et peut récupérer un portefeuille perdu — ce sont toutes des fonctions côté émetteur, pas des fonctions au niveau du réseau. En parallèle, la gouvernance réelle du protocole de Dusk, l’équipe Core R&D et le Governance Council, gère les mises à niveau du réseau de référence lui-même, et non la logique de conformité intégrée dans un actif donné. Donc ces deux couches de gouvernance ne se recouvrent pas comme je l’avais supposé. Cela signifie que, ici, « conformité programmable » se rapproche davantage d’une « conformité définie par l’émetteur, programmée une fois et contrôlée par cet émetteur par la suite » que d’un système à l’échelle du réseau qui s’adapte automatiquement à mesure que la loi change. C’est une conception solide pour donner aux émetteurs un contrôle juridique sur des actifs réglementés, mais elle reporte aussi la charge de rester à jour sur chaque émetteur individuellement. Je suis encore en train de comprendre ce que cela implique à grande échelle, lorsqu’il y aura des dizaines d’émetteurs sur Dusk au lieu d’un ou deux.
J’ai continué à revenir sur un détail de la norme XSC qui paraissait mineur jusqu’à ce que je vérifie ce que cela signifiait réellement dans la pratique. $DUSK et #DuskNetwork sont généralement présentés comme offrant une « conformité programmable », comme s’il s’agissait d’un seul système partagé qui s’ajuste au fur et à mesure que la réglementation évolue, mais les règles ne sont pas du tout régies au niveau du protocole. Elles sont définies par l’émetteur individuel au moment où un jeton de sécurité est créé. L’émetteur contrôle la liste blanche, peut forcer le transfert d’actifs pour se conformer à une injonction légale, et peut récupérer un portefeuille perdu — ce sont toutes des fonctions côté émetteur, pas des fonctions au niveau du réseau. En parallèle, la gouvernance réelle du protocole de Dusk, l’équipe Core R&D et le Governance Council, gère les mises à niveau du réseau de référence lui-même, et non la logique de conformité intégrée dans un actif donné. Donc ces deux couches de gouvernance ne se recouvrent pas comme je l’avais supposé. Cela signifie que, ici, « conformité programmable » se rapproche davantage d’une « conformité définie par l’émetteur, programmée une fois et contrôlée par cet émetteur par la suite » que d’un système à l’échelle du réseau qui s’adapte automatiquement à mesure que la loi change. C’est une conception solide pour donner aux émetteurs un contrôle juridique sur des actifs réglementés, mais elle reporte aussi la charge de rester à jour sur chaque émetteur individuellement. Je suis encore en train de comprendre ce que cela implique à grande échelle, lorsqu’il y aura des dizaines d’émetteurs sur Dusk au lieu d’un ou deux.
