En traduisant @Dusk Dusk document du cycle de vie des transactions, je n’ai corrigé qu’une seule erreur d’interprétation : une réponse d’interface en 202 Accepted signifie seulement que le nœud a pris en charge la requête. Après la soumission de la signature Dusk L1, le nœud effectue d’abord une admission ; ce n’est qu’en cas de validation que la transaction entre dans le mempool réel et est diffusée aux peers, puis les producteurs de blocs l’exécutent en fonction du gasPrice.
Je le vois comme une chaîne de traitement de règlement. 202 correspond à la réception au guichet, included signifie l’entrée dans la zone d’attente, et executed exige encore de vérifier si err est null. Après l’acceptation du bloc, il peut encore être reverted, et ce n’est que lorsque blocks/statechange indique finalized que le registre est scellé. Moonlight détecte les conflits à l’aide du compte et du nonce, Phoenix s’appuie sur le nullifier ; pour remplacer une transaction, il faut augmenter le gasPrice.
Cette chaîne d’événements ne s’applique qu’à Dusk L1 ; DuskEVM dispose d’un autre modèle de sequencer et de finalité. Lorsque j’écris un écouteur, je stocke le hash de transaction et les coordonnées du bloc, puis je vérifie avec onlyFinalized:true. Si l’on ne surveille que included, en cas de remplacement par le nœud, d’expiration ou d’éviction pour manque de capacité, on peut facilement prendre l’état local pour un dépôt effectif. L’accusé de réception n’est qu’un relevé de prise en charge ; la confirmation des fonds doit attendre l’état final.
#dusk $DUSK
Je le vois comme une chaîne de traitement de règlement. 202 correspond à la réception au guichet, included signifie l’entrée dans la zone d’attente, et executed exige encore de vérifier si err est null. Après l’acceptation du bloc, il peut encore être reverted, et ce n’est que lorsque blocks/statechange indique finalized que le registre est scellé. Moonlight détecte les conflits à l’aide du compte et du nonce, Phoenix s’appuie sur le nullifier ; pour remplacer une transaction, il faut augmenter le gasPrice.
Cette chaîne d’événements ne s’applique qu’à Dusk L1 ; DuskEVM dispose d’un autre modèle de sequencer et de finalité. Lorsque j’écris un écouteur, je stocke le hash de transaction et les coordonnées du bloc, puis je vérifie avec onlyFinalized:true. Si l’on ne surveille que included, en cas de remplacement par le nœud, d’expiration ou d’éviction pour manque de capacité, on peut facilement prendre l’état local pour un dépôt effectif. L’accusé de réception n’est qu’un relevé de prise en charge ; la confirmation des fonds doit attendre l’état final.
#dusk $DUSK