Ce qui a attiré mon attention, c’est que la mise à niveau de Boreas de Dusk a rendu l’exécution des contrats échoués plus visible, et non moins.
Depuis le déploiement de Boreas sur le mainnet du 10 juin 2026 au bloc 4 414 095, les événements de contrats révoqués peuvent encore être conservés dans les données d’archive avec un marqueur explicite « reverted ». En parallèle, ces événements échoués sont retirés du bloom de bloc canonique, et les événements de mise révoquée sont exclus des mises à jour de l’état du provisionneur.
Cette distinction compte plus qu’il n’y paraît d’abord.
Un appel révoqué ne devrait pas modifier l’état canonique. Mais pour les applications financières, effacer complètement la trace de l’événement peut rendre le débogage, la conciliation et la revue médico-légale plus difficiles. Dusk sépare « cet événement s’est produit pendant l’exécution » de « cet événement est devenu une partie de l’état valide ».
Je m’attendais à une chaîne axée sur la confidentialité qui réduirait au maximum les détails d’exécution conservés. Au lieu de cela, DuskFoundation préserve une piste d’audit plus claire pour l’activité de contrats échoués, tout en gardant l’indexation canonique propre.
Mon interprétation : il s’agit d’un petit détail du protocole, mais d’une pertinence exceptionnellement forte pour la finance onchain réglementée. La traçabilité n’est pas seulement une question de voir les transferts réussis ; il s’agit aussi de prouver ce qui a échoué et de s’assurer que cela n’a jamais contaminé l’état.
La question que je surveille : les explorateurs et les outils institutionnels vont-ils mettre en avant suffisamment clairement cette métadonnée d’événement révoqué pour que les utilisateurs puissent en bénéficier ?
@Dusk $DUSK #dusk
Depuis le déploiement de Boreas sur le mainnet du 10 juin 2026 au bloc 4 414 095, les événements de contrats révoqués peuvent encore être conservés dans les données d’archive avec un marqueur explicite « reverted ». En parallèle, ces événements échoués sont retirés du bloom de bloc canonique, et les événements de mise révoquée sont exclus des mises à jour de l’état du provisionneur.
Cette distinction compte plus qu’il n’y paraît d’abord.
Un appel révoqué ne devrait pas modifier l’état canonique. Mais pour les applications financières, effacer complètement la trace de l’événement peut rendre le débogage, la conciliation et la revue médico-légale plus difficiles. Dusk sépare « cet événement s’est produit pendant l’exécution » de « cet événement est devenu une partie de l’état valide ».
Je m’attendais à une chaîne axée sur la confidentialité qui réduirait au maximum les détails d’exécution conservés. Au lieu de cela, DuskFoundation préserve une piste d’audit plus claire pour l’activité de contrats échoués, tout en gardant l’indexation canonique propre.
Mon interprétation : il s’agit d’un petit détail du protocole, mais d’une pertinence exceptionnellement forte pour la finance onchain réglementée. La traçabilité n’est pas seulement une question de voir les transferts réussis ; il s’agit aussi de prouver ce qui a échoué et de s’assurer que cela n’a jamais contaminé l’état.
La question que je surveille : les explorateurs et les outils institutionnels vont-ils mettre en avant suffisamment clairement cette métadonnée d’événement révoqué pour que les utilisateurs puissent en bénéficier ?
@Dusk $DUSK #dusk
