[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-2-modele-memoire-pile-stockage-calldata":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-000000000102","a0000000-0000-0000-0000-000000000062","Deep EVM #2 : Modèle mémoire — Pile, mémoire, stockage et calldata","deep-evm-2-modele-memoire-pile-stockage-calldata","Plongée approfondie dans les quatre zones de données de l'EVM — pile, mémoire, stockage et calldata — leurs coûts, comportements et la formule d'expansion mémoire qui surprend les développeurs.","## Les quatre zones de données\n\nL'EVM possède quatre zones distinctes où les données peuvent résider pendant l'exécution d'un contrat. Choisir la bonne zone est l'une des décisions les plus importantes pour l'optimisation du gas.\n\n### 1. La pile\n\nLa pile est la zone de travail principale. Chaque élément fait 32 octets (256 bits). La profondeur maximale est de 1024 éléments. Les opcodes DUP et SWAP ne peuvent atteindre que 16 niveaux de profondeur.\n\nCoût : 3 gas pour la plupart des opérations de pile (PUSH, DUP, SWAP, POP). C'est l'espace le moins cher, mais aussi le plus contraint.\n\n### 2. La mémoire\n\nLa mémoire est un tableau d'octets linéaire, adressable par octet, qui commence vide à chaque contexte d'appel. Elle s'étend dynamiquement lorsque vous écrivez au-delà de sa taille actuelle.\n\nLes opcodes clés : MSTORE (écrire 32 octets), MSTORE8 (écrire 1 octet), MLOAD (lire 32 octets), MSIZE (taille actuelle).\n\n#### La formule d'expansion mémoire\n\nLe coût du gas pour l'expansion mémoire est quadratique :\n\n```\ncout_memoire = 3 * nombre_mots + nombre_mots^2 \u002F 512\n```\n\nPour les petites allocations (\u003C 724 octets), le coût est essentiellement linéaire à 3 gas par mot de 32 octets. Au-delà, le terme quadratique domine rapidement.\n\n### 3. Le stockage\n\nLe stockage est la seule zone persistante — les valeurs survivent entre les transactions. Organisé en paires clé-valeur de 32 octets chacune, mappées à l'adresse du contrat.\n\nC'est de loin la zone la plus chère : SLOAD (2100 gas froid, 100 chaud), SSTORE (22100 gas pour écrire une nouvelle valeur non nulle).\n\n### 4. Calldata\n\nCalldata est une zone en lecture seule contenant les données envoyées avec la transaction. L'accès est bon marché : CALLDATALOAD coûte 3 gas pour lire 32 octets.\n\nEn Solidity, les paramètres de fonction marqués `calldata` (pour les types mémoire) restent dans cette zone et évitent une copie en mémoire.\n\n## Le pointeur de mémoire libre\n\nSolidity maintient un « pointeur de mémoire libre » à la position 0x40. Ce pointeur suit la prochaine position mémoire disponible. Chaque allocation mémoire lit ce pointeur, l'utilise, et le met à jour.\n\n```solidity\nassembly {\n    let ptr := mload(0x40)    \u002F\u002F Lire le pointeur libre\n    mstore(ptr, value)         \u002F\u002F Écrire à la position libre\n    mstore(0x40, add(ptr, 32)) \u002F\u002F Mettre à jour le pointeur\n}\n```\n\nEn Yul et Huff, vous gérez la mémoire manuellement. Vous pouvez ignorer le pointeur libre et utiliser la mémoire à volonté — tant que vous n'écrasez pas des données dont vous avez encore besoin.\n\n## Disposition de la mémoire Solidity\n\nSolidity réserve les premières positions mémoire :\n\n- **0x00-0x3f :** Espace scratch pour le hachage\n- **0x40-0x5f :** Pointeur de mémoire libre\n- **0x60-0x7f :** Slot zéro (utilisé comme valeur initiale pour les tableaux dynamiques)\n- **0x80+ :** Début de la mémoire libre\n\nComprendre cette disposition est essentiel lorsque vous écrivez du Yul inline dans Solidity — si vous écrasez 0x40 accidentellement, l'allocateur mémoire de Solidity produira des résultats corrompus.\n\n## Comparaison des coûts\n\n| Opération | Zone | Gas |\n|-----------|------|-----|\n| PUSH\u002FDUP\u002FSWAP | Pile | 3 |\n| MLOAD\u002FMSTORE | Mémoire | 3 + expansion |\n| CALLDATALOAD | Calldata | 3 |\n| SLOAD (froid) | Stockage | 2100 |\n| SLOAD (chaud) | Stockage | 100 |\n| SSTORE (froid, 0→non-zéro) | Stockage | 22100 |\n\n## Quand utiliser chaque zone\n\n- **Pile :** Valeurs intermédiaires de calcul, compteurs de boucle, résultats temporaires. Limité à 16 de profondeur accessible.\n- **Mémoire :** Données structurées (tableaux, structs), préparation des données de retour, paramètres d'appels inter-contrats.\n- **Stockage :** État persistant du contrat — soldes, propriétaires, mappings.\n- **Calldata :** Données d'entrée en lecture seule de la transaction. Préférez `calldata` à `memory` pour les paramètres de fonction quand c'est possible.\n\n## Conclusion\n\nLes quatre zones de données de l'EVM ne sont pas interchangeables. Chacune a un profil de coût, une durée de vie et des contraintes d'accès distincts. Maîtriser quand utiliser la pile plutôt que la mémoire, quand lire le calldata plutôt que de copier en mémoire, et comment minimiser les accès au stockage — voilà la base de l'optimisation de gas.\n\nDans le prochain article, nous explorerons en détail le gas : pourquoi votre contrat coûte ce qu'il coûte, et comment réduire systématiquement ces coûts.","\u003Ch2 id=\"les-quatre-zones-de-donn-es\">Les quatre zones de données\u003C\u002Fh2>\n\u003Cp>L’EVM possède quatre zones distinctes où les données peuvent résider pendant l’exécution d’un contrat. Choisir la bonne zone est l’une des décisions les plus importantes pour l’optimisation du gas.\u003C\u002Fp>\n\u003Ch3>1. La pile\u003C\u002Fh3>\n\u003Cp>La pile est la zone de travail principale. Chaque élément fait 32 octets (256 bits). La profondeur maximale est de 1024 éléments. Les opcodes DUP et SWAP ne peuvent atteindre que 16 niveaux de profondeur.\u003C\u002Fp>\n\u003Cp>Coût : 3 gas pour la plupart des opérations de pile (PUSH, DUP, SWAP, POP). C’est l’espace le moins cher, mais aussi le plus contraint.\u003C\u002Fp>\n\u003Ch3>2. La mémoire\u003C\u002Fh3>\n\u003Cp>La mémoire est un tableau d’octets linéaire, adressable par octet, qui commence vide à chaque contexte d’appel. Elle s’étend dynamiquement lorsque vous écrivez au-delà de sa taille actuelle.\u003C\u002Fp>\n\u003Cp>Les opcodes clés : MSTORE (écrire 32 octets), MSTORE8 (écrire 1 octet), MLOAD (lire 32 octets), MSIZE (taille actuelle).\u003C\u002Fp>\n\u003Ch4>La formule d’expansion mémoire\u003C\u002Fh4>\n\u003Cp>Le coût du gas pour l’expansion mémoire est quadratique :\u003C\u002Fp>\n\u003Cpre>\u003Ccode>cout_memoire = 3 * nombre_mots + nombre_mots^2 \u002F 512\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Pour les petites allocations (< 724 octets), le coût est essentiellement linéaire à 3 gas par mot de 32 octets. Au-delà, le terme quadratique domine rapidement.\u003C\u002Fp>\n\u003Ch3>3. Le stockage\u003C\u002Fh3>\n\u003Cp>Le stockage est la seule zone persistante — les valeurs survivent entre les transactions. Organisé en paires clé-valeur de 32 octets chacune, mappées à l’adresse du contrat.\u003C\u002Fp>\n\u003Cp>C’est de loin la zone la plus chère : SLOAD (2100 gas froid, 100 chaud), SSTORE (22100 gas pour écrire une nouvelle valeur non nulle).\u003C\u002Fp>\n\u003Ch3>4. Calldata\u003C\u002Fh3>\n\u003Cp>Calldata est une zone en lecture seule contenant les données envoyées avec la transaction. L’accès est bon marché : CALLDATALOAD coûte 3 gas pour lire 32 octets.\u003C\u002Fp>\n\u003Cp>En Solidity, les paramètres de fonction marqués \u003Ccode>calldata\u003C\u002Fcode> (pour les types mémoire) restent dans cette zone et évitent une copie en mémoire.\u003C\u002Fp>\n\u003Ch2 id=\"le-pointeur-de-m-moire-libre\">Le pointeur de mémoire libre\u003C\u002Fh2>\n\u003Cp>Solidity maintient un « pointeur de mémoire libre » à la position 0x40. Ce pointeur suit la prochaine position mémoire disponible. Chaque allocation mémoire lit ce pointeur, l’utilise, et le met à jour.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">assembly {\n    let ptr := mload(0x40)    \u002F\u002F Lire le pointeur libre\n    mstore(ptr, value)         \u002F\u002F Écrire à la position libre\n    mstore(0x40, add(ptr, 32)) \u002F\u002F Mettre à jour le pointeur\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>En Yul et Huff, vous gérez la mémoire manuellement. Vous pouvez ignorer le pointeur libre et utiliser la mémoire à volonté — tant que vous n’écrasez pas des données dont vous avez encore besoin.\u003C\u002Fp>\n\u003Ch2 id=\"disposition-de-la-m-moire-solidity\">Disposition de la mémoire Solidity\u003C\u002Fh2>\n\u003Cp>Solidity réserve les premières positions mémoire :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>0x00-0x3f :\u003C\u002Fstrong> Espace scratch pour le hachage\u003C\u002Fli>\n\u003Cli>\u003Cstrong>0x40-0x5f :\u003C\u002Fstrong> Pointeur de mémoire libre\u003C\u002Fli>\n\u003Cli>\u003Cstrong>0x60-0x7f :\u003C\u002Fstrong> Slot zéro (utilisé comme valeur initiale pour les tableaux dynamiques)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>0x80+ :\u003C\u002Fstrong> Début de la mémoire libre\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Comprendre cette disposition est essentiel lorsque vous écrivez du Yul inline dans Solidity — si vous écrasez 0x40 accidentellement, l’allocateur mémoire de Solidity produira des résultats corrompus.\u003C\u002Fp>\n\u003Ch2 id=\"comparaison-des-co-ts\">Comparaison des coûts\u003C\u002Fh2>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Opération\u003C\u002Fth>\u003Cth>Zone\u003C\u002Fth>\u003Cth>Gas\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>PUSH\u002FDUP\u002FSWAP\u003C\u002Ftd>\u003Ctd>Pile\u003C\u002Ftd>\u003Ctd>3\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>MLOAD\u002FMSTORE\u003C\u002Ftd>\u003Ctd>Mémoire\u003C\u002Ftd>\u003Ctd>3 + expansion\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>CALLDATALOAD\u003C\u002Ftd>\u003Ctd>Calldata\u003C\u002Ftd>\u003Ctd>3\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>SLOAD (froid)\u003C\u002Ftd>\u003Ctd>Stockage\u003C\u002Ftd>\u003Ctd>2100\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>SLOAD (chaud)\u003C\u002Ftd>\u003Ctd>Stockage\u003C\u002Ftd>\u003Ctd>100\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>SSTORE (froid, 0→non-zéro)\u003C\u002Ftd>\u003Ctd>Stockage\u003C\u002Ftd>\u003Ctd>22100\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"quand-utiliser-chaque-zone\">Quand utiliser chaque zone\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Pile :\u003C\u002Fstrong> Valeurs intermédiaires de calcul, compteurs de boucle, résultats temporaires. Limité à 16 de profondeur accessible.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mémoire :\u003C\u002Fstrong> Données structurées (tableaux, structs), préparation des données de retour, paramètres d’appels inter-contrats.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Stockage :\u003C\u002Fstrong> État persistant du contrat — soldes, propriétaires, mappings.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Calldata :\u003C\u002Fstrong> Données d’entrée en lecture seule de la transaction. Préférez \u003Ccode>calldata\u003C\u002Fcode> à \u003Ccode>memory\u003C\u002Fcode> pour les paramètres de fonction quand c’est possible.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"conclusion\">Conclusion\u003C\u002Fh2>\n\u003Cp>Les quatre zones de données de l’EVM ne sont pas interchangeables. Chacune a un profil de coût, une durée de vie et des contraintes d’accès distincts. Maîtriser quand utiliser la pile plutôt que la mémoire, quand lire le calldata plutôt que de copier en mémoire, et comment minimiser les accès au stockage — voilà la base de l’optimisation de gas.\u003C\u002Fp>\n\u003Cp>Dans le prochain article, nous explorerons en détail le gas : pourquoi votre contrat coûte ce qu’il coûte, et comment réduire systématiquement ces coûts.\u003C\u002Fp>\n","fr","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:28.859164Z","Plongée approfondie dans les quatre zones de données de l'EVM : pile, mémoire, stockage et calldata, leurs coûts et la formule d'expansion mémoire.","EVM modèle mémoire",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"]