Ich habe mir neulich erst durch Unterlagen geknabbert und dabei gemerkt, dass da etwas nicht so ganz stimmte. Ursprünglich dachte ich, dass @Dusk _Foundation mit dem Banner „EVM-kompatibel“ vor allem die Entwickler anziehen will, die Solidity schreiben. Aber je tiefer ich grab, desto deutlicher wird: Der Schwerpunkt liegt im Hintergrund. Auf ihrer L1-Hauptkette steckt noch ein DuskVM – und der setzt auf den Weg von Rust/WASM. Dort werden speziell die zentralen Module übernommen: Zero-Knowledge-Beweise, Datenschutz/Privacy-Schutz und Protokoll-Assets. Das ist so, als würde man an der Tür ein vertrautes Schild hängen sehen, aber die eigentlichen Kernmodule, die im Verborgenen die Arbeit machen, sind in einem anderen Raum untergebracht – und der hat eine extrem hohe Eintrittsschwelle.
Das fühlt sich an wie ein Besuch im neuen Autoausstellungsraum: Die Präsentationsfläche vorne ist glänzend und einladend, jeder kann Platz nehmen und mal anfassen. Aber die Werkstatt, die wirklich über die Performance entscheidet, ist hinten. Und dort werden nicht einfach irgendwelche Standard-Tools benutzt, sondern eine andere, deutlich komplexere Montageausstattung. Nach außen wirkt alles lebendig und zugänglich – und gerade dadurch wird leicht übersehen, dass die hintere Werkstatt das ist, was am Ende bestimmt, wie schnell dieses Auto wirklich läuft.
Und dann noch $DUSK als Token: In der Mitte wirkt das Ganze ziemlich anstrengend. Ein Token muss zwei Ausführungsumgebungen bedienen: In DuskEVM fungiert er als Gas (also Ausführungsgebühren). Gleichzeitig muss er, wenn die Abwicklung wieder im DuskVM unten drunter läuft, nach dem nativen Kontenmodell abgerechnet werden. Auf dasselbe Abwicklungssubjekt sollen dann gleichzeitig zwei Syntax- und Abrechnungslogiken „gezwungen“ werden. Diese Komplexität eines „One Token, Two Rails“-Ansatzes wird in den offiziellen Materialien auch nur beiläufig in einem Satz erwähnt. $BTC
Trotzdem finde ich es ziemlich nachvollziehbar, dass sie nicht wild mit „Alles ist EVM“ um sich werfen. Wenn sie die komplexen Zero-Knowledge-Beweise und die Privacy-Transparenz im Rust/WASM-Unterbau ablegen, zeigt das: Das Team weiß offenbar, dass „es zum Laufen bringen“ und „native Effizienz“ zwei grundverschiedene Dinge sind. Diese Zurückhaltung ist tatsächlich greifbarer als bei Chains, die Kompatibilität als Allzweck-Kleber verkaufen.
Aber als jemand, der täglich auf der Chain herumstöbert und arbeitet, macht mir vor allem die Umsetzung Sorge. Die Marketing-Batterien feuern praktisch komplett auf EVM – aber die wirklich beworbenen Datenschutz- und Under-the-Hood-Assets liegen in einem Weg, den nur wenige Leute schreiben können: Rust/WASM. Wenn man Entwickler in den Low-Barrier-Front-Teil mit eher flachem Funktionsumfang führt, während man die harten, aber steilen Back-End-Komponenten versteckt, dann kommt am Ende vielleicht nur Folgendes heraus: Auf EVM stapeln sich jede Menge Toy-Demos, aber die echte Business-Logik steckt fest, weil niemand ein Wartungs-Regelwerk für die Rust-Codebasis übernimmt. $ETH
Meine Haltung ist jetzt ganz klar: Erst kühl ansehen, welche Gerichte sie wirklich auf den Tisch bringen können – und dann entscheiden, ob ich echtes Geld ausgebe. DYOR und keine Anlageberatung; den eigenen Einsatz zu schützen, ist das Wichtigste. #dusk
Das fühlt sich an wie ein Besuch im neuen Autoausstellungsraum: Die Präsentationsfläche vorne ist glänzend und einladend, jeder kann Platz nehmen und mal anfassen. Aber die Werkstatt, die wirklich über die Performance entscheidet, ist hinten. Und dort werden nicht einfach irgendwelche Standard-Tools benutzt, sondern eine andere, deutlich komplexere Montageausstattung. Nach außen wirkt alles lebendig und zugänglich – und gerade dadurch wird leicht übersehen, dass die hintere Werkstatt das ist, was am Ende bestimmt, wie schnell dieses Auto wirklich läuft.
Und dann noch $DUSK als Token: In der Mitte wirkt das Ganze ziemlich anstrengend. Ein Token muss zwei Ausführungsumgebungen bedienen: In DuskEVM fungiert er als Gas (also Ausführungsgebühren). Gleichzeitig muss er, wenn die Abwicklung wieder im DuskVM unten drunter läuft, nach dem nativen Kontenmodell abgerechnet werden. Auf dasselbe Abwicklungssubjekt sollen dann gleichzeitig zwei Syntax- und Abrechnungslogiken „gezwungen“ werden. Diese Komplexität eines „One Token, Two Rails“-Ansatzes wird in den offiziellen Materialien auch nur beiläufig in einem Satz erwähnt. $BTC
Trotzdem finde ich es ziemlich nachvollziehbar, dass sie nicht wild mit „Alles ist EVM“ um sich werfen. Wenn sie die komplexen Zero-Knowledge-Beweise und die Privacy-Transparenz im Rust/WASM-Unterbau ablegen, zeigt das: Das Team weiß offenbar, dass „es zum Laufen bringen“ und „native Effizienz“ zwei grundverschiedene Dinge sind. Diese Zurückhaltung ist tatsächlich greifbarer als bei Chains, die Kompatibilität als Allzweck-Kleber verkaufen.
Aber als jemand, der täglich auf der Chain herumstöbert und arbeitet, macht mir vor allem die Umsetzung Sorge. Die Marketing-Batterien feuern praktisch komplett auf EVM – aber die wirklich beworbenen Datenschutz- und Under-the-Hood-Assets liegen in einem Weg, den nur wenige Leute schreiben können: Rust/WASM. Wenn man Entwickler in den Low-Barrier-Front-Teil mit eher flachem Funktionsumfang führt, während man die harten, aber steilen Back-End-Komponenten versteckt, dann kommt am Ende vielleicht nur Folgendes heraus: Auf EVM stapeln sich jede Menge Toy-Demos, aber die echte Business-Logik steckt fest, weil niemand ein Wartungs-Regelwerk für die Rust-Codebasis übernimmt. $ETH
Meine Haltung ist jetzt ganz klar: Erst kühl ansehen, welche Gerichte sie wirklich auf den Tisch bringen können – und dann entscheiden, ob ich echtes Geld ausgebe. DYOR und keine Anlageberatung; den eigenen Einsatz zu schützen, ist das Wichtigste. #dusk