Glossaire Solidity A-Z

L'ABI est la spécification qui définit comment interagir avec un smart contract. Il décrit les fonctions, leurs paramètres, types de retour et événements au format JSON. C'est l'équivalent d'une API pour les smart contracts, permettant aux applications frontend et aux autres contrats de communiquer correctement avec le bytecode déployé sur la blockchain.

Type de données Solidity qui stocke une adresse Ethereum (20 bytes / 160 bits). Chaque compte (externe ou contrat) possède une adresse unique. C'est le type principal pour interagir avec d'autres contrats, envoyer de l'ether, ou gérer les permissions.

Fournisseur de nœuds Ethereum (node provider) et suite d'outils pour le développement blockchain. Propose des RPC endpoints, monitoring, webhooks, et fonctionnalités avancées comme le support multi-chain. Alternative à Infura pour se connecter aux réseaux sans héberger son propre nœud.

Fonction standard ERC-20 qui autorise un contrat (ou une adresse) à dépenser vos tokens à votre place. Nécessaire avant tout swap, staking ou interaction DeFi. Créé une allowance que le contrat peut utiliser avec transferFrom(). Attention : approuver une somme illimitée expose à des risques si le contrat est malveillant.

Langage bas niveau intégré à Solidity permettant d'écrire du code au niveau de l'EVM. Utilisé pour optimiser le gas, accéder à des opcodes non exposés en Solidity classique (comme SELFBALANCE, BASEFEE), ou manipuler directement la mémoire/storage. Réservé aux développeurs avancés car sans garde-fous (pas de vérification de type).

Propriété accessible sur toute adresse Ethereum via address.balance. Retourne le solde en wei (1 ether = 10^18 wei). Pour les contrats, address(this).balance donne le solde actuel du contrat. Essentiel pour gérer les paiements et vérifier les fonds avant un transfert.

Variable globale Solidity donnant accès aux informations du bloc actuel : block.timestamp (horodatage), block.number (hauteur de bloc), block.chainid (ID de la chaîne), block.basefee (frais de base EIP-1559), block.prevrandao (anciennement difficulty). Utilisé pour la logique temporelle, les random seeds, ou la vérification du réseau.

Code compilé au format hexadécimal exécuté par l'EVM. Quand vous déployez un smart contract, le compilateur Solidity transforme votre code en bytecode. Il existe deux types : creation bytecode (déployé une fois) et runtime bytecode (stocké on-chain après déploiement). Inspecter le bytecode permet de vérifier qu'un contrat correspond à son code source.

Fonction bas niveau pour interagir avec des contrats. Plus flexible que transfer() ou send(), permet d'envoyer de l'ether ET d'appeler des fonctions, avec un gas limit personnalisable. Retourne (bool success, bytes memory data). Contrairement à transfer(), ne revert pas automatiquement en cas d'échec, nécessite une vérification manuelle du succès. Préféré depuis Solidity 0.8+.

Identifiant unique d'une blockchain Ethereum compatible. Mainnet = 1, Goerli = 5, Polygon = 137, Arbitrum = 42161, etc. Accessible via block.chainid en Solidity ou assembly { chainid() }. Utilisé pour prévenir les replay attacks entre différentes chaînes, notamment dans les signatures EIP-712.

Fonction spéciale exécutée une seule fois au déploiement d'un contrat. Utilisée pour initialiser les variables d'état (owner, paramètres, etc.). Ne peut pas être appelée après le déploiement. Peut accepter des arguments passés lors du déploiement. Déclarée avec le mot-clé constructor.

Appel bas niveau qui exécute le code d'un autre contrat dans le contexte du contrat appelant. Le storage, msg.sender et msg.value restent ceux de l'appelant. Mécanisme fondamental des proxies upgradables (EIP-1967). DANGER : peut écraser votre storage si les layouts ne correspondent pas. Ne préserve pas le gas restant par défaut.

Mot-clé pour déclencher un événement (event). Les événements sont stockés dans les logs de transaction (pas dans le storage du contrat) et peuvent être écoutés par les frontends via Web3. Utilisés pour notifier les changements d'état importants. Beaucoup moins cher que stocker dans le storage.

Standard multi-token permettant de gérer plusieurs types de tokens (fongibles ET non-fongibles) dans un seul contrat. Plus efficace en gas que déployer plusieurs ERC-20/721. Utilisé dans les jeux blockchain (un contrat = toutes les armes, armures, etc.). Permet les transferts batch (plusieurs tokens en une transaction).

Standard de token fongible le plus utilisé sur Ethereum. Définit 6 fonctions obligatoires (totalSupply, balanceOf, transfer, approve, allowance, transferFrom) et 2 événements (Transfer, Approval). Implémenté par la majorité des tokens (USDC, USDT, LINK, UNI, etc.). Permet l'interopérabilité entre tous les protocoles DeFi.

