#dusk $DUSK
Ich habe in den letzten zwei Tagen DuskEVM-Dokumente von @Dusk durchgesehen und habe dabei einen Detailpunkt übersehen:
Wenn eine Transaktion in DuskEVM gepackt wird, heißt das nicht, dass diese Transaktion bereits vollständig abgeschlossen ist.
In dieser aktuellen Architektur macht DuskEVM nicht dasselbe wie DuskDS.
Zuerst wird ein Solidity-Vertrag in DuskEVM ausgeführt. Die Transaktion gelangt dann in den Sequencer und wird in einen L2-Block aufgenommen. Danach muss der Batcher die Transaktionsdaten noch an DuskDS übermitteln; der Status wird über Mechanismen wie Commitments und Fraud-/Fault-Proofs weiter bestätigt.
Schließlich ist DuskDS für Settlement und Data Availability zuständig.
Darum verstehe ich DuskEVM jetzt eher so, dass es nicht einfach nur „Dusk hat zusätzlich eine EVM“ ist.
Genauer gesagt:
DuskEVM führt aus, DuskDS entscheidet am Ende, ob es „zählt“.
Das erklärt auch, warum die offiziellen Dokumente Transaktions-Inclusion und Settlement so ausdrücklich voneinander unterscheiden.
Diese Designidee lässt sich sogar im aktuellen Testnet-Withdrawal-Prozess erkennen: Zuerst in DuskEVM initiieren, dann zu Dusk L1 beweisen, schließlich finalisieren. Dass auf der L2-Seite „Erfolg“ angezeigt wird, bedeutet noch nicht, dass damit alles endgültig beendet ist.
Der Unterschied ist für normale Überweisungen vielleicht nicht ganz so spannend, aber in einem Finanz-Szenario halte ich ihn für besonders wichtig.
Wenn Wertpapiere, Fonds usw. wirklich on-chain gehen, interessiert die Leute am Ende nicht nur, ob „die Transaktion schnell genug ist“, sondern vor allem ein ganz praktisches Problem:
In welcher Schicht wird dieser Status zur finalen Endgültigkeit?
Darum schaue ich mir als Nächstes DuskEVM Mainnet an: Neben Performance und Solidity-Kompatibilität möchte ich vor allem sehen, wie diese End-to-End-Kette von Execution bis DuskDS-Settlement in der Praxis läuft.
Zumindest die Aufgabentrennung auf Architektur-Ebene habe ich jetzt verstanden.
Ich habe in den letzten zwei Tagen DuskEVM-Dokumente von @Dusk durchgesehen und habe dabei einen Detailpunkt übersehen:
Wenn eine Transaktion in DuskEVM gepackt wird, heißt das nicht, dass diese Transaktion bereits vollständig abgeschlossen ist.
In dieser aktuellen Architektur macht DuskEVM nicht dasselbe wie DuskDS.
Zuerst wird ein Solidity-Vertrag in DuskEVM ausgeführt. Die Transaktion gelangt dann in den Sequencer und wird in einen L2-Block aufgenommen. Danach muss der Batcher die Transaktionsdaten noch an DuskDS übermitteln; der Status wird über Mechanismen wie Commitments und Fraud-/Fault-Proofs weiter bestätigt.
Schließlich ist DuskDS für Settlement und Data Availability zuständig.
Darum verstehe ich DuskEVM jetzt eher so, dass es nicht einfach nur „Dusk hat zusätzlich eine EVM“ ist.
Genauer gesagt:
DuskEVM führt aus, DuskDS entscheidet am Ende, ob es „zählt“.
Das erklärt auch, warum die offiziellen Dokumente Transaktions-Inclusion und Settlement so ausdrücklich voneinander unterscheiden.
Diese Designidee lässt sich sogar im aktuellen Testnet-Withdrawal-Prozess erkennen: Zuerst in DuskEVM initiieren, dann zu Dusk L1 beweisen, schließlich finalisieren. Dass auf der L2-Seite „Erfolg“ angezeigt wird, bedeutet noch nicht, dass damit alles endgültig beendet ist.
Der Unterschied ist für normale Überweisungen vielleicht nicht ganz so spannend, aber in einem Finanz-Szenario halte ich ihn für besonders wichtig.
Wenn Wertpapiere, Fonds usw. wirklich on-chain gehen, interessiert die Leute am Ende nicht nur, ob „die Transaktion schnell genug ist“, sondern vor allem ein ganz praktisches Problem:
In welcher Schicht wird dieser Status zur finalen Endgültigkeit?
Darum schaue ich mir als Nächstes DuskEVM Mainnet an: Neben Performance und Solidity-Kompatibilität möchte ich vor allem sehen, wie diese End-to-End-Kette von Execution bis DuskDS-Settlement in der Praxis läuft.
Zumindest die Aufgabentrennung auf Architektur-Ebene habe ich jetzt verstanden.