DuskVM ist wahrscheinlich wichtiger, als es auf den ersten Blick wirkt.
Ich habe mich in Dusk’s Ausführungsebene vertieft, und eine Sache ist mir besonders aufgefallen:
Dusk zwingt nicht jeden Entwickler in die EVM.
DuskVM führt Rust/WASM Smart Contracts direkt auf der Dusk L1 aus, während DuskEVM Entwicklern den SolidityEVM-Weg eröffnet. Diese Trennung ist interessant, weil die beiden Umgebungen unterschiedliche Probleme lösen.
Am 10. August ging dann das DuskEVM-Testnetz live und öffnete die EVM-kompatible Seite für Solidity- und Hardhat-basiertes Testing.
Was ich hier besonders spannend finde, ist die Architektur:
DuskVM → direkte L1-Ausführung
Rust/WASM → Protokoll-Ebene und spezialisierte Contracts
Privacy/ZK-Zugriff → näher an der Basisschicht
DuskEVM → vertrautes Ethereum-Tooling
$DUSK → natives Gas- und Staking-Asset
Meine erste Reaktion war tatsächlich: Warum zwei Ausführungspfade bauen?
Die Antwort scheint eher Flexibilität zu sein als Kompatibilität um ihrer selbst willen.
Aber ein Testnet-Launch allein sagt uns noch nicht, ob Entwickler beide Umgebungen tatsächlich in großem Maßstab nutzen werden. Das ist der Teil, den ich jetzt beobachte.
Werden echte Entwickler DuskVM wählen, wenn die direkte L1-Ausführung entscheidend ist, oder wird sich die meiste Aktivität irgendwann doch in Richtung DuskEVM verlagern?
@Dusk_Foundation $DUSK #dusk
Ich habe mich in Dusk’s Ausführungsebene vertieft, und eine Sache ist mir besonders aufgefallen:
Dusk zwingt nicht jeden Entwickler in die EVM.
DuskVM führt Rust/WASM Smart Contracts direkt auf der Dusk L1 aus, während DuskEVM Entwicklern den SolidityEVM-Weg eröffnet. Diese Trennung ist interessant, weil die beiden Umgebungen unterschiedliche Probleme lösen.
Am 10. August ging dann das DuskEVM-Testnetz live und öffnete die EVM-kompatible Seite für Solidity- und Hardhat-basiertes Testing.
Was ich hier besonders spannend finde, ist die Architektur:
DuskVM → direkte L1-Ausführung
Rust/WASM → Protokoll-Ebene und spezialisierte Contracts
Privacy/ZK-Zugriff → näher an der Basisschicht
DuskEVM → vertrautes Ethereum-Tooling
$DUSK → natives Gas- und Staking-Asset
Meine erste Reaktion war tatsächlich: Warum zwei Ausführungspfade bauen?
Die Antwort scheint eher Flexibilität zu sein als Kompatibilität um ihrer selbst willen.
Aber ein Testnet-Launch allein sagt uns noch nicht, ob Entwickler beide Umgebungen tatsächlich in großem Maßstab nutzen werden. Das ist der Teil, den ich jetzt beobachte.
Werden echte Entwickler DuskVM wählen, wenn die direkte L1-Ausführung entscheidend ist, oder wird sich die meiste Aktivität irgendwann doch in Richtung DuskEVM verlagern?
@Dusk_Foundation $DUSK #dusk