Heute Nachmittag habe ich den Citadel-Protokollvertrag von @Dusk zerlegt. An dem Wort „license“ bin ich lange hängen geblieben. Zuerst dachte ich noch: Ist das nicht einfach so, dass man die Identität direkt auf die Chain „draufknallt“? Aber nach mehrmaligem Durchgehen der Dokumentation habe ich erst verstanden – ganz und gar nicht.

Der Kern ist: Nachdem der Qualifikationsanbieter offline eine Prüfung durchgeführt hat, stellt er dir eine verschlüsselte Lizenz aus und trägt diese dann im Vertrag ein. Was der Nutzer tatsächlich einreicht, ist ein Zero-Knowledge-Proof, der lediglich belegt: „Ich habe eine gültige license in der Hand.“ Der Service-Provider prüft dann nur öffentliche Sessions und entscheidet, ob er durchlässt oder nicht. In diesem gesamten Ablauf sind drei Rollen klar unterschieden: der Nutzer, der License Provider und der Service Provider.

Das wirkt weniger so, als müsste man bei jedem Gebäude seinen Personalausweis kopieren und jedes Mal wieder vorlegen, sondern eher wie im Krankenhaus: Man wird einmal verifiziert, bekommt dann ein „ärztlich bescheinigt“-Zertifikat, und das Fitnessstudio lässt dich rein, sobald das Zertifikat gültig ist – ohne dass sie Akten oder Wohnadresse sehen. Aber „weniger offengelegt“ heißt nicht „null Vertrauen“. Wer darf ausstellen, wie wird widerrufen, wie lange ist die Gültigkeit, und ob der Service-Provider außerhalb der Chain wieder Informationen einsammelt – genau diese Punkte ziehen die tatsächliche Privatsphäre-Grenze.

Ich habe auch gesehen, dass das offizielle Team sagt, dass der komplette JS SDK noch nicht fertig ist; Protokoll und Entwicklererlebnis sind wirklich zwei Paar Schuhe. Wenn man dann das Transaktionsmodell genauer betrachtet: Moonlight ist ein öffentliches Konto – Kontostand-Adresse und Beträge sind vollständig transparent. Phoenix nutzt verschleierte Belege und Nullifier: Betrag und Teilnehmer werden nicht offengelegt, und man kann mit Viewing Keys selektiv offenlegen. Beide laufen on-chain, und Nutzer wählen je nach Szenario.

Aber bei der Integration mit Börsen gilt: Mehr Privatsphäre ist nicht automatisch besser. Verwahrung, Attribution, Audit – all das muss zum Betrieb passen. Am Ende läuft der häufigste Ein- und Auszahlungsweg doch über den öffentlichen Pfad. Wenn Nutzer etwas verstecken wollen, müssen sie öfter umwandeln – die Kosten sind nicht niedrig.

Nehmen wir als Beispiel Moonlight-Withdrawals: Die Transaktion verschwindet, sobald sie etwa eine halbe Stunde lang auf dem Node wartet, aus dem Mempool. Offiziell wird das sehr offen gesagt: Die Ablaufzeit wird nicht in die Transaktion geschrieben, sondern ist die Strategie jedes einzelnen Nodes. Rusk ist standardmäßig auf drei Tage gesetzt, manche Konfigurationen auf 30 Minuten. Node A kann es nicht sehen, Node B muss es nicht synchronisieren. transactions/removed bedeutet nur, dass es den lokalen Pool verlässt; der Grund kann sein, dass es in einen Block kommt, ersetzt wird oder Konflikte bestehen. 202 Accepted heißt nur, dass der Node die Anfrage angenommen hat – nicht, dass es der endgültige Zustand ist. Vor einem Retry muss man Nonce und Ausführungsergebnis prüfen; eine Beobachtung eines einzelnen Nodes kann man nicht als Schlussfolgerung fürs ganze Netzwerk nehmen. #dusk

Aktuell mit dem Dual-Path-Design für $DUSK : Welche Art der Verwendung bevorzugt ihr?