EIN FEHLGESCHLAGENES DUSK-VERTRAGSAUFRUF KANN TROTZDEM DEN NONCE — ODER DIE NOTES — VERBRAUCHEN.
Das ist eine der seltsameren Details, die ich im Transaktions-Lebenszyklus von @Dusk gefunden habe.
Wenn ein Vertragsaufruf fehlschlägt, schreibt DuskVM die fehlgeschlagenen Zustandsänderungen des Vertrags nicht fest.
Dieser Teil wirkt intuitiv.
Fehlgeschlagene Ausführung → der Zustand wird zurückgerollt.
Aber die Transaktion selbst rollt nicht auf die gleiche Weise zurück.
Dusk-Dokumentation sagt, dass eine ausgeführte Transaktion mit einem nicht-null Fehler einen Contract Panic oder ein anderes Ausführungsversagen darstellen kann.
Und egal ob die Ausführung gelingt oder fehlschlägt:
der Moonlight-Nonce oder die Phoenix-Notes werden verbraucht,
und das Gas wird weiterhin bezahlt.
Das schafft eine deutlich schärfere Unterscheidung als nur zu sagen „die Transaktion ist fehlgeschlagen“:
contract-state rollback ≠ transaction-layer rollback.
Für Entwickler eines Wallets oder einer dApp ist das wichtig.
Stell dir vor, die UI zeigt:
FEHLGESCHLAGEN.
Ein Nutzer könnte das natürlich so lesen:
nichts ist passiert, versuche es nochmal.
Aber das ist nicht mehr der vollständige Protokollzustand.
Die beabsichtigte Vertragsänderung ist möglicherweise nicht passiert, während die Gebühr ausgegeben wurde und der Spend-Input der Transaktion bereits weitergeschaltet wurde.
Ein naives erneutes Ausprobieren kann also nicht einfach davon ausgehen, dass die alte Nonce oder die alten Notes noch verfügbar sind.
Das ist der Fehlerpfad, den ich verhindern wollen würde, dass ein Dusk-Wallet ihn ermöglicht.
Nach einem fehlgeschlagenen Call zuerst den Spend-State aktualisieren.
Dann dem Nutzer ganz genau sagen, was fehlgeschlagen ist und was noch verbraucht wurde.
Die Metrik, die ich im Blick behalten würde, ist sehr eng:
Wie oft können Wallets sich von fehlgeschlagener Ausführung erholen, ohne falsche Annahmen über stale Nonce/Note, kaputte Retries oder die Annahme der Nutzer, sie hätten für „nichts“ bezahlt?
Ich mag dieses Designdetail, weil es zwei unterschiedliche Bedeutungen von Rollback sichtbar macht.
Die Anwendung kann zurückgehen.
Die Transaktion kann nicht so tun, als wäre sie nie passiert.
#dusk $DUSK @Dusk
$BTW $HEMI
Das ist eine der seltsameren Details, die ich im Transaktions-Lebenszyklus von @Dusk gefunden habe.
Wenn ein Vertragsaufruf fehlschlägt, schreibt DuskVM die fehlgeschlagenen Zustandsänderungen des Vertrags nicht fest.
Dieser Teil wirkt intuitiv.
Fehlgeschlagene Ausführung → der Zustand wird zurückgerollt.
Aber die Transaktion selbst rollt nicht auf die gleiche Weise zurück.
Dusk-Dokumentation sagt, dass eine ausgeführte Transaktion mit einem nicht-null Fehler einen Contract Panic oder ein anderes Ausführungsversagen darstellen kann.
Und egal ob die Ausführung gelingt oder fehlschlägt:
der Moonlight-Nonce oder die Phoenix-Notes werden verbraucht,
und das Gas wird weiterhin bezahlt.
Das schafft eine deutlich schärfere Unterscheidung als nur zu sagen „die Transaktion ist fehlgeschlagen“:
contract-state rollback ≠ transaction-layer rollback.
Für Entwickler eines Wallets oder einer dApp ist das wichtig.
Stell dir vor, die UI zeigt:
FEHLGESCHLAGEN.
Ein Nutzer könnte das natürlich so lesen:
nichts ist passiert, versuche es nochmal.
Aber das ist nicht mehr der vollständige Protokollzustand.
Die beabsichtigte Vertragsänderung ist möglicherweise nicht passiert, während die Gebühr ausgegeben wurde und der Spend-Input der Transaktion bereits weitergeschaltet wurde.
Ein naives erneutes Ausprobieren kann also nicht einfach davon ausgehen, dass die alte Nonce oder die alten Notes noch verfügbar sind.
Das ist der Fehlerpfad, den ich verhindern wollen würde, dass ein Dusk-Wallet ihn ermöglicht.
Nach einem fehlgeschlagenen Call zuerst den Spend-State aktualisieren.
Dann dem Nutzer ganz genau sagen, was fehlgeschlagen ist und was noch verbraucht wurde.
Die Metrik, die ich im Blick behalten würde, ist sehr eng:
Wie oft können Wallets sich von fehlgeschlagener Ausführung erholen, ohne falsche Annahmen über stale Nonce/Note, kaputte Retries oder die Annahme der Nutzer, sie hätten für „nichts“ bezahlt?
Ich mag dieses Designdetail, weil es zwei unterschiedliche Bedeutungen von Rollback sichtbar macht.
Die Anwendung kann zurückgehen.
Die Transaktion kann nicht so tun, als wäre sie nie passiert.
#dusk $DUSK @Dusk
$BTW $HEMI