Ein technisches Detail hat mich innehalten lassen und Dusk anders betrachtet.
Das Verhältnis zwischen DuskDS und DuskEVM hing nicht davon ab, noch eine weitere umschlossene Version des nativen $DUSK zu erstellen.
@Dusk_Foundation nutzt eine native Bridge-Architektur zwischen den Schichten.
Zunächst mag das wie eine kleine Implementierungsdetails klingen.
Aber ich denke nicht, dass es das ist.
Jede zusätzliche Bridge, jeder Wrapper oder jeder externe Custodian kann eine weitere Annahme in ein Finanzsystem einführen.
Also habe ich angefangen, Dusk anhand einer anderen Frage zu betrachten:
Wie viele zusätzliche Vertrauensannahmen braucht die Architektur tatsächlich?
Dusk’ Modell hält die Rollen klar:
DuskDS → Abwicklung und Netzwerksicherheit
DuskEVM → Ausführung von Anwendungen
Native Bridge → Übertragung von DUSK zwischen den Schichten
Das ist insbesondere für regulierte Finanzen relevant.
Wenn eine Institution bereits mit Compliance, Identität, Asset-Beschränkungen und Offenlegungsanforderungen zu tun hat, ist es nicht gerade hilfreich, unnötige Infrastrukturabhängigkeiten hinzuzufügen.
Deshalb gefällt mir hier das Designprinzip:
Füge keine Komplexität hinzu, wo das Protokoll sie nicht braucht.
Die gleiche Philosophie findet sich auch an anderen Stellen in Dusk:
Privatsphäre, wenn sensible Informationen geschützt werden müssen,
Transparenz, wenn der Markt Sichtbarkeit braucht,
und selektive Offenlegung, wenn eine autorisierte Partei Verifizierung benötigt.
Für mich ist das eine deutlich stärkere These, als einfach nur zu sagen:
„Dusk hat eine Bridge.“
Es geht darum, unnötige Vertrauensannahmen über den gesamten Finanz-Stack hinweg zu reduzieren.
#dusk
Das Verhältnis zwischen DuskDS und DuskEVM hing nicht davon ab, noch eine weitere umschlossene Version des nativen $DUSK zu erstellen.
@Dusk_Foundation nutzt eine native Bridge-Architektur zwischen den Schichten.
Zunächst mag das wie eine kleine Implementierungsdetails klingen.
Aber ich denke nicht, dass es das ist.
Jede zusätzliche Bridge, jeder Wrapper oder jeder externe Custodian kann eine weitere Annahme in ein Finanzsystem einführen.
Also habe ich angefangen, Dusk anhand einer anderen Frage zu betrachten:
Wie viele zusätzliche Vertrauensannahmen braucht die Architektur tatsächlich?
Dusk’ Modell hält die Rollen klar:
DuskDS → Abwicklung und Netzwerksicherheit
DuskEVM → Ausführung von Anwendungen
Native Bridge → Übertragung von DUSK zwischen den Schichten
Das ist insbesondere für regulierte Finanzen relevant.
Wenn eine Institution bereits mit Compliance, Identität, Asset-Beschränkungen und Offenlegungsanforderungen zu tun hat, ist es nicht gerade hilfreich, unnötige Infrastrukturabhängigkeiten hinzuzufügen.
Deshalb gefällt mir hier das Designprinzip:
Füge keine Komplexität hinzu, wo das Protokoll sie nicht braucht.
Die gleiche Philosophie findet sich auch an anderen Stellen in Dusk:
Privatsphäre, wenn sensible Informationen geschützt werden müssen,
Transparenz, wenn der Markt Sichtbarkeit braucht,
und selektive Offenlegung, wenn eine autorisierte Partei Verifizierung benötigt.
Für mich ist das eine deutlich stärkere These, als einfach nur zu sagen:
„Dusk hat eine Bridge.“
Es geht darum, unnötige Vertrauensannahmen über den gesamten Finanz-Stack hinweg zu reduzieren.
#dusk