Der gesamte Stack @Dusk hat eigentlich zwei zusammenhängende, aber unterschiedliche Bücher: eines ist das Ausführungsbuch von DuskEVM, nach außen als Ethereum-JSON-RPC dargestellt; das andere ist das Abrechnungsbuch von Dusk L1, nach außen als GraphQL / RUES. DUSK muss in beiden Büchern als dieselbe Zahl gelesen werden, doch Takt, Einheiten und Dezimalstellen unterscheiden sich.
DuskEVM ist eine EVM-Ausführungsschicht im OP-Stack-Stil. Sie liefert Blöcke, Logs und Receipts im Standard-EVM-Format; die finale Abrechnung sowie Datenverfügbarkeit werden anschließend über Batcher, Statuszusagen und Bridge-Anker in DuskDS verankert. Das heißt: Es ist kein „Adapter, der GraphQL in Echtzeit in JSON-RPC übersetzt“, sondern zwei Ebenen, die durch Bridge und Statuszusagen final konsistent gehalten werden. Was wirklich zu beachten ist, sind Cross-Layer-Szenarien: Auf DuskEVM ist inclusion schnell, aber die vollständige Abrechnung und die Bestätigung der Bridge brauchen noch ein paar Schritte – in dieser Zeit können die Zustände, die beide Seiten sehen, vorübergehend voneinander abweichen.
$DUSK macht dieses Risiko noch konkreter. Auf der nativen L1-Seite wird es über LUX dargestellt; 1 DUSK entspricht 10^9 LUX. DuskEVM legt DUSK mit 18 Dezimalstellen offen, um die Ethereum-Toolchain kompatibel zu halten. Wenn bei der Bridge-Übertragung Umrechnung oder Präzisionsbehandlung nicht korrekt ist, kann derselbe Wert kurzzeitig in beiden Büchern nicht zueinander passen. Bei einer normalen Überweisung ist das vielleicht nur ein Darstellungsfehler, bei einer regulierten Abrechnung kann daraus jedoch ein Bedienfenster werden, in dem „auf der einen Seite als angekommen angezeigt, auf der anderen Seite noch nicht final bestätigt“ ist – also eine potenziell falsche Interaktion.
Meine Einschätzung nach dem Lesen ist: Bei der Bewertung #dusk darf man nicht nur darauf schauen, dass es „mit EVM kompatibel“ ist; man muss auch die Garantien für die Konsistenz zwischen dem L1-Abrechnungsbuch und dem EVM-Ausführungsbuch prüfen. Die Unterlagen beschreiben derzeit nicht hinreichend die Priorität von maßgeblichen Datenquellen, die Mechanismen zur Konflikterkennung und -behebung. Und genau DUSK ist die Zahl, die in diesen beiden Büchern am wenigsten falsch gelesen werden darf. DYOR.
DuskEVM ist eine EVM-Ausführungsschicht im OP-Stack-Stil. Sie liefert Blöcke, Logs und Receipts im Standard-EVM-Format; die finale Abrechnung sowie Datenverfügbarkeit werden anschließend über Batcher, Statuszusagen und Bridge-Anker in DuskDS verankert. Das heißt: Es ist kein „Adapter, der GraphQL in Echtzeit in JSON-RPC übersetzt“, sondern zwei Ebenen, die durch Bridge und Statuszusagen final konsistent gehalten werden. Was wirklich zu beachten ist, sind Cross-Layer-Szenarien: Auf DuskEVM ist inclusion schnell, aber die vollständige Abrechnung und die Bestätigung der Bridge brauchen noch ein paar Schritte – in dieser Zeit können die Zustände, die beide Seiten sehen, vorübergehend voneinander abweichen.
$DUSK macht dieses Risiko noch konkreter. Auf der nativen L1-Seite wird es über LUX dargestellt; 1 DUSK entspricht 10^9 LUX. DuskEVM legt DUSK mit 18 Dezimalstellen offen, um die Ethereum-Toolchain kompatibel zu halten. Wenn bei der Bridge-Übertragung Umrechnung oder Präzisionsbehandlung nicht korrekt ist, kann derselbe Wert kurzzeitig in beiden Büchern nicht zueinander passen. Bei einer normalen Überweisung ist das vielleicht nur ein Darstellungsfehler, bei einer regulierten Abrechnung kann daraus jedoch ein Bedienfenster werden, in dem „auf der einen Seite als angekommen angezeigt, auf der anderen Seite noch nicht final bestätigt“ ist – also eine potenziell falsche Interaktion.
Meine Einschätzung nach dem Lesen ist: Bei der Bewertung #dusk darf man nicht nur darauf schauen, dass es „mit EVM kompatibel“ ist; man muss auch die Garantien für die Konsistenz zwischen dem L1-Abrechnungsbuch und dem EVM-Ausführungsbuch prüfen. Die Unterlagen beschreiben derzeit nicht hinreichend die Priorität von maßgeblichen Datenquellen, die Mechanismen zur Konflikterkennung und -behebung. Und genau DUSK ist die Zahl, die in diesen beiden Büchern am wenigsten falsch gelesen werden darf. DYOR.
