#dusk $DUSK Voici quelque chose qui est souvent passé sous silence dans la plupart des explications sur DUSK : ce n’est pas une chaîne avec un seul modèle de confidentialité greffé. C’est une chaîne qui exécute simultanément deux modèles de transaction distincts, car un paiement et une sécurité ne sont pas le même type d’objet et ne peuvent pas échouer de la même manière.
Phoenix est le modèle de type UTxO pour les transferts du quotidien rendus obscurs — les soldes et les contreparties sont cachés, les notes sont suivies dans un arbre de Merkle, et des nullifiants empêchent les doubles dépenses sans révéler quelle note a été dépensée. Il est conçu pour le débit et la confidentialité lors des transferts de valeur ordinaires.
Zedger est différent, volontairement. Il est modélisé spécifiquement pour les titres tokenisés, où l’enjeu n’est pas seulement de masquer un solde — il s’agit de prouver correctement les événements du cycle de vie (émission, restrictions de transfert, opérations sur titres, rachat) dans un cadre réglementaire, sans divulguer la table des capitalisations au public de la chaîne. Un token de sécurité a des obligations que Phoenix n’était jamais conçu à porter : des restrictions de transfert liées au statut de l’investisseur, la capacité pour un émetteur de geler ou de récupérer dans des conditions juridiques spécifiques, des exigences d’audit qui subsistent même lorsque les soldes restent scellés.
Exécuter les deux sur une même couche de règlement est le pari d’ingénierie. Dusk ne choisit pas entre « chaîne de paiements privés » et « chaîne de titres conformes » — elle soutient qu’il faut disposer des deux primitives dans le même environnement d’exécution, parce qu’un marché réglementé touche les deux types de transactions le même jour de bourse. Le contrat de transfert gère ces deux flux via le même modèle d’intégrité basé sur l’arbre de Merkle : une architecture plus propre que de faire du pont entre deux chaînes avec deux garanties de confidentialité différentes.
La question ouverte est de savoir si cette complexité à double modèle devient un fardeau de maintenance au fur et à mesure que chaque spécification évolue indépendamment, ou si elle est réellement plus robuste qu’une couche de confidentialité « universelle ».
Quelqu’un connaît-il un autre L1 déployant deux modèles de transaction de production volontairement séparés par classe d’actifs, plutôt qu’une primitive générique de confidentialité étirée sur tout?
@Dusk $NVDAB
Phoenix est le modèle de type UTxO pour les transferts du quotidien rendus obscurs — les soldes et les contreparties sont cachés, les notes sont suivies dans un arbre de Merkle, et des nullifiants empêchent les doubles dépenses sans révéler quelle note a été dépensée. Il est conçu pour le débit et la confidentialité lors des transferts de valeur ordinaires.
Zedger est différent, volontairement. Il est modélisé spécifiquement pour les titres tokenisés, où l’enjeu n’est pas seulement de masquer un solde — il s’agit de prouver correctement les événements du cycle de vie (émission, restrictions de transfert, opérations sur titres, rachat) dans un cadre réglementaire, sans divulguer la table des capitalisations au public de la chaîne. Un token de sécurité a des obligations que Phoenix n’était jamais conçu à porter : des restrictions de transfert liées au statut de l’investisseur, la capacité pour un émetteur de geler ou de récupérer dans des conditions juridiques spécifiques, des exigences d’audit qui subsistent même lorsque les soldes restent scellés.
Exécuter les deux sur une même couche de règlement est le pari d’ingénierie. Dusk ne choisit pas entre « chaîne de paiements privés » et « chaîne de titres conformes » — elle soutient qu’il faut disposer des deux primitives dans le même environnement d’exécution, parce qu’un marché réglementé touche les deux types de transactions le même jour de bourse. Le contrat de transfert gère ces deux flux via le même modèle d’intégrité basé sur l’arbre de Merkle : une architecture plus propre que de faire du pont entre deux chaînes avec deux garanties de confidentialité différentes.
La question ouverte est de savoir si cette complexité à double modèle devient un fardeau de maintenance au fur et à mesure que chaque spécification évolue indépendamment, ou si elle est réellement plus robuste qu’une couche de confidentialité « universelle ».
Quelqu’un connaît-il un autre L1 déployant deux modèles de transaction de production volontairement séparés par classe d’actifs, plutôt qu’une primitive générique de confidentialité étirée sur tout?
@Dusk $NVDAB