POURQUOI UN ÉVÉNEMENT DE BLOCHAIN N’EST PAS IDENTIQUE À LA FINALITÉ
Auparavant, je pensais qu’une plateforme d’échange devait surtout savoir quand une transaction blockchain avait lieu. Mais en observant Dusk, je me suis posé des questions. Si une transaction peut encore changer, je ne suis pas sûr qu’une plateforme d’échange doive considérer cet événement comme de l’argent final.
C’est pourquoi RUES (Rusk Universal Event System) a attiré mon attention. Dusk liste précisément RUES pour l’infrastructure, les indexeurs et les échanges. Pour moi, la partie la plus intéressante, c’est ce que l’échange fait après avoir reçu l’événement.
Le cycle de vie des transactions de Dusk distingue « inclus », « exécutés », « confirmés » et « finalisés ». Sa documentation indique de surveiller la transaction exécutée, de vérifier les erreurs, de confirmer que le bloc est finalisé, puis de réécouter si un bloc est annulé (revert). Je comprends pourquoi c’est important : créditer un échange trop tôt pourrait transformer un état temporaire en un solde réel.
Je pense toujours au suivi des colis du transporteur. Si mon colis indique « en cours de livraison », je sais qu’il bouge, mais je ne le considérerais pas encore comme livré. Je suis peut-être trop prudent, mais je vois pourquoi un échange voudrait la même séparation entre « en mouvement » et « livré ».
Le détail sur l’idempotence m’a aussi fait m’arrêter. Dusk indique aux scanners de dépôts d’utiliser l’ID de transaction de Dusk comme clé d’idempotence, et non le mémo, et d’écrire le crédit et le point de contrôle du bloc de manière atomique. Ainsi, si le scanner plante et relit la même plage, cette transaction ne devrait pas devenir un second dépôt.
Et maintenant, je me demande si je regardais RUES de manière trop simple. Si un échange doit penser séparément l’événement, la finalité, les annulations (reverts) et le traitement en double, quelle part du travail réel se fait en fait après que la blockchain a déclaré qu’il s’est passé quelque chose ? @Dusk #dusk $DUSK
Auparavant, je pensais qu’une plateforme d’échange devait surtout savoir quand une transaction blockchain avait lieu. Mais en observant Dusk, je me suis posé des questions. Si une transaction peut encore changer, je ne suis pas sûr qu’une plateforme d’échange doive considérer cet événement comme de l’argent final.
C’est pourquoi RUES (Rusk Universal Event System) a attiré mon attention. Dusk liste précisément RUES pour l’infrastructure, les indexeurs et les échanges. Pour moi, la partie la plus intéressante, c’est ce que l’échange fait après avoir reçu l’événement.
Le cycle de vie des transactions de Dusk distingue « inclus », « exécutés », « confirmés » et « finalisés ». Sa documentation indique de surveiller la transaction exécutée, de vérifier les erreurs, de confirmer que le bloc est finalisé, puis de réécouter si un bloc est annulé (revert). Je comprends pourquoi c’est important : créditer un échange trop tôt pourrait transformer un état temporaire en un solde réel.
Je pense toujours au suivi des colis du transporteur. Si mon colis indique « en cours de livraison », je sais qu’il bouge, mais je ne le considérerais pas encore comme livré. Je suis peut-être trop prudent, mais je vois pourquoi un échange voudrait la même séparation entre « en mouvement » et « livré ».
Le détail sur l’idempotence m’a aussi fait m’arrêter. Dusk indique aux scanners de dépôts d’utiliser l’ID de transaction de Dusk comme clé d’idempotence, et non le mémo, et d’écrire le crédit et le point de contrôle du bloc de manière atomique. Ainsi, si le scanner plante et relit la même plage, cette transaction ne devrait pas devenir un second dépôt.
Et maintenant, je me demande si je regardais RUES de manière trop simple. Si un échange doit penser séparément l’événement, la finalité, les annulations (reverts) et le traitement en double, quelle part du travail réel se fait en fait après que la blockchain a déclaré qu’il s’est passé quelque chose ? @Dusk #dusk $DUSK