Für eine lange Zeit hielt ich EVM-Kompatibilität für weitgehend ein Marketing-Häkchen – etwas, das Chains ankreuzen, um zugänglich zu wirken, ohne dass sich darunter viel ändert. Je mehr ich mir DuskEVM jedoch ansah, desto weniger hielt diese Erklärung stand.
DuskEVM ermöglicht es Entwicklern, Solidity zu schreiben und vertraute Ethereum-Tools zu nutzen, und stellt dabei eine EVM-kompatible Ausführungsumgebung mit OP-Stack-Kompatibilität bereit. Unter dieser vertrauten Entwicklererfahrung liefert DuskDS die zugrunde liegende Settlement- bzw. Abrechnungsschicht.
Dieser Unterschied ist wichtiger, als er zunächst erscheint. Die Ausführungsumgebung fühlt sich für Ethereum-Entwickler vertraut an, aber das zugrunde liegende Settlement und die Finalität sind an die eigene Infrastruktur von Dusk gebunden – nicht an die Basisschicht von Ethereum.
Was das in der Praxis bewirkt, ist: Es senkt die Kosten, etwas Neues auszuprobieren. Ein Entwickler muss sich keine Sprache neu aneignen oder keine Infrastruktur neu aufbauen, nur um zu testen, ob Dusk’s Privacy- und Compliance-Funktionen zu seinem Use Case passen. Das verlagert den Anreiz von „überzeuge mich zum Wechsel“ hin zu „lass mich das mitbringen, was ich bereits habe, und sehen, was sich darunter verändert“.
Der Nachteil ist, dass Vertrautheit reale Unterschiede im Settlement-Verhalten verschleiern kann, wenn Menschen davon ausgehen, EVM-Kompatibilität bedeute, dass alles identisch funktioniert.
Die Frage ist also: Senkt das Senken der Wechselkosten tatsächlich die Zeit bis zur Akzeptanz, oder verschiebt es nur den Punkt nach hinten, an dem Entwickler sich mit den Unterschieden darunter auseinandersetzen müssen?
@Dusk_Foundation #dusk $DUSK
DuskEVM ermöglicht es Entwicklern, Solidity zu schreiben und vertraute Ethereum-Tools zu nutzen, und stellt dabei eine EVM-kompatible Ausführungsumgebung mit OP-Stack-Kompatibilität bereit. Unter dieser vertrauten Entwicklererfahrung liefert DuskDS die zugrunde liegende Settlement- bzw. Abrechnungsschicht.
Dieser Unterschied ist wichtiger, als er zunächst erscheint. Die Ausführungsumgebung fühlt sich für Ethereum-Entwickler vertraut an, aber das zugrunde liegende Settlement und die Finalität sind an die eigene Infrastruktur von Dusk gebunden – nicht an die Basisschicht von Ethereum.
Was das in der Praxis bewirkt, ist: Es senkt die Kosten, etwas Neues auszuprobieren. Ein Entwickler muss sich keine Sprache neu aneignen oder keine Infrastruktur neu aufbauen, nur um zu testen, ob Dusk’s Privacy- und Compliance-Funktionen zu seinem Use Case passen. Das verlagert den Anreiz von „überzeuge mich zum Wechsel“ hin zu „lass mich das mitbringen, was ich bereits habe, und sehen, was sich darunter verändert“.
Der Nachteil ist, dass Vertrautheit reale Unterschiede im Settlement-Verhalten verschleiern kann, wenn Menschen davon ausgehen, EVM-Kompatibilität bedeute, dass alles identisch funktioniert.
Die Frage ist also: Senkt das Senken der Wechselkosten tatsächlich die Zeit bis zur Akzeptanz, oder verschiebt es nur den Punkt nach hinten, an dem Entwickler sich mit den Unterschieden darunter auseinandersetzen müssen?
@Dusk_Foundation #dusk $DUSK