DuskEVM ist interessant, weil es EVM-Entwickler nicht dazu zwingt, bei Null anzufangen.
Wenn du bereits mit Solidity, Vyper, Foundry, Hardhat, viem oder ethers arbeitest, geht es darum, diesen vertrauten Workflow in den Dusk-Stack zu bringen.
Der Teil, der mich jedoch mehr interessiert, ist das, was darunter passiert.
DuskEVM ist die Ethereum-kompatible Ausführungsumgebung, während DuskDS Konsens, Settlement und Data Availability (Datenverfügbarkeit) übernimmt.
DUSK wird für die Ausführung genutzt und kann über die Bridge zwischen Dusk L1 und DuskEVM wechseln.
Auch der Transaktionsfluss ist erwähnenswert.
Eine Transaktion erreicht zuerst den DuskEVM-Sequencer und wird dann in einen L2-Block aufgenommen.
Der Batcher veröffentlicht die Transaktionsdaten an DuskDS, während State Commitments und Fault Proofs den daraus resultierenden Zustand mit dem DuskDS-Settlement verbinden.
Dieser letzte Teil ist wichtig, weil Transaktionsinklusion und Settlement nicht dasselbe sind.
Wenn du nur siehst, dass eine Transaktion aufgenommen wurde, heißt das nicht, dass du Finalität allein auf Basis der vergangenen Zeit annehmen solltest.
Ich finde auch gut, dass Dusk nicht jede Anwendung in dieselbe Umgebung zwängt.
Für Solidity-Anwendungen, EVM-Wallets und bestehende Ethereum-Tools ist DuskEVM der naheliegende Weg.
Für Rust/WASM-Verträge, die direkt mit Dusk L1 zusammenarbeiten müssen, bleibt DuskVM die Option.
Der interessante Punkt ist also nicht einfach „Dusk hat jetzt ein EVM“.
Vielmehr gibt Dusk Entwicklerinnen und Entwicklern eine vertraute Ausführungsumgebung und hält sie gleichzeitig mit dem eigenen Settlement- und Data-Availability-Layer verbunden.
@Dusk
#dusk
$DUSK
Wenn du bereits mit Solidity, Vyper, Foundry, Hardhat, viem oder ethers arbeitest, geht es darum, diesen vertrauten Workflow in den Dusk-Stack zu bringen.
Der Teil, der mich jedoch mehr interessiert, ist das, was darunter passiert.
DuskEVM ist die Ethereum-kompatible Ausführungsumgebung, während DuskDS Konsens, Settlement und Data Availability (Datenverfügbarkeit) übernimmt.
DUSK wird für die Ausführung genutzt und kann über die Bridge zwischen Dusk L1 und DuskEVM wechseln.
Auch der Transaktionsfluss ist erwähnenswert.
Eine Transaktion erreicht zuerst den DuskEVM-Sequencer und wird dann in einen L2-Block aufgenommen.
Der Batcher veröffentlicht die Transaktionsdaten an DuskDS, während State Commitments und Fault Proofs den daraus resultierenden Zustand mit dem DuskDS-Settlement verbinden.
Dieser letzte Teil ist wichtig, weil Transaktionsinklusion und Settlement nicht dasselbe sind.
Wenn du nur siehst, dass eine Transaktion aufgenommen wurde, heißt das nicht, dass du Finalität allein auf Basis der vergangenen Zeit annehmen solltest.
Ich finde auch gut, dass Dusk nicht jede Anwendung in dieselbe Umgebung zwängt.
Für Solidity-Anwendungen, EVM-Wallets und bestehende Ethereum-Tools ist DuskEVM der naheliegende Weg.
Für Rust/WASM-Verträge, die direkt mit Dusk L1 zusammenarbeiten müssen, bleibt DuskVM die Option.
Der interessante Punkt ist also nicht einfach „Dusk hat jetzt ein EVM“.
Vielmehr gibt Dusk Entwicklerinnen und Entwicklern eine vertraute Ausführungsumgebung und hält sie gleichzeitig mit dem eigenen Settlement- und Data-Availability-Layer verbunden.
@Dusk
#dusk
$DUSK