Das gruseligste Dusk-Event für mich ist eines, das ich aus finaler Geschichte ziehen kann und für das ich trotzdem kein Recht habe, zu handeln.
Boreas hat die Semantik des Archivs geändert, sodass Vertragsevents aus rückgängig gemachter Ausführung erhalten bleiben können, statt zu verschwinden. Der entscheidende Punkt ist das Flag, das daran hängt. Ein Event kann im Archiv existieren und trotzdem reverted: true tragen.
Das durchbricht einen Shortcut, den ich als Indexer normalerweise versucht wäre zu verwenden: „Ein Event existiert in finaler Historie, daher ist die Zustandsänderung passiert.“
Dusk’ eigenes Moonlight-Deposit-Muster filtert für event.reverted === false, bevor es einen Zufluss akzeptiert. Ich würde dieselbe Disziplin auf jeden Contract-Worker anwenden, der etwas off-chain freigibt. Wenn eine Redemption-Funktion ein Event ausgibt und später einen Panic auslöst, darf mein Backend das Event allein nicht als Erlaubnis behandeln, um die Redemption als abgeschlossen zu markieren.
Der Block mag final sein. Der Ereigniseintrag mag abfragbar sein. Der Vertragszustand kann trotzdem sagen, dass die Aktion zurückgerollt wurde.
Also würde ich das Revert-Bit neben jedes indexierte Event speichern und es zu einem Teil der Business-Regel machen – nicht zu einem Debugging-Feld.
Auf Dusk sagt mir die finale Historie, was aufgezeichnet wurde. reverted sagt mir, ob ich dem Event glauben darf.
#dusk $DUSK @Dusk
Boreas hat die Semantik des Archivs geändert, sodass Vertragsevents aus rückgängig gemachter Ausführung erhalten bleiben können, statt zu verschwinden. Der entscheidende Punkt ist das Flag, das daran hängt. Ein Event kann im Archiv existieren und trotzdem reverted: true tragen.
Das durchbricht einen Shortcut, den ich als Indexer normalerweise versucht wäre zu verwenden: „Ein Event existiert in finaler Historie, daher ist die Zustandsänderung passiert.“
Dusk’ eigenes Moonlight-Deposit-Muster filtert für event.reverted === false, bevor es einen Zufluss akzeptiert. Ich würde dieselbe Disziplin auf jeden Contract-Worker anwenden, der etwas off-chain freigibt. Wenn eine Redemption-Funktion ein Event ausgibt und später einen Panic auslöst, darf mein Backend das Event allein nicht als Erlaubnis behandeln, um die Redemption als abgeschlossen zu markieren.
Der Block mag final sein. Der Ereigniseintrag mag abfragbar sein. Der Vertragszustand kann trotzdem sagen, dass die Aktion zurückgerollt wurde.
Also würde ich das Revert-Bit neben jedes indexierte Event speichern und es zu einem Teil der Business-Regel machen – nicht zu einem Debugging-Feld.
Auf Dusk sagt mir die finale Historie, was aufgezeichnet wurde. reverted sagt mir, ob ich dem Event glauben darf.
#dusk $DUSK @Dusk