In den letzten beiden Tagen habe ich die Core Components von @Dusk noch einmal neu gezeichnet, damit die drei Namen DuskVM, DuskEVM und DuskDS sauber getrennt sind. Anfangs dachte ich auch, es gehe nur um „eine Kette, die zwei Arten von virtuellen Maschinen unterstützt“. In Wahrheit ist die Aufteilung aber eher wie drei Ebenen: DuskDS übernimmt Konsens, Finalität und Datenverfügbarkeit; DuskVM lässt Rust/WASM-Verträge direkt auf L1 laufen; DuskEVM ist eine EVM-äquivalente Ausführungsumgebung auf Basis von OP Stack und übergibt Abrechnung und Datenveröffentlichung an DuskDS.
Das bedeutet: Entwickler haben nicht einfach die stumpfe Wahl zwischen zwei Optionen. Wenn es schon vorhandene Solidity-Verträge gibt, und man EVM-Wallets sowie Toolchains nutzt, sind die Kosten mit DuskEVM geringer. Wenn man dagegen direkt mit L1-Assets zu tun hat, ein Phoenix-Privacy-Modell braucht, ZK-Fähigkeiten oder eine noch tiefergehende Protokollkontrolle, ist DuskVM der native Einstieg. Beide Wege teilen sich die Abrechnungs-Basis, aber das heißt nicht, dass Funktionen und Sicherheitsannahmen vollständig identisch sind.
Ich bin ziemlich skeptisch gegenüber der Aussage „EVM-kompatibel = die komplette Community/Ökologie kommt automatisch mit“. Kompatibilität senkt höchstens die Hürde bei der Bereitstellung, ersetzt aber nicht die Wallet-Anbindung, stabile RPCs, Indexer, Liquidität und echte Nutzer. Umgekehrt reicht auch das reine Betonen von nativem Rust/ZK nicht: Die Tools sind zu unhandlich, Entwickler würden nicht aus technischer Reinheit heraus komplett ihre Produkte neu schreiben.
Wenn ich also die technischen Fortschritte von $DUSK betrachte, dann würde ich die Kennzahlen auseinandernehmen: Gibt es bei DuskEVM Drittanbieter-Solidity-Apps? Gibt es bei DuskVM nicht-offizielle Verträge? Und ist der Pfad, wie beide auf DuskDS abrechnen, stabil? Falls die „Burggräben“ von #dusk wirklich tragen, sollte das heißen: „Wer mit den Tools vertraut ist, kann einsteigen; und wenn man Privatsphäre braucht, kann man immer noch nach unten gehen“, statt drei neue Namen einfach nebeneinander zu stapeln. Entscheidet ihr zuerst nach Kompatibilität – oder nach nativen Fähigkeiten?
Das bedeutet: Entwickler haben nicht einfach die stumpfe Wahl zwischen zwei Optionen. Wenn es schon vorhandene Solidity-Verträge gibt, und man EVM-Wallets sowie Toolchains nutzt, sind die Kosten mit DuskEVM geringer. Wenn man dagegen direkt mit L1-Assets zu tun hat, ein Phoenix-Privacy-Modell braucht, ZK-Fähigkeiten oder eine noch tiefergehende Protokollkontrolle, ist DuskVM der native Einstieg. Beide Wege teilen sich die Abrechnungs-Basis, aber das heißt nicht, dass Funktionen und Sicherheitsannahmen vollständig identisch sind.
Ich bin ziemlich skeptisch gegenüber der Aussage „EVM-kompatibel = die komplette Community/Ökologie kommt automatisch mit“. Kompatibilität senkt höchstens die Hürde bei der Bereitstellung, ersetzt aber nicht die Wallet-Anbindung, stabile RPCs, Indexer, Liquidität und echte Nutzer. Umgekehrt reicht auch das reine Betonen von nativem Rust/ZK nicht: Die Tools sind zu unhandlich, Entwickler würden nicht aus technischer Reinheit heraus komplett ihre Produkte neu schreiben.
Wenn ich also die technischen Fortschritte von $DUSK betrachte, dann würde ich die Kennzahlen auseinandernehmen: Gibt es bei DuskEVM Drittanbieter-Solidity-Apps? Gibt es bei DuskVM nicht-offizielle Verträge? Und ist der Pfad, wie beide auf DuskDS abrechnen, stabil? Falls die „Burggräben“ von #dusk wirklich tragen, sollte das heißen: „Wer mit den Tools vertraut ist, kann einsteigen; und wenn man Privatsphäre braucht, kann man immer noch nach unten gehen“, statt drei neue Namen einfach nebeneinander zu stapeln. Entscheidet ihr zuerst nach Kompatibilität – oder nach nativen Fähigkeiten?
