Un délai de retrait ne devrait pas créer une nouvelle identité
Une demande de retrait expire. La réponse tentante est simple : reconstruire la transaction et la renvoyer.
Sur Dusk, cela peut rendre le problème opérationnel plus difficile.
Pour les retraits Moonlight, les consignes d’intégration indiquent que la transaction doit être construite et signée une seule fois, ses octets sérialisés et son identifiant de transaction étant stockés avant diffusion. Si l’envoi rencontre un délai d’attente de transport, la reprise sûre consiste à rediffuser exactement ces octets signés. La transaction conserve la même identité pendant que son statut en chaîne est examiné.
Pourquoi est-ce important ? Parce qu’un délai d’attente ne prouve pas que la première tentative a échoué. Même un 202 Accepted ne confirme que l’acheminement, pas l’inclusion ni la finalité. Créer une autre transaction avant de lever cette incertitude introduit un autre objet que le système de retrait devra suivre.
Moonlight fait la distinction explicitement. Les transactions utilisent des nonces de compte séquentiels, et une transaction conflictuelle ayant le même nonce remplace l’entrée existante dans le mempool uniquement lorsque son prix du gas est strictement plus élevé. Ce remplacement génère un identifiant de transaction différent. Dusk indique donc aux opérateurs d’échange de rapprocher les deux identifiants et d’éviter de débiter deux fois.
Ainsi, « reprise » et « remplacement » ne sont pas des actions backend interchangeables. Une reprise préserve l’identité de la tentative de paiement. Un remplacement crée délibérément une nouvelle identité pour le même nonce.
Pour l’infrastructure de garde, l’idempotence va donc au-delà de la conception de la base de données : la construction des transactions, l’allocation des nonces, les octets signés et les écritures comptables doivent tous décrire le même retrait.
@Dusk $DUSK #dusk
Une demande de retrait expire. La réponse tentante est simple : reconstruire la transaction et la renvoyer.
Sur Dusk, cela peut rendre le problème opérationnel plus difficile.
Pour les retraits Moonlight, les consignes d’intégration indiquent que la transaction doit être construite et signée une seule fois, ses octets sérialisés et son identifiant de transaction étant stockés avant diffusion. Si l’envoi rencontre un délai d’attente de transport, la reprise sûre consiste à rediffuser exactement ces octets signés. La transaction conserve la même identité pendant que son statut en chaîne est examiné.
Pourquoi est-ce important ? Parce qu’un délai d’attente ne prouve pas que la première tentative a échoué. Même un 202 Accepted ne confirme que l’acheminement, pas l’inclusion ni la finalité. Créer une autre transaction avant de lever cette incertitude introduit un autre objet que le système de retrait devra suivre.
Moonlight fait la distinction explicitement. Les transactions utilisent des nonces de compte séquentiels, et une transaction conflictuelle ayant le même nonce remplace l’entrée existante dans le mempool uniquement lorsque son prix du gas est strictement plus élevé. Ce remplacement génère un identifiant de transaction différent. Dusk indique donc aux opérateurs d’échange de rapprocher les deux identifiants et d’éviter de débiter deux fois.
Ainsi, « reprise » et « remplacement » ne sont pas des actions backend interchangeables. Une reprise préserve l’identité de la tentative de paiement. Un remplacement crée délibérément une nouvelle identité pour le même nonce.
Pour l’infrastructure de garde, l’idempotence va donc au-delà de la conception de la base de données : la construction des transactions, l’allocation des nonces, les octets signés et les écritures comptables doivent tous décrire le même retrait.
@Dusk $DUSK #dusk
