Je pense que nous posons généralement la mauvaise question quand une transaction Dusk « échoue ».
Un 202 Accepted ne signifie que que le nœud a accepté la requête pour l’acheminement. Cela ne veut pas dire que la transaction est déjà dans le mempool ou dans un bloc. Un exemple que j’ai trouvé intéressant est un nonce futur. Si une transaction Moonlight arrive avec un nonce futur tandis qu’un nonce antérieur manque encore, Dusk peut la conserver en dehors du vrai mempool et attendre que l’écart de nonce se referme au lieu de la rejeter immédiatement. Elle obtient alors un état différé pendant que cela se produit.
Ce n’est qu’une partie de l’histoire. Une fois qu’une transaction passe l’admission, elle entre dans le mempool local de ce nœud. Les autres nœuds conservent leurs propres mempools et effectuent aussi leurs propres contrôles d’admission. Plus tard, une transaction peut être sélectionnée pour un bloc, exécutée, puis finalement finalisée. Elle peut aussi quitter le mempool local sans que cela signifie automatiquement qu’elle a échoué. L’expiration, le remplacement, les limites de capacité et les conflits peuvent tous conduire à une suppression.
C’est là que, selon moi, la différence compte pour les portefeuilles et les exchanges. La documentation d’intégration de Dusk indique de conserver la transaction signée exacte, de traiter 202 Accepted uniquement comme un routage réussi, et de renvoyer les mêmes octets signés après un délai d’expiration de transport au lieu de créer une nouvelle transaction à l’aveugle. Un retrait ne devrait être marqué comme terminé qu’après avoir vérifié l’exécution et une fois le bloc finalisé.
Plus j’y regardais, moins l’expression « transaction submitted » m’a semblé être un statut utile en soi. Une transaction peut attendre un nonce, rester dans le mempool d’un nœud, être exécutée avec une erreur, ou se trouver dans un bloc qui n’est pas encore final. Ce sont des situations très différentes, même si, de l’extérieur, elles peuvent toutes donner l’impression qu’« elle est encore en attente ».
Pour moi, c’est la leçon utile tirée du flux de transactions de Dusk : « submitted » n’est que le début. Ce qui compte, c’est l’état que vous pouvez réellement prouver que la transaction a atteint.
$DUSK @Dusk #dusk
Un 202 Accepted ne signifie que que le nœud a accepté la requête pour l’acheminement. Cela ne veut pas dire que la transaction est déjà dans le mempool ou dans un bloc. Un exemple que j’ai trouvé intéressant est un nonce futur. Si une transaction Moonlight arrive avec un nonce futur tandis qu’un nonce antérieur manque encore, Dusk peut la conserver en dehors du vrai mempool et attendre que l’écart de nonce se referme au lieu de la rejeter immédiatement. Elle obtient alors un état différé pendant que cela se produit.
Ce n’est qu’une partie de l’histoire. Une fois qu’une transaction passe l’admission, elle entre dans le mempool local de ce nœud. Les autres nœuds conservent leurs propres mempools et effectuent aussi leurs propres contrôles d’admission. Plus tard, une transaction peut être sélectionnée pour un bloc, exécutée, puis finalement finalisée. Elle peut aussi quitter le mempool local sans que cela signifie automatiquement qu’elle a échoué. L’expiration, le remplacement, les limites de capacité et les conflits peuvent tous conduire à une suppression.
C’est là que, selon moi, la différence compte pour les portefeuilles et les exchanges. La documentation d’intégration de Dusk indique de conserver la transaction signée exacte, de traiter 202 Accepted uniquement comme un routage réussi, et de renvoyer les mêmes octets signés après un délai d’expiration de transport au lieu de créer une nouvelle transaction à l’aveugle. Un retrait ne devrait être marqué comme terminé qu’après avoir vérifié l’exécution et une fois le bloc finalisé.
Plus j’y regardais, moins l’expression « transaction submitted » m’a semblé être un statut utile en soi. Une transaction peut attendre un nonce, rester dans le mempool d’un nœud, être exécutée avec une erreur, ou se trouver dans un bloc qui n’est pas encore final. Ce sont des situations très différentes, même si, de l’extérieur, elles peuvent toutes donner l’impression qu’« elle est encore en attente ».
Pour moi, c’est la leçon utile tirée du flux de transactions de Dusk : « submitted » n’est que le début. Ce qui compte, c’est l’état que vous pouvez réellement prouver que la transaction a atteint.
$DUSK @Dusk #dusk