[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-12-huff-avance-execution-adaptative":3},{"article":4,"author":59},{"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":38,"related_articles":39},"d6000000-0000-0000-0000-000000000112","a0000000-0000-0000-0000-000000000062","Deep EVM #12 : Huff avancé — Exécution adaptative et calcul on-chain","deep-evm-12-huff-avance-execution-adaptative","Patterns Huff avancés pour les contrats de production : exécution adaptative basée sur l'état de la blockchain, authentification multi-opérateur, astuces de disposition mémoire et optimisation extrême du gas.","## Au-delà des bases\n\nLes trois articles précédents ont couvert les fondamentaux de Huff : macros, gestion de pile et tables de saut. Cet article explore les techniques avancées que les développeurs de bots MEV et de protocoles DeFi utilisent en production.\n\n## Exécution adaptative\n\nL'exécution adaptative signifie que le contrat ajuste son comportement en fonction de l'état actuel de la blockchain — prix du gas, numéro de bloc, état des pools de liquidité — plutôt que de suivre un chemin d'exécution fixe.\n\n### Branchement basé sur le prix du gas\n\n```huff\n#define macro ADAPTIVE_EXECUTION() = takes(0) returns(0) {\n    gasprice                \u002F\u002F [gasPrice]\n    0x174876E800            \u002F\u002F [100 gwei, gasPrice]\n    gt                      \u002F\u002F [gasPrice > 100 gwei?]\n    expensive_gas jumpi\n\n    \u002F\u002F Chemin gas normal — exécution complète\n    FULL_SWAP()\n    stop\n\n    expensive_gas:\n    \u002F\u002F Chemin gas élevé — seulement les opérations rentables\n    MINIMAL_SWAP()\n    stop\n}\n```\n\nCe pattern est crucial pour les bots MEV : quand le gas est élevé, seules les opportunités les plus rentables valent la peine d'être poursuivies.\n\n### Vérification d'état on-chain\n\nAvant d'exécuter un swap d'arbitrage, vérifiez que les réserves du pool n'ont pas changé depuis votre simulation :\n\n```huff\n#define macro CHECK_RESERVES() = takes(2) returns(0) {\n    \u002F\u002F takes: [expected_reserve0, expected_reserve1]\n    \u002F\u002F Appeler getReserves() sur le pool\n    0x0902f1ac              \u002F\u002F selector getReserves()\n    0x00 mstore\n    0x00 0x00 0x04 0x00     \u002F\u002F retOffset, retSize, argsSize, argsOffset\n    [POOL] gas staticcall   \u002F\u002F [success]\n    iszero revert_path jumpi\n\n    \u002F\u002F Comparer avec les réserves attendues\n    0x00 mload              \u002F\u002F [actual_reserve0]\n    dup3                    \u002F\u002F [expected_reserve0, actual_reserve0]\n    eq iszero revert_path jumpi\n\n    0x20 mload              \u002F\u002F [actual_reserve1]\n    dup3                    \u002F\u002F [expected_reserve1, actual_reserve1]\n    eq iszero revert_path jumpi\n\n    \u002F\u002F Les réserves correspondent — continuer\n    pop pop                 \u002F\u002F nettoyer la pile\n    continue jump\n\n    revert_path:\n        0x00 0x00 revert    \u002F\u002F Annuler — les conditions ont changé\n    continue:\n}\n```\n\n## Authentification multi-opérateur\n\nPour les bots MEV opérés par plusieurs adresses :\n\n```huff\n#define macro IS_AUTHORIZED() = takes(0) returns(0) {\n    caller                      \u002F\u002F [caller]\n    dup1 [OPERATOR_1] eq        \u002F\u002F [isOp1?, caller]\n    authorized jumpi\n    dup1 [OPERATOR_2] eq        \u002F\u002F [isOp2?, caller]\n    authorized jumpi\n    [OPERATOR_3] eq             \u002F\u002F [isOp3?]\n    authorized jumpi\n    0x00 0x00 revert\n\n    authorized:\n    pop                         \u002F\u002F nettoyer la pile\n}\n```\n\nChaque vérification supplémentaire coûte environ 15 gas (PUSH20 + EQ + JUMPI). Pour 3 opérateurs, c'est un overhead négligeable.\n\n## Astuces de disposition mémoire\n\n### Réutilisation de zones mémoire\n\nDans un contrat Huff, vous n'avez pas de pointeur de mémoire libre. Planifiez votre disposition mémoire comme un développeur embarqué :\n\n```huff\n\u002F\u002F Zones mémoire du contrat\n\u002F\u002F 0x00-0x1f : espace scratch pour keccak256\n\u002F\u002F 0x20-0x3f : espace scratch pour les retours\n\u002F\u002F 0x40-0x7f : zone de calldata pour les appels externes\n\u002F\u002F 0x80-0xbf : zone de stockage temporaire pour les valeurs de pile profondes\n```\n\nEn réutilisant les mêmes zones mémoire, vous évitez l'expansion mémoire et les coûts quadratiques associés.\n\n### Encodage compact des données\n\n```huff\n\u002F\u002F Au lieu de stocker des adresses complètes de 32 octets :\n\u002F\u002F Utilisez les 20 octets réels et compactez 2 adresses dans 40 octets\n\u002F\u002F au lieu de 64 octets\nmstore(0x00, shl(96, address1))  \u002F\u002F Adresse 1 aux octets 0-19\nmstore(0x14, shl(96, address2))  \u002F\u002F Adresse 2 aux octets 20-39\n```\n\n## Optimisation extrême : chaque octet compte\n\n### Remplacer les zéros par RETURNDATASIZE\n\nAvant le premier CALL, `RETURNDATASIZE` retourne 0 et ne coûte que 2 gas au lieu des 3 gas de `PUSH1 0x00` :\n\n```huff\n\u002F\u002F Au lieu de :\n0x00            \u002F\u002F 3 gas, 2 octets\n\n\u002F\u002F Utilisez (avant le premier CALL) :\nreturndatasize  \u002F\u002F 2 gas, 1 octet\n```\n\nÉconomie : 1 gas + 1 octet de bytecode. Sur un contrat avec 50 utilisations de zéro, c'est 50 gas et 50 octets.\n\n### SELFBALANCE au lieu de BALANCE\n\n```huff\n\u002F\u002F Au lieu de :\naddress balance  \u002F\u002F 2 opcodes, 2605 gas (froid)\n\n\u002F\u002F Utilisez :\nselfbalance      \u002F\u002F 1 opcode, 5 gas\n```\n\n## Conclusion\n\nLes techniques avancées de Huff — exécution adaptative, disposition mémoire planifiée, et micro-optimisations au niveau de l'octet — séparent les contrats de production des exercices d'apprentissage. Dans les prochains articles, nous passerons au MEV : ce qu'il est, comment trouver des opportunités d'arbitrage, et comment construire un pipeline de simulation.","\u003Ch2 id=\"au-del-des-bases\">Au-delà des bases\u003C\u002Fh2>\n\u003Cp>Les trois articles précédents ont couvert les fondamentaux de Huff : macros, gestion de pile et tables de saut. Cet article explore les techniques avancées que les développeurs de bots MEV et de protocoles DeFi utilisent en production.\u003C\u002Fp>\n\u003Ch2 id=\"ex-cution-adaptative\">Exécution adaptative\u003C\u002Fh2>\n\u003Cp>L’exécution adaptative signifie que le contrat ajuste son comportement en fonction de l’état actuel de la blockchain — prix du gas, numéro de bloc, état des pools de liquidité — plutôt que de suivre un chemin d’exécution fixe.\u003C\u002Fp>\n\u003Ch3>Branchement basé sur le prix du gas\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define macro ADAPTIVE_EXECUTION() = takes(0) returns(0) {\n    gasprice                \u002F\u002F [gasPrice]\n    0x174876E800            \u002F\u002F [100 gwei, gasPrice]\n    gt                      \u002F\u002F [gasPrice > 100 gwei?]\n    expensive_gas jumpi\n\n    \u002F\u002F Chemin gas normal — exécution complète\n    FULL_SWAP()\n    stop\n\n    expensive_gas:\n    \u002F\u002F Chemin gas élevé — seulement les opérations rentables\n    MINIMAL_SWAP()\n    stop\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Ce pattern est crucial pour les bots MEV : quand le gas est élevé, seules les opportunités les plus rentables valent la peine d’être poursuivies.\u003C\u002Fp>\n\u003Ch3>Vérification d’état on-chain\u003C\u002Fh3>\n\u003Cp>Avant d’exécuter un swap d’arbitrage, vérifiez que les réserves du pool n’ont pas changé depuis votre simulation :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define macro CHECK_RESERVES() = takes(2) returns(0) {\n    \u002F\u002F takes: [expected_reserve0, expected_reserve1]\n    \u002F\u002F Appeler getReserves() sur le pool\n    0x0902f1ac              \u002F\u002F selector getReserves()\n    0x00 mstore\n    0x00 0x00 0x04 0x00     \u002F\u002F retOffset, retSize, argsSize, argsOffset\n    [POOL] gas staticcall   \u002F\u002F [success]\n    iszero revert_path jumpi\n\n    \u002F\u002F Comparer avec les réserves attendues\n    0x00 mload              \u002F\u002F [actual_reserve0]\n    dup3                    \u002F\u002F [expected_reserve0, actual_reserve0]\n    eq iszero revert_path jumpi\n\n    0x20 mload              \u002F\u002F [actual_reserve1]\n    dup3                    \u002F\u002F [expected_reserve1, actual_reserve1]\n    eq iszero revert_path jumpi\n\n    \u002F\u002F Les réserves correspondent — continuer\n    pop pop                 \u002F\u002F nettoyer la pile\n    continue jump\n\n    revert_path:\n        0x00 0x00 revert    \u002F\u002F Annuler — les conditions ont changé\n    continue:\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"authentification-multi-op-rateur\">Authentification multi-opérateur\u003C\u002Fh2>\n\u003Cp>Pour les bots MEV opérés par plusieurs adresses :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define macro IS_AUTHORIZED() = takes(0) returns(0) {\n    caller                      \u002F\u002F [caller]\n    dup1 [OPERATOR_1] eq        \u002F\u002F [isOp1?, caller]\n    authorized jumpi\n    dup1 [OPERATOR_2] eq        \u002F\u002F [isOp2?, caller]\n    authorized jumpi\n    [OPERATOR_3] eq             \u002F\u002F [isOp3?]\n    authorized jumpi\n    0x00 0x00 revert\n\n    authorized:\n    pop                         \u002F\u002F nettoyer la pile\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Chaque vérification supplémentaire coûte environ 15 gas (PUSH20 + EQ + JUMPI). Pour 3 opérateurs, c’est un overhead négligeable.\u003C\u002Fp>\n\u003Ch2 id=\"astuces-de-disposition-m-moire\">Astuces de disposition mémoire\u003C\u002Fh2>\n\u003Ch3>Réutilisation de zones mémoire\u003C\u002Fh3>\n\u003Cp>Dans un contrat Huff, vous n’avez pas de pointeur de mémoire libre. Planifiez votre disposition mémoire comme un développeur embarqué :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">\u002F\u002F Zones mémoire du contrat\n\u002F\u002F 0x00-0x1f : espace scratch pour keccak256\n\u002F\u002F 0x20-0x3f : espace scratch pour les retours\n\u002F\u002F 0x40-0x7f : zone de calldata pour les appels externes\n\u002F\u002F 0x80-0xbf : zone de stockage temporaire pour les valeurs de pile profondes\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>En réutilisant les mêmes zones mémoire, vous évitez l’expansion mémoire et les coûts quadratiques associés.\u003C\u002Fp>\n\u003Ch3>Encodage compact des données\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-huff\">\u002F\u002F Au lieu de stocker des adresses complètes de 32 octets :\n\u002F\u002F Utilisez les 20 octets réels et compactez 2 adresses dans 40 octets\n\u002F\u002F au lieu de 64 octets\nmstore(0x00, shl(96, address1))  \u002F\u002F Adresse 1 aux octets 0-19\nmstore(0x14, shl(96, address2))  \u002F\u002F Adresse 2 aux octets 20-39\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"optimisation-extr-me-chaque-octet-compte\">Optimisation extrême : chaque octet compte\u003C\u002Fh2>\n\u003Ch3>Remplacer les zéros par RETURNDATASIZE\u003C\u002Fh3>\n\u003Cp>Avant le premier CALL, \u003Ccode>RETURNDATASIZE\u003C\u002Fcode> retourne 0 et ne coûte que 2 gas au lieu des 3 gas de \u003Ccode>PUSH1 0x00\u003C\u002Fcode> :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">\u002F\u002F Au lieu de :\n0x00            \u002F\u002F 3 gas, 2 octets\n\n\u002F\u002F Utilisez (avant le premier CALL) :\nreturndatasize  \u002F\u002F 2 gas, 1 octet\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Économie : 1 gas + 1 octet de bytecode. Sur un contrat avec 50 utilisations de zéro, c’est 50 gas et 50 octets.\u003C\u002Fp>\n\u003Ch3>SELFBALANCE au lieu de BALANCE\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-huff\">\u002F\u002F Au lieu de :\naddress balance  \u002F\u002F 2 opcodes, 2605 gas (froid)\n\n\u002F\u002F Utilisez :\nselfbalance      \u002F\u002F 1 opcode, 5 gas\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"conclusion\">Conclusion\u003C\u002Fh2>\n\u003Cp>Les techniques avancées de Huff — exécution adaptative, disposition mémoire planifiée, et micro-optimisations au niveau de l’octet — séparent les contrats de production des exercices d’apprentissage. Dans les prochains articles, nous passerons au MEV : ce qu’il est, comment trouver des opportunités d’arbitrage, et comment construire un pipeline de simulation.\u003C\u002Fp>\n","fr","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:29.108772Z","Patterns Huff avancés : exécution adaptative, authentification multi-opérateur, disposition mémoire et optimisation extrême du gas.","huff avancé evm",null,"index, follow",[21,26,30,34],{"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-000000000017","Huff","huff",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000019","MEV","mev",{"id":35,"name":36,"slug":37,"created_at":25},"c0000000-0000-0000-0000-000000000013","Security","security","Blockchain",[40,47,53],{"id":41,"title":42,"slug":43,"excerpt":44,"locale":12,"category_name":45,"published_at":46},"d0000000-0000-0000-0000-000000000677","Pourquoi Bali devient le hub impact-tech d'Asie du Sud-Est en 2026","pourquoi-bali-devient-hub-impact-tech-asie-sud-est-2026","Bali se classe 16e parmi les écosystèmes startups d'Asie du Sud-Est. Avec une concentration croissante de bâtisseurs Web3, de startups IA durables et d'entreprises eco-travel tech, l'île se forge une identité de capitale impact-tech de la région.","Ingénierie","2026-03-28T10:44:49.517126Z",{"id":48,"title":49,"slug":50,"excerpt":51,"locale":12,"category_name":45,"published_at":52},"d0000000-0000-0000-0000-000000000676","Le patchwork de la protection des données ASEAN : checklist de conformité pour les développeurs","patchwork-protection-donnees-asean-checklist-conformite-developpeurs","Sept pays de l'ASEAN disposent désormais de lois complètes sur la protection des données, chacune avec des modèles de consentement, des exigences de localisation et des structures de sanctions différents. Voici une checklist pratique de conformité pour les développeurs.","2026-03-28T10:44:49.504560Z",{"id":54,"title":55,"slug":56,"excerpt":57,"locale":12,"category_name":45,"published_at":58},"d0000000-0000-0000-0000-000000000675","La transformation numérique de 29 milliards de dollars d'Indonesia : opportunités pour les éditeurs de logiciels","transformation-numerique-29-milliards-dollars-indonesia-opportunites-editeurs-logiciels","Le marché des services informatiques d'Indonesia devrait atteindre 29,03 milliards de dollars en 2026, contre 24,37 milliards en 2025. L'infrastructure cloud, l'IA, le e-commerce et les centres de données tirent la croissance la plus rapide d'Asie du Sud-Est.","2026-03-28T10:44:49.469231Z",{"id":13,"name":60,"slug":61,"bio":62,"photo_url":18,"linkedin":18,"role":63,"created_at":64,"updated_at":64},"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"]