📅8.23
Zum Glück habe ich gestern $KII ausgegeben. Damals, als ich das Airdrop bekam, lag der Wert bei 45; ich habe es bis gestern Morgen durchgehalten, um um 24 dann verkauft zu haben. So konnte ich meinen Schweinebraten-Reis erhalten. Das ist ein Betrugsprojekt – und die haben noch die Dreistigkeit, an dem Wettbewerb teilzunehmen. Die Brüder, die den Wettbewerb gescaled/gespamt haben, sind wirklich übel dran.
Gestern Abend habe ich mir die Architektur-Dokumentation von @Dusk angesehen, und eine Frage ließ sich die ganze Zeit nicht aus dem Kopf bekommen: Was genau ist DuskEVM?
Die offiziellen Dokumente erklären das ganz klar: DuskEVM ist eine EVM-kompatible Ausführungs- bzw. Execution-Layer oberhalb der DuskDS-Abrechnungsschicht. Es ist keine eigenständige parallele Chain und verwaltet auch kein eigenes separates Ledger – es kümmert sich nur um die Vertragsausführung. Das wird auch durch die Analyse von HTX bestätigt: Dusk hat in der Architektur drei Ebenen – DuskDS ist für Abrechnung und Data Availability zuständig, DuskEVM ist für die Ausführung von EVM-Anwendungen verantwortlich. Die beiden Ebenen machen jeweils ihre Aufgabe, es sind nicht zwei Chains.
In der offiziellen Werbung werden DuskDS und DuskEVM jedoch oft getrennt vorgestellt, und ich habe mich anfangs auch fast so missverstanden, als wären es zwei unabhängige Chains. In Wahrheit gilt: Nachdem DuskEVM Transaktionen ausgeführt hat, veröffentlicht der Batcher die Transaktionsdaten im Blob-Format auf DuskDS. Statuszusagen und Antifraud-/Anti-Betrugsbeweise verankern dann das Ergebnis-Statusbild wieder in der Abrechnungsschicht. DuskEVM übernimmt die Ausführung, DuskDS die endgültige Bestätigung als Beleg/Proof. Beide stehen in einer Upstream/Downstream-Beziehung – nicht nebeneinander.
Aber genau diese Upstream/Downstream-Beziehung bringt ein Entwicklungs-Kostenrisiko mit sich, das in der Komplexität über dem liegt, was ich mir vorgestellt hatte. Die Gesamtkosten einer Anwendung auf DuskEVM setzen sich aus zwei Teilen zusammen: den Kosten für die EVM-Vertragsausführung plus den Kosten für die Datenverfügbarkeit der an DuskDS übermittelten Daten. Das bedeutet, wenn man Gas-Kosten einfach wie bei Ethereum anhand der üblichen Erfahrung schätzt, wird man die Kosten der darunterliegenden Schicht nicht mit einrechnen – dieser zusätzliche Aufwand ist real vorhanden.
Die Positionierung von DuskEVM ist für Solidity-Entwickler in der Tat attraktiv – bekannte Toolchains, geringe Migrationskosten. Aber wenn Entwickler nicht darauf achten, wie sich diese beiden Ebenen kostenmäßig zusammensetzen, können sie nach dem Go-Live feststellen, dass die Kosten deutlich höher ausfallen als erwartet.
#dusk $DUSK
Zum Glück habe ich gestern $KII ausgegeben. Damals, als ich das Airdrop bekam, lag der Wert bei 45; ich habe es bis gestern Morgen durchgehalten, um um 24 dann verkauft zu haben. So konnte ich meinen Schweinebraten-Reis erhalten. Das ist ein Betrugsprojekt – und die haben noch die Dreistigkeit, an dem Wettbewerb teilzunehmen. Die Brüder, die den Wettbewerb gescaled/gespamt haben, sind wirklich übel dran.
Gestern Abend habe ich mir die Architektur-Dokumentation von @Dusk angesehen, und eine Frage ließ sich die ganze Zeit nicht aus dem Kopf bekommen: Was genau ist DuskEVM?
Die offiziellen Dokumente erklären das ganz klar: DuskEVM ist eine EVM-kompatible Ausführungs- bzw. Execution-Layer oberhalb der DuskDS-Abrechnungsschicht. Es ist keine eigenständige parallele Chain und verwaltet auch kein eigenes separates Ledger – es kümmert sich nur um die Vertragsausführung. Das wird auch durch die Analyse von HTX bestätigt: Dusk hat in der Architektur drei Ebenen – DuskDS ist für Abrechnung und Data Availability zuständig, DuskEVM ist für die Ausführung von EVM-Anwendungen verantwortlich. Die beiden Ebenen machen jeweils ihre Aufgabe, es sind nicht zwei Chains.
In der offiziellen Werbung werden DuskDS und DuskEVM jedoch oft getrennt vorgestellt, und ich habe mich anfangs auch fast so missverstanden, als wären es zwei unabhängige Chains. In Wahrheit gilt: Nachdem DuskEVM Transaktionen ausgeführt hat, veröffentlicht der Batcher die Transaktionsdaten im Blob-Format auf DuskDS. Statuszusagen und Antifraud-/Anti-Betrugsbeweise verankern dann das Ergebnis-Statusbild wieder in der Abrechnungsschicht. DuskEVM übernimmt die Ausführung, DuskDS die endgültige Bestätigung als Beleg/Proof. Beide stehen in einer Upstream/Downstream-Beziehung – nicht nebeneinander.
Aber genau diese Upstream/Downstream-Beziehung bringt ein Entwicklungs-Kostenrisiko mit sich, das in der Komplexität über dem liegt, was ich mir vorgestellt hatte. Die Gesamtkosten einer Anwendung auf DuskEVM setzen sich aus zwei Teilen zusammen: den Kosten für die EVM-Vertragsausführung plus den Kosten für die Datenverfügbarkeit der an DuskDS übermittelten Daten. Das bedeutet, wenn man Gas-Kosten einfach wie bei Ethereum anhand der üblichen Erfahrung schätzt, wird man die Kosten der darunterliegenden Schicht nicht mit einrechnen – dieser zusätzliche Aufwand ist real vorhanden.
Die Positionierung von DuskEVM ist für Solidity-Entwickler in der Tat attraktiv – bekannte Toolchains, geringe Migrationskosten. Aber wenn Entwickler nicht darauf achten, wie sich diese beiden Ebenen kostenmäßig zusammensetzen, können sie nach dem Go-Live feststellen, dass die Kosten deutlich höher ausfallen als erwartet.
#dusk $DUSK
