#dusk $DUSK @Dusk
Hé, tu sais… une question au sujet de @DuskFoundation me reste en tête : si un échange reçoit « 202 Accepted » pour mon retrait, pourquoi le travail n’est-il pas terminé ?
On a l’habitude de lire une réponse comme « terminé ». Mais sur une blockchain, soumission et règlement sont deux moments différents.
Sur Dusk L1, « 202 Accepted » signifie seulement qu’un nœud a accepté la transaction pour l’acheminement. Cela ne prouve pas que la transaction est entrée dans le mempool, qu’elle a atteint des pairs, qu’elle s’est exécutée avec succès, ni qu’elle est devenue définitive.
Dusk sépare ces étapes. « transactions/included » indique l’admission dans le mempool local. « transactions/executed » signifie que la transaction s’est exécutée à l’intérieur d’un bloc accepté, et que le champ « err » doit être nul. La finalité arrive lorsqu’un événement « blocks/statechange » est marqué « finalized ». Avant cela, un bloc accepté peut encore être annulé.
Hypothétiquement, disons que je retire du DUSK depuis un échange. Son système signe la transaction Moonlight, enregistre ses octets et son ID, puis la diffuse. La réponse 202 confirme l’acheminement — pas l’achèvement. L’échange doit vérifier l’exécution et l’état du bloc finalisé.
Mais je me suis arrêté là un instant.
Peut-être que la finalité n’est pas seulement une fonctionnalité du consensus. C’est aussi une responsabilité opérationnelle.
Alors, quand un retrait est-il réellement terminé : quand l’API répond, ou lorsque la réversion n’est plus possible ? Je réfléchis encore à ça. 🤔
Hé, tu sais… une question au sujet de @DuskFoundation me reste en tête : si un échange reçoit « 202 Accepted » pour mon retrait, pourquoi le travail n’est-il pas terminé ?
On a l’habitude de lire une réponse comme « terminé ». Mais sur une blockchain, soumission et règlement sont deux moments différents.
Sur Dusk L1, « 202 Accepted » signifie seulement qu’un nœud a accepté la transaction pour l’acheminement. Cela ne prouve pas que la transaction est entrée dans le mempool, qu’elle a atteint des pairs, qu’elle s’est exécutée avec succès, ni qu’elle est devenue définitive.
Dusk sépare ces étapes. « transactions/included » indique l’admission dans le mempool local. « transactions/executed » signifie que la transaction s’est exécutée à l’intérieur d’un bloc accepté, et que le champ « err » doit être nul. La finalité arrive lorsqu’un événement « blocks/statechange » est marqué « finalized ». Avant cela, un bloc accepté peut encore être annulé.
Hypothétiquement, disons que je retire du DUSK depuis un échange. Son système signe la transaction Moonlight, enregistre ses octets et son ID, puis la diffuse. La réponse 202 confirme l’acheminement — pas l’achèvement. L’échange doit vérifier l’exécution et l’état du bloc finalisé.
Mais je me suis arrêté là un instant.
Peut-être que la finalité n’est pas seulement une fonctionnalité du consensus. C’est aussi une responsabilité opérationnelle.
Alors, quand un retrait est-il réellement terminé : quand l’API répond, ou lorsque la réversion n’est plus possible ? Je réfléchis encore à ça. 🤔