Comment estimer les frais de gas sur Ethereum et d'autres chaînes

Pour estimer des frais de gas, multipliez le gas qu’une transaction utilisera par le prix que vous payez par unité de gas. Sur Ethereum après l’EIP-1559, cela signifie (frais de base + pourboire) × unités de gas utilisées. Les unités proviennent de la simulation de votre transaction exacte. Le prix provient du réseau en direct. Ce guide couvre les deux aspects, puis aborde ce qui change sur les layer 2, avec les comptes intelligents, et lorsque vous intégrez des paiements dans une application.

(Si vous êtes arrivé ici en cherchant le prix du carburant pour votre voiture, cette page traite des frais de transaction blockchain.)

TL;DR

• Frais = gas utilisé × prix par gas. Le gas utilisé mesure le travail computationnel. Le prix par gas reflète la demande.
• Simulez la transaction exacte avec eth_estimateGas pour les unités, et lisez les données de frais en direct pour le prix. Rafraîchissez les deux juste avant la signature.
• Une limite de gas est un plafond, pas un coût. Le gas non utilisé n’est pas consommé, mais une transaction échouée paie tout de même pour le travail effectué.
• Les rollups comme Arbitrum ajoutent un coût de données de couche 1. Utilisez l’estimateur propre à chaque chaîne, pas une hypothèse basée sur le mainnet Ethereum.
• Pour les applications de paiement, stockez l’estimation, les champs de frais, l’horodatage et les frais du reçu final afin de pouvoir rapprocher ultérieurement.

Table des matières

• La formule derrière chaque estimation de gas
• Limite de gas vs prix du gas
• Un exemple travaillé
• Estimer le gas dans le code
• Les layer 2 et autres chaînes ne suivent pas la formule du mainnet
• Comptes intelligents et gas sponsorisé
• Erreurs d’estimation courantes
• Ce qu’il faut enregistrer pour les paiements
• Notre point de vue
• Évitez la plomberie des frais par chaîne
• FAQ
• Sources

La formule derrière chaque estimation de gas

Ethereum.org définit le gas comme l’unité qui mesure l’effort computationnel nécessaire pour exécuter des opérations sur le réseau. Chaque transaction en consomme une certaine quantité. Vous payez ensuite un prix pour chaque unité. Cela donne deux nombres distincts :

1. Les unités de gas dépendent de ce que fait la transaction. Envoyer de l’ETH à une adresse simple est basique. Appeler un contrat intelligent ne l’est pas.
2. Le prix par gas dépend de l’encombrement du réseau à l’instant T. Il est exprimé en gwei.

Le point que la plupart des calculateurs masquent : changer la logique de votre contrat modifie le premier nombre, tandis que la congestion modifie le second. Une bonne interface affiche les deux au lieu d’un total unique inexpliqué.

Gwei et ETH

Un gwei équivaut à 0,000000001 ETH (10^-9). Pour convertir, multipliez les unités de gas par le prix en gwei, puis divisez par 1 000 000 000 pour obtenir de l’ETH. Multipliez par le prix de l’ETH seulement si vous voulez un montant en dollars. Notre convertisseur gwei gère wei, gwei et ETH dans les deux sens.

Ce qu’a changé l’EIP-1559

Depuis l’EIP-1559, chaque bloc possède un frais de base par gaz qui augmente ou diminue selon la demande, et le frais de base est brûlé. Par-dessus cela, une transaction comporte un frais de priorité (le pourboire) et un frais maximal, le montant maximum que vous êtes prêt à payer par gaz au total. Vous payez le frais de base du bloc qui vous inclut plus votre pourboire, tant que la somme reste inférieure à votre frais maximal.

Ainsi, une estimation de portefeuille comporte trois éléments variables : les unités, le frais de base et le pourboire. Le frais maximal est un plafond de sécurité, pas une prédiction.

Limite de gaz vs prix du gaz

Ces deux termes déroutent la plupart des débutants, les voici donc côte à côte.

	Limite de gaz	Prix du gaz
Qu’est-ce que c’est	Le nombre maximal d’unités de gaz que vous autorisez la transaction à utiliser	Ce que vous payez par unité, en gwei
Défini par	Votre estimation du travail impliqué	La demande du marché, plus votre pourboire
L’augmenter	N’augmente pas les frais par lui-même	Augmente les frais directement
Trop bas	La transaction échoue	La transaction attend ou n’est pas incluse

Le comportement clé : une limite de gaz est un plafond. Un transfert ETH standard utilise 21 000 gaz, et le gaz alloué non utilisé est retourné. MetaMask note que l’augmentation manuelle d’une limite n’augmente pas nécessairement les frais finaux car le gaz non utilisé n’est pas consommé. Cela n’achète pas non plus une confirmation plus rapide. Une substitution manuelle vous protège seulement contre une sous-estimation.

