DuskEVM: Die Plattform, die meine Sicht auf „EVM-Kompatibilität“ verändert hat
Früher dachte ich jedes Mal, wenn ich eine Chain sah, die sagte „wir haben ein EVM“, oft: Schon wieder ein EVM-Fork, wieder muss ich einen Haufen Neues lernen.
Aber als ich DuskEVM selbst neben den OP-Stack-Workflow stellte, den ich gewohnt bin, merkte ich: Die Geschichte ist eine völlig andere.
Hardhat bleibt gleich.
Foundry bleibt gleich.
JSON-RPC bleibt gleich.
Blockscout bleibt gleich.
Sogar DuskEVM nutzt OP Stack / op-geth, daher fühlt sich die Bereitstellung nahezu so an, als gäbe es keine nennenswerte „Lernkurve“.
Doch der Punkt, der meine Aufmerksamkeit wirklich weckt, liegt unterhalb der EVM-Schicht.
DuskEVM ist nicht einfach nur das Hochheben einer EVM-Umgebung auf eine andere Chain. Transaction-Daten werden in DuskDS gegeben – die Settlement- & Data-Availability-Schicht von Dusk – statt sich wie im OP-Mainnet/Base-Modell auf Ethereum L1 zu stützen.
Und von hier aus ist es nicht Solidity oder Entwickler-Tools, die sich verändern.
Was sich verändert, ist, wo die Anwendung gesettled wird.
@Dusk mang bringt in ihr System das ein, was sie über viele Jahre aufgebaut haben: deterministisches Settlement, Zedger und die damit verbundenen Komponenten rund um Compliance/Institutional Infrastructure.
Deshalb beginne ich, DuskEVM nicht als „eine weitere EVM-Chain“ zu sehen, sondern als einen Weg, bestehende EVM-Applications in eine Infrastruktur zu bringen, die für regulierte Finanzen ausgelegt ist.
Die interessanteste Frage ist jetzt nicht mehr:
„Müssen Developer einen neuen Stack lernen?“
Sondern:
Wenn die technische Reibung nahezu bei null liegt, was wird dann dazu führen, dass Developer DuskEVM statt Base oder OP Mainnet wählen?
Das Ökosystem?
Die institutionelle Übernahme?
Compliance?
Oder die Economics von Gas und Settlement?
Das ist der Teil, den ich in der Story #dusk . $DUSK
Früher dachte ich jedes Mal, wenn ich eine Chain sah, die sagte „wir haben ein EVM“, oft: Schon wieder ein EVM-Fork, wieder muss ich einen Haufen Neues lernen.
Aber als ich DuskEVM selbst neben den OP-Stack-Workflow stellte, den ich gewohnt bin, merkte ich: Die Geschichte ist eine völlig andere.
Hardhat bleibt gleich.
Foundry bleibt gleich.
JSON-RPC bleibt gleich.
Blockscout bleibt gleich.
Sogar DuskEVM nutzt OP Stack / op-geth, daher fühlt sich die Bereitstellung nahezu so an, als gäbe es keine nennenswerte „Lernkurve“.
Doch der Punkt, der meine Aufmerksamkeit wirklich weckt, liegt unterhalb der EVM-Schicht.
DuskEVM ist nicht einfach nur das Hochheben einer EVM-Umgebung auf eine andere Chain. Transaction-Daten werden in DuskDS gegeben – die Settlement- & Data-Availability-Schicht von Dusk – statt sich wie im OP-Mainnet/Base-Modell auf Ethereum L1 zu stützen.
Und von hier aus ist es nicht Solidity oder Entwickler-Tools, die sich verändern.
Was sich verändert, ist, wo die Anwendung gesettled wird.
@Dusk mang bringt in ihr System das ein, was sie über viele Jahre aufgebaut haben: deterministisches Settlement, Zedger und die damit verbundenen Komponenten rund um Compliance/Institutional Infrastructure.
Deshalb beginne ich, DuskEVM nicht als „eine weitere EVM-Chain“ zu sehen, sondern als einen Weg, bestehende EVM-Applications in eine Infrastruktur zu bringen, die für regulierte Finanzen ausgelegt ist.
Die interessanteste Frage ist jetzt nicht mehr:
„Müssen Developer einen neuen Stack lernen?“
Sondern:
Wenn die technische Reibung nahezu bei null liegt, was wird dann dazu führen, dass Developer DuskEVM statt Base oder OP Mainnet wählen?
Das Ökosystem?
Die institutionelle Übernahme?
Compliance?
Oder die Economics von Gas und Settlement?
Das ist der Teil, den ich in der Story #dusk . $DUSK
