Ich komme immer wieder auf etwas zurück, das ich bei der Erforschung von @Dusk frage: Ob Compliance wirklich einen Preis in Form von Datenschutz bezahlen muss, und dass der Großteil der Design-Logik darin liegt, dass Citadel 2 „den Nachweis, dass eine Prüfung erfolgt ist“ von „der Offenlegung der Person hinter dem Account“ trennt.

Der Ablauf beginnt damit, dass der License Provider den Nutzer off-chain prüft und die benötigten Attribute signiert.

Daraufhin erstellt der Nutzer ein Zero-Knowledge-Proof, um nachzuweisen, dass er eine gültige, signierte und on-chain registrierte License besitzt – genau das fand ich am interessantesten.

Das Proof wird über Kryptografie ausgeführt, ohne dass Wallet-Schlüssel, Attribute oder die konkrete License offengelegt werden. Hier wird die Frage nach dem Datenschutz wirklich geprüft.

Die Service-Policy ist stets im Hintergrund vorhanden und wartet darauf, dass der Service Provider entscheidet, welcher Provider als vertrauenswürdig gilt, welche Attribute akzeptiert werden und ob die Sitzung noch gültig ist.

Am Ende bestätigt der Contract lediglich das gültige Proof und protokolliert eine öffentliche Sitzung. On-chain bleibt nur der Nachweis, dass ein gültiges Credential verwendet wurde.

Was ich noch nicht weiß, ist, wie dieses Mechanismus funktionieren wird, wenn sich die Policy ändert, wenn ein Provider ein falsches Credential ausstellt oder wenn alte Sessions weiterhin gültig sind, statt im idealen Fall.

Die Frage ist, ob die Kryptografie tatsächlich den Bedarf beseitigt, die Identität für das Access Control offenzulegen, oder ob sie das Vertrauen nur an die Stelle verlagert, die das Credential ausstellt und dessen Interpretation übernimmt.

Ich verfolge, wie #dusk die Grenze zwischen kryptografischem Proof und Service-Policy behandelt, wenn reguliertes Finance es wirklich zu nutzen beginnt. $DUSK $KII $AKE
#RedditToJoinSP500 #US30YBondAuctionYieldHighestSince2001 #GlobalStocksNearRecordHighs #ProCapFilesBitcoinTreasuryDiscountETF