#dusk $DUSK
Ich habe in den letzten beiden Tagen die Architektur-Dokumentation von @Dusk noch einmal durchgelesen, und dabei ist mir ein Problem aufgefallen, bei dem ich es vorher eigentlich zu simpel gesehen habe.
Am Ende kehrt DuskEVM also auch zum DuskDS settlement zurück—warum behält man dann noch DuskVM separat?
Zuerst dachte ich, der Unterschied läge nur in der Programmiersprache: einmal Solidity und einmal Rust/WASM.
Aber wenn man weiterliest, zeigt sich, dass der Unterschied eigentlich im Ausführungspfad liegt.
DuskVM läuft direkt auf L1.
DuskEVM läuft nicht so. Die Transaktion geht zuerst zum Sequencer, dann wird sie auf der EVM-Ebene ausgeführt. Danach folgen Batch und State Commitment, und erst danach wird es wieder an DuskDS angebunden.
Selbst wenn es am Ende auf dieselbe Settlement-Ebene hinausläuft, sind die dazwischenliegenden Schritte also völlig unterschiedlich.
Ich finde, dieser Unterschied ist ziemlich wichtig.
Wenn es bereits ein Solidity-Produkt gibt und man nur wenig Code umstellen möchte, dann ist DuskEVM sehr sinnvoll. Tools und Entwicklungsgewohnheiten sind im Grunde bereits vertraut.
Aber wenn die Anwendung selbst ohnehin direkt mit L1 zu tun haben muss oder wenn man die Dusk-eigenen Ausführungsfähigkeiten bzw. Logik auf Protokoll-Ebene nutzen will, dann ist es vielleicht nicht unbedingt nötig, diese zusätzliche EVM-Ebene hart zu umgehen.
Darum mache ich mir mittlerweile auch nicht mehr so viele Gedanken darüber, wer von DuskEVM und DuskVM „höher“ ist.
Es sind eher zwei Wege.
Der eine macht es für bestehende EVM-Entwickler leichter, einzusteigen.
Der andere ist für diejenigen, die von Anfang an Dusk-native Fähigkeiten direkt nutzen wollten.
Beide können am Ende an DuskDS andocken, aber der Execution Path ist nicht derselbe.
Das ist auch der Punkt, weshalb ich finde, dass sich diese Dusk-Architektur eher zu untersuchen lohnt als „noch eine L1, die kompatibel mit EVM ist“.
Ich habe in den letzten beiden Tagen die Architektur-Dokumentation von @Dusk noch einmal durchgelesen, und dabei ist mir ein Problem aufgefallen, bei dem ich es vorher eigentlich zu simpel gesehen habe.
Am Ende kehrt DuskEVM also auch zum DuskDS settlement zurück—warum behält man dann noch DuskVM separat?
Zuerst dachte ich, der Unterschied läge nur in der Programmiersprache: einmal Solidity und einmal Rust/WASM.
Aber wenn man weiterliest, zeigt sich, dass der Unterschied eigentlich im Ausführungspfad liegt.
DuskVM läuft direkt auf L1.
DuskEVM läuft nicht so. Die Transaktion geht zuerst zum Sequencer, dann wird sie auf der EVM-Ebene ausgeführt. Danach folgen Batch und State Commitment, und erst danach wird es wieder an DuskDS angebunden.
Selbst wenn es am Ende auf dieselbe Settlement-Ebene hinausläuft, sind die dazwischenliegenden Schritte also völlig unterschiedlich.
Ich finde, dieser Unterschied ist ziemlich wichtig.
Wenn es bereits ein Solidity-Produkt gibt und man nur wenig Code umstellen möchte, dann ist DuskEVM sehr sinnvoll. Tools und Entwicklungsgewohnheiten sind im Grunde bereits vertraut.
Aber wenn die Anwendung selbst ohnehin direkt mit L1 zu tun haben muss oder wenn man die Dusk-eigenen Ausführungsfähigkeiten bzw. Logik auf Protokoll-Ebene nutzen will, dann ist es vielleicht nicht unbedingt nötig, diese zusätzliche EVM-Ebene hart zu umgehen.
Darum mache ich mir mittlerweile auch nicht mehr so viele Gedanken darüber, wer von DuskEVM und DuskVM „höher“ ist.
Es sind eher zwei Wege.
Der eine macht es für bestehende EVM-Entwickler leichter, einzusteigen.
Der andere ist für diejenigen, die von Anfang an Dusk-native Fähigkeiten direkt nutzen wollten.
Beide können am Ende an DuskDS andocken, aber der Execution Path ist nicht derselbe.
Das ist auch der Punkt, weshalb ich finde, dass sich diese Dusk-Architektur eher zu untersuchen lohnt als „noch eine L1, die kompatibel mit EVM ist“.