Als ich gestern Abend die Dusk-Dokumente durchgesehen habe, habe ich erst gemerkt, dass ich „EVM unterstützen“ viel zu selbstverständlich verstanden habe. Dusk packt die Verträge nicht einfach komplett in eine einzige virtuelle Maschine: Vertraute Anwendungen aus der Welt von Solidity und Foundry können über DuskEVM laufen, zahlen Gas mit DUSK und übergeben Batch-Daten sowie Zustandszusicherungen zur Abrechnung an DuskDS; wenn man native Privatsphäre und Zero-Knowledge-Fähigkeiten braucht oder Smart Contracts mit protokollweitem Asset-Handling, dann laufen solche Verträge direkt auf DuskVM – mit Rust/WASM.
Ich habe es so verstanden, als gäbe es zwei Bedienpulte aus derselben Transaktionsorganisation. Eines lässt die gewohnten Buttons unverändert – damit geht die Migration schneller; das andere ist näher an den zugrunde liegenden Tresoren, kann nativer mit den Regeln interagieren und schlussendlich wird trotzdem auf derselben Clearing-Base die Buchführung bestätigt. Diese Abwägung ist wichtiger als die vier Worte „kompatibel mit EVM“, denn sie trennt Entwicklungs-Workflow von nativen Fähigkeiten.
Doch zwei Wege bedeuten auch mehr Komplexität durch Brücken und Interaktionen über Ebenen hinweg, außerdem muss der Zustand exakt beurteilt werden. Die offiziellen Dokumente weisen klar darauf hin: Das schnelle Packen in DuskEVM bedeutet nicht, dass der Abschluss bereits in DuskDS erfolgt ist. Ich werde nicht nur darauf schauen, ob die Seite „Erfolgreich“ anzeigt, und das dann als endgültig abgeschlossen ansehen. Später muss man prüfen, ob die Experience über Ebenen hinweg wirklich reibungslos ist, ob die Tools ausgereift sind und ob die Menge echter Verträge wächst. Die Architektur gibt die Wahl – erst die Umsetzung gibt die Antwort.
@Dusk $DUSK #dusk
Ich habe es so verstanden, als gäbe es zwei Bedienpulte aus derselben Transaktionsorganisation. Eines lässt die gewohnten Buttons unverändert – damit geht die Migration schneller; das andere ist näher an den zugrunde liegenden Tresoren, kann nativer mit den Regeln interagieren und schlussendlich wird trotzdem auf derselben Clearing-Base die Buchführung bestätigt. Diese Abwägung ist wichtiger als die vier Worte „kompatibel mit EVM“, denn sie trennt Entwicklungs-Workflow von nativen Fähigkeiten.
Doch zwei Wege bedeuten auch mehr Komplexität durch Brücken und Interaktionen über Ebenen hinweg, außerdem muss der Zustand exakt beurteilt werden. Die offiziellen Dokumente weisen klar darauf hin: Das schnelle Packen in DuskEVM bedeutet nicht, dass der Abschluss bereits in DuskDS erfolgt ist. Ich werde nicht nur darauf schauen, ob die Seite „Erfolgreich“ anzeigt, und das dann als endgültig abgeschlossen ansehen. Später muss man prüfen, ob die Experience über Ebenen hinweg wirklich reibungslos ist, ob die Tools ausgereift sind und ob die Menge echter Verträge wächst. Die Architektur gibt die Wahl – erst die Umsetzung gibt die Antwort.
@Dusk $DUSK #dusk