Standard de token non fongible (NFT) où chaque token possède un ID unique. Contrairement à l'ERC-20, les tokens ne sont pas interchangeables. Utilisé pour les NFTs d'art, les objets de jeu, les noms de domaine (ENS), etc. Définit ownerOf(), transferFrom(), approve(), et les événements Transfer/Approval.

Bibliothèque JavaScript pour interagir avec Ethereum depuis le frontend ou Node.js. Alternative moderne à Web3.js : plus légère, meilleure documentation, API plus intuitive. Permet de se connecter aux wallets (MetaMask), signer des transactions, appeler des smart contracts, écouter les événements, etc.

Mécanisme pour émettre des logs depuis un smart contract. Les événements sont stockés dans les logs de transaction (EVM), pas dans le storage (beaucoup moins cher). Utilisés pour notifier le frontend des changements d'état. Les paramètres indexed (max 3) permettent de filtrer efficacement les événements.

Machine virtuelle qui exécute le bytecode des smart contracts. C'est l'environnement d'exécution d'Ethereum : une machine à états déterministe et répliquée sur tous les nœuds. L'EVM interprète les opcodes, gère la mémoire, le storage et le call stack. Adopté par de nombreuses blockchains (Polygon, BSC, Avalanche, Arbitrum, Optimism).

Fonction spéciale exécutée quand le contrat reçoit un appel à une fonction inexistante ou des données malformées. Déclarée avec fallback() external [payable]. Depuis Solidity 0.6, séparée de receive() (pour les paiements directs). Utilisée dans les proxies pour rediriger tous les appels vers l'implémentation.

Suite d'outils pour le développement Solidity écrite en Rust : forge (compilation, tests), cast (interactions CLI), anvil (node local), chisel (REPL Solidity). Ultra-rapide, tests écrits en Solidity (pas JS), fuzzing intégré. Alternative moderne à Hardhat, privilégié par les équipes sécurité.

Bloc de code réutilisable dans un contrat Solidity. Peut être : public (appelable de l'extérieur), external (seulement extérieur), internal (contrat + héritage), private (contrat uniquement). Peut être view (lecture seule) ou pure (aucun accès à l'état). Peut recevoir des paramètres et retourner des valeurs.

Unité de mesure du coût computationnel d'une opération sur l'EVM. Chaque opcode a un coût en gas (SSTORE = 20k, addition = 3, etc.). Le gas limit définit le maximum de gas d'une transaction, le gas price le prix par unité en gwei. Gas total = gas utilisé × gas price. Mécanisme anti-spam et de priorisation des transactions.

Framework de développement Ethereum le plus populaire. Environnement complet pour compiler, tester, déployer et débugger des smart contracts. Intègre un node local, un runner de tests (Mocha/Chai), des plugins (Etherscan verify, gas reporter, etc.), et une console interactive. Tests écrits en JavaScript/TypeScript.

Mot-clé pour les variables assignables uniquement au déploiement (constructor) mais jamais après. Contrairement à constant, la valeur peut être calculée dynamiquement. Plus économe en gas qu'une variable normale car stocké directement dans le bytecode (pas de SLOAD). Utilisé pour des paramètres de configuration fixes.

Mot-clé pour les paramètres d'événements permettant le filtrage efficace des logs. Maximum 3 paramètres indexed par événement. Les valeurs indexed sont stockées dans les topics (32 bytes chacun), facilitant la recherche. Essentiel pour filtrer les événements Transfer d'un utilisateur spécifique par exemple.

Fournisseur de nœuds Ethereum permettant d'interagir avec la blockchain sans héberger son propre nœud. Propose des endpoints RPC pour Mainnet, testnets et autres chaînes (Polygon, Arbitrum, Optimism). Propriété de ConsenSys. Alternative : Alchemy, Quicknode. Limite de requêtes gratuite : 100k/jour.

Contrat abstrait définissant les signatures de fonctions sans implémentation. Utilisé pour interagir avec des contrats externes dont on connaît l'ABI. Toutes les fonctions sont automatiquement external. Pas de variables d'état, pas de constructor, pas de fonctions internes. Permet le polymorphisme et la composition de contrats.

Contrat spécial contenant du code réutilisable, déployé une seule fois. Utilisé avec le mot-clé using pour attacher des fonctions à des types. Les fonctions de bibliothèque sont internal par défaut. Ne peut pas avoir de variables d'état (sauf constants), ni recevoir d'ether. Économise du gas en mutualisant le code.

