#dusk $DUSK @Dusk Ich habe immer noch nicht ganz verstanden, welche genaue Rolle dieses „DuskEVM“ in Dusk eigentlich einnimmt. Diese Woche habe ich mir extra Zeit genommen, es mir für sich allein genauer anzusehen.
Kurz gesagt: DuskEVM ist in der Dusk-Ökologie eine eigene Schicht, die speziell dafür da ist, den Entwicklungsstil von Ethereum-Smart-Contracts zu unterstützen. Wenn man die Sprache und die Werkzeuge von Ethereum gewohnt ist, muss man nicht alles neu lernen, um eine Anwendung auf Dusk zu deployen. DuskEVM betreibt dabei aber nicht unabhängig eine komplett eigene Datenhaltung samt finaler Abrechnungslogik. Die echten Transaktionsdaten als Nachweis und die endgültige Bestätigung werden von der darunterliegenden Abrechnungsschicht von Dusk übernommen. DuskEVM ist eher wie eine darüberliegende Schicht, die sich speziell um die Ausführung von Smart Contracts kümmert.
Am Anfang bin ich davon ausgegangen, dass es sich um eine gleichrangige, eigenständige Chain handelt – also eine, die unabhängig von der unteren Abrechnungsschicht läuft, mit zwei getrennten Ledgern, die jeweils für sich arbeiten. Später habe ich die offiziellen Architektur-Erklärungen mehrmals durchgesehen und erst dann gemerkt, dass ich das falsch verstanden habe: Nachdem die Ausführungsschicht die Transaktionen verarbeitet hat, müssen die Ergebnisse letztlich dennoch gepackt und an die untere Abrechnungsschicht gesendet werden, damit dort die echten Nachweise und Bestätigungen stattfinden. Beide hängen also als Upstream/Downstream zusammen, nicht als parallele Ebenen. Auf diesem Missverständnis bin ich selbst eine Weile herumgerannt, vor allem weil in den Werbematerialien die beiden Schichten oft getrennt vorgestellt werden – was es leicht macht, den Eindruck zu erwecken, es seien zwei unabhängige, parallel laufende Chains.
Für Entwickler ist diese Ebenenbeziehung tatsächlich ziemlich wichtig: Das bedeutet, dass die tatsächlichen Betriebskosten für eine Anwendung, die du auf DuskEVM deployst, nicht nur danach beurteilt werden können, wie viele Ressourcen die Ausführung dieser Schicht selbst verbraucht. Man muss auch die Kosten für den Versand der Daten an die untere Abrechnungsschicht mit einrechnen. Erst die Addition beider Posten ergibt die vollständigen Kosten. Wenn man die Deploy-Kosten nur auf Basis der Erfahrungen von Ethereum abschätzt, vergisst man sehr leicht den Teil der unteren Schicht.
Wenn mein Verständnis dabei irgendwo abweicht, bitte gerne Bescheid geben. Ich habe diese Logik auch erst in den letzten Tagen sauber sortiert und bin nicht sicher, ob ich vielleicht Details übersehen habe.
Kurz gesagt: DuskEVM ist in der Dusk-Ökologie eine eigene Schicht, die speziell dafür da ist, den Entwicklungsstil von Ethereum-Smart-Contracts zu unterstützen. Wenn man die Sprache und die Werkzeuge von Ethereum gewohnt ist, muss man nicht alles neu lernen, um eine Anwendung auf Dusk zu deployen. DuskEVM betreibt dabei aber nicht unabhängig eine komplett eigene Datenhaltung samt finaler Abrechnungslogik. Die echten Transaktionsdaten als Nachweis und die endgültige Bestätigung werden von der darunterliegenden Abrechnungsschicht von Dusk übernommen. DuskEVM ist eher wie eine darüberliegende Schicht, die sich speziell um die Ausführung von Smart Contracts kümmert.
Am Anfang bin ich davon ausgegangen, dass es sich um eine gleichrangige, eigenständige Chain handelt – also eine, die unabhängig von der unteren Abrechnungsschicht läuft, mit zwei getrennten Ledgern, die jeweils für sich arbeiten. Später habe ich die offiziellen Architektur-Erklärungen mehrmals durchgesehen und erst dann gemerkt, dass ich das falsch verstanden habe: Nachdem die Ausführungsschicht die Transaktionen verarbeitet hat, müssen die Ergebnisse letztlich dennoch gepackt und an die untere Abrechnungsschicht gesendet werden, damit dort die echten Nachweise und Bestätigungen stattfinden. Beide hängen also als Upstream/Downstream zusammen, nicht als parallele Ebenen. Auf diesem Missverständnis bin ich selbst eine Weile herumgerannt, vor allem weil in den Werbematerialien die beiden Schichten oft getrennt vorgestellt werden – was es leicht macht, den Eindruck zu erwecken, es seien zwei unabhängige, parallel laufende Chains.
Für Entwickler ist diese Ebenenbeziehung tatsächlich ziemlich wichtig: Das bedeutet, dass die tatsächlichen Betriebskosten für eine Anwendung, die du auf DuskEVM deployst, nicht nur danach beurteilt werden können, wie viele Ressourcen die Ausführung dieser Schicht selbst verbraucht. Man muss auch die Kosten für den Versand der Daten an die untere Abrechnungsschicht mit einrechnen. Erst die Addition beider Posten ergibt die vollständigen Kosten. Wenn man die Deploy-Kosten nur auf Basis der Erfahrungen von Ethereum abschätzt, vergisst man sehr leicht den Teil der unteren Schicht.
Wenn mein Verständnis dabei irgendwo abweicht, bitte gerne Bescheid geben. Ich habe diese Logik auch erst in den letzten Tagen sauber sortiert und bin nicht sicher, ob ich vielleicht Details übersehen habe.