Six choses qu’une session Citadel ne met jamais en chaîne : la clé de votre portefeuille, la licence utilisée, les clés de l’émetteur et du service, les attributs signés et le chemin de preuve Merkle. Ce qui est mis en chaîne, c’est une seule session. Publique, vérifiable, ennuyeuse.
@Dusk classe cela dans la divulgation sélective, et ce n’est pas un interrupteur de confidentialité. Un fournisseur de licence vous vérifie hors chaîne, signe vos attributs, publie une licence chiffrée et l’enregistre dans un contrat Citadel. Ensuite, vous prouvez en connaissance nulle que vous détenez une licence enregistrée. Pas laquelle licence. Juste qu’elle existe. Le contrat vérifie, enregistre une session, et vous remettez un cookie de session au service.
Puis la documentation trace une ligne, clairement. Citadel prouve que la session est valide de façon cryptographique. Il ne décide pas de la politique du service. Le service choisit encore quels émetteurs il fait confiance, quels attributs il accepte, si la session est révoquée, et si ce cookie fonctionne deux fois.
Mon travail du jour consiste à tester une application de trading de titres, et cette séparation ressemble à quelque chose copié sur mon bureau. Personne là-bas ne voit l’image complète, volontairement. L’utilisateur voit sa propre commande. Le back office voit le lot. Le dépositaire voit une instruction de règlement. Le superviseur tire un rapport sur demande. Quatre vues d’une même opération, démêlées bien avant que quiconque n’écrive un circuit de preuve.
Mon avis : la partie précieuse de Citadel n’est pas la cryptographie, c’est le refus. Une chaîne qui décide de votre éligibilité est une chaîne qu’aucune plateforme ne pourrait adopter. L’éligibilité, c’est la juridiction, les conditions du produit et l’appétit de risque de l’émetteur. Tout cela ne devrait pas nécessiter un hard fork.
Une application sur Dusk est-elle conforme ? Non. Il faut encore qu’une personne soit fournisseur de licence, qu’elle exécute les vérifications hors chaîne et qu’elle réponde lorsqu’une vérification était incorrecte. Outils actuels : une bibliothèque Rust, le contrat de licence, un CLI de portefeuille et un SDK JavaScript encore indiqué comme à venir. $DUSK paie le gas et sécurise le réseau en y mettant des fonds en garantie (staking).
Alors qui doit jouer le rôle de fournisseur de licence pour un actif réglementé : la plateforme, l’émetteur, ou un tiers dont le seul rôle est de vérifier ? Je reviens sans cesse vers le troisième, sans raison claire.
#dusk
@Dusk classe cela dans la divulgation sélective, et ce n’est pas un interrupteur de confidentialité. Un fournisseur de licence vous vérifie hors chaîne, signe vos attributs, publie une licence chiffrée et l’enregistre dans un contrat Citadel. Ensuite, vous prouvez en connaissance nulle que vous détenez une licence enregistrée. Pas laquelle licence. Juste qu’elle existe. Le contrat vérifie, enregistre une session, et vous remettez un cookie de session au service.
Puis la documentation trace une ligne, clairement. Citadel prouve que la session est valide de façon cryptographique. Il ne décide pas de la politique du service. Le service choisit encore quels émetteurs il fait confiance, quels attributs il accepte, si la session est révoquée, et si ce cookie fonctionne deux fois.
Mon travail du jour consiste à tester une application de trading de titres, et cette séparation ressemble à quelque chose copié sur mon bureau. Personne là-bas ne voit l’image complète, volontairement. L’utilisateur voit sa propre commande. Le back office voit le lot. Le dépositaire voit une instruction de règlement. Le superviseur tire un rapport sur demande. Quatre vues d’une même opération, démêlées bien avant que quiconque n’écrive un circuit de preuve.
Mon avis : la partie précieuse de Citadel n’est pas la cryptographie, c’est le refus. Une chaîne qui décide de votre éligibilité est une chaîne qu’aucune plateforme ne pourrait adopter. L’éligibilité, c’est la juridiction, les conditions du produit et l’appétit de risque de l’émetteur. Tout cela ne devrait pas nécessiter un hard fork.
Une application sur Dusk est-elle conforme ? Non. Il faut encore qu’une personne soit fournisseur de licence, qu’elle exécute les vérifications hors chaîne et qu’elle réponde lorsqu’une vérification était incorrecte. Outils actuels : une bibliothèque Rust, le contrat de licence, un CLI de portefeuille et un SDK JavaScript encore indiqué comme à venir. $DUSK paie le gas et sécurise le réseau en y mettant des fonds en garantie (staking).
Alors qui doit jouer le rôle de fournisseur de licence pour un actif réglementé : la plateforme, l’émetteur, ou un tiers dont le seul rôle est de vérifier ? Je reviens sans cesse vers le troisième, sans raison claire.
#dusk