Structure de données clé-valeur (comme un dictionnaire/hashmap). Très efficace en gas, pas de limitation de taille. Pas itérable (impossible de lister toutes les clés). Stocké dans le storage du contrat. Syntaxe : mapping(KeyType => ValueType). Les clés inexistantes retournent la valeur par défaut (0, false, address(0), etc.).

Zone de stockage temporaire utilisée pendant l'exécution d'une fonction. Moins coûteuse que le storage. Reset à chaque appel de fonction. Obligatoire pour les types complexes (arrays, strings, structs) passés en paramètres ou retournés. Déclaration : string memory, uint256[] memory, etc.

Wallet Ethereum le plus populaire, disponible en extension navigateur (Chrome, Firefox, Brave) et mobile. Permet de gérer des comptes, signer des transactions, interagir avec des dApps, et se connecter à plusieurs réseaux (Mainnet, testnets, L2). Injecte window.ethereum dans les pages web pour que les dApps puissent demander des connexions.

Fonction réutilisable qui modifie le comportement d'autres fonctions. Utilisé principalement pour les vérifications d'accès (onlyOwner) ou les conditions (whenNotPaused). Le symbole _; marque l'endroit où le code de la fonction modifiée s'exécute. Peut accepter des paramètres. Empilable : plusieurs modifiers sur une même fonction.

Variable globale Solidity contenant les informations du message/appel actuel. msg.sender = adresse de l'appelant, msg.value = montant d'ether envoyé (en wei), msg.data = calldata brute, msg.sig = signature de la fonction (4 premiers bytes de msg.data). Essentiel pour l'authentification et la gestion des paiements.

Token unique et non interchangeable, généralement au standard ERC-721 ou ERC-1155. Chaque NFT possède un ID unique et peut représenter un objet numérique (art, musique, vidéo), un objet de jeu, un certificat de propriété, etc. Les métadonnées (image, nom, description) sont souvent stockées sur IPFS ou Arweave.

Instance d'un client Ethereum (Geth, Nethermind, Erigon, Besu) qui participe au réseau. Un nœud complet (full node) stocke toute la blockchain et valide chaque transaction. Un nœud archive (archive node) stocke également tous les états historiques. Un light node ne stocke que les headers de blocs. Nécessaire pour interagir avec Ethereum sans dépendre d'un tiers.

Bibliothèque de smart contracts sécurisés et audités, standard de l'industrie. Fournit des implémentations ERC-20, ERC-721, ERC-1155, Ownable, Pausable, ReentrancyGuard, AccessControl, etc. Utilisée par 99% des projets DeFi et NFT. Mise à jour régulièrement pour suivre les nouveaux standards et patcher les vulnérabilités.

Service permettant aux smart contracts d'accéder à des données externes (prix des actifs, résultats sportifs, météo, etc.). La blockchain ne peut pas accéder au monde réel par elle-même, les oracles comblent ce fossé. Chainlink est le leader du marché. Risques : centralisation, manipulation, latence.

Contrat de base OpenZeppelin pour gérer un propriétaire unique (owner). Fournit le modifier onlyOwner pour restreindre l'accès aux fonctions critiques. Le propriétaire peut être transféré avec transferOwnership() ou renoncé avec renounceOwnership(). Pattern de sécurité fondamental pour les contrats administrés.

Mot-clé permettant à une fonction ou une adresse de recevoir de l'ether. Fonction payable : peut recevoir msg.value. Adresse payable : peut recevoir des transferts via .transfer() ou .send(). Sans payable, toute tentative d'envoi d'ether provoque une erreur. Essentiel pour les paiements on-chain.

Pattern permettant de rendre un smart contract upgradable. Le proxy délègue tous les appels à un contrat d'implémentation via delegatecall. Pour upgrader, il suffit de pointer vers une nouvelle implémentation. Standards : EIP-1967 (Transparent Proxy), UUPS (Universal Upgradeable Proxy Standard), Beacon Proxy. Attention aux risques de storage collision.

Modificateur de fonction indiquant qu'elle ne lit ni ne modifie l'état du contrat. Fonctions mathématiques pures, utilitaires, hash, etc. Plus restrictif que view. Ne peut pas accéder au storage, aux variables d'état, ni à block, msg (sauf msg.sig et msg.data). Utile pour des fonctions utilitaires sans effet de bord.

Fonction spéciale exécutée quand le contrat reçoit de l'ether sans données (msg.data vide). Déclarée avec receive() external payable. Introduite en Solidity 0.6 pour séparer la réception d'ether (receive) des appels de fonctions inexistantes (fallback). Limite de 2300 gas si appelée via transfer() (pas assez pour écrire dans le storage).

Vulnérabilité où un contrat externe rappelle une fonction du contrat victime avant que la première exécution ne soit terminée. Célèbre dans le hack de The DAO (2016, 60M$ volés). Prévention : suivre le pattern Checks-Effects-Interactions, ou utiliser ReentrancyGuard d'OpenZeppelin. Toujours mettre à jour l'état avant les appels externes.

