Je regarde en boucle le @Dusk depuis un moment, et plus je regarde, plus je trouve ça intéressant.
D’abord, parlons du cycle de vie des transactions qui me met vraiment dans le rythme. Au début, j’ai été un peu trompé par l’idée de finalité déterministe : j’ai retourné des documentations pendant plusieurs jours avant de comprendre que « confirmed » et « finalized » sont deux choses complètement différentes. Le bloc n’est pas encore passé à l’étape finale : il peut toujours être revert. Le flux se fait comme suit : le provisioner propose d’abord un bloc candidat, puis un comité aléatoire fait la validation, ensuite une série de Ratification, et ce n’est qu’après le ratify que c’est réellement « posé ». Ce n’est pas comme si une fois proposé c’était automatiquement plié ; au contraire, après la finalisation, tu n’as plus besoin d’empiler des confirmations.
Si c’est juste un simple virement, ça passe encore, mais pour un dépôt d’échange ou une livraison de titres, on ne peut pas jouer comme ça. Le fait de détecter l’événement « executed » ne fait que dire que l’exécution a eu lieu : il faut encore vérifier que l’eventuel « error » est vide, et ce n’est qu’avec l’événement « finalized » que c’est solide. Si jamais tu reçois un « reverted », il faut reécouter/rejouer. Un revert de contrat, c’est une erreur de code ; un revert de bloc, c’est un changement de consensus. La logique de reprise part donc dans deux directions complètement opposées. Si l’intégrateur prend « confirmed » pour « finalized », la déterministicité s’effondre au niveau applicatif. Ce qui me préoccupe le plus maintenant, c’est de savoir si l’échange et Dusk Trade utilisent bien tous les deux « finalized » comme frontière, et s’il existe un processus de rejouabilité auditable.
Passons au trading équitable : là, ça m’a vraiment dégoûté. Le mempool, c’est comme une serre en verre sans rideaux : tu veux acheter quoi que ce soit, tout le monde le voit. Les robots à pinces peuvent te planter le bec à tout moment. Le $DUSK fait directement des enchères privées en lots à l’échelle du protocole : les offres et les quantités sont soumises, puis ZK les étouffe instantanément. Les nœuds calculent un prix « juste » qui fait tendre la différence entre la demande totale des ordres cachés et l’offre totale des ordres de vente vers zéro ; ensuite, dans le même bloc, tous les ordres en attente sont réglés à ce prix. L’asymétrie d’information est renversée : la dark pool n’est plus équitable seulement en surface, elle l’est jusque dans ses entrailles.
Côté conformité, on ne se moque pas du monde non plus. Phoenix utilise ZK pour préserver la confidentialité, Moonlight passe par un registre transparent, Citadel supporte la divulgation sélective, et XSC écrit les critères d’éligibilité, les limites et les rapports directement dans la logique du contrat. Nul besoin de tout compter sur des règles en dehors de la chaîne.
Plus un produit est complexe, plus il y a de règles ; et la vraie question est : est-ce que ces règles peuvent tourner de manière fiable ensemble dans différents workflows ? C’est exactement ce que je continue de surveiller. La véritable finalité n’est pas un terme : c’est un enchaînement d’événements de nœud jusqu’au registre, sans que personne ne se précipite entre-temps. #dusk $DUSK
D’abord, parlons du cycle de vie des transactions qui me met vraiment dans le rythme. Au début, j’ai été un peu trompé par l’idée de finalité déterministe : j’ai retourné des documentations pendant plusieurs jours avant de comprendre que « confirmed » et « finalized » sont deux choses complètement différentes. Le bloc n’est pas encore passé à l’étape finale : il peut toujours être revert. Le flux se fait comme suit : le provisioner propose d’abord un bloc candidat, puis un comité aléatoire fait la validation, ensuite une série de Ratification, et ce n’est qu’après le ratify que c’est réellement « posé ». Ce n’est pas comme si une fois proposé c’était automatiquement plié ; au contraire, après la finalisation, tu n’as plus besoin d’empiler des confirmations.
Si c’est juste un simple virement, ça passe encore, mais pour un dépôt d’échange ou une livraison de titres, on ne peut pas jouer comme ça. Le fait de détecter l’événement « executed » ne fait que dire que l’exécution a eu lieu : il faut encore vérifier que l’eventuel « error » est vide, et ce n’est qu’avec l’événement « finalized » que c’est solide. Si jamais tu reçois un « reverted », il faut reécouter/rejouer. Un revert de contrat, c’est une erreur de code ; un revert de bloc, c’est un changement de consensus. La logique de reprise part donc dans deux directions complètement opposées. Si l’intégrateur prend « confirmed » pour « finalized », la déterministicité s’effondre au niveau applicatif. Ce qui me préoccupe le plus maintenant, c’est de savoir si l’échange et Dusk Trade utilisent bien tous les deux « finalized » comme frontière, et s’il existe un processus de rejouabilité auditable.
Passons au trading équitable : là, ça m’a vraiment dégoûté. Le mempool, c’est comme une serre en verre sans rideaux : tu veux acheter quoi que ce soit, tout le monde le voit. Les robots à pinces peuvent te planter le bec à tout moment. Le $DUSK fait directement des enchères privées en lots à l’échelle du protocole : les offres et les quantités sont soumises, puis ZK les étouffe instantanément. Les nœuds calculent un prix « juste » qui fait tendre la différence entre la demande totale des ordres cachés et l’offre totale des ordres de vente vers zéro ; ensuite, dans le même bloc, tous les ordres en attente sont réglés à ce prix. L’asymétrie d’information est renversée : la dark pool n’est plus équitable seulement en surface, elle l’est jusque dans ses entrailles.
Côté conformité, on ne se moque pas du monde non plus. Phoenix utilise ZK pour préserver la confidentialité, Moonlight passe par un registre transparent, Citadel supporte la divulgation sélective, et XSC écrit les critères d’éligibilité, les limites et les rapports directement dans la logique du contrat. Nul besoin de tout compter sur des règles en dehors de la chaîne.
Plus un produit est complexe, plus il y a de règles ; et la vraie question est : est-ce que ces règles peuvent tourner de manière fiable ensemble dans différents workflows ? C’est exactement ce que je continue de surveiller. La véritable finalité n’est pas un terme : c’est un enchaînement d’événements de nœud jusqu’au registre, sans que personne ne se précipite entre-temps. #dusk $DUSK