Le danger va dans l’autre sens. Si un contrat manque de gaz pendant l’exécution, il se réinitialise mais consomme tout de même le gaz que vous avez fourni. Et le calcul est payé même quand une transaction se réinitialise. C’est pourquoi vous devez simuler avant de diffuser.

Un exemple travaillé

Les chiffres ci-dessous sont illustratifs, pas des prix en temps réel. Supposons un frais de base de 20 gwei et un frais de priorité de 2 gwei, soit 22 gwei par gaz.

Transaction	Unités de gaz	Prix par gaz	Frais en gwei	Frais en ETH
Transfert ETH simple	21 000	22 gwei	462 000	0,000462
Approbation ERC-20 (affichage portefeuille typique)	45 000	22 gwei	990 000	0,00099

Le chiffre de 21 000 pour un transfert simple provient de Ethereum.org. Le chiffre de 45 000 est ce que MetaMask affiche couramment pour une approbation ERC-20, mais le vrai nombre dépend du contrat et de son état. Un transfert de jeton ou un échange différera à nouveau. C’est toute la raison pour laquelle vous ne pouvez pas coder en dur les unités pour quoi que ce soit au-delà d’un transfert simple.

Pour obtenir un chiffre en monnaie fiduciaire, prenez 0,000462 ETH et multipliez par le prix actuel de l’ETH. Faites-le en dernier, et étiquetez-le comme approximatif.

Estimer le gaz dans le code

Si vous construisez plutôt que de cliquer, le processus comporte quatre étapes.

1. Décrivez l’intention complète de la transaction. eth_estimateGas a besoin de la chaîne, de l’adresse de destination, du calldata et de la valeur, ainsi que des champs de frais optionnels. Changez le montant du token, le destinataire ou l’état du contrat et l’estimation peut changer. Ne réutilisez jamais l’estimation d’un autre transfert.
2. Appelez eth_estimateGas sur un nœud. Il renvoie les unités requises, généralement sous forme de nombre hexadécimal que vous devez décoder.
3. Récupérez les recommandations de prix actuelles. Demandez à un oracle de frais ou à votre nœud un frais de base et une suggestion de pourboire pour la vitesse souhaitée (lent, standard, rapide).
4. Calculez et présentez une fourchette. Multipliez les unités par le prix, et montrez aux utilisateurs un maximum ou une fourchette. Un devis n’est pas une garantie, et le réseau peut évoluer entre l’estimation et l’inclusion.

Ajoutez ensuite une habitude qui évite les maux de tête : rafraîchissez le prix immédiatement avant de signer. Le prix du gaz est sensible à la demande, donc la même transaction peut coûter des montants différents à différents moments. Ethereum.org renvoie vers des explorateurs de blocs et des trackers de gaz pour des données en direct lorsque vous n’avez besoin que d’une vérification rapide manuelle.

Augmentez la limite, pas le prix

Un petit tampon sur la limite de gaz est une assurance bon marché, car le gaz non utilisé n’est pas facturé. Augmenter le prix par gaz, en revanche, augmente directement ce que vous payez. Gardez ces deux décisions séparées dans votre code.

Les Layer 2 et autres chaînes ne suivent pas la formule du mainnet

Une seule formule EVM générique peut induire en erreur. Les rollups facturent deux choses : l’exécution sur la couche 2 et la publication des données de votre transaction sur la couche 1.

Arbitrum en est un bon exemple. Sa documentation indique que la voie rapide consiste à appeler eth_estimateGas et multiplier par le prix du gaz de la chaîne enfant. La limite de gaz retournée inclut le calcul de la couche 2 plus un tampon pour le coût de la couche 1. Ce tampon dépend de la taille du calldata compressé et de la tarification de la chaîne parente, donc l’estimation peut varier lorsque la couche 1 est chargée. Pour une comptabilité au niveau des composants, l’appel NodeInterface.gasEstimateComponents détaille le total, le tampon de la couche 1 et les données de frais de base. Arbitrum avertit lui-même que les estimations sont approximatives et que les frais réels peuvent différer.

Pour une analyse plus approfondie, consultez notre article sur le suivi des frais de gaz Arbitrum en direct avec NodeInterface et la formule de Nitro.

Tron fonctionne sur un modèle entièrement différent. Il facture en bande passante et en énergie plutôt qu’en prix du gaz, donc rien de ce qui précède ne s’applique directement. Notre guide sur les frais TRON et le calculateur de frais TRON pour les transferts USDT-TRC20 couvrent ce modèle.

La règle pour les produits multi-chaînes : utilisez l’estimateur propre à chaque réseau, et gardez la logique spécifique à chaque chaîne derrière une seule interface.

Comptes intelligents et gaz sponsorisé

