[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-3-comprendre-gas-couts-contrat":3},{"article":4,"author":54},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":34,"related_articles":35},"d6000000-0000-0000-0000-000000000103","a0000000-0000-0000-0000-000000000062","Deep EVM #3 : Comprendre le gas — Pourquoi votre contrat coûte ce qu'il coûte","deep-evm-3-comprendre-gas-couts-contrat","Analyse détaillée de la tarification du gas dans l'EVM : barème des opcodes, EIP-1559, frais de base, frais de priorité, estimation du gas et techniques d'optimisation.","## Pourquoi le gas existe\n\nLe gas résout deux problèmes fondamentaux dans un système de calcul décentralisé :\n\n1. **Le problème de l'arrêt** — Il est mathématiquement impossible de déterminer si un programme arbitraire se terminera. Le gas impose une limite supérieure : si vous manquez de gas, l'exécution s'arrête.\n2. **La tarification des ressources** — Chaque nœud du réseau doit exécuter votre transaction. Le gas tarifie équitablement le calcul, le stockage et la bande passante que vous consommez.\n\n## EIP-1559 : le marché du gas moderne\n\nDepuis la mise à jour London (août 2021), Ethereum utilise un mécanisme de frais à deux composantes :\n\n- **Frais de base (baseFee)** — Déterminé algorithmiquement par le protocole. Augmente quand les blocs sont remplis à plus de 50 %, diminue quand ils sont en dessous. Ce montant est brûlé.\n- **Frais de priorité (tip)** — Pourboire payé directement au validateur. Incite l'inclusion de votre transaction.\n\n```\ncoût_total = gas_utilisé * (baseFee + maxPriorityFeePerGas)\n```\n\nVotre transaction spécifie `maxFeePerGas` (maximum que vous êtes prêt à payer) et `maxPriorityFeePerGas` (pourboire). Si baseFee + tip dépasse maxFeePerGas, la transaction attend dans le mempool.\n\n## Anatomie du coût d'une transaction\n\nDécomposons le coût total d'un transfert ERC-20 :\n\n1. **Gas intrinsèque** : 21 000 gas (coût fixe de toute transaction)\n2. **Calldata** : 4 gas par octet nul, 16 par non-nul. Un appel `transfer(address,uint256)` encode ~68 octets.\n3. **Exécution** : SLOAD pour les soldes (2100 froid), SSTORE pour mettre à jour deux soldes (5000-22100 chacun), LOG pour émettre l'événement Transfer.\n4. **Overhead du contrat** : Dispatch de fonction, vérification SafeMath, encodage ABI.\n\nTotal typique : ~65 000 gas pour un transfert ERC-20 standard.\n\n## Techniques d'optimisation du gas\n\n### 1. Packing de variables de stockage\n\nSolidity empaquette les variables de stockage qui tiennent dans un seul slot de 32 octets :\n\n```solidity\n\u002F\u002F Mauvais : 3 slots (3 * SLOAD = 6300 gas froid)\nuint256 a;\nuint256 b;\nuint256 c;\n\n\u002F\u002F Bon : 1 slot (1 * SLOAD = 2100 gas froid)\nuint128 a;\nuint64 b;\nuint64 c;\n```\n\n### 2. Utiliser calldata au lieu de memory\n\nPour les paramètres de fonction que vous ne modifiez pas :\n\n```solidity\n\u002F\u002F Coûteux : copie les données en mémoire\nfunction process(uint256[] memory data) external { ... }\n\n\u002F\u002F Économique : lit directement depuis calldata\nfunction process(uint256[] calldata data) external { ... }\n```\n\n### 3. Erreurs personnalisées vs require avec message\n\n```solidity\n\u002F\u002F Coûteux : stocke la chaîne dans le bytecode\nrequire(balance >= amount, \"Insufficient balance\");\n\n\u002F\u002F Économique : seulement 4 octets de sélecteur\nerror InsufficientBalance();\nif (balance \u003C amount) revert InsufficientBalance();\n```\n\n### 4. Opérations non vérifiées\n\n```solidity\n\u002F\u002F Quand vous savez que le débordement est impossible :\nunchecked {\n    i++; \u002F\u002F Économise ~80 gas par itération\n}\n```\n\n## Gas et MEV\n\nPour les bots MEV, chaque unité de gas économisée est un gain direct de profit. Un bot d'arbitrage qui utilise 200 000 gas au lieu de 300 000 peut surenchérir ses concurrents avec un frais de priorité plus élevé tout en restant rentable.\n\nLes techniques avancées incluent :\n- Écrire en Yul ou Huff pour un contrôle total\n- Préchauffer les slots avec des listes d'accès EIP-2930\n- Utiliser des tables de saut au lieu de dispatchers if-else\n- Minimiser les appels inter-contrats\n\n## Conclusion\n\nLe gas est le langage économique de l'EVM. Comprendre pourquoi chaque opération coûte ce qu'elle coûte — et comment réduire systématiquement ces coûts — est une compétence fondamentale pour tout développeur de smart contracts.\n\nDans le prochain article, nous explorerons les primitives de sécurité de l'EVM : msg.sender, le contrôle d'accès et la protection contre la réentrance.","\u003Ch2 id=\"pourquoi-le-gas-existe\">Pourquoi le gas existe\u003C\u002Fh2>\n\u003Cp>Le gas résout deux problèmes fondamentaux dans un système de calcul décentralisé :\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Le problème de l’arrêt\u003C\u002Fstrong> — Il est mathématiquement impossible de déterminer si un programme arbitraire se terminera. Le gas impose une limite supérieure : si vous manquez de gas, l’exécution s’arrête.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>La tarification des ressources\u003C\u002Fstrong> — Chaque nœud du réseau doit exécuter votre transaction. Le gas tarifie équitablement le calcul, le stockage et la bande passante que vous consommez.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"eip-1559-le-march-du-gas-moderne\">EIP-1559 : le marché du gas moderne\u003C\u002Fh2>\n\u003Cp>Depuis la mise à jour London (août 2021), Ethereum utilise un mécanisme de frais à deux composantes :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Frais de base (baseFee)\u003C\u002Fstrong> — Déterminé algorithmiquement par le protocole. Augmente quand les blocs sont remplis à plus de 50 %, diminue quand ils sont en dessous. Ce montant est brûlé.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Frais de priorité (tip)\u003C\u002Fstrong> — Pourboire payé directement au validateur. Incite l’inclusion de votre transaction.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode>coût_total = gas_utilisé * (baseFee + maxPriorityFeePerGas)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Votre transaction spécifie \u003Ccode>maxFeePerGas\u003C\u002Fcode> (maximum que vous êtes prêt à payer) et \u003Ccode>maxPriorityFeePerGas\u003C\u002Fcode> (pourboire). Si baseFee + tip dépasse maxFeePerGas, la transaction attend dans le mempool.\u003C\u002Fp>\n\u003Ch2 id=\"anatomie-du-co-t-d-une-transaction\">Anatomie du coût d’une transaction\u003C\u002Fh2>\n\u003Cp>Décomposons le coût total d’un transfert ERC-20 :\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Gas intrinsèque\u003C\u002Fstrong> : 21 000 gas (coût fixe de toute transaction)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Calldata\u003C\u002Fstrong> : 4 gas par octet nul, 16 par non-nul. Un appel \u003Ccode>transfer(address,uint256)\u003C\u002Fcode> encode ~68 octets.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Exécution\u003C\u002Fstrong> : SLOAD pour les soldes (2100 froid), SSTORE pour mettre à jour deux soldes (5000-22100 chacun), LOG pour émettre l’événement Transfer.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Overhead du contrat\u003C\u002Fstrong> : Dispatch de fonction, vérification SafeMath, encodage ABI.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Total typique : ~65 000 gas pour un transfert ERC-20 standard.\u003C\u002Fp>\n\u003Ch2 id=\"techniques-d-optimisation-du-gas\">Techniques d’optimisation du gas\u003C\u002Fh2>\n\u003Ch3>1. Packing de variables de stockage\u003C\u002Fh3>\n\u003Cp>Solidity empaquette les variables de stockage qui tiennent dans un seul slot de 32 octets :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Mauvais : 3 slots (3 * SLOAD = 6300 gas froid)\nuint256 a;\nuint256 b;\nuint256 c;\n\n\u002F\u002F Bon : 1 slot (1 * SLOAD = 2100 gas froid)\nuint128 a;\nuint64 b;\nuint64 c;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>2. Utiliser calldata au lieu de memory\u003C\u002Fh3>\n\u003Cp>Pour les paramètres de fonction que vous ne modifiez pas :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Coûteux : copie les données en mémoire\nfunction process(uint256[] memory data) external { ... }\n\n\u002F\u002F Économique : lit directement depuis calldata\nfunction process(uint256[] calldata data) external { ... }\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>3. Erreurs personnalisées vs require avec message\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Coûteux : stocke la chaîne dans le bytecode\nrequire(balance >= amount, \"Insufficient balance\");\n\n\u002F\u002F Économique : seulement 4 octets de sélecteur\nerror InsufficientBalance();\nif (balance < amount) revert InsufficientBalance();\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>4. Opérations non vérifiées\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Quand vous savez que le débordement est impossible :\nunchecked {\n    i++; \u002F\u002F Économise ~80 gas par itération\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"gas-et-mev\">Gas et MEV\u003C\u002Fh2>\n\u003Cp>Pour les bots MEV, chaque unité de gas économisée est un gain direct de profit. Un bot d’arbitrage qui utilise 200 000 gas au lieu de 300 000 peut surenchérir ses concurrents avec un frais de priorité plus élevé tout en restant rentable.\u003C\u002Fp>\n\u003Cp>Les techniques avancées incluent :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Écrire en Yul ou Huff pour un contrôle total\u003C\u002Fli>\n\u003Cli>Préchauffer les slots avec des listes d’accès EIP-2930\u003C\u002Fli>\n\u003Cli>Utiliser des tables de saut au lieu de dispatchers if-else\u003C\u002Fli>\n\u003Cli>Minimiser les appels inter-contrats\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"conclusion\">Conclusion\u003C\u002Fh2>\n\u003Cp>Le gas est le langage économique de l’EVM. Comprendre pourquoi chaque opération coûte ce qu’elle coûte — et comment réduire systématiquement ces coûts — est une compétence fondamentale pour tout développeur de smart contracts.\u003C\u002Fp>\n\u003Cp>Dans le prochain article, nous explorerons les primitives de sécurité de l’EVM : msg.sender, le contrôle d’accès et la protection contre la réentrance.\u003C\u002Fp>\n","fr","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:28.865860Z","Analyse détaillée de la tarification du gas EVM : barème des opcodes, EIP-1559, estimation et techniques d'optimisation du gas.","gas EVM optimisation",null,"index, follow",[21,26,30],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000020","Gas Optimization","gas-optimization",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000014","Solidity","solidity","Blockchain",[36,42,48],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":34,"published_at":41},"d0000000-0000-0000-0000-000000000608","La couche d'interoperabilite Ethereum : comment 55+ L2 deviennent une seule chaine","couche-interoperabilite-ethereum-55-l2-deviennent-une-seule-chaine","Ethereum compte 55+ rollups Layer 2, fragmentant la liquidite et l'experience utilisateur. La couche d'interoperabilite Ethereum — combinant messagerie cross-rollup, sequenceurs partages et based rollups — vise a les unifier en un reseau composable unique.","2026-03-28T10:44:45.078068Z",{"id":43,"title":44,"slug":45,"excerpt":46,"locale":12,"category_name":34,"published_at":47},"d0000000-0000-0000-0000-000000000607","Les preuves ZK au-dela des rollups : l'inference IA verifiable sur Ethereum","preuves-zk-au-dela-des-rollups-inference-ia-verifiable-ethereum","Les preuves a connaissance nulle ne sont plus un simple outil de scalabilite. En 2026, zkML permet l'inference IA verifiable on-chain, les ZK coprocesseurs deplacent le calcul lourd hors chaine avec verification on-chain, et de nouveaux systemes de preuve comme SP1 et Jolt rendent tout cela pratique.","2026-03-28T10:44:45.071974Z",{"id":49,"title":50,"slug":51,"excerpt":52,"locale":12,"category_name":34,"published_at":53},"d0000000-0000-0000-0000-000000000584","EIP-7702 en pratique : construire des flux de comptes intelligents apres Pectra","eip-7702-en-pratique-construire-flux-comptes-intelligents-apres-pectra","EIP-7702 permet a tout EOA Ethereum d'agir temporairement comme un contrat intelligent dans une seule transaction. Voici comment implementer les transactions par lots, le parrainage de gas et la recuperation sociale avec la nouvelle primitive d'account abstraction.","2026-03-28T10:44:43.586053Z",{"id":13,"name":55,"slug":56,"bio":57,"photo_url":18,"linkedin":18,"role":58,"created_at":59,"updated_at":59},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]