Vor ein paar Tagen habe ich mich mit einem alten Freund, der bereits bei der Umsetzung von regulatorisch konformen Security-Tokens (证券通证) mitgewirkt hat, in lockeren Gesprächen unterhalten. Dabei ging es um die grundlegende Positionierung von @Dusk (https://www.binance.com/zh-CN/square/profile/dusk_foundation). Die von ihm ins Spiel gebrachten Ansichten haben meine ersten Erkenntnisse aktualisiert, die sich beim Lesen von Kapitel 1 des Whitepapers bei mir herausgebildet hatten.

Viele in der Szene sprechen über Dusk und schauen dabei nur auf das Label „Privacy L1“. Sie gehen automatisch davon aus, dass eine Architektur, die Privatsphäre und Auditierung (Prüfbarkeit) zugleich berücksichtigt, RWA-Assets direkt übernehmen kann. Doch dieser Freund, der seit langem mit Institutionen in Kontakt ist, hat mir auf ein Umsetzungs-Widerspruch hingewiesen, den ich zuvor übersehen hatte: Diese native Konzeption bringt von Natur aus unvermeidliche Anpassungskosten mit.

Ich habe daraufhin das Whitepaper-Kapitel 1 erneut durchgesehen. Dort wird ganz klar als Kernziel genannt, eine datenschutzkonforme Finanz-Infrastruktur aufzubauen. Dazu werden PLONK-Zero-Knowledge-Beweise genutzt und mit drei grundlegenden Primitiven REGISTER, SEND und CREATE kombiniert, um Transaktionsinformationen zu verschlüsseln und gleichzeitig eine autorisierte Auditierungs-/Prüfungs-„Pipeline“ vorzusehen. $DUSK übernimmt dabei Aufgaben wie das Deployen von Smart Contracts im Netzwerk sowie Beweisberechnungen und trägt entsprechend den Aufwand in der Berechnung.

Theoretisch überwindet es die Extreme einer rein anonymen Kette und einer vollständig transparenten öffentlichen Kette. Da jedoch die bestehenden Geschäftssysteme traditioneller Finanzinstitute (TradFi) bereits weit ausgereift und verfestigt sind, kann die Anbindung an diese native Privacy-Architektur nicht einfach durch ein „Zuklemmen“ erfolgen; dafür muss man bestehende Prozesse umbauen. Es lässt sich nicht ohne Weiteres als simpler Anschluss für Security-Token-Lösungen „online“ bringen.

Meiner Ansicht nach handelt es sich dabei nicht um ein kurzfristiges Störfall-Risiko, sondern um ein strukturelles Problem, das beim On-Chain-Ansatz von TradFi systembedingt mitgeliefert wird. Viele lassen sich leicht von der Datenschutz-Technologie-Narration anziehen, überschätzen die Geschwindigkeit der Umsetzung und unterschätzen die lange, zähe Phase von Compliance-Umstellungen auf Seiten der Institutionen sowie die notwendige Abstimmung im Geschäftsablauf. Genau das ist auch die zentrale Variable, der ich seit dem Lesen des Einstiegskapitels kontinuierlich Aufmerksamkeit schenke.#dusk $DUSK

Über welche Kern-Designs wird im Dusk-Netzwerk Privatsphäre und Compliance in beide Richtungen kompatibel gemacht?