Dusk mit Chainlink zu arbeiten wirkt unkompliziert, bis man fragt, in welche Richtung die Daten sich bewegen. Dann wird es spannend, denn die beiden Richtungen haben völlig unterschiedliche Datenschutz-Eigenschaften.
Eingehende Daten sind die einfache Hälfte. Ein Dusk-Contract, der eine tokenisierte Anleihe hält, benötigt Referenzzinsen, FX sowie den NAV eines Fonds. All das ist von Natur aus öffentlich. Ein Oracle, das einen Euro-Kurs auf Dusk schreibt, leakt nichts darüber, wer was hält, weil die Zahl niemals privat war. Der Datenschutz bleibt unberührt.
Ausgehende Daten sind der Punkt, an dem es nicht mehr so einfach ist.
Nehmen wir Proof of Reserve. Der gesamte Wert dieses Musters besteht darin, eine Bestätigung zu veröffentlichen, dass Reserven existieren und zur ausgegebenen Menge passen. Bei Dusk werden die Bestände per Design abgeschirmt. Entweder legt die Bestätigung die Bilanzen offen, auf die sie sich bezieht – und damit wäre der Sinn der Abschirmung dahin – oder sie muss ein Beweis über einen verborgenen Zustand sein, statt dessen Veröffentlichung. Das sind sehr unterschiedliche technische Probleme, und sie werden oft so besprochen, als wären es das Gleiche.
Cross-Chain ist die schärfere Variante. Wenn man ein abgeschirmtes Dusk-Asset auf eine transparente Kette bewegt, reist der Datenschutz nicht mit. Im Moment der Landung sind der Kontostand öffentlich, der Inhaber ist öffentlich und die Historie ist öffentlich. Jede Datenschutzgarantie, die Dusk aufbaut, endet genau an dieser Grenze.
Das macht Interoperabilität eher zu einer politischen Frage als zu einer technischen. Nicht nur: Kann sich dieses Asset bewegen? Sondern: Soll dieses konkrete Instrument überhaupt die Erlaubnis haben, eine konforme private Umgebung zu verlassen, in der das Verzeichnis seines Inhabers zu einem öffentlichen Datensatz wird.
@Dusk wie denkst du über diese Randfrage nach? Ist das Bridging aus dem abgeschirmten Zustand auf Protokollebene eingeschränkt, oder wird es dem überlassen, der das Instrument ausgibt?
Mich interessiert, ob hier jemand der Meinung ist, dass Privacy-Chains bestimmte Bridges kategorisch ablehnen sollten.
@Dusk $DUSK #dusk #RWA
Eingehende Daten sind die einfache Hälfte. Ein Dusk-Contract, der eine tokenisierte Anleihe hält, benötigt Referenzzinsen, FX sowie den NAV eines Fonds. All das ist von Natur aus öffentlich. Ein Oracle, das einen Euro-Kurs auf Dusk schreibt, leakt nichts darüber, wer was hält, weil die Zahl niemals privat war. Der Datenschutz bleibt unberührt.
Ausgehende Daten sind der Punkt, an dem es nicht mehr so einfach ist.
Nehmen wir Proof of Reserve. Der gesamte Wert dieses Musters besteht darin, eine Bestätigung zu veröffentlichen, dass Reserven existieren und zur ausgegebenen Menge passen. Bei Dusk werden die Bestände per Design abgeschirmt. Entweder legt die Bestätigung die Bilanzen offen, auf die sie sich bezieht – und damit wäre der Sinn der Abschirmung dahin – oder sie muss ein Beweis über einen verborgenen Zustand sein, statt dessen Veröffentlichung. Das sind sehr unterschiedliche technische Probleme, und sie werden oft so besprochen, als wären es das Gleiche.
Cross-Chain ist die schärfere Variante. Wenn man ein abgeschirmtes Dusk-Asset auf eine transparente Kette bewegt, reist der Datenschutz nicht mit. Im Moment der Landung sind der Kontostand öffentlich, der Inhaber ist öffentlich und die Historie ist öffentlich. Jede Datenschutzgarantie, die Dusk aufbaut, endet genau an dieser Grenze.
Das macht Interoperabilität eher zu einer politischen Frage als zu einer technischen. Nicht nur: Kann sich dieses Asset bewegen? Sondern: Soll dieses konkrete Instrument überhaupt die Erlaubnis haben, eine konforme private Umgebung zu verlassen, in der das Verzeichnis seines Inhabers zu einem öffentlichen Datensatz wird.
@Dusk wie denkst du über diese Randfrage nach? Ist das Bridging aus dem abgeschirmten Zustand auf Protokollebene eingeschränkt, oder wird es dem überlassen, der das Instrument ausgibt?
Mich interessiert, ob hier jemand der Meinung ist, dass Privacy-Chains bestimmte Bridges kategorisch ablehnen sollten.
@Dusk $DUSK #dusk #RWA
