Le mempool que voient les nœuds n’est pas la liste complète des transactions en attente à l’échelle du réseau
Précision particulière dans la documentation de l’API Dusk HTTP : la valeur `mempoolTxs` renvoie le mempool mémoire local du nœud actuel, trié par prix de Gas ; ce n’est ni une vue globale, ni une liste incluant les transactions futures en nonce conservées temporairement dans la prequeue. Cette frontière influence directement l’interprétation, par les outils de supervision, de la notion de « disparition des transactions ».
Lorsqu’une application interroge un nœud et ne voit pas une transaction, plusieurs explications sont possibles : elle n’a pas encore été propagée, elle a été reçue par un autre nœud, ou elle est encore en attente car son nonce est plus futur et a été placée dans la prequeue. Si l’interface indique immédiatement à l’utilisateur de la renvoyer, cela peut créer une intention de remplacement et de doublon. La méthode la plus sûre consiste à croiser le hachage de la transaction, le nœud d’envoi, le nonce du compte et l’état final dans le bloc, afin de fournir un diagnostic sourcé.
Pour évaluer un « lieu de transaction », les données du mempool ne peuvent pas être utilisées directement comme preuve de congestion ou de niveau de frais à l’échelle du réseau. Le tri effectué par un nœud ne reflète que son ensemble local de candidats. Les critères de définition des indicateurs doivent inclure le nœud échantillonné, la fenêtre temporelle, ainsi que l’exclusion liée à la prequeue. Sans un périmètre de calcul clair, plus le tableau de bord est précis, plus il risque d’induire en erreur.
J’ai lu la documentation de développement de @Dusk et j’adore ce genre de phrase qui limite volontairement la signification d’une API. $DUSK #DUSKARMY. : un produit de données fiable doit d’abord dire ce qu’il ne peut pas voir, puis seulement ensuite préciser ce qu’il voit — en particulier, on ne devrait jamais conclure que le réseau entier a rejeté une transaction sur la base de l’absence constatée sur un nœud unique.
Précision particulière dans la documentation de l’API Dusk HTTP : la valeur `mempoolTxs` renvoie le mempool mémoire local du nœud actuel, trié par prix de Gas ; ce n’est ni une vue globale, ni une liste incluant les transactions futures en nonce conservées temporairement dans la prequeue. Cette frontière influence directement l’interprétation, par les outils de supervision, de la notion de « disparition des transactions ».
Lorsqu’une application interroge un nœud et ne voit pas une transaction, plusieurs explications sont possibles : elle n’a pas encore été propagée, elle a été reçue par un autre nœud, ou elle est encore en attente car son nonce est plus futur et a été placée dans la prequeue. Si l’interface indique immédiatement à l’utilisateur de la renvoyer, cela peut créer une intention de remplacement et de doublon. La méthode la plus sûre consiste à croiser le hachage de la transaction, le nœud d’envoi, le nonce du compte et l’état final dans le bloc, afin de fournir un diagnostic sourcé.
Pour évaluer un « lieu de transaction », les données du mempool ne peuvent pas être utilisées directement comme preuve de congestion ou de niveau de frais à l’échelle du réseau. Le tri effectué par un nœud ne reflète que son ensemble local de candidats. Les critères de définition des indicateurs doivent inclure le nœud échantillonné, la fenêtre temporelle, ainsi que l’exclusion liée à la prequeue. Sans un périmètre de calcul clair, plus le tableau de bord est précis, plus il risque d’induire en erreur.
J’ai lu la documentation de développement de @Dusk et j’adore ce genre de phrase qui limite volontairement la signification d’une API. $DUSK #DUSKARMY. : un produit de données fiable doit d’abord dire ce qu’il ne peut pas voir, puis seulement ensuite préciser ce qu’il voit — en particulier, on ne devrait jamais conclure que le réseau entier a rejeté une transaction sur la base de l’absence constatée sur un nœud unique.