#dusk @Dusk Dusk musste DuskEVM eigentlich gar nicht entwickeln. Es verfügt bereits über eine eigene native Ausführungsumgebung, DuskVM, die Rust-Code ausführt, der zu WASM kompiliert wurde, statt Solidity. Dass beide nebeneinander existieren, anstatt sich für eine davon zu entscheiden und ganz auf sie zu setzen, sagt etwas darüber aus, wofür die beiden jeweils optimiert sind und welche Kompromisse dafür eingegangen wurden.
DuskVM ist der native Weg. Rust und WASM bieten eine genauere Kontrolle auf niedrigerer Ebene, im Allgemeinen besser vorhersehbare Performance und direkten Zugriff auf alle Dusk-spezifischen Primitiven, die die Basisschicht bereitstellt, ohne dafür eine Kompatibilitätsschicht durchlaufen zu müssen. Der Kompromiss liegt auf der Hand: In der Kryptobranche kennen fast alle Solidity, aber nur sehr wenige bereits Rust. Wer auf DuskVM aufbaut, muss also ein ganzes Ökosystem kennenlernen, statt ein bestehendes mitzubringen.
DuskEVM gibt es speziell, um diese Hürde zu beseitigen. Solidity ist mit großem Abstand die bekannteste Smart-Contract-Sprache der Branche. Dank EVM-Kompatibilität können bestehende Tools, etablierte Entwicklergewohnheiten und bereits geprüfte Vertragsmuster weitgehend unverändert übernommen werden. Der Preis dafür ist, dass du nun auf einer virtuellen Maschine arbeitest, die ursprünglich nicht für diese Chain entwickelt wurde. Außerdem liegt eine zusätzliche Schicht dazwischen – die Rollup-Struktur, die wir vor einiger Zeit behandelt haben –, zwischen deinem Vertrag und den zugrunde liegenden Abwicklungsgarantien der Basisschicht.
Bei der tatsächlichen Wahl geht es also nicht um „besser oder schlechter“, sondern darum, welche Einschränkung du in Kauf nehmen möchtest. DuskVM tauscht die Vertrautheit der Entwickler gegen eine engere native Integration. DuskEVM gibt einen Teil dieser nativen Integration zugunsten des sofortigen Zugriffs auf das gesamte bestehende Solidity-Ökosystem und all die Entwickler auf, die sich damit bereits auskennen.
Wenn also ein Projekt tatsächlich regulierte Finanzinfrastruktur auf Dusk entwickelt: Läuft diese Entscheidung meist darauf hinaus, dass die Vertrautheit der Entwickler automatisch den Ausschlag gibt? Oder gibt es bestimmte technische Anwendungsfälle, bei denen der native DuskVM-Weg eindeutig die bessere Wahl ist, auch wenn die Entwickler dafür etwas Neues lernen müssen?
$DUSK
DuskVM ist der native Weg. Rust und WASM bieten eine genauere Kontrolle auf niedrigerer Ebene, im Allgemeinen besser vorhersehbare Performance und direkten Zugriff auf alle Dusk-spezifischen Primitiven, die die Basisschicht bereitstellt, ohne dafür eine Kompatibilitätsschicht durchlaufen zu müssen. Der Kompromiss liegt auf der Hand: In der Kryptobranche kennen fast alle Solidity, aber nur sehr wenige bereits Rust. Wer auf DuskVM aufbaut, muss also ein ganzes Ökosystem kennenlernen, statt ein bestehendes mitzubringen.
DuskEVM gibt es speziell, um diese Hürde zu beseitigen. Solidity ist mit großem Abstand die bekannteste Smart-Contract-Sprache der Branche. Dank EVM-Kompatibilität können bestehende Tools, etablierte Entwicklergewohnheiten und bereits geprüfte Vertragsmuster weitgehend unverändert übernommen werden. Der Preis dafür ist, dass du nun auf einer virtuellen Maschine arbeitest, die ursprünglich nicht für diese Chain entwickelt wurde. Außerdem liegt eine zusätzliche Schicht dazwischen – die Rollup-Struktur, die wir vor einiger Zeit behandelt haben –, zwischen deinem Vertrag und den zugrunde liegenden Abwicklungsgarantien der Basisschicht.
Bei der tatsächlichen Wahl geht es also nicht um „besser oder schlechter“, sondern darum, welche Einschränkung du in Kauf nehmen möchtest. DuskVM tauscht die Vertrautheit der Entwickler gegen eine engere native Integration. DuskEVM gibt einen Teil dieser nativen Integration zugunsten des sofortigen Zugriffs auf das gesamte bestehende Solidity-Ökosystem und all die Entwickler auf, die sich damit bereits auskennen.
Wenn also ein Projekt tatsächlich regulierte Finanzinfrastruktur auf Dusk entwickelt: Läuft diese Entscheidung meist darauf hinaus, dass die Vertrautheit der Entwickler automatisch den Ausschlag gibt? Oder gibt es bestimmte technische Anwendungsfälle, bei denen der native DuskVM-Weg eindeutig die bessere Wahl ist, auch wenn die Entwickler dafür etwas Neues lernen müssen?
$DUSK