Je m’attendais à ce qu’une chaîne conçue pour des marchés réglementés soit livrée avec une longue liste de contrats natifs. Conformité, identité, registre, le reste : tout est intégré dès la genèse.
Dusk en propose deux : Stake et Transfer.
Stake suit les prestataires, les mises, les récompenses et la gestion de l’ensemble des validateurs. Transfer déplace DUSK et sert de point d’entrée pour l’exécution des transactions et le paiement du gaz.
C’est l’ensemble de la genèse.
Tout ce qui est réglementé se place au-dessus. Zedger sur DuskVM, Hedger sur DuskEVM, Citadel pour l’identité, Dusk Trade comme interface produit. Rien de tout cela n’est soudé à la base.
Le raisonnement que je donnerais, c’est que les exigences évoluent. Les règles d’éligibilité, les obligations de divulgation et les formats de reporting changent avec la réglementation, et tout ce qui est défini à la genèse ne change qu’au moyen d’un hard fork. Mettre la logique de conformité dans la couche de base signifierait une chaîne qui devrait faire un fork à chaque fois qu’une directive est mise à jour.
L’objection est toutefois réelle. Une base légère signifie que les garanties qui intéressent vraiment les gens vivent dans des contrats qui peuvent être mis à jour, et la mise à jour est une promesse de sécurité différente de l’immuabilité.
Les éléments les plus susceptibles de changer devraient-ils se trouver le plus loin du consensus, ou est-ce que cela ne fait que déplacer le risque vers un endroit moins examiné ?
Base légère, ou garanties légères ?
#dusk @Dusk $DUSK