@Dusk #dusk
$DUSK Composants principaux
Le réseau Dusk utilise une architecture modulaire conçue pour la finance réglementée : la confidentialité là où elle est nécessaire, la transparence là où elle est utile, et le règlement déterministe lorsque les flux du marché l’exigent. À un niveau élevé :
Composant :
1. DuskDS
Rôle :
Fondation de règlement et de disponibilité des données : consensus, finalité et modèles de transaction Dusk
Où aller ensuite :
Dusk dispose d’une architecture en deux couches :
DuskDS – la couche de règlement et de données (consensus, disponibilité des données, modèles de transaction)
DuskEVM – la couche d’exécution EVM où s’exécutent les smart contracts et où réside Hedger
Cette page décrit les modèles de transaction sur DuskDS. Elle sert de contexte pour comprendre comment le règlement et la confidentialité fonctionnent « en coulisses ». Si vous développez des dApps sur DuskEVM, vous interagirez principalement avec Hedger et les contrats EVM à la place.
Phoenix vs Moonlight (sur DuskDS)
Sur DuskDS, la valeur peut se déplacer de deux manières natives :
Moonlight – transferts publics, basés sur des comptes
Phoenix – transferts protégés, basés sur des notes, utilisant des preuves à connaissance nulle
Dans les deux cas, le règlement s’effectue finalement sur la même chaîne, mais ils exposent des informations différentes aux observateurs.
Pour les détails complets de l’implémentation, vous pouvez vous référer au Livre blanc.
Moonlight – soldes publics
Moonlight est le modèle de transaction transparent :
Les comptes affichent des soldes visibles.
Les transferts montrent l’expéditeur, le destinataire et le montant.
Il convient aux flux qui doivent être observables (par ex. certains scénarios de trésorerie ou de reporting).
Conceptuellement, il se comporte comme un modèle de compte standard.
Pour la plupart des utilisateurs, c’est « simplement la manière transparente de déplacer du DUSK » au niveau du protocole.
Phoenix – soldes protégés
Phoenix est le modèle axé sur la confidentialité :
Les fonds résident sous forme de « notes » chiffrées plutôt que de soldes explicites.
Les transactions prouvent la correction (pas de double dépense, fonds suffisants) au moyen de preuves à connaissance nulle sans révéler :le montant transféré,l’expéditeur de la note, sauf au destinataire,entre quelles notes spécifiques.
Les utilisateurs peuvent révéler sélectivement des informations via des clés de consultation lorsque la réglementation ou l’audit l’exige.
$DUSK Composants principaux
Le réseau Dusk utilise une architecture modulaire conçue pour la finance réglementée : la confidentialité là où elle est nécessaire, la transparence là où elle est utile, et le règlement déterministe lorsque les flux du marché l’exigent. À un niveau élevé :
Composant :
1. DuskDS
Rôle :
Fondation de règlement et de disponibilité des données : consensus, finalité et modèles de transaction Dusk
Où aller ensuite :
Dusk dispose d’une architecture en deux couches :
DuskDS – la couche de règlement et de données (consensus, disponibilité des données, modèles de transaction)
DuskEVM – la couche d’exécution EVM où s’exécutent les smart contracts et où réside Hedger
Cette page décrit les modèles de transaction sur DuskDS. Elle sert de contexte pour comprendre comment le règlement et la confidentialité fonctionnent « en coulisses ». Si vous développez des dApps sur DuskEVM, vous interagirez principalement avec Hedger et les contrats EVM à la place.
Phoenix vs Moonlight (sur DuskDS)
Sur DuskDS, la valeur peut se déplacer de deux manières natives :
Moonlight – transferts publics, basés sur des comptes
Phoenix – transferts protégés, basés sur des notes, utilisant des preuves à connaissance nulle
Dans les deux cas, le règlement s’effectue finalement sur la même chaîne, mais ils exposent des informations différentes aux observateurs.
Pour les détails complets de l’implémentation, vous pouvez vous référer au Livre blanc.
Moonlight – soldes publics
Moonlight est le modèle de transaction transparent :
Les comptes affichent des soldes visibles.
Les transferts montrent l’expéditeur, le destinataire et le montant.
Il convient aux flux qui doivent être observables (par ex. certains scénarios de trésorerie ou de reporting).
Conceptuellement, il se comporte comme un modèle de compte standard.
Pour la plupart des utilisateurs, c’est « simplement la manière transparente de déplacer du DUSK » au niveau du protocole.
Phoenix – soldes protégés
Phoenix est le modèle axé sur la confidentialité :
Les fonds résident sous forme de « notes » chiffrées plutôt que de soldes explicites.
Les transactions prouvent la correction (pas de double dépense, fonds suffisants) au moyen de preuves à connaissance nulle sans révéler :le montant transféré,l’expéditeur de la note, sauf au destinataire,entre quelles notes spécifiques.
Les utilisateurs peuvent révéler sélectivement des informations via des clés de consultation lorsque la réglementation ou l’audit l’exige.
