Архивированное событие «Угасание» может описать изменение состояния, которого не происходило
Бэкенд может прочитать событие из финализированного архива Dusk и все равно принять неверное финансовое решение.
Поскольку Boreas стал активным в мейннете на блоке перезапуска 4,414,095, Dusk намеренно сохраняет в архивных данных откатившиеся события контрактов с пометкой reverted. Эти события являются историческим доказательством того, что выполнение их породило — но не подтверждением того, что их эффекты состояния пережили откат.
После Boreas откатившиеся события исключаются из канонического bloom блока, а откатившиеся события по ставкам не обновляют состояние провиженера.
Этот нюанс важен там, где события превращаются в мутации базы данных. Индексатор, который воспринимает «событие существует» как «операция выполнена успешно», может засчитать депозит, записать выплату или запустить логику downstream для состояния, которое цепочка откатила.
В собственных рекомендациях Dusk по депозитам Moonlight правило сформулировано явно: прямой депозит принимается только тогда, когда событие передачи соответствует ожидаемой операции и event.reverted === false.
Итак, финализация отвечает на один вопрос: эта архивная история считается урегулированной? Она не отменяет необходимости интерпретировать то, что говорит эта история.
Для интеграций Dusk после Boreas reverted — это не метаданные, которые можно игнорировать. Это часть условия принятия, разделяющего доказательства исторического выполнения и каноническое состояние.
@Dusk $DUSK #dusk
Бэкенд может прочитать событие из финализированного архива Dusk и все равно принять неверное финансовое решение.
Поскольку Boreas стал активным в мейннете на блоке перезапуска 4,414,095, Dusk намеренно сохраняет в архивных данных откатившиеся события контрактов с пометкой reverted. Эти события являются историческим доказательством того, что выполнение их породило — но не подтверждением того, что их эффекты состояния пережили откат.
После Boreas откатившиеся события исключаются из канонического bloom блока, а откатившиеся события по ставкам не обновляют состояние провиженера.
Этот нюанс важен там, где события превращаются в мутации базы данных. Индексатор, который воспринимает «событие существует» как «операция выполнена успешно», может засчитать депозит, записать выплату или запустить логику downstream для состояния, которое цепочка откатила.
В собственных рекомендациях Dusk по депозитам Moonlight правило сформулировано явно: прямой депозит принимается только тогда, когда событие передачи соответствует ожидаемой операции и event.reverted === false.
Итак, финализация отвечает на один вопрос: эта архивная история считается урегулированной? Она не отменяет необходимости интерпретировать то, что говорит эта история.
Для интеграций Dusk после Boreas reverted — это не метаданные, которые можно игнорировать. Это часть условия принятия, разделяющего доказательства исторического выполнения и каноническое состояние.
@Dusk $DUSK #dusk
