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 fondamental représentant une adresse Ethereum de 20 octets (160 bits). Peut désigner un compte utilisateur (EOA) ou un smart contract. Les adresses peuvent recevoir des Ether et interagir avec la blockchain. Solidity offre deux variantes : `address` (standard) et `address payable` (peut recevoir de l'Ether via `.transfer()` ou `.send()`).

Structure de données contenant des éléments du même type. Peut être de taille fixe (`uint[5]`) ou dynamique (`uint[]`). Les arrays dynamiques en storage consomment du gas lors de l'ajout/suppression d'éléments. Supporte les opérations `.push()`, `.pop()`, et `.length`.

Fonction utilisée pour vérifier des conditions qui ne devraient jamais être fausses (invariants internes). Contrairement à `require`, `assert` consomme tout le gas restant en cas d'échec et indique un bug dans le code. À utiliser pour détecter les états impossibles, comme les erreurs de débordement avant Solidity 0.8.0.

Variable globale donnant accès aux informations du bloc actuel sur la blockchain. Propriétés utiles : `block.timestamp` (timestamp Unix), `block.number` (numéro du bloc), `block.difficulty` (difficulté PoW, obsolète post-Merge), `block.gaslimit`. Attention : `block.timestamp` est manipulable par les mineurs à quelques secondes près.

Type de données primitif représentant une valeur logique : `true` ou `false`. Occupe 1 byte en storage mais est packable avec d'autres variables pour économiser du gas. Supporte les opérations logiques : `&&` (AND), `||` (OR), `!` (NOT).

Type pour stocker des données binaires brutes. Deux variantes : `bytes` (dynamique, comme un array) et `bytes1` à `bytes32` (taille fixe). `bytes32` est très utilisé pour les hash et identifiants. Plus gas-efficient que les string pour les données brutes.

Zone mémoire en lecture seule où sont stockés les arguments des fonctions external. Beaucoup plus gas-efficient que `memory` car les données ne sont pas copiées. À privilégier pour les paramètres des fonctions `external` qui ne nécessitent pas de modification.

Modificateur pour les variables dont la valeur est fixée à la compilation et ne changera jamais. Les constantes ne consomment pas de storage : elles sont inlinées dans le bytecode. À utiliser pour les valeurs mathématiques, adresses fixes, etc. Combinable avec `immutable` pour l'optimisation.

Fonction spéciale exécutée une seule fois lors du déploiement du contrat. Utilisée pour initialiser les variables d'état, définir le owner, etc. Depuis Solidity 0.8.0, utilise le mot-clé `constructor()`. Ne peut pas être appelée après le déploiement.

Unité fondamentale de code en Solidity, similaire à une classe en programmation orientée objet. Un contrat contient des variables d'état, des fonctions, des events et des modifiers. Une fois déployé sur la blockchain, son code est immuable mais son état peut évoluer via les transactions.

Organisation décentralisée gérée par des smart contracts et gouvernée par ses membres via des tokens de vote. Les décisions sont prises collectivement via des propositions et votes on-chain. Exemples célèbres : MakerDAO, Uniswap DAO. Les DAO permettent une gouvernance transparente et sans intermédiaire.

Écosystème de services financiers décentralisés construits sur blockchain (prêts, échanges, yield farming, staking). Pas d'intermédiaire, les smart contracts remplacent les institutions financières traditionnelles. Protocoles majeurs : Uniswap, Aave, Compound, MakerDAO.

Opcode permettant à un contrat d'exécuter le code d'un autre contrat dans son propre contexte (storage, msg.sender, msg.value). Utilisé pour les proxies et bibliothèques. Très puissant mais dangereux : peut modifier le storage de manière inattendue si mal utilisé. Différent de `call` qui exécute dans le contexte du contrat appelé.

Type défini par l'utilisateur pour créer un ensemble de constantes nommées. Améliore la lisibilité du code et réduit les erreurs. Stocké comme `uint8` en interne (0, 1, 2...). Utile pour les états, statuts, rôles.

Standard multi-token permettant de gérer plusieurs types de tokens (fongibles et non-fongibles) dans un seul contrat. Plus gas-efficient que déployer plusieurs ERC-20/ERC-721. Supporte les transferts par batch. Très utilisé dans les jeux blockchain et metaverses.

Standard de token fongible sur Ethereum. Définit les fonctions obligatoires : `totalSupply`, `balanceOf`, `transfer`, `approve`, `transferFrom`, `allowance`. Chaque token est identique et interchangeable (comme une monnaie). Standard le plus utilisé pour les cryptomonnaies et utilitaires.

Standard de token non-fongible (NFT) sur Ethereum. Chaque token a un identifiant unique et des propriétés distinctes. Fonctions principales : `ownerOf`, `balanceOf`, `transferFrom`, `approve`, `safeTransferFrom`. Utilisé pour l'art numérique, collectibles, immobilier virtuel, tickets.

Mécanisme pour logger des informations sur la blockchain de manière gas-efficient. Les events sont stockés dans les logs (pas dans le storage) et peuvent être écoutés par les applications frontend. Utilise `emit` pour déclencher. Les paramètres `indexed` (max 3) permettent la recherche/filtrage.

Fonction exécutée quand un contrat reçoit un appel à une fonction inexistante ou des Ether sans données. Depuis Solidity 0.6.0, séparée en `fallback()` (appels avec data) et `receive()` (réception d'Ether pur). Doit être `external`. Utile pour les proxies et la gestion d'Ether.

Bloc de code réutilisable dans un contrat. Peut être `public`, `private`, `internal`, `external`. Modificateurs d'état : `view` (lecture seule), `pure` (pas d'accès à l'état), `payable` (peut recevoir Ether). Les fonctions externes coûtent moins cher en gas que public pour les gros paramètres.

Unité de mesure du coût computationnel sur Ethereum. Chaque opération (lecture storage, calcul, transfert Ether) coûte un montant fixe de gas. Le gas price (en gwei) détermine le coût final en ETH. Optimiser le gas est crucial pour réduire les frais des utilisateurs.

Unité de mesure d'Ether égale à 10^9 wei (1 milliardième d'ETH). Utilisée principalement pour exprimer le gas price. Exemple : un gas price de 50 gwei signifie que chaque unité de gas coûte 50 gwei. Si une transaction consomme 21000 gas, elle coûtera 21000 × 50 gwei = 0.00105 ETH.

Modificateur pour les variables assignées une seule fois (dans le constructor ou à la déclaration) et qui ne changent plus après. Contrairement à `constant`, la valeur peut être déterminée au moment du déploiement. Plus gas-efficient que les variables normales car la valeur est inlinée dans le bytecode.

Mécanisme permettant à un contrat d'hériter des propriétés et méthodes d'un autre contrat. Utilise le mot-clé `is`. Solidity supporte l'héritage multiple. Les fonctions peuvent être overridées avec `virtual` et `override`. Très utilisé avec OpenZeppelin pour réutiliser du code audité.

Définition de contrat abstraite contenant uniquement les signatures de fonctions (pas d'implémentation). Utilisée pour interagir avec des contrats externes dont on connaît l'ABI. Toutes les fonctions sont automatiquement `external`. Équivalent des interfaces en Java/TypeScript.

Structure de données clé-valeur, similaire à un hashmap. Extrêmement gas-efficient pour les lookups. Syntaxe : `mapping(keyType => valueType)`. Les clés n'existent pas vraiment : toute clé retourne la valeur par défaut si non assignée. Ne peut pas être itéré (pas de `.length`).

Zone de stockage temporaire effacée entre les appels de fonction. Plus cher que `calldata` mais moins cher que `storage`. Utilisée pour les variables locales de types complexes (arrays, structs, strings). Les données en memory peuvent être modifiées, contrairement à calldata.

Fonction réutilisable qui modifie le comportement d'autres fonctions. Utilisée pour les vérifications (auth, conditions), les locks (reentrancy), etc. Le symbole `_` représente le corps de la fonction modifiée. Peut prendre des paramètres.

Variable globale contenant l'adresse de l'appelant direct de la fonction. Dans une chaîne d'appels A → B → C, `msg.sender` dans C sera B. Contrairement à `tx.origin` (toujours l'EOA initial), `msg.sender` change à chaque appel. Utilisé pour l'authentification.

Variable globale (type `uint256`) contenant la quantité d'Ether (en wei) envoyée avec l'appel de fonction. Utilisable uniquement dans les fonctions `payable`. Permet de recevoir des paiements dans les smart contracts.

Token unique et non-interchangeable, généralement implémenté via ERC-721 ou ERC-1155. Chaque NFT a un identifiant unique et peut représenter la propriété d'un objet numérique ou physique (art, musique, immobilier, tickets). Métadonnées souvent stockées off-chain (IPFS).

Instruction de bas niveau exécutée par la machine virtuelle Ethereum (EVM). Chaque opcode a un coût en gas fixe. Exemples : `ADD` (addition), `SSTORE` (écriture storage), `CALL` (appel externe). Le bytecode compilé est une séquence d'opcodes. Yul permet d'écrire des opcodes manuellement pour optimiser.

Service qui fournit des données du monde réel à la blockchain (prix, météo, résultats sportifs). Les smart contracts ne peuvent pas accéder directement à internet. Chainlink est l'oracle le plus utilisé. Critique pour la DeFi (prix des assets). Les oracles mal sécurisés sont une vulnérabilité majeure.

Modificateur permettant à une fonction ou adresse de recevoir de l'Ether. Une fonction sans `payable` rejettera toute transaction envoyant de l'Ether. Pour les adresses, `address payable` permet d'utiliser `.transfer()` et `.send()`. Cast requis : `payable(address)`.

Directive du compilateur spécifiant la version de Solidity requise. Forme `pragma solidity ^0.8.0;` signifie "version 0.8.x compatible". Depuis 0.8.0 : protection overflow/underflow intégrée. Important pour la reproductibilité des builds et la sécurité.

Pattern de contrat permettant les mises à jour (upgradability). Le proxy contient le storage et délègue la logique à un contrat d'implémentation via `delegatecall`. Permet de corriger des bugs ou ajouter des fonctionnalités sans perdre les données. Patterns : Transparent Proxy, UUPS, Diamond.

Modificateur de fonction indiquant qu'elle ne lit ni ne modifie l'état du contrat. Fonctions pures : calculs mathématiques, conversions, validations. Plus restrictif que `view`. Ne coûte pas de gas si appelée externally.

Fonction spéciale exécutée quand le contrat reçoit de l'Ether pur (sans données). Introduite en Solidity 0.6.0. Syntaxe : `receive() external payable {}`. Si absente, `fallback()` est appelée. Si les deux sont absentes, le contrat ne peut pas recevoir d'Ether via `transfer` ou `send`.

Vulnérabilité permettant à un attaquant d'appeler récursivement une fonction avant que l'exécution initiale ne soit terminée. Cause du hack The DAO (2016, $60M). Protection : Checks-Effects-Interactions pattern, ou modifier `nonReentrant` (OpenZeppelin). Toujours mettre à jour l'état avant les appels externes.

Fonction de validation des conditions d'entrée. Si la condition est fausse, la transaction revert et le gas non-utilisé est remboursé. Utilisée pour vérifier les inputs, permissions, états. Peut inclure un message d'erreur. Préférer `require` à `assert` pour les validations utilisateur.

Annule toutes les modifications d'état et rembourse le gas restant. Utilisé avec des custom errors (0.8.4+) pour économiser du gas vs `require` avec strings. Forme : `revert ErrorName(params);` ou `revert("message");`. Plus explicite que `require(!condition)`.

Zone de stockage persistante du contrat sur la blockchain. Chaque contrat a son propre storage organisé en slots de 32 bytes. Extrêmement coûteux en gas (20000 gas pour écrire un nouveau slot). Les variables d'état sont en storage. Optimisation : packing de variables, minimiser les écritures.

Type personnalisé regroupant plusieurs variables sous un même nom. Similaire aux objets/classes mais sans méthodes. Utilisé pour organiser des données complexes. Peut être stocké en storage, memory ou calldata. Supporte le packing en storage pour optimiser le gas.

Type entier non-signé (≥0). Disponible de `uint8` (0-255) à `uint256` (0-2^256-1). `uint` est un alias de `uint256`. Depuis Solidity 0.8.0, protégé contre les overflows/underflows automatiquement. Utiliser des tailles plus petites (uint128, uint64) pour le packing en storage.

Modificateur de fonction indiquant qu'elle lit l'état du contrat mais ne le modifie pas. Ne coûte pas de gas quand appelée externally (hors transaction). Remplace l'ancien `constant`. Garantit qu'aucune variable d'état ne sera modifiée.

Plus petite unité d'Ether. 1 ETH = 10^18 wei. Toutes les valeurs d'Ether en Solidity sont stockées en wei (type `uint256`). Unités : 1 wei, 10^9 wei = 1 gwei, 10^18 wei = 1 ether. Utiliser les suffixes : `1 ether`, `50 gwei`.

Langage assembleur de bas niveau pour Solidity et Vyper. Permet d'écrire du code très optimisé en accédant directement aux opcodes EVM. Utilisé dans les blocs `assembly {}`. Dangereux si mal utilisé (pas de vérification de types). Réservé aux optimisations extrêmes et bibliothèques.