Heute habe ich den ganzen Nachmittag damit verbracht, mir das Dusk Network gründlich anzuschauen, um am Creatorpad-Programm des Projekts auf Binance teilzunehmen.
Da gibt es eine Einzelheit, die mich veranlasst hat, den Privacy-Teil des Dusk Network noch einmal zu lesen. „Selective Disclosure“ klingt ziemlich einfach: private Daten behalten, aber bei Bedarf offenlegen. Doch wenn man in die Docs tiefer geht, ist die Art, wie Dusk die Komponenten aufteilt, anders als ich es mir anfangs vorgestellt hatte.
Dusk beschreibt die Privacy derzeit in drei Richtungen: ein Public-Konto mit Moonlight, Shielded-Transaktionen mit Phoenix und Selective Disclosure, wenn eine berechtigte Partei einen Nachweis benötigt.
Ich bin tiefer in Citadel eingestiegen, weil die Docs das als Identity- und Access-Layer für Selective Disclosure definieren. Citadel verwendet Zero-Knowledge-Proofs, damit Nutzer belegen können, dass sie über eine gültige Lizenz verfügen, ohne dabei alle identifizierenden Informationen öffentlich machen zu müssen.
Das Bemerkenswerte liegt hier: In den Beispielen aus den Docs steht nicht „die komplette Identität offenlegen“. Der Nutzer erstellt anschließend einen Proof, und der Service Provider prüft die Berechtigung mithilfe des Prozesses von Citadel.
Moment—das heißt noch nicht, dass alle Daten auf Dusk automatisch selektiv offengelegt werden. Die Docs beschreiben nur die Primitives und Muster, damit Anwendungen passende Workflows aufbauen können.
Vielleicht ist das die Stelle, die ich mir behalten sollte: Dusk’ Selective Disclosure ist nicht „Privacy mit einem öffentlichen Schalter“, sondern die Art, Berechtigungen zum Beweisen einer Information von der Offenlegung aller Informationen zu trennen.
Damit wird die nächste Frage erst richtig spannend: Wie weit werden diese Primitives in realen Anwendungen tatsächlich umgesetzt?
#dusk $DUSK @Dusk $BTC
Da gibt es eine Einzelheit, die mich veranlasst hat, den Privacy-Teil des Dusk Network noch einmal zu lesen. „Selective Disclosure“ klingt ziemlich einfach: private Daten behalten, aber bei Bedarf offenlegen. Doch wenn man in die Docs tiefer geht, ist die Art, wie Dusk die Komponenten aufteilt, anders als ich es mir anfangs vorgestellt hatte.
Dusk beschreibt die Privacy derzeit in drei Richtungen: ein Public-Konto mit Moonlight, Shielded-Transaktionen mit Phoenix und Selective Disclosure, wenn eine berechtigte Partei einen Nachweis benötigt.
Ich bin tiefer in Citadel eingestiegen, weil die Docs das als Identity- und Access-Layer für Selective Disclosure definieren. Citadel verwendet Zero-Knowledge-Proofs, damit Nutzer belegen können, dass sie über eine gültige Lizenz verfügen, ohne dabei alle identifizierenden Informationen öffentlich machen zu müssen.
Das Bemerkenswerte liegt hier: In den Beispielen aus den Docs steht nicht „die komplette Identität offenlegen“. Der Nutzer erstellt anschließend einen Proof, und der Service Provider prüft die Berechtigung mithilfe des Prozesses von Citadel.
Moment—das heißt noch nicht, dass alle Daten auf Dusk automatisch selektiv offengelegt werden. Die Docs beschreiben nur die Primitives und Muster, damit Anwendungen passende Workflows aufbauen können.
Vielleicht ist das die Stelle, die ich mir behalten sollte: Dusk’ Selective Disclosure ist nicht „Privacy mit einem öffentlichen Schalter“, sondern die Art, Berechtigungen zum Beweisen einer Information von der Offenlegung aller Informationen zu trennen.
Damit wird die nächste Frage erst richtig spannend: Wie weit werden diese Primitives in realen Anwendungen tatsächlich umgesetzt?
#dusk $DUSK @Dusk $BTC
