Le nœud renvoie « 202 Accepted » : il reste encore combien d’étapes avant un règlement réellement réussi ?
Dans les systèmes de paiement traditionnels, « la banque a bien reçu la demande » et « les fonds sont arrivés » sont deux états différents. Après avoir étudié le cycle de vie de la transaction du @Dusk , j’ai constaté que, côté chaîne, il ne suffit pas non plus de se fier à une seule confirmation de succès.
Pour une transaction Dusk L1, le processus passe généralement par :
soumission, prévalidation par le nœud, entrée dans le mempool local, propagation aux autres nœuds, sélection par le producteur de blocs, exécution, puis confirmation finale.
Le point le plus facile à mal interpréter est que l’interface de soumission renvoie 202 Accepted : cela ne signifie que que le nœud a reçu les données et prévoit de les propager, mais n’indique pas encore l’entrée dans un bloc.
Même lorsque la transaction entre dans le mempool du nœud, cela ne prouve qu’elle a passé les vérifications initiales de ce nœud. Une fois qu’elle est incluse dans un bloc, il faut encore vérifier si l’erreur (err) dans le résultat d’exécution est vide. Si le contrat revient (revert) à cause de paramètres, d’un état ou d’un problème de Gas, le Nonce et le Gas déjà consommé peuvent rester irrécupérables.
Enfin, il faut attendre que le bloc atteigne l’état finalized. La documentation officielle le rappelle clairement : ne pas confondre included, removed ou le simple accepted avec un signal d’ultime finalité du paiement.
C’est crucial pour les futurs services de règlement de titres de Dusk. Pour les institutions, ce n’est pas seulement de savoir si une fenêtre affiche un message vert : l’essentiel est de savoir à partir de quel état irréversible le transfert d’actifs et l’écriture comptable sont effectués.
Le site web de Dusk indique que la finalité réseau est d’environ 10 secondes, mais l’application doit tout de même reconnaître correctement l’état final, plutôt que d’essayer de deviner le résultat en se basant sur une attente fixe de 10 secondes.
Pour déterminer si un système de règlement au niveau institutionnel est suffisamment mature, je regarde en priorité :
1. la stabilité du temps de confirmation finale ;
2. le taux d’échec d’exécution ;
3. le nombre de fois où des blocs sont rollback et où une nouvelle réconciliation est effectuée ;
4. si l’application distingue la soumission, l’exécution et la confirmation finale ;
5. si le côté actif et le côté paiement utilisent la même norme de finalité.
Un véritable règlement on-chain, ce n’est pas simplement que la transaction a été envoyée : c’est que tous les participants ont une réponse cohérente à la question « quand peut-on comptabiliser ? ».#dusk $DUSK
Dans les systèmes de paiement traditionnels, « la banque a bien reçu la demande » et « les fonds sont arrivés » sont deux états différents. Après avoir étudié le cycle de vie de la transaction du @Dusk , j’ai constaté que, côté chaîne, il ne suffit pas non plus de se fier à une seule confirmation de succès.
Pour une transaction Dusk L1, le processus passe généralement par :
soumission, prévalidation par le nœud, entrée dans le mempool local, propagation aux autres nœuds, sélection par le producteur de blocs, exécution, puis confirmation finale.
Le point le plus facile à mal interpréter est que l’interface de soumission renvoie 202 Accepted : cela ne signifie que que le nœud a reçu les données et prévoit de les propager, mais n’indique pas encore l’entrée dans un bloc.
Même lorsque la transaction entre dans le mempool du nœud, cela ne prouve qu’elle a passé les vérifications initiales de ce nœud. Une fois qu’elle est incluse dans un bloc, il faut encore vérifier si l’erreur (err) dans le résultat d’exécution est vide. Si le contrat revient (revert) à cause de paramètres, d’un état ou d’un problème de Gas, le Nonce et le Gas déjà consommé peuvent rester irrécupérables.
Enfin, il faut attendre que le bloc atteigne l’état finalized. La documentation officielle le rappelle clairement : ne pas confondre included, removed ou le simple accepted avec un signal d’ultime finalité du paiement.
C’est crucial pour les futurs services de règlement de titres de Dusk. Pour les institutions, ce n’est pas seulement de savoir si une fenêtre affiche un message vert : l’essentiel est de savoir à partir de quel état irréversible le transfert d’actifs et l’écriture comptable sont effectués.
Le site web de Dusk indique que la finalité réseau est d’environ 10 secondes, mais l’application doit tout de même reconnaître correctement l’état final, plutôt que d’essayer de deviner le résultat en se basant sur une attente fixe de 10 secondes.
Pour déterminer si un système de règlement au niveau institutionnel est suffisamment mature, je regarde en priorité :
1. la stabilité du temps de confirmation finale ;
2. le taux d’échec d’exécution ;
3. le nombre de fois où des blocs sont rollback et où une nouvelle réconciliation est effectuée ;
4. si l’application distingue la soumission, l’exécution et la confirmation finale ;
5. si le côté actif et le côté paiement utilisent la même norme de finalité.
Un véritable règlement on-chain, ce n’est pas simplement que la transaction a été envoyée : c’est que tous les participants ont une réponse cohérente à la question « quand peut-on comptabiliser ? ».#dusk $DUSK