Sechs Dinge, die eine Citadel-Session niemals onchain stellt: den Wallet-Schlüssel, die verwendete Lizenz, die Issuer- und Service-Keys, die signierten Attribute und den Merkle-Proof-Pfad. Was onchain geht, ist genau eine Session. Öffentlich, verifizierbar, langweilig.
@Dusk ordnet das unter selektive Offenlegung ein, und es ist kein Datenschutz-Schalter. Ein License Provider prüft dich off-chain, signiert deine Attribute, veröffentlicht eine verschlüsselte Lizenz und registriert sie in einem Citadel-Contract. Später beweist du in Zero Knowledge, dass du eine registrierte Lizenz besitzt. Nicht welche Lizenz. Nur, dass sie existiert. Der Contract verifiziert, protokolliert eine Session, und du übergibst der Service-Seite ein Session-Cookie.
Dann ziehen die Doks eine klare Linie. Citadel beweist, dass die Session kryptografisch gültig ist. Es entscheidet nicht über die Service-Policy. Der Service wählt weiterhin, welchen Issuern er vertraut, welche Attribute er akzeptiert, ob die Session widerrufen ist und ob dieses Cookie zweimal funktioniert.
Mein Job ist das Testen einer App für Wertpapierhandel, und diese Aufteilung liest sich wie etwas, das von meinem Schreibtisch abgetippt wurde. Niemand dort sieht das Gesamtbild, absichtlich. Der Nutzer sieht seine eigene Order. Backoffice sieht den Batch. Das Deponierungs- bzw. Verwahrstelle sieht eine Settlement-Anweisung. Der Supervisor zieht auf Anfrage einen Bericht. Vier Sichten auf einen Trade – sortiert, lange bevor irgendwer einen Proof-Circuit geschrieben hat.
Meine Einschätzung: Das Wertvolle an Citadel ist nicht die Kryptografie, sondern die Verweigerung. Eine Kette, die für dich die Eignung entscheidet, ist eine, die kein Veranstaltungsort übernehmen dürfte. Eignung ist Jurisdiktion, Produktausgestaltung und die Risikoappetits des Issuers. All das sollte keinen Hard Fork brauchen.
Macht das eine App auf Dusk compliant? Nein. Jemand muss immer noch der License Provider sein, die Off-Chain-Checks ausführen und beantworten, wenn ein Check falsch war. Tooling heute: eine Rust-Bibliothek, der License-Contract, ein Wallet-CLI und ein JavaScript-SDK, das als „kommt noch“ gelistet ist. $DUSK zahlt Gas und sichert das Netzwerk durch Staking.
Also: Wer sollte diese Rolle des License Providers für ein reguliertes Asset innehaben – der Venue, der Issuer oder ein Dritter, dessen einzige Aufgabe darin besteht zu prüfen? Ich lande immer wieder beim dritten, ohne einen wirklich triftigen Grund.
#dusk
@Dusk ordnet das unter selektive Offenlegung ein, und es ist kein Datenschutz-Schalter. Ein License Provider prüft dich off-chain, signiert deine Attribute, veröffentlicht eine verschlüsselte Lizenz und registriert sie in einem Citadel-Contract. Später beweist du in Zero Knowledge, dass du eine registrierte Lizenz besitzt. Nicht welche Lizenz. Nur, dass sie existiert. Der Contract verifiziert, protokolliert eine Session, und du übergibst der Service-Seite ein Session-Cookie.
Dann ziehen die Doks eine klare Linie. Citadel beweist, dass die Session kryptografisch gültig ist. Es entscheidet nicht über die Service-Policy. Der Service wählt weiterhin, welchen Issuern er vertraut, welche Attribute er akzeptiert, ob die Session widerrufen ist und ob dieses Cookie zweimal funktioniert.
Mein Job ist das Testen einer App für Wertpapierhandel, und diese Aufteilung liest sich wie etwas, das von meinem Schreibtisch abgetippt wurde. Niemand dort sieht das Gesamtbild, absichtlich. Der Nutzer sieht seine eigene Order. Backoffice sieht den Batch. Das Deponierungs- bzw. Verwahrstelle sieht eine Settlement-Anweisung. Der Supervisor zieht auf Anfrage einen Bericht. Vier Sichten auf einen Trade – sortiert, lange bevor irgendwer einen Proof-Circuit geschrieben hat.
Meine Einschätzung: Das Wertvolle an Citadel ist nicht die Kryptografie, sondern die Verweigerung. Eine Kette, die für dich die Eignung entscheidet, ist eine, die kein Veranstaltungsort übernehmen dürfte. Eignung ist Jurisdiktion, Produktausgestaltung und die Risikoappetits des Issuers. All das sollte keinen Hard Fork brauchen.
Macht das eine App auf Dusk compliant? Nein. Jemand muss immer noch der License Provider sein, die Off-Chain-Checks ausführen und beantworten, wenn ein Check falsch war. Tooling heute: eine Rust-Bibliothek, der License-Contract, ein Wallet-CLI und ein JavaScript-SDK, das als „kommt noch“ gelistet ist. $DUSK zahlt Gas und sichert das Netzwerk durch Staking.
Also: Wer sollte diese Rolle des License Providers für ein reguliertes Asset innehaben – der Venue, der Issuer oder ein Dritter, dessen einzige Aufgabe darin besteht zu prüfen? Ich lande immer wieder beim dritten, ohne einen wirklich triftigen Grund.
#dusk