Instruction pour valider des conditions et reverter si elles ne sont pas remplies. Rembourse le gas restant (contrairement à assert). Syntaxe : require(condition, "Message d'erreur"). Utilisé pour valider les inputs, les permissions, les états. Depuis Solidity 0.8.4, on peut utiliser des custom errors pour économiser du gas.

Instruction pour annuler une transaction et rembourser le gas restant. Peut inclure un message d'erreur ou utiliser des custom errors (plus économes). Toutes les modifications d'état sont annulées. require() est un raccourci pour if (!condition) revert(). Utilisé pour gérer les erreurs et les conditions invalides.

Fonction pour détruire un contrat et envoyer son ether restant à une adresse. Le bytecode reste sur la blockchain (historique immuable) mais les appels futurs échouent. Coûte du gas négatif (remboursement) mais DÉPRÉCIÉ depuis EIP-6049. Ne devrait plus être utilisé dans les nouveaux contrats. Alternative : désactiver le contrat avec un flag.

Cryptographie à courbe elliptique (ECDSA) utilisée pour prouver la possession d'une clé privée. Une signature se compose de (v, r, s). Permet les meta-transactions, les permits (ERC-20 sans approve), les votes off-chain, etc. Standard : EIP-712 (typed structured data hashing). Vérifiable on-chain avec ecrecover().

Compilateur officiel Solidity qui transforme le code .sol en bytecode EVM. Disponible en CLI (solc), JavaScript (solc-js), ou intégré dans Hardhat/Foundry. Génère le bytecode, l'ABI, les métadonnées, et les optimisations. Versioning strict : pragma solidity ^0.8.0; spécifie les versions compatibles.

Zone de stockage persistante du contrat, conservée entre les transactions. Très coûteuse en gas (SSTORE = 20k gas pour une nouvelle valeur, 5k pour une mise à jour). Organisée en slots de 32 bytes. Les variables d'état (state variables) sont stockées dans le storage. À minimiser pour optimiser le gas.

Type personnalisé regroupant plusieurs variables sous un même nom. Similaire aux objets/structs dans d'autres langages. Peut contenir n'importe quel type (uint, address, mapping, array, autres structs). Stocké dans storage, memory ou calldata selon le contexte. Utilisé pour organiser des données complexes.

Fonction pour envoyer de l'ether depuis un contrat vers une adresse payable. Syntaxe : recipient.transfer(amount). Limite de 2300 gas (suffisant pour un receive() simple, mais pas pour du code complexe). Revert automatiquement en échec. Déprécié au profit de call{value: amount}("") qui offre plus de contrôle.

Fonction ERC-20 permettant de transférer des tokens depuis le compte d'un utilisateur vers un autre, après approbation. Nécessite que l'utilisateur ait appelé approve() au préalable. Utilisé par tous les protocoles DeFi (Uniswap, Aave, etc.) pour déplacer les tokens de l'utilisateur. Décremente l'allowance après chaque transfert.

Variable globale Solidity contenant les informations de la transaction actuelle. tx.origin = adresse de l'émetteur initial (EOA, jamais un contrat), tx.gasprice = prix du gas de la transaction. Différent de msg.sender dans le cas d'appels de contrat à contrat. ⚠️ Ne jamais utiliser tx.origin pour l'authentification (vulnérable aux phishing).

Bloc désactivant les vérifications d'overflow/underflow introduites en Solidity 0.8. Permet d'économiser du gas quand on sait qu'un overflow est impossible (ex: dans un compteur de boucle). À utiliser avec précaution car réintroduit les risques d'overflow. Utile pour les optimisations avancées.

Modificateur de fonction indiquant qu'elle lit l'état mais ne le modifie pas. Peut accéder aux variables d'état, au storage, à block, msg, etc. Ne coûte pas de gas si appelée depuis l'extérieur (lecture gratuite), mais coûte du gas si appelée depuis une transaction (car exécutée par l'EVM). Plus permissif que pure.

Spécifie qui peut accéder à une fonction ou variable. 4 niveaux : public (tous), external (seulement extérieur, pas d'appels internes), internal (contrat + héritage), private (contrat uniquement). Pour les variables d'état : public génère automatiquement un getter. Critique pour la sécurité : toujours spécifier explicitement.

Application ou dispositif permettant de gérer des clés privées et de signer des transactions. Types : hot wallet (en ligne, MetaMask, Coinbase Wallet), cold wallet (hors ligne, Ledger, Trezor), smart contract wallet (Gnosis Safe, Argent). Un wallet ne stocke pas les cryptos (elles sont sur la blockchain), seulement les clés.