Un événement de fin de soirée archivé peut décrire un changement d’état qui ne s’est jamais produit
Un backend peut lire un événement depuis l’archive finalisée de Dusk et prendre néanmoins la mauvaise décision financière.
Depuis que Boreas est devenu actif sur le mainnet au bloc de redémarrage 4,414,095, Dusk conserve volontairement les événements de contrats annulés (revert) dans les données d’archive, avec un marqueur indiquant qu’ils ont été revert. Ces événements constituent une preuve historique que l’exécution les a produits—ce n’est pas une preuve que leurs effets d’état ont survécu.
Après Boreas, les événements revert sont exclus du bloom de bloc canonique, et les événements de mise (stake) revert ne mettent pas à jour l’état du pourvoyeur.
Cette distinction est importante partout où les événements deviennent des mutations de base de données. Un indexeur qui considère « l’événement existe » comme « l’opération a réussi » peut créditer un dépôt, enregistrer un paiement (payout), ou déclencher une logique en aval pour un état que la chaîne a annulé.
Le guide de dépôt de Moonlight de Dusk énonce explicitement la règle : un dépôt direct n’est accepté que lorsque l’événement de transfert correspond à l’opération attendue et que event.reverted === false.
Ainsi, la finalisation répond à une seule question : cette histoire archivée est-elle réglée (settled) ? Elle n’efface pas la nécessité d’interpréter ce que cette histoire dit.
Pour les intégrations de Dusk après Boreas, revert n’est pas un métadonnée à ignorer. C’est une partie de la condition d’acceptation qui sépare les preuves d’exécution historique de l’état canonique.
@Dusk $DUSK #dusk
Un backend peut lire un événement depuis l’archive finalisée de Dusk et prendre néanmoins la mauvaise décision financière.
Depuis que Boreas est devenu actif sur le mainnet au bloc de redémarrage 4,414,095, Dusk conserve volontairement les événements de contrats annulés (revert) dans les données d’archive, avec un marqueur indiquant qu’ils ont été revert. Ces événements constituent une preuve historique que l’exécution les a produits—ce n’est pas une preuve que leurs effets d’état ont survécu.
Après Boreas, les événements revert sont exclus du bloom de bloc canonique, et les événements de mise (stake) revert ne mettent pas à jour l’état du pourvoyeur.
Cette distinction est importante partout où les événements deviennent des mutations de base de données. Un indexeur qui considère « l’événement existe » comme « l’opération a réussi » peut créditer un dépôt, enregistrer un paiement (payout), ou déclencher une logique en aval pour un état que la chaîne a annulé.
Le guide de dépôt de Moonlight de Dusk énonce explicitement la règle : un dépôt direct n’est accepté que lorsque l’événement de transfert correspond à l’opération attendue et que event.reverted === false.
Ainsi, la finalisation répond à une seule question : cette histoire archivée est-elle réglée (settled) ? Elle n’efface pas la nécessité d’interpréter ce que cette histoire dit.
Pour les intégrations de Dusk après Boreas, revert n’est pas un métadonnée à ignorer. C’est une partie de la condition d’acceptation qui sépare les preuves d’exécution historique de l’état canonique.
@Dusk $DUSK #dusk