[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-6-gestion-memoire-yul-mstore-mload":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-000000000106","a0000000-0000-0000-0000-000000000062","Deep EVM #6 : Gestion mémoire en Yul — mstore, mload et pointeur de mémoire libre","deep-evm-6-gestion-memoire-yul-mstore-mload","Maîtrisez la gestion mémoire EVM en Yul : opérations mstore\u002Fmload, pointeur de mémoire libre, expansion mémoire et patterns d'allocation pour smart contracts optimisés.","## La mémoire dans l'EVM\n\nLa mémoire EVM est un tableau d'octets linéaire qui commence vide et s'étend dynamiquement. Elle est volatile — effacée à la fin de chaque contexte d'appel. L'accès se fait par mots de 32 octets avec mstore\u002Fmload, ou octet par octet avec mstore8.\n\n## mstore et mload en détail\n\n### mstore(offset, value)\n\nÉcrit un mot de 32 octets à la position `offset` en mémoire :\n\n```yul\nmstore(0x00, 0x42)  \u002F\u002F Écrit 0x42 (rembourré à 32 octets) à la position 0\nmstore(0x20, 0xff)  \u002F\u002F Écrit 0xff à la position 32\n```\n\nImportant : mstore écrit toujours 32 octets. `mstore(0x00, 1)` écrit 31 octets de zéros suivis de 0x01.\n\n### mload(offset)\n\nLit 32 octets depuis la position `offset` :\n\n```yul\nlet value := mload(0x00)  \u002F\u002F Lit memory[0x00..0x20]\n```\n\n## Le pointeur de mémoire libre\n\nSolidity stocke le pointeur de mémoire libre à `0x40`. C'est un compteur qui indique où commence la mémoire inutilisée.\n\n```yul\nfunction allocate(size) -> ptr {\n    ptr := mload(0x40)              \u002F\u002F Position actuelle\n    mstore(0x40, add(ptr, size))    \u002F\u002F Avancer le pointeur\n}\n```\n\nCe pattern est l'équivalent EVM de `malloc()`. En Yul pur, vous pouvez ignorer ce pointeur et gérer la mémoire manuellement, mais si vous mélangez Yul et Solidity, respectez-le.\n\n## Expansion mémoire et coûts\n\nLa mémoire s'étend automatiquement quand vous écrivez au-delà de sa taille actuelle. Le coût suit une formule quadratique :\n\n```\ncout_gas = 3 * mots + mots^2 \u002F 512\n```\n\nOù `mots = ceil(taille_max_accédée \u002F 32)`.\n\nPour les petites allocations (\u003C 724 octets), c'est essentiellement 3 gas par mot. Au-delà, le coût quadratique explose rapidement. C'est pourquoi vous ne devez jamais allouer de grandes zones mémoire sans nécessité.\n\n## Patterns d'utilisation mémoire\n\n### Pattern 1 : Zone scratch (0x00-0x3f)\n\nLes 64 premiers octets sont l'espace scratch de Solidity. En Yul pur, utilisez-les pour les calculs temporaires :\n\n```yul\n\u002F\u002F Hacher une valeur\nmstore(0x00, value)\nlet hash := keccak256(0x00, 0x20)\n```\n\n### Pattern 2 : Construire des données de retour\n\n```yul\n\u002F\u002F Retourner un uint256\nmstore(0x00, result)\nreturn(0x00, 0x20)\n```\n\n### Pattern 3 : Préparer un appel externe\n\n```yul\n\u002F\u002F Préparer calldata pour transfer(address,uint256)\nmstore(0x00, 0xa9059cbb)                    \u002F\u002F Sélecteur\nmstore(0x04, recipient)                       \u002F\u002F Adresse\nmstore(0x24, amount)                          \u002F\u002F Montant\nlet success := call(gas(), token, 0, 0x00, 0x44, 0x00, 0x20)\n```\n\n### Pattern 4 : Copier calldata en mémoire\n\n```yul\n\u002F\u002F Copier les arguments de la transaction\ncalldatacopy(0x00, 0x04, 0x40)  \u002F\u002F Copier 64 octets depuis la position 4 du calldata\nlet arg1 := mload(0x00)\nlet arg2 := mload(0x20)\n```\n\n## Pièges courants\n\n1. **Écraser 0x40** — Si vous utilisez Yul inline dans Solidity, n'écrasez jamais le pointeur de mémoire libre.\n2. **Chevauchement mémoire** — mstore écrit 32 octets ; écrire à des positions non alignées peut écraser des données adjacentes.\n3. **Expansion coûteuse** — Accéder à une position mémoire très élevée coûte cher même si vous n'utilisez pas les octets intermédiaires.\n\n## Conclusion\n\nLa gestion mémoire en Yul est un outil puissant mais demande de la rigueur. Comprendre mstore\u002Fmload, le pointeur de mémoire libre et les coûts d'expansion vous permet d'écrire des smart contracts significativement plus efficaces en gas.\n\nDans le prochain article, nous couvrirons les boucles et conditionnels efficaces en gas dans Yul.","\u003Ch2 id=\"la-m-moire-dans-l-evm\">La mémoire dans l’EVM\u003C\u002Fh2>\n\u003Cp>La mémoire EVM est un tableau d’octets linéaire qui commence vide et s’étend dynamiquement. Elle est volatile — effacée à la fin de chaque contexte d’appel. L’accès se fait par mots de 32 octets avec mstore\u002Fmload, ou octet par octet avec mstore8.\u003C\u002Fp>\n\u003Ch2 id=\"mstore-et-mload-en-d-tail\">mstore et mload en détail\u003C\u002Fh2>\n\u003Ch3>mstore(offset, value)\u003C\u002Fh3>\n\u003Cp>Écrit un mot de 32 octets à la position \u003Ccode>offset\u003C\u002Fcode> en mémoire :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yul\">mstore(0x00, 0x42)  \u002F\u002F Écrit 0x42 (rembourré à 32 octets) à la position 0\nmstore(0x20, 0xff)  \u002F\u002F Écrit 0xff à la position 32\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Important : mstore écrit toujours 32 octets. \u003Ccode>mstore(0x00, 1)\u003C\u002Fcode> écrit 31 octets de zéros suivis de 0x01.\u003C\u002Fp>\n\u003Ch3>mload(offset)\u003C\u002Fh3>\n\u003Cp>Lit 32 octets depuis la position \u003Ccode>offset\u003C\u002Fcode> :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yul\">let value := mload(0x00)  \u002F\u002F Lit memory[0x00..0x20]\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"le-pointeur-de-m-moire-libre\">Le pointeur de mémoire libre\u003C\u002Fh2>\n\u003Cp>Solidity stocke le pointeur de mémoire libre à \u003Ccode>0x40\u003C\u002Fcode>. C’est un compteur qui indique où commence la mémoire inutilisée.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yul\">function allocate(size) -> ptr {\n    ptr := mload(0x40)              \u002F\u002F Position actuelle\n    mstore(0x40, add(ptr, size))    \u002F\u002F Avancer le pointeur\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Ce pattern est l’équivalent EVM de \u003Ccode>malloc()\u003C\u002Fcode>. En Yul pur, vous pouvez ignorer ce pointeur et gérer la mémoire manuellement, mais si vous mélangez Yul et Solidity, respectez-le.\u003C\u002Fp>\n\u003Ch2 id=\"expansion-m-moire-et-co-ts\">Expansion mémoire et coûts\u003C\u002Fh2>\n\u003Cp>La mémoire s’étend automatiquement quand vous écrivez au-delà de sa taille actuelle. Le coût suit une formule quadratique :\u003C\u002Fp>\n\u003Cpre>\u003Ccode>cout_gas = 3 * mots + mots^2 \u002F 512\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Où \u003Ccode>mots = ceil(taille_max_accédée \u002F 32)\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>Pour les petites allocations (< 724 octets), c’est essentiellement 3 gas par mot. Au-delà, le coût quadratique explose rapidement. C’est pourquoi vous ne devez jamais allouer de grandes zones mémoire sans nécessité.\u003C\u002Fp>\n\u003Ch2 id=\"patterns-d-utilisation-m-moire\">Patterns d’utilisation mémoire\u003C\u002Fh2>\n\u003Ch3>Pattern 1 : Zone scratch (0x00-0x3f)\u003C\u002Fh3>\n\u003Cp>Les 64 premiers octets sont l’espace scratch de Solidity. En Yul pur, utilisez-les pour les calculs temporaires :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yul\">\u002F\u002F Hacher une valeur\nmstore(0x00, value)\nlet hash := keccak256(0x00, 0x20)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Pattern 2 : Construire des données de retour\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-yul\">\u002F\u002F Retourner un uint256\nmstore(0x00, result)\nreturn(0x00, 0x20)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Pattern 3 : Préparer un appel externe\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-yul\">\u002F\u002F Préparer calldata pour transfer(address,uint256)\nmstore(0x00, 0xa9059cbb)                    \u002F\u002F Sélecteur\nmstore(0x04, recipient)                       \u002F\u002F Adresse\nmstore(0x24, amount)                          \u002F\u002F Montant\nlet success := call(gas(), token, 0, 0x00, 0x44, 0x00, 0x20)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Pattern 4 : Copier calldata en mémoire\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-yul\">\u002F\u002F Copier les arguments de la transaction\ncalldatacopy(0x00, 0x04, 0x40)  \u002F\u002F Copier 64 octets depuis la position 4 du calldata\nlet arg1 := mload(0x00)\nlet arg2 := mload(0x20)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"pi-ges-courants\">Pièges courants\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>Écraser 0x40\u003C\u002Fstrong> — Si vous utilisez Yul inline dans Solidity, n’écrasez jamais le pointeur de mémoire libre.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Chevauchement mémoire\u003C\u002Fstrong> — mstore écrit 32 octets ; écrire à des positions non alignées peut écraser des données adjacentes.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Expansion coûteuse\u003C\u002Fstrong> — Accéder à une position mémoire très élevée coûte cher même si vous n’utilisez pas les octets intermédiaires.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"conclusion\">Conclusion\u003C\u002Fh2>\n\u003Cp>La gestion mémoire en Yul est un outil puissant mais demande de la rigueur. Comprendre mstore\u002Fmload, le pointeur de mémoire libre et les coûts d’expansion vous permet d’écrire des smart contracts significativement plus efficaces en gas.\u003C\u002Fp>\n\u003Cp>Dans le prochain article, nous couvrirons les boucles et conditionnels efficaces en gas dans Yul.\u003C\u002Fp>\n","fr","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:28.882345Z","Maîtrisez la gestion mémoire EVM en Yul : mstore\u002Fmload, pointeur de mémoire libre, coûts d'expansion et patterns d'allocation.","Yul gestion mémoire EVM",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-000000000018","Yul","yul","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"]