#dusk Ich habe die Architektur-Dokumentation von @Dusk noch einmal komplett neu sortiert. Zuerst hat mich nicht der Zero-Knowledge-Beweis ausgebremst, sondern die Frage, warum derselbe Netzwerktyp gleichzeitig zwei Überweisungswege—einen öffentlich und einen privat—vorhalten muss. Viele Projekte behandeln Privatsphäre wie einen Schalter: Wenn er an ist, sieht man nichts; wenn er aus ist, ist alles transparent. Sobald man aber in reale Finanzszenarien eintaucht, reicht diese Entweder-oder-Logik nicht mehr aus: Der Zahler möchte das Guthaben schützen, der Emittent muss möglicherweise die Berechtigung verifizieren, und der Prüfer muss in bestimmten Bereichen Belege erhalten.
Dusk bildet auf der Basisebene Moonlight als öffentliches Kontomodell ab und Phoenix als privates UTXO-Modell. Beide können $DUSK übertragen, Gas bezahlen und als Ausführungs-Einstiegspunkt für Smart Contracts dienen. Darüber hinaus gibt es die direkte Ausführung von Rust/WASM-Contracts über die DuskVM sowie DuskEVM für den Solidity-Toolchain-Stack. Das Interessante an dieser Kombination ist nicht die Formulierung „Privacy Chain“, sondern dass die Funktionen „öffentliche Abrechnung“, „private Überweisung“ und „Anwendungs-Kompatibilität“ jeweils unterschiedliche Aufgaben übernehmen.
Auch wenn die Schichten sauber getrennt sind, heißt das nicht, dass die Benutzergrenzen automatisch klar sind. Wann wechselt das Geld von öffentlichem Guthaben zu privatem Guthaben? Wer hat die selektive Offenlegungsberechtigung? Laufen Anwendungen über DuskVM oder DuskEVM? Kann ein normaler Nutzer Zustandsänderungen über Schichten hinweg nachvollziehen? All das erhöht die Lern- und Verstehenskosten. Vor allem bei regulierten Vermögenswerten gilt: Privatsphäre bedeutet nicht, Offenlegung zu verweigern, sondern Offenlegung auf Empfänger, Inhalte und Zeitpunkt zu begrenzen. Jede Unklarheit im Berechtigungskonzept kann am Ende zu einer anderen Art von Blackbox führen.
Deshalb schaue ich mir Dusk nicht nur mit der Frage an, ob es eine einzelne Überweisung verbergen kann. Vielmehr interessiert mich: Wenn Offenlegung nötig ist, kann man dann genügend Beweise liefern? Wenn Vertraulichkeit nötig ist, kann man dann möglichst wenig irrelevante Informationen preisgeben? Und können beide Wege nach dem Wechsel ihre Klarheit beibehalten? Die Architekturidee ist richtig—die eigentliche Schwierigkeit besteht darin, die Komplexität im Protokoll zu lassen, statt sie den Nutzern aufzubürden.
$SNXXB $BTC
Dusk bildet auf der Basisebene Moonlight als öffentliches Kontomodell ab und Phoenix als privates UTXO-Modell. Beide können $DUSK übertragen, Gas bezahlen und als Ausführungs-Einstiegspunkt für Smart Contracts dienen. Darüber hinaus gibt es die direkte Ausführung von Rust/WASM-Contracts über die DuskVM sowie DuskEVM für den Solidity-Toolchain-Stack. Das Interessante an dieser Kombination ist nicht die Formulierung „Privacy Chain“, sondern dass die Funktionen „öffentliche Abrechnung“, „private Überweisung“ und „Anwendungs-Kompatibilität“ jeweils unterschiedliche Aufgaben übernehmen.
Auch wenn die Schichten sauber getrennt sind, heißt das nicht, dass die Benutzergrenzen automatisch klar sind. Wann wechselt das Geld von öffentlichem Guthaben zu privatem Guthaben? Wer hat die selektive Offenlegungsberechtigung? Laufen Anwendungen über DuskVM oder DuskEVM? Kann ein normaler Nutzer Zustandsänderungen über Schichten hinweg nachvollziehen? All das erhöht die Lern- und Verstehenskosten. Vor allem bei regulierten Vermögenswerten gilt: Privatsphäre bedeutet nicht, Offenlegung zu verweigern, sondern Offenlegung auf Empfänger, Inhalte und Zeitpunkt zu begrenzen. Jede Unklarheit im Berechtigungskonzept kann am Ende zu einer anderen Art von Blackbox führen.
Deshalb schaue ich mir Dusk nicht nur mit der Frage an, ob es eine einzelne Überweisung verbergen kann. Vielmehr interessiert mich: Wenn Offenlegung nötig ist, kann man dann genügend Beweise liefern? Wenn Vertraulichkeit nötig ist, kann man dann möglichst wenig irrelevante Informationen preisgeben? Und können beide Wege nach dem Wechsel ihre Klarheit beibehalten? Die Architekturidee ist richtig—die eigentliche Schwierigkeit besteht darin, die Komplexität im Protokoll zu lassen, statt sie den Nutzern aufzubürden.
$SNXXB $BTC