Si vous utilisez l’abstraction de compte avec un paymaster, un devis de transaction simple ne suffit pas. L’ERC-7677 explique que l’estimation du paymaster dépend du contexte, car le portefeuille et le bundler savent comment l’opération utilisateur sera réellement soumise. Il stipule que les portefeuilles devraient utiliser les valeurs de gaz fournies par le paymaster pour les champs spécifiques au paymaster, y compris le gaz post-opération, car les bundlers peuvent sous-estimer ces coûts.

En pratique : estimez via le même chemin portefeuille, paymaster et bundler que vous utiliserez pour diffuser. Ne réutilisez pas un chiffre provenant d’une transaction ordinaire.

Erreurs d’estimation courantes

• Afficher un seul chiffre sans contexte. Les utilisateurs devraient voir les unités, le prix et un maximum.
• Utiliser la limite maximale du portefeuille comme frais attendus. La limite est un plafond. La multiplier par le prix surestime les frais probables.
• Estimer une fois et signer plus tard. Les prix et l’état des contrats évoluent. Re-simulez juste avant de signer.
• Appliquer les hypothèses d’Ethereum mainnet à un rollup. Vous manquerez la composante de données de la couche 1.
• Ignorer les échecs. Une transaction annulée coûte quand même du gaz. Simulez d’abord et remontez les erreurs avant que l’utilisateur ne paie.
• Négliger la piste d’audit. Sans enregistrements, la finance ne peut pas rapprocher les devis de ce qui a été réellement facturé.

Ce qu’il faut enregistrer pour les paiements

Si votre application déplace de l’argent, traitez l’estimation comme une donnée à conserver. Pour chaque transaction, stockez :

• la chaîne et le contexte de bloc
• l’estimation de gaz et la limite de gaz que vous avez définie
• les champs de frais utilisés (frais de base, pourboire, frais max)
• l’horodatage de l’estimation
• les frais finaux du reçu de transaction

Comparer le devis au reçu vous indique dans quelle mesure vos estimations dérivent et si vos marges sont trop serrées ou trop larges. Cela donne aussi au support une réponse directe quand un client demande pourquoi des frais ont changé.

Notre point de vue

La plupart des équipes avec qui nous discutons ne peinent pas sur la formule. Elles peinent sur tout ce qui l’entoure : faire tourner des nœuds pour plusieurs réseaux, décoder les réponses brutes, gérer les particularités de frais de chaque chaîne, et maintenir tout cela cohérent au fil des évolutions des chaînes.

Nous avons construit Chaingateway pour combler cet écart. L’idée est une API REST unique sur des chaînes telles qu’Ethereum, Tron, Bitcoin, Solana, Polygon, BNB Chain et Arbitrum, avec estimation automatique du gaz et données pré-décodées, pour que votre équipe n’ait pas à maintenir un parcours de frais séparé par réseau. Notre vision est que l’estimation des frais devrait être une étape intégrée de l’envoi d’une transaction, et non un projet annexe que vos développeurs reconstruisent pour chaque chaîne.

Nous pensons aussi qu’un devis doit être honnête. Affichez l’estimation comme une estimation, gardez les frais du reçu à côté, et laissez les chiffres vous montrer où placer vos marges.

— Bitblade

Évitez la plomberie de frais par chaîne

Si vous construisez des portefeuilles, des paiements ou des flux de dépôt, notre API Blockchain vous permet de créer des portefeuilles, d’envoyer des transferts de tokens avec estimation automatique du gaz, et de récupérer des données de transaction décodées via une seule interface. Associez-la aux Webhooks Chaingateway pour recevoir des notifications en temps réel à l’arrivée des paiements, au lieu de faire du polling. Les requêtes sont signées HMAC.

Les plans sont facturés par mois ou par an, et vous pouvez voir chaque niveau sur la page de tarification :

Plan	Mensuel	Annuel
Plus	49 EUR par mois	490 EUR par an
Pro	99 EUR par mois	990 EUR par an
Premium	249 EUR par mois	2490 EUR par an
Enterprise	499 EUR par mois	4990 EUR par an

Vous développez sur Arbitrum ? Découvrez comment envoyer des jetons ERC-20 sur la couche 2 avec un seul appel REST. Pour comprendre l’ETH, le gas et les jetons ERC-20, notre présentation d’Ethereum est un bon point de départ.

Sources

• Ethereum gas and fees: technical overview, ethereum.org
• How to estimate the gas fee, MetaMask Help Center
• How gas fees, limits, and network fees work, MetaMask Help Center
• How to estimate gas in Arbitrum, Arbitrum docs
• ERC-7677: Paymaster Web Service Capability
• EIP-1559, Ethereum Improvement Proposals

Recommandés

• Track Live Arbitrum Gas Fees With NodeInterface and Nitro’s Formula
• Ethereum Overview: ETH, Gas Fees and ERC-20 Tokens Explained
• TRON Fee Calculator for USDT-TRC20 Transfers
• TRON Fees: Ultimate Guide + Free Calculator