Un evento de atardecer archivado puede describir un cambio de estado que nunca ocurrió
Un backend puede leer un evento del archivo finalizado de Dusk y aun así tomar una decisión financiera incorrecta.
Desde que Boreas se activó en la mainnet en el bloque de reinicio 4.414.095, Dusk retiene deliberadamente en los datos de archivo los eventos de contratos revertidos con un marcador de reversión. Esos eventos son evidencia histórica de que la ejecución los produjo, no una prueba de que sus efectos de estado se hayan mantenido.
Después de Boreas, los eventos revertidos se excluyen del bloom de bloque canónico, y los eventos de stake revertidos no actualizan el estado del provisioner.
Esa distinción importa donde los eventos se convierten en mutaciones de base de datos. Un indexador que trate “el evento existe” como “la operación tuvo éxito” puede acreditar un depósito, registrar un pago o activar lógica aguas abajo para un estado que la cadena revirtió.
La guía de depósitos de Moonlight de Dusk hace la regla explícita: un depósito directo se acepta solo cuando el evento de transferencia coincide con la operación esperada y event.reverted === false.
Así, la finalización responde una pregunta: ¿esta historia archivada está resuelta? No borra la necesidad de interpretar lo que esa historia dice.
Para integraciones de Dusk posteriores a Boreas, revertido no es metadato para ignorar. Es parte de la condición de aceptación que separa la evidencia de ejecución histórica del estado canónico.
@Dusk $DUSK #dusk
Un backend puede leer un evento del archivo finalizado de Dusk y aun así tomar una decisión financiera incorrecta.
Desde que Boreas se activó en la mainnet en el bloque de reinicio 4.414.095, Dusk retiene deliberadamente en los datos de archivo los eventos de contratos revertidos con un marcador de reversión. Esos eventos son evidencia histórica de que la ejecución los produjo, no una prueba de que sus efectos de estado se hayan mantenido.
Después de Boreas, los eventos revertidos se excluyen del bloom de bloque canónico, y los eventos de stake revertidos no actualizan el estado del provisioner.
Esa distinción importa donde los eventos se convierten en mutaciones de base de datos. Un indexador que trate “el evento existe” como “la operación tuvo éxito” puede acreditar un depósito, registrar un pago o activar lógica aguas abajo para un estado que la cadena revirtió.
La guía de depósitos de Moonlight de Dusk hace la regla explícita: un depósito directo se acepta solo cuando el evento de transferencia coincide con la operación esperada y event.reverted === false.
Así, la finalización responde una pregunta: ¿esta historia archivada está resuelta? No borra la necesidad de interpretar lo que esa historia dice.
Para integraciones de Dusk posteriores a Boreas, revertido no es metadato para ignorar. Es parte de la condición de aceptación que separa la evidencia de ejecución histórica del estado canónico.
@Dusk $DUSK #dusk
