#dusk $DUSK
Ich habe Binance geöffnet, um über @Dusk zu posten, aber der Markt hat mir stattdessen eine Comedy-Show serviert. 😂
Die gestrigen Gewinner sitzen jetzt im Tab „Verlierer“ – $APR hat eine komplette Runde gedreht, ohne die Koffer zu packen, während $COW und CYS Richtung Mond gehen. 🚀
Wie auch immer… zurück zu DuskVM, wo fehlgeschlagene Transaktionen zurückgerollt werden können – im Gegensatz zu meinen schlechten Trades. 👇
Eigentlich dachte ich, der Smart-Contract-Status auf @Dusk würde als Sammlung separater Key-Value-Einträge gespeichert.
DuskVM nimmt einen anderen Weg.
Ein nativer Dusk-Contract hält seinen Status im WASM-linearen Speicher. Wenn jemand den Contract aufruft, lädt die Laufzeit diesen persistierten Speicher, lässt den Contract sein statisches State-Objekt aktualisieren und schreibt den geänderten Speicher nur dann zurück, wenn der Aufruf erfolgreich war.
Wenn der Aufruf panikt oder fehlschlägt, kehrt der Status zu seiner vorherigen Version zurück.
Das ist sauberer, als ich erwartet hatte, weil ein teilweise abgeschlossener Update nicht zurückbleiben sollte und halbfertigen Contract-Status hinterlässt. Entwickler können den Status außerdem mit gewöhnlichen Rust-Strukturen modellieren, wie z. B. Enums, Sets und Maps, statt jeden Wert manuell als isolierten Storage-Slot zu behandeln.
Aber Rollback macht die Contract-Logik noch nicht korrekt.
Der Contract selbst bleibt dafür verantwortlich, seine Eingaben zu validieren und zu entscheiden, was als Erfolg gilt. Wenn fehlerhafte Logik eine Aktion akzeptiert und normal zurückkehrt, gibt es für die Laufzeit keinen Grund, diese Statusänderung rückgängig zu machen.
Das verschiebt die Grenze auf interessante Weise.
DuskVM kann den Status vor einer fehlgeschlagenen Ausführung schützen, aber es kann eine Anwendung nicht vor einem Fehler schützen, den ihr eigener Code als gültig betrachtet.
Bietet automatisches State-Rollback die wichtige Sicherheitsgrenze – oder liegt das eigentliche Contract-Risiko immer noch größtenteils in der Input-Validierung??
Wo sitzt die echte Sicherheit von Dusk-Contracts? 👀
#dusk
Eine Bildunterschrift für diesen
Ich habe Binance geöffnet, um über @Dusk zu posten, aber der Markt hat mir stattdessen eine Comedy-Show serviert. 😂
Die gestrigen Gewinner sitzen jetzt im Tab „Verlierer“ – $APR hat eine komplette Runde gedreht, ohne die Koffer zu packen, während $COW und CYS Richtung Mond gehen. 🚀
Wie auch immer… zurück zu DuskVM, wo fehlgeschlagene Transaktionen zurückgerollt werden können – im Gegensatz zu meinen schlechten Trades. 👇
Eigentlich dachte ich, der Smart-Contract-Status auf @Dusk würde als Sammlung separater Key-Value-Einträge gespeichert.
DuskVM nimmt einen anderen Weg.
Ein nativer Dusk-Contract hält seinen Status im WASM-linearen Speicher. Wenn jemand den Contract aufruft, lädt die Laufzeit diesen persistierten Speicher, lässt den Contract sein statisches State-Objekt aktualisieren und schreibt den geänderten Speicher nur dann zurück, wenn der Aufruf erfolgreich war.
Wenn der Aufruf panikt oder fehlschlägt, kehrt der Status zu seiner vorherigen Version zurück.
Das ist sauberer, als ich erwartet hatte, weil ein teilweise abgeschlossener Update nicht zurückbleiben sollte und halbfertigen Contract-Status hinterlässt. Entwickler können den Status außerdem mit gewöhnlichen Rust-Strukturen modellieren, wie z. B. Enums, Sets und Maps, statt jeden Wert manuell als isolierten Storage-Slot zu behandeln.
Aber Rollback macht die Contract-Logik noch nicht korrekt.
Der Contract selbst bleibt dafür verantwortlich, seine Eingaben zu validieren und zu entscheiden, was als Erfolg gilt. Wenn fehlerhafte Logik eine Aktion akzeptiert und normal zurückkehrt, gibt es für die Laufzeit keinen Grund, diese Statusänderung rückgängig zu machen.
Das verschiebt die Grenze auf interessante Weise.
DuskVM kann den Status vor einer fehlgeschlagenen Ausführung schützen, aber es kann eine Anwendung nicht vor einem Fehler schützen, den ihr eigener Code als gültig betrachtet.
Bietet automatisches State-Rollback die wichtige Sicherheitsgrenze – oder liegt das eigentliche Contract-Risiko immer noch größtenteils in der Input-Validierung??
Wo sitzt die echte Sicherheit von Dusk-Contracts? 👀
#dusk
Eine Bildunterschrift für diesen
🔘 State rollback
🔘 Input validation
🔘 Both together
🔘 Better testing
14 Stunde(n) übrig