#dusk Alle, die mit Ethereum arbeiten (#ETH ) oder mit Dingen wie Arbitrum, Optimism L2s genutzt haben, sollten da bestimmt schon ihre Erfahrungen gemacht haben. Solidity-Kontrakte zu schreiben ist zwar einfach, aber sobald es um komplexe Berechnungen oder Zero-Knowledge-Proofs (ZKP) geht, wird die Performance der EVM (Ethereum Virtual Machine) so langsam wie ein alter Kutschwagen – und die Gas-Kosten sind auch noch völlig überrissen. Wenn man dann aber für bessere Performance eine völlig neue Basissprache entwickelt, sind weder Entwickler noch Nutzer wirklich bereit, umzuziehen, und das Ökosystem kühlt sofort ab.
Heute habe ich mir die Designs von @Dusk ($DUSK ) angesehen und fand die Idee, mit dem Problem umzugehen, ziemlich interessant – sie macht sich das Ganze direkt zu einem „Lego-Modul-Baukasten“.
Ganz einfach: Sie teilen die Basis in drei Teile auf:
Die Basis „großes Hauptbuch und Abwicklungsstelle“ (DuskDS): Zuständig dafür, SA-Kon-Konsens auszuführen und Daten abzurechnen. Das ist wie der Hauptserver einer Bank – kümmert sich nur um die endgültige Zuordnung und Sicherheit der Assets auf der untersten Ebene, macht keinen Schnickschnack, garantiert extrem hohe Datenverfügbarkeit und Abrechnungs-Determinismus.
Die native „Turbo-Engine“ (DuskVM / Piecrust): Eine native VM, die mit Rust und WASM läuft und speziell für Zero-Knowledge-Proofs und anspruchsvolle Privacy-Computations gedacht ist. Das ist wie ein Profi-Grafikchip fürs System – ZK-Privacy-Transaktionen sind damit quasi im Handumdrehen erledigt.
Der „Ethereum-Allzweck-Front-End“-Bauzug (DuskEVM): Speziell als Kompatibilitätsschicht für Ethereum-Ökosystem-Entwickler gedacht. Entwickler müssen keine neue Sprache lernen: Sie können einfach mit Hardhat und Metamask die Anwendungen, die auf ETH laufen, 1:1 rüberholen – und zahlen den Gas-Aufwand, den $DUSK generiert.
Dieses Design mit Trennung von Abwicklungsebene und Ausführungsebene fühlt sich an, als würde man das riesige Ethereum-Ökosystem „schmerzfrei“ in eine super Basisschicht einstecken, die schon einen ZKP-Privacy-Beschleuniger eingebaut hat.
Aber mal ehrlich: So gut die Schichtenarchitektur-Idee auch ist – die größte Herausforderung liegt in der Sicherheit bei mehrschichtigen Interaktionen. Wenn Assets zwischen DuskEVM und der nativen Privacy-Schicht über Schichten hinweg verschoben werden, verdoppelt sich die logische Komplexität: Gibt es dann Lücken in den Verträgen? Wird die Verzögerung bei der abteilungsübergreifenden Abrechnung von den Nutzern akzeptiert? Das sind alles harte Prüfungen, die man unbedingt bestehen muss, bevor das Mainnet-Ökosystem wirklich floriert. Schreibt euch in den Kommentaren mal die Erfahrungen aus!
Heute habe ich mir die Designs von @Dusk ($DUSK ) angesehen und fand die Idee, mit dem Problem umzugehen, ziemlich interessant – sie macht sich das Ganze direkt zu einem „Lego-Modul-Baukasten“.
Ganz einfach: Sie teilen die Basis in drei Teile auf:
Die Basis „großes Hauptbuch und Abwicklungsstelle“ (DuskDS): Zuständig dafür, SA-Kon-Konsens auszuführen und Daten abzurechnen. Das ist wie der Hauptserver einer Bank – kümmert sich nur um die endgültige Zuordnung und Sicherheit der Assets auf der untersten Ebene, macht keinen Schnickschnack, garantiert extrem hohe Datenverfügbarkeit und Abrechnungs-Determinismus.
Die native „Turbo-Engine“ (DuskVM / Piecrust): Eine native VM, die mit Rust und WASM läuft und speziell für Zero-Knowledge-Proofs und anspruchsvolle Privacy-Computations gedacht ist. Das ist wie ein Profi-Grafikchip fürs System – ZK-Privacy-Transaktionen sind damit quasi im Handumdrehen erledigt.
Der „Ethereum-Allzweck-Front-End“-Bauzug (DuskEVM): Speziell als Kompatibilitätsschicht für Ethereum-Ökosystem-Entwickler gedacht. Entwickler müssen keine neue Sprache lernen: Sie können einfach mit Hardhat und Metamask die Anwendungen, die auf ETH laufen, 1:1 rüberholen – und zahlen den Gas-Aufwand, den $DUSK generiert.
Dieses Design mit Trennung von Abwicklungsebene und Ausführungsebene fühlt sich an, als würde man das riesige Ethereum-Ökosystem „schmerzfrei“ in eine super Basisschicht einstecken, die schon einen ZKP-Privacy-Beschleuniger eingebaut hat.
Aber mal ehrlich: So gut die Schichtenarchitektur-Idee auch ist – die größte Herausforderung liegt in der Sicherheit bei mehrschichtigen Interaktionen. Wenn Assets zwischen DuskEVM und der nativen Privacy-Schicht über Schichten hinweg verschoben werden, verdoppelt sich die logische Komplexität: Gibt es dann Lücken in den Verträgen? Wird die Verzögerung bei der abteilungsübergreifenden Abrechnung von den Nutzern akzeptiert? Das sind alles harte Prüfungen, die man unbedingt bestehen muss, bevor das Mainnet-Ökosystem wirklich floriert. Schreibt euch in den Kommentaren mal die Erfahrungen aus!
