duskvm

#dusk $DUSK @Dusk
Dusk’s modulare Stack: Drei Ebenen, ein Zweck

Was wäre, wenn die Blockchain-Architektur die Abwicklung und die Ausführung als getrennte Aufgaben behandelt?

@Dusk verfolgt genau diesen Ansatz mit einem modularen Design, das auf drei Komponenten basiert:

1. DuskDS — die Abwicklungsgrundlage
Sie übernimmt Konsens, Finalität, Datenverfügbarkeit und Dusks native Transaktionsmodelle, einschließlich Moonlight für öffentliche Überweisungen und Phoenix für geschützte Überweisungen.

2. DuskEVM — der EVM-Pfad
Entwickler können Solidity und vertraute Ethereum-Tools nutzen, während Anwendungen über DuskDS abwickeln. Das macht die Umgebung zugänglicher für EVM-basierte DeFi- und tokenisierte-Asset-Anwendungen.

3. DuskVM — direkte L1-Ausführung
DuskVM führt Rust/WASM-Smart-Contracts direkt auf Dusk L1 aus und eignet sich daher für Anwendungen, die tieferen Zugriff auf Dusks Transaktionsmodelle, Datenschutz oder Zero-Knowledge-Funktionen benötigen.

Das Spannende daran ist die Trennung selbst: Verschiedene Anwendungen können die Ausführungsumgebung wählen, die sie benötigen, ohne die zugrunde liegende Abwicklungsebene zu ersetzen.

Für $DUSK entsteht so eine Grundlage, in der EVM-Kompatibilität, direkte L1-Ausführung, Datenschutz und deterministische Abwicklung innerhalb derselben umfassenderen Architektur zusammenarbeiten können.

#DUSK #DuskEVM #DuskVM

Umfrage: 🏗️ Welcher Teil von Dusks modularer Architektur interessiert dich am meisten?

Ich habe immer wieder eine Sache falsch gemacht, während ich Moonlight und Phoenix durchdachte: Ich behandelte die Zustandsform so, als würde sie auch die Endgültigkeit bestimmen.
Diese Annahme begann mich zu stören.
Moonlight kommt bei #DuskVM mit einem public-account-Modell: Balances, Sender, Receiver, Amount und Nonce Progression.
Phoenix ist um eine komplett andere Spur herum gebaut: Encrypted Notes, Shielded Outputs, Nullifiers und Private State.
Mein erster Instinkt war, dass zwei so unterschiedliche Systeme wahrscheinlich auch zwei unterschiedliche Wege brauchen, um final zu werden.
Aber vielleicht fügte ich an der Stelle Komplexität hinzu, die eigentlich gar nicht da ist.
Moonlight kann weiterhin account-geformt bleiben. Phoenix kann weiterhin note-geformt bleiben. #DuskVM muss weder das eine noch das andere in ein universelles Zustandsformat flachdrücken, nur um zu entscheiden, wann die Ausführung abgeschlossen ist.
Das ließ mich auch #DuskDS neu überdenken.
Ich war davon ausgegangen, dass es darunter einen gemeinsam genutzten $DUSK -Zustand erzeugen muss, der beide Modelle verbindet. Davon bin ich jetzt weniger überzeugt.
Die Ausführungslogik kann spezialisiert bleiben, während Dusk L1 dem resultierenden Zustand weiterhin eine deterministische Endgültigkeitsgrenze gibt.
Und ehrlich gesagt, ist diese Trennung für mich spannender als die einzelnen Zustandsmodelle.
Verschiedene Arten, Zustand darzustellen, erfordern nicht notwendigerweise unterschiedliche Antworten auf die Frage, wann dieser Zustand am Ende wirklich abgeschlossen ist.
Das, worüber ich noch nachdenke, ist, wie sauber diese Trennung Bestand hat, während Moonlight und Phoenix komplexer werden.

#dusk $DUSK @Dusk

@Dusk baut etwas DeFi, und tokenisierte Finanzierungen werden zunehmend Folgendes brauchen: Privatsphäre ohne den Verlust der Compliance. Öffentliche Blockchains sind leistungsfähig, weil Transaktionen transparent und verifizierbar sein können, aber regulierte Finanzmärkte dürfen nicht jede Bilanz, Position, Anlegerdetails oder Transaktion öffentlich offenlegen. @Dusk begegnet dieser Herausforderung, indem es Zero-Knowledge-Technologie, vertrauliche Überweisungen, selektive Offenlegung, Zugriffskontrollen und deterministische Abrechnung kombiniert. �
Dusk +1
Was diesen Ansatz interessant macht, ist die Idee, dass Privatsphäre nicht zwangsläufig bedeuten muss, alles zu verbergen. Autorisierte Teilnehmer können die Informationen erhalten, die sie benötigen, während sensible Daten vor unnötiger öffentlicher Offenlegung geschützt bleiben. Das kann besonders relevant sein für tokenisierte Wertpapiere, Real-World-Assets, institutionelles DeFi und andere Finanz-Workflows, in denen Eignung, Reporting, Übertragungsbeschränkungen und Abrechnungsregeln eine Rolle spielen. �
DOCS +1
Dusk nutzt außerdem eine modulare Architektur: #DuskDS konzentriert sich auf Abrechnung und Datenverfügbarkeit, #DuskVM für die native Rust/WASM-Ausführung und #DuskEVM für EVM-kompatible Anwendungen. Das eröffnet Entwicklern verschiedene Wege – je nachdem, ob eine Anwendung native Privatsphäre, vertraute EVM-Tools oder regulierte Abrechnungsinfrastruktur priorisiert. �
DOCS
Für mich ist der interessante Teil von Dusk nicht nur „Privatsphäre“. Es ist die Kombination aus Privatsphäre, Compliance und planbarer Abrechnung in einer einzigen Finanzinfrastruktur. Wenn mehr Real-World-Assets und institutionelle Märkte on-chain gehen, könnten diese Fähigkeiten zunehmend an Bedeutung gewinnen. #dusk $DUSK