Als die Ingenieure von Dusk Network entscheiden mussten, wie Verträge tatsächlich ausgeführt werden, griffen sie nicht nach dem naheliegenden Abkürzungsweg. Die meisten neuen Layer-1s, die in den letzten Jahren gestartet sind, wurden ab Tag 1 EVM-kompatibel ausgeliefert und setzten darauf, dass die Vertrautheit mit Solidity alle technischen Nachteile überwiegen würde. Dusk Network baute zuerst seine eigene virtuelle Maschine: Piecrust, eine WASM-basierte Laufzeit mit nativer Unterstützung für Zero-Knowledge-Operationen wie PLONK und Groth16-Verifikation sowie einem Delta-basierten Zustandsmodell, das nur das speichert, was sich tatsächlich geändert hat, statt bei jedem Block den kompletten Zustand neu zu schreiben.
Das ist ein schwierigerer, langsamerer Weg. Es ist auch der einzige Weg, der es Dusk Network ermöglichte, dass seine Verträge Zero-Knowledge-native sind – und nicht nur Zero-Knowledge-nah –, da standardisierte EVM-Umgebungen nicht für die vertrauliche Proof-Verifikation als erstklassige Operation entworfen wurden. Der Preis dafür war die Entwicklervertrautheit: Die meisten Ingenieure kennen Solidity, deutlich weniger kennen Rust plus die Contract-Makros von Dusk Network – und das war eine reale Kostenposition, die das Team bewusst in Kauf nahm.
Spannend ist, dass Dusk Network diese Abwägung nicht für immer beibehielt. Mit DuskEVM kam eine zweite Ausführungsumgebung hinzu, vollständig EVM-äquivalent, die sich auf dieselbe zugrunde liegende DuskDS-Schicht absetzt, die Piecrust-basierte Verträge verwenden, mit einer vertrauenslosen nativen Bridge und Standard-Tooling, das Entwicklern bereits vertraut ist. Anstatt ein einziges Ausführungsmodell auszuwählen und jeden Use Case zwingend durch dieses zu pressen, trennte Dusk Network Settlement und Ausführung vollständig: Privacy-native Anwendungen leben auf Piecrust, Ethereum-native Teams auf DuskEVM – und beide erben dieselben Konsens- und Finalitätsgarantien darunter.
Ich denke, diese Reihenfolge war die richtige Entscheidung: Erst das schwierigere, stärker differenzierende Produkt bauen und erst dann den vertrauten Einstieg ergänzen, sobald das Fundament steht. Ob 2 Ausführungsumgebungen Liquidität und Aufmerksamkeit fragmentieren, statt Flexibilität hinzuzufügen, ist jedoch noch eine offene Designfrage, die niemand außerhalb von Dusk Network bislang vollständig beantworten kann.
#dusk $DUSK @Dusk
Das ist ein schwierigerer, langsamerer Weg. Es ist auch der einzige Weg, der es Dusk Network ermöglichte, dass seine Verträge Zero-Knowledge-native sind – und nicht nur Zero-Knowledge-nah –, da standardisierte EVM-Umgebungen nicht für die vertrauliche Proof-Verifikation als erstklassige Operation entworfen wurden. Der Preis dafür war die Entwicklervertrautheit: Die meisten Ingenieure kennen Solidity, deutlich weniger kennen Rust plus die Contract-Makros von Dusk Network – und das war eine reale Kostenposition, die das Team bewusst in Kauf nahm.
Spannend ist, dass Dusk Network diese Abwägung nicht für immer beibehielt. Mit DuskEVM kam eine zweite Ausführungsumgebung hinzu, vollständig EVM-äquivalent, die sich auf dieselbe zugrunde liegende DuskDS-Schicht absetzt, die Piecrust-basierte Verträge verwenden, mit einer vertrauenslosen nativen Bridge und Standard-Tooling, das Entwicklern bereits vertraut ist. Anstatt ein einziges Ausführungsmodell auszuwählen und jeden Use Case zwingend durch dieses zu pressen, trennte Dusk Network Settlement und Ausführung vollständig: Privacy-native Anwendungen leben auf Piecrust, Ethereum-native Teams auf DuskEVM – und beide erben dieselben Konsens- und Finalitätsgarantien darunter.
Ich denke, diese Reihenfolge war die richtige Entscheidung: Erst das schwierigere, stärker differenzierende Produkt bauen und erst dann den vertrauten Einstieg ergänzen, sobald das Fundament steht. Ob 2 Ausführungsumgebungen Liquidität und Aufmerksamkeit fragmentieren, statt Flexibilität hinzuzufügen, ist jedoch noch eine offene Designfrage, die niemand außerhalb von Dusk Network bislang vollständig beantworten kann.
#dusk $DUSK @Dusk
