In den letzten zwei Tagen habe ich die Dokumentation von Citadel komplett durchgesehen. Eigentlich wollte ich nur eine kleine Sache verstehen: Wie man selektive Offenlegung hinbekommt. Danach habe ich gemerkt, dass ich eine Stelle zuvor falsch verstanden hatte.
Ich dachte, der Ablauf sei so: Identitätsdaten werden verschlüsselt auf die Blockchain geschrieben, und ein Regulator bekommt den Schlüssel zur Entschlüsselung.
So ist es nicht. Auf der Blockchain gibt es von Anfang bis Ende keine Identitätsdaten.
Der echte Ablauf ist ein Dreiparteien-Setup. Zuerst beantragst du beim License Provider ein verschlüsseltes Berechtigungszertifikat. Das passiert off-chain: Der Anbieter prüft Attribute wie Wohnsitz und die Qualifikation als geeigneter Investor. Das Zertifikat wird dir ausgestellt, und du verwahrst es selbst.
Wenn du später deine Berechtigung nachweisen willst, erstellst du on-chain einen Zero-Knowledge-Beweis: Er belegt, dass ich ein gültiges Zertifikat besitze und dass es bestimmte, festgelegte Eigenschaften erfüllt.
Der Service Provider erhält dabei nur ein notwendiges session cookie. Keine Ausweisnummer, keine Adresse und auch nicht das Zertifikat selbst.
Wo liegt der Unterschied? Wenn man verschlüsselte Daten auf die Blockchain schreibt, bedeutet ein Tag der Schlüsselkompromittierung, dass die Daten vollständig offengelegt werden – und die On-Chain-Aufzeichnungen bleiben dauerhaft erhalten. Bei Citadel werden sensible Daten nie on-chain abgelegt. Stattdessen wird nur ein Nachweis on-chain geführt. Das nimmt die Verantwortung für den Besitz sensibler Daten von der Plattform.
Der XSC-Standard ist die passende zweite Hälfte: Anlegerberechtigungen und Übertragungsbeschränkungen werden direkt in das Asset selbst geschrieben, und der Vertrag prüft automatisch. Nicht-konforme Übertragungen werden bereits in der Verifikationsphase abgeblockt – nicht erst später sanktioniert.
Aber als ich hierher kam, habe ich gestoppt.
Der zentrale Vertrauensanker des gesamten Modells liegt nicht in der Kryptografie, sondern beim License Provider.
Wer darf Zertifikate ausstellen? Wie werden Zertifikate widerrufen? Wenn die Ausstellerorganisation geschlossen wird: Sind die alten Zertifikate in der Hand dann noch gültig? Die Definition „qualifizierter Investor“ ist je nach Land nicht einheitlich – erkennt man in Deutschland ein von den Niederlanden ausgestelltes Zertifikat an?
All das spielt sich nicht in den Schaltkreisen ab, sondern im Bereich Governance. Die Beschreibung in den Dokumenten zum Widerrufsmechanismus ist im Vergleich zu anderen Teilen eher dünn.
Deshalb schaue ich mir Citadel jetzt an und bin nicht so sehr daran interessiert, wie viele Millisekunden die Nachweisgenerierung dauert. Ich warte auf die ersten Listen von License Providern: Wie viele gibt es, und welche Qualifikationen haben sie?
Der kryptografische Teil ist erledigt. Der Rest ist die mühselige Arbeit, jede zugelassene Institution einzeln zu verhandeln – und genau das ist der langsamste Teil.
#dusk $DUSK @Dusk
Ich dachte, der Ablauf sei so: Identitätsdaten werden verschlüsselt auf die Blockchain geschrieben, und ein Regulator bekommt den Schlüssel zur Entschlüsselung.
So ist es nicht. Auf der Blockchain gibt es von Anfang bis Ende keine Identitätsdaten.
Der echte Ablauf ist ein Dreiparteien-Setup. Zuerst beantragst du beim License Provider ein verschlüsseltes Berechtigungszertifikat. Das passiert off-chain: Der Anbieter prüft Attribute wie Wohnsitz und die Qualifikation als geeigneter Investor. Das Zertifikat wird dir ausgestellt, und du verwahrst es selbst.
Wenn du später deine Berechtigung nachweisen willst, erstellst du on-chain einen Zero-Knowledge-Beweis: Er belegt, dass ich ein gültiges Zertifikat besitze und dass es bestimmte, festgelegte Eigenschaften erfüllt.
Der Service Provider erhält dabei nur ein notwendiges session cookie. Keine Ausweisnummer, keine Adresse und auch nicht das Zertifikat selbst.
Wo liegt der Unterschied? Wenn man verschlüsselte Daten auf die Blockchain schreibt, bedeutet ein Tag der Schlüsselkompromittierung, dass die Daten vollständig offengelegt werden – und die On-Chain-Aufzeichnungen bleiben dauerhaft erhalten. Bei Citadel werden sensible Daten nie on-chain abgelegt. Stattdessen wird nur ein Nachweis on-chain geführt. Das nimmt die Verantwortung für den Besitz sensibler Daten von der Plattform.
Der XSC-Standard ist die passende zweite Hälfte: Anlegerberechtigungen und Übertragungsbeschränkungen werden direkt in das Asset selbst geschrieben, und der Vertrag prüft automatisch. Nicht-konforme Übertragungen werden bereits in der Verifikationsphase abgeblockt – nicht erst später sanktioniert.
Aber als ich hierher kam, habe ich gestoppt.
Der zentrale Vertrauensanker des gesamten Modells liegt nicht in der Kryptografie, sondern beim License Provider.
Wer darf Zertifikate ausstellen? Wie werden Zertifikate widerrufen? Wenn die Ausstellerorganisation geschlossen wird: Sind die alten Zertifikate in der Hand dann noch gültig? Die Definition „qualifizierter Investor“ ist je nach Land nicht einheitlich – erkennt man in Deutschland ein von den Niederlanden ausgestelltes Zertifikat an?
All das spielt sich nicht in den Schaltkreisen ab, sondern im Bereich Governance. Die Beschreibung in den Dokumenten zum Widerrufsmechanismus ist im Vergleich zu anderen Teilen eher dünn.
Deshalb schaue ich mir Citadel jetzt an und bin nicht so sehr daran interessiert, wie viele Millisekunden die Nachweisgenerierung dauert. Ich warte auf die ersten Listen von License Providern: Wie viele gibt es, und welche Qualifikationen haben sie?
Der kryptografische Teil ist erledigt. Der Rest ist die mühselige Arbeit, jede zugelassene Institution einzeln zu verhandeln – und genau das ist der langsamste Teil.
#dusk $DUSK @Dusk