Der Teil von DuskEVM, den ich nicht erwartet hatte, ist nicht die Solidity-Unterstützung — sondern was passiert, wenn DUSK zurück in die native Layer wechselt.
Der eigene Testnet-Guide von Dusk sagt, dass ein Withdrawal aus DuskEVM drei separate On-Chain-Aktionen erfordert: erstens auf DuskEVM initiieren, zweitens auf Dusk L1 beweisen, und dann drittens auf Dusk L1 finalisieren. Außerdem muss der Nutzer genug ungeschirmtes DUSK auf L1 haben, um sowohl die Proof- als auch die Finalisierungs-Transaktionen zu bezahlen. Die Withdrawal-Bereitschaft hängt von veröffentlichtem Netzwerkstatus, Proof-Reife und Dispute-Game-Prüfungen ab — nicht von einem einfachen Timer.
Das hat mich zweimal hinsehen lassen, weil „EVM-Kompatibilität“ so klingen kann, als würde das gesamte Erlebnis standardmäßig vertraut werden. In der Praxis legt die Bridge die tiefere Architektur offen: DuskEVM ist eine EVM-Ausführungsumgebung, die Daten über DuskDS absetzt und veröffentlicht — nicht dieselbe Ausführungsschicht wie die nativen Rust/WASM-Contracts von Dusk.
Ich lese die zusätzlichen Schritte nicht automatisch als etwas Schlechtes. Die Doku verknüpft die Bereitschaft mit Proof-Reife und Dispute-Game-Checks, sodass die Reibung zumindest mit dem Sicherheitsmodell zusammenhängt. Aber das wirft für $DUSK eine echte Produktfrage auf: Können Production-Apps diesen Proving-/Finalization-Flow so gut abstrahieren, dass Nutzer die Sicherheitsvorteile erhalten, ohne die Komplexität zwischen den Layern zu spüren?
Das scheint wichtiger zu beobachten als eine weitere Deployment-Demo.
@Dusk_Foundation $DUSK #dusk
Der eigene Testnet-Guide von Dusk sagt, dass ein Withdrawal aus DuskEVM drei separate On-Chain-Aktionen erfordert: erstens auf DuskEVM initiieren, zweitens auf Dusk L1 beweisen, und dann drittens auf Dusk L1 finalisieren. Außerdem muss der Nutzer genug ungeschirmtes DUSK auf L1 haben, um sowohl die Proof- als auch die Finalisierungs-Transaktionen zu bezahlen. Die Withdrawal-Bereitschaft hängt von veröffentlichtem Netzwerkstatus, Proof-Reife und Dispute-Game-Prüfungen ab — nicht von einem einfachen Timer.
Das hat mich zweimal hinsehen lassen, weil „EVM-Kompatibilität“ so klingen kann, als würde das gesamte Erlebnis standardmäßig vertraut werden. In der Praxis legt die Bridge die tiefere Architektur offen: DuskEVM ist eine EVM-Ausführungsumgebung, die Daten über DuskDS absetzt und veröffentlicht — nicht dieselbe Ausführungsschicht wie die nativen Rust/WASM-Contracts von Dusk.
Ich lese die zusätzlichen Schritte nicht automatisch als etwas Schlechtes. Die Doku verknüpft die Bereitschaft mit Proof-Reife und Dispute-Game-Checks, sodass die Reibung zumindest mit dem Sicherheitsmodell zusammenhängt. Aber das wirft für $DUSK eine echte Produktfrage auf: Können Production-Apps diesen Proving-/Finalization-Flow so gut abstrahieren, dass Nutzer die Sicherheitsvorteile erhalten, ohne die Komplexität zwischen den Layern zu spüren?
Das scheint wichtiger zu beobachten als eine weitere Deployment-Demo.
@Dusk_Foundation $DUSK #dusk