Je réfléchissais récemment à une question : pourquoi la plupart des chaînes publiques mettent-elles l’accent sur la compatibilité, alors que si peu de personnes parlent de « savoir si des actifs différents nécessitent une logique d’exécution différente » ?
En examinant l’architecture technique de Dusk, j’ai constaté qu’elle ne suit pas la voie du « une seule machine virtuelle pour tout ». DuskEVM offre aux développeurs Solidity un environnement familier, DuskVM permet aux contrats Rust de s’exécuter directement sur la couche L1, et Transfer Contract répartit, selon la charge utile de chaque transaction, vers le chemin de vérification correspondant — ce choix ne vise pas à faire de la démonstration, mais à répondre à une réalité : une fois que des actifs complexes comme le capital-investissement ou les obligations d’entreprise sont tokenisés, les règles d’exécution dont ils ont besoin sont entièrement différentes de celles des simples jetons.
Le problème des actifs traditionnels n’est pas tant leur émission que leur utilisation. Une part de fonds de capital-investissement peut-elle être donnée en garantie ? Si oui, à qui les actifs mis en garantie peuvent-ils être transférés lors de la liquidation ? Comment vérifier l’identité d’un investisseur qualifié ? Si ces règles restent cantonnées à des protocoles hors chaîne ou à des restrictions côté front-end, elles seront contournées ; si elles sont codées en dur dans le contrat, on sacrifiera la flexibilité.
La démarche de Dusk consiste à placer la logique de vérification en amont, dans l’environnement d’exécution. Phoenix gère les transactions qui doivent dissimuler les montants, Moonlight gère les scénarios qui doivent être publics et transparents, et les deux partagent une même couche de règlement. Cela signifie que les attributs des actifs ne dépendent pas de la discipline de l’émetteur, mais de l’exécution forcée par l’architecture sous-jacente.
Mais cette superposition entraîne aussi un coût cognitif. Les développeurs doivent comprendre à quel moment utiliser quelle machine virtuelle, et les utilisateurs doivent savoir par quel chemin leur transaction est traitée. Si la majorité des gens n’utilisent longtemps que la couche compatible EVM, alors les capacités natives de DuskVM et Phoenix ne seraient que des avantages théoriques.
Ainsi, ce qui m’intéresse n’est pas tant le nombre de types d’actifs que Dusk peut prendre en charge, mais plutôt de savoir si ces actifs utiliseront réellement les capacités différenciées que son architecture a conçues. La valeur d’une architecture technique doit, en fin de compte, être validée par les scénarios d’utilisation réels.
#dusk @Dusk $DUSK
En examinant l’architecture technique de Dusk, j’ai constaté qu’elle ne suit pas la voie du « une seule machine virtuelle pour tout ». DuskEVM offre aux développeurs Solidity un environnement familier, DuskVM permet aux contrats Rust de s’exécuter directement sur la couche L1, et Transfer Contract répartit, selon la charge utile de chaque transaction, vers le chemin de vérification correspondant — ce choix ne vise pas à faire de la démonstration, mais à répondre à une réalité : une fois que des actifs complexes comme le capital-investissement ou les obligations d’entreprise sont tokenisés, les règles d’exécution dont ils ont besoin sont entièrement différentes de celles des simples jetons.
Le problème des actifs traditionnels n’est pas tant leur émission que leur utilisation. Une part de fonds de capital-investissement peut-elle être donnée en garantie ? Si oui, à qui les actifs mis en garantie peuvent-ils être transférés lors de la liquidation ? Comment vérifier l’identité d’un investisseur qualifié ? Si ces règles restent cantonnées à des protocoles hors chaîne ou à des restrictions côté front-end, elles seront contournées ; si elles sont codées en dur dans le contrat, on sacrifiera la flexibilité.
La démarche de Dusk consiste à placer la logique de vérification en amont, dans l’environnement d’exécution. Phoenix gère les transactions qui doivent dissimuler les montants, Moonlight gère les scénarios qui doivent être publics et transparents, et les deux partagent une même couche de règlement. Cela signifie que les attributs des actifs ne dépendent pas de la discipline de l’émetteur, mais de l’exécution forcée par l’architecture sous-jacente.
Mais cette superposition entraîne aussi un coût cognitif. Les développeurs doivent comprendre à quel moment utiliser quelle machine virtuelle, et les utilisateurs doivent savoir par quel chemin leur transaction est traitée. Si la majorité des gens n’utilisent longtemps que la couche compatible EVM, alors les capacités natives de DuskVM et Phoenix ne seraient que des avantages théoriques.
Ainsi, ce qui m’intéresse n’est pas tant le nombre de types d’actifs que Dusk peut prendre en charge, mais plutôt de savoir si ces actifs utiliseront réellement les capacités différenciées que son architecture a conçues. La valeur d’une architecture technique doit, en fin de compte, être validée par les scénarios d’utilisation réels.
#dusk @Dusk $DUSK