duskvm

#dusk $DUSK @Dusk
La pile modulaire de Dusk : trois couches, un objectif

Et si l’architecture blockchain traitait le règlement et l’exécution comme deux tâches distinctes ?

@Dusk adopte cette approche avec une conception modulaire construite autour de trois composants :

1. DuskDS — la base de règlement
Elle gère le consensus, la finalité, la disponibilité des données et les modèles de transactions natifs de Dusk, y compris Moonlight pour les transferts publics et Phoenix pour les transferts protégés (shielded).

2. DuskEVM — la voie EVM
Les développeurs peuvent utiliser Solidity et des outils Ethereum familiers, tandis que les applications sont réglées via DuskDS. Cela rend l’environnement plus accessible pour la DeFi basée sur EVM et pour les applications d’actifs tokenisés.

3. DuskVM — l’exécution directe sur la couche L1
DuskVM exécute directement sur Dusk L1 des contrats intelligents Rust/WASM, ce qui le rend adapté aux applications qui ont besoin d’un accès plus approfondi aux modèles de transactions de Dusk, à la confidentialité ou aux capacités de preuve à divulgation nulle (zero-knowledge).

La partie intéressante, c’est la séparation elle-même : différentes applications peuvent choisir l’environnement d’exécution dont elles ont besoin sans remplacer la couche de règlement sous-jacente.

Pour $DUSK , cela crée une base où la compatibilité EVM, l’exécution directe sur L1, la confidentialité et le règlement déterministe peuvent coexister au sein de la même architecture plus large.

#DUSK #DuskEVM #DuskVM

Sondage : 🏗️ Quelle partie de l’architecture modulaire de Dusk vous intéresse le plus ?

Je ne cessais de me tromper sur un point en réfléchissant à Moonlight et Phoenix : je traitais la forme de l’état comme si elle déterminait aussi la finalité.
Cette hypothèse a commencé à me gêner.
Moonlight arrive en #DuskVM portant un modèle de compte public : Soldes, Expéditeur, Destinataire, Montant et Progression du nonce.
Phoenix est construit autour d’une piste entièrement différente : Notes chiffrées, Sorties dissimulées, Nullificateurs et État privé.
Mon premier réflexe était que deux systèmes aussi différents devaient probablement nécessiter deux façons différentes de devenir final.
Mais peut-être que c’est là que j’ajoutais une complexité qui n’était pas réellement nécessaire.
Moonlight peut rester en forme de compte. Phoenix peut rester en forme de note. #DuskVM n’a pas besoin d’aplatir l’un ou l’autre dans un format d’état universel juste pour décider quand l’exécution est terminée.
Cela m’a aussi amené à reconsidérer #DuskDS .
J’avais supposé qu’il devait créer un seul état partagé $DUSK sous les deux modèles. Je n’en suis plus aussi sûr.
La logique d’exécution peut rester spécialisée tandis que Dusk L1 donne à l’état résultant une frontière de finalité déterministe.
Et honnêtement, cette séparation m’intéresse davantage que les modèles d’état individuels.
Des façons différentes de représenter l’état ne nécessitent pas forcément des réponses différentes à la question de savoir quand cet état est enfin terminé.
Ce qui me préoccupe encore, c’est à quel point cette séparation reste propre à mesure que Moonlight et Phoenix deviennent plus complexes.

#dusk $DUSK @Dusk

@Dusk construit quelque chose de DeFi et la finance tokenisée aura de plus en plus besoin de : la confidentialité sans perdre la conformité. Les blockchains publiques sont puissantes car les transactions peuvent être transparentes et vérifiables, mais les marchés financiers réglementés ne peuvent pas exposer publiquement chaque solde, position, détail d’investisseur ou transaction. @Dusk aborde ce défi en combinant des technologies à preuves à divulgation nulle (zero-knowledge), des transferts confidentiels, la divulgation sélective, des contrôles d’accès et un règlement déterministe. �
Dusk +1
Ce qui rend cette approche intéressante, c’est l’idée que la confidentialité ne doit pas forcément signifier cacher tout. Les participants autorisés peuvent recevoir les informations dont ils ont besoin, tandis que les données sensibles restent protégées contre une exposition publique inutile. Cela peut être particulièrement pertinent pour les titres tokenisés, les actifs du monde réel, la DeFi institutionnelle et d’autres flux financiers où l’éligibilité, le reporting, les restrictions de transfert et les règles de règlement comptent. �
DOCS +1
Dusk utilise aussi une architecture modulaire, avec #DuskDS axé sur le règlement et la disponibilité des données, #DuskVM pour l’exécution native en Rust/WASM, et #DuskEVM pour les applications compatibles EVM. Cela offre aux développeurs différents parcours selon qu’une application donne la priorité à la confidentialité native, aux outils EVM familiers ou à l’infrastructure de règlement réglementée. �
DOCS
Pour moi, la partie la plus intéressante de Dusk n’est pas simplement « la confidentialité ». C’est la combinaison de la confidentialité, de la conformité et d’un règlement prévisible au sein d’une même infrastructure financière. Si davantage d’actifs du monde réel et de marchés institutionnels passent on-chain, ces capacités pourraient devenir de plus en plus importantes. #dusk $DUSK