Ich habe mich dabei erwischt, mir DuskEVM aus einem anderen Blickwinkel anzusehen: nicht das, was Entwickler darauf aufbauen können, sondern das, was tatsächlich passiert, nachdem sie es bereitgestellt haben.
Die Architektur begann mehr Sinn zu ergeben, als ich eine Transaktion durch den Stack verfolgt habe.
Dusk trennt Ausführung von Abrechnung.
DuskEVM ist der Ort, an dem die EVM-Anwendung läuft.
DuskDS liegt darunter als Konsens-, Abrechnungs- und Data-Availability-Schicht.
Zunächst klingt das nach einem Implementierungsdetail.
Aber bei regulierten Assets bin ich mir nicht sicher, ob das nur ein Detail ist.
Eine tokenisierte Sicherheit muss mehr leisten, als nur Smart-Contract-Logik auszuführen. Irgendwann muss der Markt wissen, welcher Zustand tatsächlich finalisiert wurde und wann.
Das ließ mich die Aufteilung anders betrachten.
Die Ausführung entscheidet, was passieren soll.
Die Abrechnung bestimmt, was tatsächlich geschehen ist.
Und Dusk setzt diese Aufgaben bewusst auf unterschiedliche Ebenen.
Das Spannende ist, dass DuskEVM die Entwicklerumgebung nicht neu erfinden muss, um dorthin zu gelangen.
Solidity-Anwendungen können auf standardmäßige EVM-Tools setzen, während der daraus resultierende Zustand über DuskDS abgerechnet wird.
Damit wird die Frage weniger: „Warum ein weiteres EVM bauen?“
Stattdessen:
Warum überhaupt die Anwendungsumgebung von der Abrechnungsschicht trennen?
Bei einer normalen DeFi-Anwendung dürfte die Unterscheidung für den Nutzer kaum eine Rolle spielen.
Bei einer regulierten Sicherheit ist die Abrechnung Teil des Produkts.
Eigentum, Transfers, Zahlungen und Finalität müssen letztlich zu etwas werden, auf das sich der Markt verlassen kann.
Genau dort beginnt Dusk’s Architektur weniger wie eine EVM-Chain mit Zusatzfunktionen zu wirken und mehr wie der Versuch, zwei unterschiedliche Aufgaben zu trennen, die die Finanzinfrastruktur schon immer erfüllen musste.
Und damit bleibt mir eine einzige Frage.
Wenn die Ausführung flexibel sein kann, während die Abrechnung darunter deterministisch bleibt, könnte diese Trennung es erleichtern, verschiedene regulierte Marktanwendungen auf derselben finanziellen Basisebene zu bauen?
Denn vielleicht ist das Spannende an DuskEVM nicht, dass es vertraut aussieht.
Vielleicht ist es das, was darunter passiert, nachdem der vertraute Teil abgeschlossen ist.
#dusk $DUSK @Dusk
Die Architektur begann mehr Sinn zu ergeben, als ich eine Transaktion durch den Stack verfolgt habe.
Dusk trennt Ausführung von Abrechnung.
DuskEVM ist der Ort, an dem die EVM-Anwendung läuft.
DuskDS liegt darunter als Konsens-, Abrechnungs- und Data-Availability-Schicht.
Zunächst klingt das nach einem Implementierungsdetail.
Aber bei regulierten Assets bin ich mir nicht sicher, ob das nur ein Detail ist.
Eine tokenisierte Sicherheit muss mehr leisten, als nur Smart-Contract-Logik auszuführen. Irgendwann muss der Markt wissen, welcher Zustand tatsächlich finalisiert wurde und wann.
Das ließ mich die Aufteilung anders betrachten.
Die Ausführung entscheidet, was passieren soll.
Die Abrechnung bestimmt, was tatsächlich geschehen ist.
Und Dusk setzt diese Aufgaben bewusst auf unterschiedliche Ebenen.
Das Spannende ist, dass DuskEVM die Entwicklerumgebung nicht neu erfinden muss, um dorthin zu gelangen.
Solidity-Anwendungen können auf standardmäßige EVM-Tools setzen, während der daraus resultierende Zustand über DuskDS abgerechnet wird.
Damit wird die Frage weniger: „Warum ein weiteres EVM bauen?“
Stattdessen:
Warum überhaupt die Anwendungsumgebung von der Abrechnungsschicht trennen?
Bei einer normalen DeFi-Anwendung dürfte die Unterscheidung für den Nutzer kaum eine Rolle spielen.
Bei einer regulierten Sicherheit ist die Abrechnung Teil des Produkts.
Eigentum, Transfers, Zahlungen und Finalität müssen letztlich zu etwas werden, auf das sich der Markt verlassen kann.
Genau dort beginnt Dusk’s Architektur weniger wie eine EVM-Chain mit Zusatzfunktionen zu wirken und mehr wie der Versuch, zwei unterschiedliche Aufgaben zu trennen, die die Finanzinfrastruktur schon immer erfüllen musste.
Und damit bleibt mir eine einzige Frage.
Wenn die Ausführung flexibel sein kann, während die Abrechnung darunter deterministisch bleibt, könnte diese Trennung es erleichtern, verschiedene regulierte Marktanwendungen auf derselben finanziellen Basisebene zu bauen?
Denn vielleicht ist das Spannende an DuskEVM nicht, dass es vertraut aussieht.
Vielleicht ist es das, was darunter passiert, nachdem der vertraute Teil abgeschlossen ist.
#dusk $DUSK @Dusk