#dusk $DUSK @Dusk En lisant le livre blanc de Dusk, j’ai remarqué un détail facile à passer à côté : la description de différents contrats utilise des temps verbaux différents.
Dans la section 6.2, lorsqu’il décrit les contrats Genesis, Transfer et Stake, le texte se concentre principalement sur la manière dont ils remplissent actuellement leurs fonctions : transfert, déduction des Gas, mise en jeu (staking), etc. Ce sont les infrastructures nécessaires au fonctionnement du réseau Dusk.
En revanche, dans la section 6.3, qui présente Zedger et Citadel, on observe des formulations clairement plus orientées vers l’avenir, par exemple « designed to be deployed » et « will allow ».
À elle seule, la conjugaison ne peut évidemment pas prouver qu’une fonction « n’est pas encore réalisée ». Mais en tant qu’indice de document technique, elle nous rappelle au moins ceci : la conception d’architecture dans le livre blanc, les protocoles déjà déployés et les capacités des produits actuellement utilisables ne relèvent pas du même concept.
Regardons maintenant le site officiel de Dusk : l’état des différents produits y est déjà indiqué comme Live, Building et Testnet. Cela nous donne un cadre de référence plus concret : lorsqu’on discute d’une capacité, faut-il aussi la distinguer selon qu’elle est conçue, déjà déployée, ou déjà vérifiable et utilisable dans la pratique ?
Aujourd’hui, les discussions de Dusk concernant la finance on-chain réglementée se concentrent de plus en plus sur des processus complets, comme l’accès des investisseurs, les transferts contrôlés, la divulgation de la confidentialité et la clôture (settlement).
La question devient alors plus précise :
À quel stade se trouvent actuellement les capacités de Zedger, XSC et Citadel, respectivement parmi « conception, déploiement, utilisation vérifiable » ?
Si l’objectif de Dusk est de porter un marché financier réellement réglementé, quel est, selon le livre blanc, le maillon clé qui nécessite le plus une validation externe pour passer de la conception à une utilisation dans le monde réel ?#dusk $DUSK @Dusk
Dans la section 6.2, lorsqu’il décrit les contrats Genesis, Transfer et Stake, le texte se concentre principalement sur la manière dont ils remplissent actuellement leurs fonctions : transfert, déduction des Gas, mise en jeu (staking), etc. Ce sont les infrastructures nécessaires au fonctionnement du réseau Dusk.
En revanche, dans la section 6.3, qui présente Zedger et Citadel, on observe des formulations clairement plus orientées vers l’avenir, par exemple « designed to be deployed » et « will allow ».
À elle seule, la conjugaison ne peut évidemment pas prouver qu’une fonction « n’est pas encore réalisée ». Mais en tant qu’indice de document technique, elle nous rappelle au moins ceci : la conception d’architecture dans le livre blanc, les protocoles déjà déployés et les capacités des produits actuellement utilisables ne relèvent pas du même concept.
Regardons maintenant le site officiel de Dusk : l’état des différents produits y est déjà indiqué comme Live, Building et Testnet. Cela nous donne un cadre de référence plus concret : lorsqu’on discute d’une capacité, faut-il aussi la distinguer selon qu’elle est conçue, déjà déployée, ou déjà vérifiable et utilisable dans la pratique ?
Aujourd’hui, les discussions de Dusk concernant la finance on-chain réglementée se concentrent de plus en plus sur des processus complets, comme l’accès des investisseurs, les transferts contrôlés, la divulgation de la confidentialité et la clôture (settlement).
La question devient alors plus précise :
À quel stade se trouvent actuellement les capacités de Zedger, XSC et Citadel, respectivement parmi « conception, déploiement, utilisation vérifiable » ?
Si l’objectif de Dusk est de porter un marché financier réellement réglementé, quel est, selon le livre blanc, le maillon clé qui nécessite le plus une validation externe pour passer de la conception à une utilisation dans le monde réel ?#dusk $DUSK @Dusk
