Une transaction de Dusk peut disparaître du mempool de mon nœud sans jamais atteindre une expiration on-chain.
C’est le délai que je ne voudrais pas coder en dur dans un portefeuille. @Dusk transactions ne portent aucun champ d’expiration. L’expiration relève de la politique locale de Rusk. La valeur par défaut intégrée est de trois jours, tandis que les nœuds installés avec node-installer v0.5.22 utilisent une durée de vie de mempool de 30 minutes avec des vérifications toutes les cinq minutes.
Ainsi, deux nœuds Dusk en bonne santé peuvent me donner des réponses très différentes sur la durée pendant laquelle la même transaction en attente est autorisée à rester.
La partie la plus vicieuse est l’événement “removed”. Il ne m’indique que que la transaction a quitté le mempool local de ce nœud. L’inclusion, le remplacement, l’expiration, l’éviction pour capacité, ou un conflit de dépense peuvent tous provoquer cette sortie. Si je traduis “removed” directement par “failed”, ma logique de récupération se trompe.
Pour un service de retrait, cette supposition peut toucher l’utilisateur. Je peux marquer un paiement comme mort parce que mon nœud l’a expiré localement pendant qu’un autre nœud l’avait déjà propagé plus loin.
Je traiterais le timeout du mempool comme une configuration du nœud, puis je consulterais l’état du ledger avant de décider qu’une transaction DUSK est suffisamment sûre pour être reconstruite.
Sur Dusk, “absente de mon mempool” n’est pas la même chose que “disparue”.
$SOXSB $ACE #dusk $DUSK @Dusk
C’est le délai que je ne voudrais pas coder en dur dans un portefeuille. @Dusk transactions ne portent aucun champ d’expiration. L’expiration relève de la politique locale de Rusk. La valeur par défaut intégrée est de trois jours, tandis que les nœuds installés avec node-installer v0.5.22 utilisent une durée de vie de mempool de 30 minutes avec des vérifications toutes les cinq minutes.
Ainsi, deux nœuds Dusk en bonne santé peuvent me donner des réponses très différentes sur la durée pendant laquelle la même transaction en attente est autorisée à rester.
La partie la plus vicieuse est l’événement “removed”. Il ne m’indique que que la transaction a quitté le mempool local de ce nœud. L’inclusion, le remplacement, l’expiration, l’éviction pour capacité, ou un conflit de dépense peuvent tous provoquer cette sortie. Si je traduis “removed” directement par “failed”, ma logique de récupération se trompe.
Pour un service de retrait, cette supposition peut toucher l’utilisateur. Je peux marquer un paiement comme mort parce que mon nœud l’a expiré localement pendant qu’un autre nœud l’avait déjà propagé plus loin.
Je traiterais le timeout du mempool comme une configuration du nœud, puis je consulterais l’état du ledger avant de décider qu’une transaction DUSK est suffisamment sûre pour être reconstruite.
Sur Dusk, “absente de mon mempool” n’est pas la même chose que “disparue”.
$SOXSB $ACE #dusk $DUSK @Dusk
