J’ai commencé à envisager les intégrations blockchain sous un angle différent : un événement peut dire à une application ce qui s’est produit, mais tous les événements ne lui indiquent pas que le résultat est final.
Cette distinction devient importante lorsque le logiciel réagit à une activité onchain.
Le nœud Rusk de Dusk expose le RUES (Rusk Universal Event System), que des applications et des intégrations externes peuvent utiliser pour des événements blockchain. Pour les transactions, RUES inclut des événements tels que included (inclus), removed (supprimé) et executed (exécuté). Mais ces événements correspondent à des étapes différentes du cycle de vie.
Par exemple, executed signifie qu’une transaction a été exécutée dans un bloc accepté, mais l’application doit encore examiner le résultat de l’exécution. Plus important encore : un bloc accepté peut toujours être annulé. Dusk affirme qu’un bloc devient final lorsque son état passe à finalized (finalisé).
Cela crée une distinction intéressante :
observer un événement n’est pas la même chose que confirmer l’état final.
La documentation d’intégration de Dusk recommande donc de vérifier d’abord la réussite de l’exécution, puis de confirmer que le bloc concerné a été finalisé. Les nœuds d’archivage peuvent conserver des index historiques finalisés, y compris finalizedEvents, pour les applications qui ont besoin de données historiques finalisées.
Pour moi, cela change la façon dont je réfléchis aux intégrations blockchain.
Le défi n’est pas simplement de recevoir des événements.
Il s’agit de savoir quand une application peut traiter le résultat de manière sûre comme final.
@Dusk $DUSK #dusk
Cette distinction devient importante lorsque le logiciel réagit à une activité onchain.
Le nœud Rusk de Dusk expose le RUES (Rusk Universal Event System), que des applications et des intégrations externes peuvent utiliser pour des événements blockchain. Pour les transactions, RUES inclut des événements tels que included (inclus), removed (supprimé) et executed (exécuté). Mais ces événements correspondent à des étapes différentes du cycle de vie.
Par exemple, executed signifie qu’une transaction a été exécutée dans un bloc accepté, mais l’application doit encore examiner le résultat de l’exécution. Plus important encore : un bloc accepté peut toujours être annulé. Dusk affirme qu’un bloc devient final lorsque son état passe à finalized (finalisé).
Cela crée une distinction intéressante :
observer un événement n’est pas la même chose que confirmer l’état final.
La documentation d’intégration de Dusk recommande donc de vérifier d’abord la réussite de l’exécution, puis de confirmer que le bloc concerné a été finalisé. Les nœuds d’archivage peuvent conserver des index historiques finalisés, y compris finalizedEvents, pour les applications qui ont besoin de données historiques finalisées.
Pour moi, cela change la façon dont je réfléchis aux intégrations blockchain.
Le défi n’est pas simplement de recevoir des événements.
Il s’agit de savoir quand une application peut traiter le résultat de manière sûre comme final.
@Dusk $DUSK #dusk
