duskds

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

Je passe par ici pour vous parler de DuskDS, l’une des couches peut-être les plus confuses de l’architecture de @Dusk 🌒. Mais je vais essayer de vous les expliquer de la façon la plus simple possible, sans technicité.

Dans le billet précédent, nous avons vu que DuskEVM est la couche où l’on développe et exécute des applications ou des contrats intelligents compatibles avec EVM, tandis que DuskDS est une autre couche de l’infrastructure qui permet de gérer les données et les opérations réalisées dans DuskEVM.

En bref, DuskDS aide à ce que les opérations effectuées dans DuskEVM puissent être enregistrées et reliées à l’infrastructure principale de Dusk (Dusk L1), ce qui facilite leur règlement et la disponibilité des données.

Il faut garder à l’esprit que DuskEVM et DuskDS ne sont pas deux tokens différents ni deux blockchains qui se concurrencent. Ce sont des couches différentes qui remplissent des fonctions distinctes au sein de l’architecture de $DUSK .

Dans le prochain billet, nous parlerons de Dusk L1 et de la manière dont il se relie aux couches que nous avons vues précédemment.

#dusk #DuskEVM #DuskDS

J’ai ajouté une petite position $DUSK aujourd’hui, mais je surveille DuskEVM différemment maintenant.

Ce qui m’a marqué n’était pas seulement la compatibilité EVM — c’est la manière dont Hedger rend les transactions privées vérifiables grâce au chiffrement homomorphe et à des preuves ZK. Avant, je voyais la confidentialité comme une fonctionnalité utilisateur ; maintenant je la vois comme un mécanisme d’adoption pour les applications réglementées.

@Dusk alimentation aussi l’exécution, tandis que DuskDS gère le règlement et la disponibilité des données. Cette séparation me paraît importante.

Je ne suis toujours pas sûr de la rapidité d’adoption par de vrais utilisateurs, mais l’architecture a changé ma façon de voir.

$ATM $BANK #DUSK #DUSKEVM #DuskDS #Web3

Qu’est-ce qui, selon vous, compte le plus pour DUSK ?

Le pont est encore en panne, et c’est exactement à cela que je reviens pendant un certain temps.

@Dusk a suspendu ses services de pont le 16 janvier après que la surveillance a détecté une activité incohérente avec les opérations normales — un portefeuille opérationnel géré par une équipe, et non le protocole. Les blocs de DuskDS n’ont jamais cessé. Mais le pont reste à l’arrêt pendant qu’ils finalisent les travaux de durcissement, et la mitigation déjà déployée est une liste de blocage des destinataires dans le Web Wallet. Signalez une adresse frauduleuse, affichez un avertissement, arrêtez l’envoi.

C’est tout. C’est le filet de sécurité.

Et voici ce que je n’arrive pas à arrêter de me demander : si vous utilisez Rusk CLI ou vos propres outils, cet avertissement ne se déclenche jamais. Vous êtes totalement souverain — et totalement exposé. La cryptographie ZK en dessous est un travail réellement sérieux. Rien de tout cela n’a touché la surface de risque réelle de cette semaine.

Je ne pense pas que la liste de blocage soit un mauvais choix. Pragmatique­ment, c’est correct — couvrir le plus grand nombre d’utilisateurs le plus vite possible, et corriger l’architecture ensuite.

Mais $DUSK se positionne explicitement pour des marchés institutionnels réglementés. Si le contrôle de sécurité le plus visible vit dans un Web Wallet plutôt que dans le protocole lui-même, il existe une vraie question sur ce qui se passe lorsqu’une équipe de conformité soumet réellement cette pile à des tests de résistance.

C’est l’écart que je surveille. Pas la cryptographie — la gouvernance de l’endroit où la protection vit réellement.

Si les institutions ont besoin de garanties au niveau du protocole, et pas d’avertissements côté interface, la feuille de route actuelle de Dusk va-t-elle assez vite dans cette direction ?

#Dusk #DeFi #ZeroKnowledge #Bridge #DuskDS