Als ich mir dieses Mal Dusk-Dokumentationen ansah, war es nicht die Privacy-Funktion, die mich wirklich zum Stillstehen brachte, sondern die Frage, warum sie nicht einfach nur EVM machen.
Jetzt behält Dusk sowohl DuskVM als auch DuskEVM bei: Erstere läuft direkt auf Dusk L1 und richtet sich an Rust/WASM-Verträge; letztere bietet wiederum Solidity, Vyper und eine vertraute EVM-Toolchain. Die offizielle Antwort für Entwickler ist eigentlich ganz eindeutig: Zwei Wege lösen nicht dasselbe Problem.
> Das sieht wie doppelte Errichtung aus, ist aber im Grunde ein Tausch von „Entwicklungsbequemlichkeit“ gegen „native Fähigkeiten“.
Aus Sicht eines normalen EVM-Developers ist DuskEVM eindeutig die bequemere Option. Wallets, Sprache und Toolchain sind vertrauter, die Migrationskosten sind niedrig und das Team muss nicht erst eine komplett neue und fremde Art des Entwickelns erlernen.
Aber wenn eine Anwendung direkt an die nativen Assets von Dusk, dessen Privacy-Fähigkeiten und Zero-Knowledge-Logik heran muss oder wenn sie näher an die L1-Ausführungsumgebung herankommen soll, dann hat DuskVM durchaus ihren Platz. Die offizielle Dokumentation ordnet diese beiden Pfade klar voneinander ab und zwingt nicht alle Anwendungen, denselben Weg zu gehen.
Und genau hier liegt das Problem.
Zwei Ausführungsumgebungen bedeuten höhere Komplexität in Entwicklung und Wartung, und Ökosystem-Tools können unmöglich vollständig vereinheitlicht werden.
Wenn man jedoch nur EVM-Kompatibilität anstrebt, könnte Dusk seine außergewöhnlichsten Fähigkeiten auch in einem allgemeinen Ausführungs-Framework „einsperren“.
Mittlerweile habe ich immer mehr den Eindruck, dass Dusk nicht wirklich auf „Ob wir mit Ethereum kompatibel sein sollten“ setzt, sondern darauf:
**Ob man Entwickler erst mit Vertrautem hereinhole, damit sie schnell loslegen können, und erst wenn echte native Fähigkeiten gebraucht werden, bereit sind, den Wegwechsel in eine andere Ausführungsumgebung in Kauf zu nehmen.**
Wenn du Entwickler bist: Würdest du die vertrautere EVM wählen, um schnell live zu gehen, oder würdest du für Privacy und native Fähigkeiten die Lernkosten einer neuen Ausführungsumgebung auf dich nehmen? @Dusk
#dusk $DUSK
Jetzt behält Dusk sowohl DuskVM als auch DuskEVM bei: Erstere läuft direkt auf Dusk L1 und richtet sich an Rust/WASM-Verträge; letztere bietet wiederum Solidity, Vyper und eine vertraute EVM-Toolchain. Die offizielle Antwort für Entwickler ist eigentlich ganz eindeutig: Zwei Wege lösen nicht dasselbe Problem.
> Das sieht wie doppelte Errichtung aus, ist aber im Grunde ein Tausch von „Entwicklungsbequemlichkeit“ gegen „native Fähigkeiten“.
Aus Sicht eines normalen EVM-Developers ist DuskEVM eindeutig die bequemere Option. Wallets, Sprache und Toolchain sind vertrauter, die Migrationskosten sind niedrig und das Team muss nicht erst eine komplett neue und fremde Art des Entwickelns erlernen.
Aber wenn eine Anwendung direkt an die nativen Assets von Dusk, dessen Privacy-Fähigkeiten und Zero-Knowledge-Logik heran muss oder wenn sie näher an die L1-Ausführungsumgebung herankommen soll, dann hat DuskVM durchaus ihren Platz. Die offizielle Dokumentation ordnet diese beiden Pfade klar voneinander ab und zwingt nicht alle Anwendungen, denselben Weg zu gehen.
Und genau hier liegt das Problem.
Zwei Ausführungsumgebungen bedeuten höhere Komplexität in Entwicklung und Wartung, und Ökosystem-Tools können unmöglich vollständig vereinheitlicht werden.
Wenn man jedoch nur EVM-Kompatibilität anstrebt, könnte Dusk seine außergewöhnlichsten Fähigkeiten auch in einem allgemeinen Ausführungs-Framework „einsperren“.
Mittlerweile habe ich immer mehr den Eindruck, dass Dusk nicht wirklich auf „Ob wir mit Ethereum kompatibel sein sollten“ setzt, sondern darauf:
**Ob man Entwickler erst mit Vertrautem hereinhole, damit sie schnell loslegen können, und erst wenn echte native Fähigkeiten gebraucht werden, bereit sind, den Wegwechsel in eine andere Ausführungsumgebung in Kauf zu nehmen.**
Wenn du Entwickler bist: Würdest du die vertrautere EVM wählen, um schnell live zu gehen, oder würdest du für Privacy und native Fähigkeiten die Lernkosten einer neuen Ausführungsumgebung auf dich nehmen? @Dusk
#dusk $DUSK