Je regardais autrefois un agent d’entretien perdre la trace des fonds d’un client parce que son système n’arrivait pas à synchroniser deux grands livres.
Le cabinet d’un ami gérait à la fois des actifs publics et privés pour des clients institutionnels. Un jour, une conversion a échoué à mi-chemin. Les fonds sont sortis du grand livre privé, mais n’ont jamais été arrivés sur le grand livre public. Le système affichait un état équilibré, mais l’argent était introuvable. Il leur a fallu trois semaines pour démêler tout ça. 💀
Ce souvenir a pris une toute autre dimension en lisant le modèle à double état de Dusk.
Voici l’architecture : Moonlight pour les transferts publics. Phoenix pour le privé, des notes chiffrées. Les deux s’alignent sur la même chaîne. Le contrat de transfert coordonne le mouvement de la valeur.
C’est propre, non ?
Sauf qu’il existe un manque que la documentation ne traite pas : les conversions entre états ne sont pas atomiques.
Imaginez ceci :
· une institution détient 1M de DUSK répartis entre les deux états : 500k publics, 500k privés
· lance la conversion de 200k de Phoenix vers Moonlight
· les notes Phoenix sont consommées. Le crédit Moonlight échoue ou est retardé.
· l’offre totale est temporairement réduite. 200k disparaissent du système.
L’attaquant surveille, détecte les notes consommées, constate que Moonlight n’a pas crédité. Exploite l’écart. Retire des fonds d’une plateforme qui ne consulte que les soldes Moonlight.
Des fonds qui existent dans aucun état, ou dans les deux.
La correction ? Un Unified State Aggregator (agrégateur d’état unifié) avec des preuves ZK. Il fournit une vue unifiée du total des avoirs sur les deux modèles sans révéler les transactions individuelles. Les gestionnaires (custodians) vérifient l’exactitude. Pas de trous de synchronisation. Pas d’arbitrage.
$DUSK construit une infrastructure réglementée de niveau réel. Mais un double état sans conversion atomique ? C’est une bombe à retardement pour la garde (custody).
Dusk va-t-il résoudre la séparation des états avant la première faille exploitée ? 🤔@Dusk #dusk $BMT $TAC
Le cabinet d’un ami gérait à la fois des actifs publics et privés pour des clients institutionnels. Un jour, une conversion a échoué à mi-chemin. Les fonds sont sortis du grand livre privé, mais n’ont jamais été arrivés sur le grand livre public. Le système affichait un état équilibré, mais l’argent était introuvable. Il leur a fallu trois semaines pour démêler tout ça. 💀
Ce souvenir a pris une toute autre dimension en lisant le modèle à double état de Dusk.
Voici l’architecture : Moonlight pour les transferts publics. Phoenix pour le privé, des notes chiffrées. Les deux s’alignent sur la même chaîne. Le contrat de transfert coordonne le mouvement de la valeur.
C’est propre, non ?
Sauf qu’il existe un manque que la documentation ne traite pas : les conversions entre états ne sont pas atomiques.
Imaginez ceci :
· une institution détient 1M de DUSK répartis entre les deux états : 500k publics, 500k privés
· lance la conversion de 200k de Phoenix vers Moonlight
· les notes Phoenix sont consommées. Le crédit Moonlight échoue ou est retardé.
· l’offre totale est temporairement réduite. 200k disparaissent du système.
L’attaquant surveille, détecte les notes consommées, constate que Moonlight n’a pas crédité. Exploite l’écart. Retire des fonds d’une plateforme qui ne consulte que les soldes Moonlight.
Des fonds qui existent dans aucun état, ou dans les deux.
La correction ? Un Unified State Aggregator (agrégateur d’état unifié) avec des preuves ZK. Il fournit une vue unifiée du total des avoirs sur les deux modèles sans révéler les transactions individuelles. Les gestionnaires (custodians) vérifient l’exactitude. Pas de trous de synchronisation. Pas d’arbitrage.
$DUSK construit une infrastructure réglementée de niveau réel. Mais un double état sans conversion atomique ? C’est une bombe à retardement pour la garde (custody).
Dusk va-t-il résoudre la séparation des états avant la première faille exploitée ? 🤔@Dusk #dusk $BMT $TAC
