#dusk $DUSK J’ai relu le processus de validation des frais de transaction de Dusk du point de vue de l’utilisateur, et j’ai constaté que l’affichage du portefeuille « frais estimés » n’est que l’information la plus superficielle. Lorsqu’on entre réellement dans la validation réseau, le système ne s’intéresse pas seulement à savoir combien valent respectivement le gas limit et le gas price ; il doit aussi vérifier si leur produit, qui donne les frais maximaux, correspond exactement au max fee déjà prouvé dans la transaction. Tant que ces champs ne coïncident pas, les paramètres de la transaction sont eux-mêmes en conflit.
Il faut noter ici qu’une même contrainte de frais est vérifiée à la fois lors de l’admission dans le mempool et lors de l’exécution par la VM. La première couche sert à bloquer le plus tôt possible les entrées incohérentes avant que la transaction ne continue à se propager, afin de réduire les données invalides qui consomment les ressources du nœud. Cependant, le mempool n’est pas la frontière finale de l’exécution du protocole, car le contenu d’un bloc n’emprunte pas nécessairement le chemin de réception familier à un nœud ordinaire.
La VM doit donc revérifier une seconde fois. Ce n’est pas une simple répétition, mais une garantie que, quelle que soit la porte d’entrée par laquelle une transaction apparaît, dès lors qu’elle est destinée à modifier l’état de la chaîne, elle doit respecter le même ensemble d’équations de frais. On peut considérer le mempool comme un filtrage à l’entrée, tandis que la vérification par la VM détermine si la transaction est autorisée à s’exécuter. Le premier améliore l’efficacité du traitement réseau, le second garantit la cohérence du résultat du protocole.
Quand les utilisateurs d’ETH voient le gas limit et le gas price, ils ont tendance à discuter d’abord de savoir si les frais sont élevés et si l’estimation est précise ; mais le point central de cette contrainte de sécurité dans Dusk est de vérifier si la preuve des frais, le contenu de la signature, l’exécution réelle et le calcul du remboursement peuvent rester cohérents. Même si l’estimation fournie par le portefeuille semble raisonnable, tant que les champs ne sont pas strictement liés entre eux, il peut encore subsister une marge pour des cas de traitement anormaux.
Cela signifie aussi que la correction de sécurité ne fera pas nécessairement ressentir immédiatement aux utilisateurs ordinaires une baisse des frais. Sa valeur la plus directe est de réduire le nombre de transactions dont les données de frais se contredisent et qui atteignent le flux d’exécution. À l’avenir, je serai plus attentif à savoir si le portefeuille @Dusk peut afficher séparément les frais maximaux réservés, les frais réellement consommés et le remboursement final. Pour ceux qui utilisent DUSK pour payer les frais du réseau, un simple chiffre de gas est difficile à interpréter : il n’explique pas à quelle étape la transaction a échoué, ni ne permet de déterminer si différents clients ont appliqué les mêmes règles. @Dusk $BTC