⛓️ Encyclopédie de la Blockchain

Qu'est-ce qu'un Registre (Ledger) ?

Un registre est simplement un livre de comptes. C'est la base de toute l'économie depuis des millénaires. Il enregistre "Qui possède Quoi" ou "Qui a transféré Quoi à Qui".

• Registre Centralisé (Ex: Banque) : Le registre est détenu, maintenu et validé par une seule entité (la banque). Vous devez faire confiance à cette entité pour qu'elle soit honnête et compétente (ne pas se faire hacker, ne pas censurer vos transactions). C'est le modèle "Trust-based".
• Registre Décentralisé (Ex: Fichier Excel partagé) : Le registre est copié chez plusieurs acteurs. C'est mieux, mais pose un problème : qui a la "vraie" version ? Si A et B modifient le fichier en même temps, quel est le bon ?

DLT (Distributed Ledger Technology)

Une DLT est un type spécifique de registre décentralisé qui résout le problème de la "vraie version". C'est une base de données répliquée, partagée et synchronisée entre les membres d'un réseau.

Une DLT n'a pas besoin d'administrateur central. Elle utilise un mécanisme de consensus (voir 2.1) pour s'assurer que toutes les copies du registre sont identiques et valides.

La Blockchain : Un Type Spécifique de DLT

Toute blockchain est une DLT, mais toute DLT n'est pas une blockchain.

La **Blockchain** est une DLT qui implémente le registre sous la forme d'une **chaîne de blocs** (voir 1.2). Les données sont regroupées en "blocs" et chaque bloc est lié cryptographiquement au précédent. Cette structure de données (le *chaînage*) est ce qui la rend **immuable** (résistante à la modification) par nature.

Il existe d'autres DLT qui n'utilisent pas de blocs (ex: IOTA Tangle, Hedera Hashgraph), mais la blockchain est l'implémentation la plus connue et la plus éprouvée.

Les Propriétés Fondamentales (Blockchain Publique)

• Décentralisation : Le registre n'est stocké sur aucun serveur central. Il est répliqué sur des milliers de "nœuds" (ordinateurs) indépendants.
• Transparence : (Pour les blockchains publiques comme Bitcoin/Ethereum). N'importe qui peut lire le registre, vérifier les transactions et l'historique complet.
• Immuabilité (Tamper-proof) : Une fois qu'une transaction est confirmée dans un bloc, il est cryptographiquement impossible de la modifier ou de la supprimer sans invalider tous les blocs suivants (voir 1.3).
• Résistance à la Censure : Aucune entité ne peut empêcher une transaction valide d'être incluse dans le registre.

1. L'En-tête de Bloc (Block Header)

C'est le "ciment" de la blockchain. L'en-tête est une petite structure de données (ex: 80 octets pour Bitcoin) qui contient les métadonnées vitales du bloc. C'est sur l'en-tête que le consensus (le minage) s'opère. Il contient :

• Version : La version du protocole du bloc.
• Hash du Bloc Précédent (Previous Hash) : C'est le lien cryptographique. C'est le hash SHA-256 de l'en-tête du bloc *précédent*. C'est ce qui forme la chaîne.
• Racine de Merkle (Merkle Root) : Le hash unique qui résume et garantit l'intégrité de *toutes* les transactions incluses dans le corps du bloc (voir 1.4).
• Timestamp : L'heure (en secondes Unix) à laquelle le bloc a été créé par le mineur.
• Cible de Difficulté (Difficulty Target) : Un nombre (ex: `00000000FFFF...`) que le hash du bloc *doit* être inférieur pour être valide (voir 2.2).
• Nonce (Number used once) : Le nombre que les mineurs modifient des milliards de fois par seconde jusqu'à ce qu'ils trouvent un hash d'en-tête valide (inférieur à la Cible).

2. Le Corps du Bloc (Block Body)

C'est la "charge utile" du bloc. Il s'agit simplement de la liste complète de toutes les transactions (ex: 1 Mo de données, soit ~2500 transactions pour Bitcoin) qui ont été sélectionnées par le mineur depuis la Mempool (voir 1.5) pour être incluses dans ce bloc.

Le Chaînage (L'Immuabilité)

Le processus de création d'un bloc (ex: Bloc #101) est le suivant :

1. Un mineur sélectionne des transactions.
2. Il les résume en une Racine de Merkle.
3. Il récupère le Hash du Bloc #100 (ex: `0000...abcd`).
4. Il assemble l'en-tête du Bloc #101 (incluant `0000...abcd` et la Racine de Merkle).
5. Il "mine" : il cherche un Nonce jusqu'à ce que `HASH(En-tête #101 + Nonce)` soit valide (ex: `0000...f012`).
6. Le bloc #101 est créé et diffusé.

Le mineur suivant (pour le Bloc #102) devra inclure `0000...f012` dans son propre en-tête.

Conséquence : Si un attaquant veut modifier une transaction dans le Bloc #100, la Racine de Merkle #100 change, donc le Hash du Bloc #100 change. Le Bloc #101 (qui pointait vers l'ancien hash) devient orphelin et invalide. L'attaquant devrait reminer le Bloc #100, *ET* le Bloc #101, *ET* tous les blocs suivants, plus vite que le reste du réseau. C'est cryptographiquement impossible.

Construction de l'Arbre (Agréger)

L'arbre est construit "du bas vers le haut" en hachant les transactions par paires jusqu'à ce qu'il ne reste qu'un seul hash : la Racine (Merkle Root).

Exemple avec 8 transactions (T1 à T8) :

1. Niveau 0 (Feuilles) : On hache chaque transaction :
   • H1 = H(T1), H2 = H(T2), H3 = H(T3)... H8 = H(T8)
2. Niveau 1 : On hache les hachages précédents par paires :
   • H12 = H(H1 + H2)
   • H34 = H(H3 + H4)
   • H56 = H(H5 + H6)
   • H78 = H(H7 + H8)
3. Niveau 2 : On répète le processus :
   • H1234 = H(H12 + H34)
   • H5678 = H(H56 + H78)
4. Niveau 3 (La Racine) :
   • MerkleRoot = H(H1234 + H5678)

Cette MerkleRoot est le *seul* hash qui est inclus dans l'en-tête du bloc. Il sert d'empreinte digitale pour l'ensemble des transactions.

Avantages de cette Structure

1. Immuabilité (Intégrité)

Si un attaquant modifie 1 octet de la transaction `T3`, son hash `H3` change. Par effet d'avalanche (voir 1.3), `H34` change, puis `H1234` change, et enfin la `MerkleRoot` change. Le hash du bloc entier est donc invalidé. L'intégrité de milliers de transactions est garantie par un seul hash de 32 octets.

2. Efficacité de la Vérification (SPV)

C'est l'avantage le plus puissant. Un "light client" (ex: un portefeuille mobile) n'a pas besoin de télécharger les 500 Go de la blockchain Bitcoin. Il ne télécharge que les **en-têtes de bloc** (ex: 80 Mo).

SPV (Simple Payment Verification) :

• Vous voulez prouver que *votre* transaction (T3) est bien dans le Bloc #100.
• Le "Full Node" (serveur) n'a pas besoin de vous envoyer les 7 autres transactions (T1, T2, T4...T8).
• Il vous envoie uniquement le "chemin" (Merkle Path) dont vous avez besoin : H4, H12, et H5678.
• Votre portefeuille "light" peut alors recalculer :
  1. H3 = H(Votre T3) (connu)
  2. H34 = H(H3 + H4) (H4 fourni)
  3. H1234 = H(H12 + H34) (H12 fourni)
  4. MerkleRoot_Calculée = H(H1234 + H5678) (H5678 fourni)

Vous comparez votre `MerkleRoot_Calculée` à celle présente dans l'en-tête du Bloc #100. Si elles correspondent, vous avez la **preuve mathématique** que votre transaction est incluse, en n'ayant reçu que 3 hachages (log2(N)) au lieu de 7 transactions.

Gossip Protocol (Protocole de Commérage)

Lorsqu'un nœud (ex: votre portefeuille) crée une nouvelle transaction, il ne l'envoie pas à un "serveur central".

1. Votre portefeuille se connecte à un petit nombre de nœuds (ex: 8-10 "pairs").
2. Il envoie la transaction à ces 8 pairs.
3. Chacun de ces 8 pairs vérifie la transaction (Ex: La signature est-elle valide ? Alice a-t-elle les fonds ?).
4. S'ils la jugent valide, ils la transmettent à *leurs* 8 pairs (qui ne sont pas vous).
5. Ceux-ci la retransmettent à leurs propres pairs, etc.

Ce "Gossip Protocol" (commérage) permet à la transaction de se propager de manière exponentielle et décentralisée à travers le globe en quelques secondes.

Rôle d'un Nœud (Node)

Un "Full Node" (nœud complet) est un participant du réseau qui :

• Télécharge l'intégralité de la blockchain.
• Vérifie indépendamment *chaque* transaction et *chaque* bloc selon les règles du protocole.
• Refuse les blocs/transactions invalides (ex: un bloc qui crée trop de bitcoins).
• Participe au Gossip Protocol.

Les nœuds sont les gardiens des règles. Les mineurs (PoW) ou validateurs (PoS) *proposent* des blocs, mais les *nœuds* les acceptent ou les rejettent. C'est ce qui maintient la décentralisation.

La Mempool (Memory Pool)

Lorsqu'un nœud reçoit une transaction valide via le Gossip Protocol, mais qu'elle n'est pas encore incluse dans un bloc, où la met-il ?

Il la stocke dans sa Mempool (Pool de Mémoire). C'est un "sas" ou une "salle d'attente" pour toutes les transactions non confirmées que le nœud a vues.

Le "Marché aux Frais"

Un bloc (ex: Bitcoin) a une taille limitée (ex: 1 Mo). Il ne peut contenir qu'environ 2500 transactions. Cependant, la Mempool peut contenir 10 000, 50 000, voire 200 000 transactions en attente lors des pics d'activité.

Comment un mineur choisit-il quelles transactions inclure ?

Il se comporte de manière économiquement rationnelle : il trie la Mempool par frais de transaction (exprimés en "satoshi/vByte" ou "Gwei") et remplit son bloc avec les 2500 transactions les plus rentables (celles qui paient le plus de frais).

Conséquence : C'est un marché. Si vous voulez que votre transaction soit confirmée rapidement (dans le prochain bloc de 10 min), vous devez payer un "Gas Price" (frais) plus élevé que les autres. Si vous payez des frais trop bas, votre transaction peut rester "bloquée" dans la Mempool pendant des heures ou des jours, jusqu'à ce que le réseau se désengorge.

Le "Puzzle" du Minage (Bitcoin)

Le minage n'est pas de "résoudre un problème mathématique complexe" (ce qui implique une intelligence), mais de "trouver un nombre" par force brute.

1. Le mineur assemble un "candidat de bloc" (en-tête + transactions).
2. L'objectif est de trouver un Nonce (un nombre) tel que :
   SHA256( SHA256( En-tête_du_Bloc + Nonce ) )
   ...soit *inférieur* à la Cible de Difficulté (Difficulty Target).
3. Cette "Cible" est un très grand nombre. Être "inférieur" à ce nombre signifie, en pratique, que le hash doit commencer par un certain nombre de zéros (ex: `0000000000000000000abc...`).
4. Il n'y a pas de raccourci. Le mineur doit essayer des milliards de Nonces par seconde (Nonce=1, Nonce=2, Nonce=3...) jusqu'à ce qu'il en trouve un qui, par pure chance, produit un hash valide.

Le premier mineur qui trouve un hash valide gagne la "course", diffuse son bloc au réseau, et reçoit la Récompense de Bloc (ex: 6.25 BTC) + les Frais de Transaction. Ce processus s'appelle le "minage".

Ajustement de la Difficulté & Halving

Ajustement de la Difficulté :

• Le protocole Bitcoin est conçu pour qu'un bloc soit trouvé en moyenne toutes les 10 minutes.
• Si la puissance de calcul totale du réseau (Hashrate) augmente (plus de mineurs), les blocs seront trouvés plus vite (ex: 8 min).
• Tous les 2016 blocs (~2 semaines), chaque nœud du réseau recalcule automatiquement la "Cible de Difficulté". Si le temps moyen était de 8 min, le protocole *augmente* la difficulté (en *abaissant* le nombre Cible) pour ramener le temps moyen à 10 min.

La Sécurité : L'Attaque des 51%

La sécurité du PoW repose sur la "tyrannie de la majorité". La chaîne la plus longue (avec le plus de PoW cumulé) est considérée comme la chaîne valide.

• Pour réécrire l'histoire (ex: annuler une de ses propres transactions après qu'elle ait été confirmée, ou "double-dépense"), un attaquant doit secrètement miner une chaîne parallèle (fork).
• Pour que sa chaîne parallèle soit acceptée par le réseau, elle doit devenir *plus longue* que la chaîne honnête.
• Pour cela, il doit avoir plus de 51% de la puissance de hachage (Hashrate) mondiale.
• Le coût d'acquisition (CAPEX) et d'opération (OPEX - électricité) pour obtenir >51% du hashrate de Bitcoin se chiffre en milliards de dollars, rendant l'attaque économiquement irrationnelle (il coûte plus cher d'attaquer que de simplement participer honnêtement).

Inconvénient majeur : La consommation énergétique (Proof-of-Waste). L'énergie est "brûlée" uniquement pour prouver l'honnêteté, ce qui a conduit à la création du Proof-of-Stake.

Le Mécanisme (Ethereum PoS - "Gasper")

Il n'y a plus de "mineurs" en compétition. Il y a des **"Validateurs"** qui coopèrent.

• Devenir Validateur (Le "Stake") : Pour participer, un utilisateur doit envoyer 32 ETH (~$100k) à un contrat de dépôt (le "staking"). Cet argent est une **caution** (un collatéral). L'utilisateur gère un "nœud validateur".
• Le Temps (Slots & Epochs) : Le temps n'est plus aléatoire (10 min). Il est divisé en Slots (12 secondes) et Epochs (32 Slots, soit ~6.4 minutes).
• Proposer un Bloc : Pour chaque Slot (toutes les 12 sec), un validateur est choisi *aléatoirement* par le protocole pour être le **Proposeur de Bloc**. Il crée le bloc et le diffuse.
• Attester un Bloc : Pour chaque Slot, un "comité" d'autres validateurs (ex: 10 000) est choisi aléatoirement. Leur travail est d'**Attester** (voter) pour le bloc qu'ils estiment valide. Ces attestations sont ce qui "cimente" le bloc dans la chaîne.
• Récompenses : Les proposeurs et les attestors honnêtes qui font leur travail reçoivent de petites récompenses (intérêts sur leur stake de 32 ETH, ex: ~3-5% APY).

La Sécurité : Le "Slashing" (La Punition)

Qu'est-ce qui empêche un Proposeur de bloc de proposer deux blocs différents (un "fork") pour tricher ? Ou un Attestor de voter pour deux chaînes différentes ?

Contrairement au PoW où le tricheur ne perd que son coût d'électricité gaspillé, en PoS, la punition est explicite et déterministe : le **Slashing**.

• Le "Slashing" est la destruction (le "burn") d'une partie ou de la totalité de la caution de 32 ETH du validateur.
• Acte Malveillant (ex: double-vote) -> Preuve Cryptographique -> Détection par le réseau -> Destruction de la caution du validateur + Éjection du réseau.

Sécurité (Attaque des 51%)

Une attaque 51% en PoS n'est pas de 51% de l'énergie, mais de 51% du *capital total staké*. L'attaquant devrait acheter des milliards de dollars d'ETH pour tenter une réorganisation de la chaîne.

Le "coût" de cette attaque est fondamentalement différent :

• PoW : Coût de l'énergie (OPEX). Si l'attaque échoue, l'attaquant a "juste" perdu de l'argent en électricité.
• PoS : Coût du capital (CAPEX). Si l'attaque échoue (ou même si elle réussit mais est forkée par la communauté), le protocole peut *slasher* (détruire) les milliards de dollars de l'attaquant.

Avantages : Efficacité énergétique (~99.95% de moins que PoW), pas de matériel spécialisé (ASIC).
Inconvénients : Plus complexe, risque de centralisation du capital (les "riches" qui stakent deviennent plus riches).

Philosophie & Tokenomics

La philosophie de Bitcoin est celle de la **"Sound Money" (Monnaie Saine)**. Son objectif premier est d'être la meilleure **Réserve de Valeur (Store of Value)** jamais créée : décentralisée, résistante à la censure, non-souveraine, et surtout, **rare**.

Tokenomics (Hard Cap) :

• Offre Maximale : 21 millions de BTC. Ce nombre est inscrit dans le code et ne peut pas être changé sans un consensus de 99.9% du réseau.
• Émission (Le "Halving") : L'émission de nouveaux BTC (la "Récompense de Bloc") est divisée par deux tous les 210 000 blocs (~4 ans).
  • 2009 : 50 BTC / bloc
  • 2012 : 25 BTC / bloc
  • 2016 : 12.5 BTC / bloc
  • 2020 : 6.25 BTC / bloc
  • ~2024 : 3.125 BTC / bloc
• Cela rend l'émission de Bitcoin (son "inflation") parfaitement prévisible et décroissante, le rendant plus rare que l'or (dont l'offre augmente d'~1-2% par an via l'extraction).

Architecture : Le Modèle UTXO

Bitcoin n'utilise pas de "comptes" (comme un compte bancaire). Votre "solde" n'est pas un nombre stocké quelque part. Votre portefeuille gère une collection de "pièces" non dépensées.

UTXO = Unspent Transaction Output (Sortie de Transaction Non Dépensée).

Analogie (Le Portefeuille) :

• Votre portefeuille ne contient pas un "solde de 10€". Il contient un billet de 5€, un billet de 1€, et une pièce de 2€ (et 2€ en pièces).
• Ces "billets" sont des UTXOs (des sorties de transactions passées que vous avez reçues).

Fonctionnement d'une Transaction :

• Vous voulez acheter quelque chose à 8€.
• Vous ne pouvez pas "casser" votre billet de 5€. Vous devez utiliser le billet de 5€ *et* le billet de 1€ *et* la pièce de 2€. (Total 8€).
• Une transaction Bitcoin détruit les anciens UTXOs (Inputs) et en crée de nouveaux (Outputs).

Transaction :
--- INPUTS (Consommés/Détruits) ---
UTXO 1 (de Bob) : 5 BTC
UTXO 2 (de Charlie) : 4 BTC
(Total Input : 9 BTC)

--- OUTPUTS (Créés) ---
Output 1 (à Alice) : 8 BTC (Le paiement)
Output 2 (à Moi-même) : 0.9 BTC (La "monnaie" rendue)

(Total Output : 8.9 BTC)
(Différence : 0.1 BTC = Frais pour le mineur)

Avantages UTXO : Parallélisable, plus privé (vous pouvez utiliser des UTXOs différents pour des paiements différents), traçabilité claire.
Inconvénient : Complexe pour développer des logiques d'état (Smart Contracts).

Philosophie & Objectif

La philosophie d'Ethereum (lancé en 2015) est d'être un **"Ordinateur Mondial" (World Computer)**. L'objectif n'est pas d'être une "meilleure monnaie", mais de créer une **plateforme décentralisée pour exécuter du code (Smart Contracts)**.

Bitcoin sécurise les transactions (état passé). Ethereum sécurise les **transitions d'état** (calculs). C'est une base de données transactionnelle décentralisée et un ordinateur d'état (state machine).

Architecture : Le Modèle de Comptes

Pour gérer des logiques complexes (comme un Smart Contract qui a son propre "solde" et sa propre "mémoire"), le modèle UTXO de Bitcoin est inefficace. Ethereum utilise un **Modèle de Comptes**, similaire à un compte bancaire.

Le "World State" d'Ethereum est une gigantesque base de données associant des "Adresses" à des "Comptes". Il existe deux types de comptes :

• 1. EOA (Externally Owned Account) :
  • Contrôlé par : Une Clé Privée (un utilisateur).
  • Peut : Initier des transactions (envoyer de l'ETH, appeler un contrat), payer le Gas.
  • Ne peut pas : Contenir du code.
  • Exemple : Votre compte sur Metamask.
• 2. CA (Contract Account) :
  • Contrôlé par : Son propre code (immuable).
  • Ne peut pas : Initier des transactions (il ne peut qu'**réagir** à une transaction reçue d'un EOA ou d'un autre contrat).
  • Peut : Contenir du code (fonctions), avoir son propre stockage (mémoire), et appeler d'autres contrats.
  • Exemple : Le contrat Uniswap, un contrat NFT.

Fonctionnement d'une Transaction

Dans le modèle de comptes, une transaction est plus simple (conceptuellement) :

• Transaction Simple (Transfert) :
  • EOA (Alice) envoie une transaction "Transfert 1 ETH" à EOA (Bob).
  • Le réseau vérifie si Alice a 1 ETH (+ les frais).
  • État final : Solde Alice -1, Solde Bob +1.
  • (C'est un simple changement de `balance` dans le "World State").
• Transaction Complexe (Appel de Contrat) :
  • EOA (Alice) envoie une transaction au Contrat "Uniswap".
  • La transaction contient 1 ETH et des "data" (ex: "Je veux échanger cet ETH contre du DAI").
  • L'EVM (voir 3.3) exécute le *code* du contrat Uniswap.
  • Le code (en une seule transaction) : 1) Reçoit l'ETH d'Alice, 2) Calcule le montant de DAI, 3) Envoie le DAI à Alice.
  • État final : Solde Alice -1 ETH, +1900 DAI. Solde Contrat +1 ETH, -1900 DAI.

Avantage : Extrêmement flexible, intuitif pour les développeurs, gestion d'état complexe (nécessaire pour la DeFi/NFTs).
Inconvénient : Moins parallélisable que l'UTXO, risque de "réentrance" (un bug de sécurité spécifique aux smart contracts).

L'EVM (Ethereum Virtual Machine)

Chaque "Full Node" d'Ethereum exécute une instance de l'EVM.

• Déterministe : Le code `2 + 2` doit donner `4` sur *tous* les nœuds, en Chine, aux USA, partout, sans ambiguïté. C'est pourquoi l'EVM est très simple (pas d'accès réseau, pas de système de fichiers).
• Exécution (Bytecode & Opcodes) : Vous écrivez un contrat en **Solidity** (haut niveau). Le compilateur (solc) le transforme en **Bytecode** (bas niveau). L'EVM exécute ce bytecode en lisant des **Opcodes** (instructions machine).
• État (State) : L'EVM maintient l'état de tous les comptes (soldes, stockage des contrats). Une transaction est une requête pour *modifier* cet état.

Le Mécanisme du "Gas" (Anti-DoS)

Problème : Si le code est exécuté sur des milliers de nœuds volontaires, qu'est-ce qui empêche un attaquant de déployer un contrat avec une boucle infinie (`while(true) {}`) pour faire planter tout le réseau (Attaque par Déni de Service - DoS) ?

Solution : Le "Gas". Chaque Opcode (instruction) a un coût fixe en "Gas", une unité de calcul.

# Coûts (simplifiés)
ADD (Addition) : 3 Gas
SHA3 (Hachage) : 30 Gas
CALL (Appel contrat) : 40 Gas
SLOAD (Lire du stockage) : 200 Gas
SSTORE (Écrire dans le stockage) : 20 000 Gas (très cher)

Avant d'exécuter une transaction, l'utilisateur doit fournir un Gas Limit (ex: 50 000 Gas). L'EVM exécute le code et décrémente le Gas. Si le Gas tombe à 0 *avant* la fin de l'exécution (ex: une boucle infinie), l'EVM s'arrête, annule (revert) toutes les modifications, mais **conserve les frais payés**. L'attaque DoS est économiquement impossible.

Le Marché des Frais (EIP-1559)

Depuis 2021, le calcul des frais sur Ethereum est géré par l'EIP-1559, qui est plus complexe qu'un simple prix.

Frais Totaux = (Base Fee + Priority Fee) * Gas Used

• Gas Used : Le montant exact de Gas que votre transaction a consommé (ex: 21 000 pour un transfert simple, 150 000 pour un swap Uniswap).
• Base Fee (Frais de Base) :
  • Défini par le **protocole** (pas les mineurs/validateurs).
  • Ajusté automatiquement à chaque bloc. Si le bloc précédent était plein (>15M Gas), le Base Fee augmente. S'il était vide, il baisse.
  • Le Base Fee est **BRÛLÉ (BURN)** : il est détruit, retiré de la circulation. C'est le mécanisme déflationniste d'ETH.
• Priority Fee (Pourboire) :
  • Défini par l'**utilisateur**.
  • C'est le "pourboire" que vous payez directement au **Validateur** pour l'inciter à inclure votre transaction en priorité dans le bloc.

Propriétés du Smart Contract

• Immuable : Une fois qu'un contrat est déployé sur la blockchain (à une adresse fixe, ex: `0x123...`), son code **ne peut plus jamais être modifié**. C'est crucial pour la confiance : vous savez que les règles (ex: d'un protocole DeFi) ne changeront pas. (Des "proxies" permettent des mises à jour, mais c'est un pattern avancé).
• Déterministe : L'exécution du contrat (ex: `calculerInterets()`) donnera le même résultat pour tous les nœuds du réseau.
• Autonome : Il s'exécute automatiquement lorsque quelqu'un (un EOA) l'appelle (en lui envoyant une transaction).
• Transparent : Le bytecode (et souvent le code source Solidity) de tous les contrats publics est visible par tous (ex: sur Etherscan).

"Code is Law" (Le Code fait Loi)

C'est la philosophie centrale. Les smart contracts remplacent les contrats légaux (basés sur la confiance en la justice) par des contrats cryptographiques (basés sur la certitude mathématique).

Si le contrat de prêt dit "SI (solde < 150% du prêt), ALORS (liquider la position)", cette règle sera exécutée *automatiquement*, sans pitié, sans appel à un juge, sans délai. L'exécution du code *est* la loi.

Inconvénient : C'est une lame à double tranchant. Si le code contient un bug (ex: le hack de "The DAO" en 2016, ou un bug de "réentrance"), ce bug est lui aussi immuable et sera exploité.

Langage : Solidity

**Solidity** est le langage de programmation le plus populaire pour écrire des smart contracts sur l'EVM. C'est un langage de haut niveau, "Turing-complet", statiquement typé, qui ressemble à un mélange de C++, Python et JavaScript.

// Exemple "HelloWorld" en Solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SimpleStorage {
    
    // Une variable d'état (stockée sur la blockchain)
    uint256 private storedData; 

    // Événement (pour logger)
    event DataChanged(uint256 newValue);

    // Fonction publique (écriture - coûte du Gas)
    // Modifie l'état de la blockchain
    function set(uint256 newValue) public {
        storedData = newValue;
        emit DataChanged(newValue);
    }

    // Fonction "view" (lecture - gratuit si appelé "off-chain")
    // Ne modifie pas l'état
    function get() public view returns (uint256) {
        return storedData;
    }
}

Composabilité ("Money Legos")

La véritable puissance de la DeFi. Un smart contract peut *appeler* les fonctions d'un autre smart contract.

Une application (ex: "Instadapp") n'a pas besoin de réinventer le prêt et l'échange. Elle peut construire une interface qui, en une seule transaction, appelle `emprunter()` sur le contrat Aave, puis `swap()` sur le contrat Uniswap, puis `deposer()` sur le contrat Compound. C'est comme assembler des "Legos financiers".

Les Standards de Tokens (Ethereum)

Un "Token" est simplement un smart contract qui respecte une interface (un standard). Cela permet à tous les portefeuilles (Metamask) et marketplaces (OpenSea) de les "comprendre" et de les afficher.

• ERC-20 (Fongible) : Le standard des "monnaies" (ex: USDC, SHIB, LINK). C'est un contrat qui gère un simple mapping `(adresse -> solde)`. Tous les tokens sont identiques.
  • function balanceOf(address)
  • function transfer(address, uint)
• ERC-721 (Non Fongible) : Le standard des NFTs (ex: CryptoPunks, Bored Apes). C'est un contrat qui gère un mapping `(TokenID -> adresse_propriétaire)`. Chaque token (identifié par son ID) est unique et ne peut avoir qu'un seul propriétaire.
  • function ownerOf(uint tokenId)
  • function transferFrom(address from, address to, uint tokenId)
• ERC-1155 (Multi-Token) : Un standard hybride (utilisé par les jeux vidéo). Un seul contrat peut gérer à la fois des items fongibles (ex: 1000 "Potions de Vie") et non fongibles (ex: 1 "Épée Unique").

Critique : On-Chain vs. Off-Chain (Où est le JPG ?)

C'est la plus grande confusion. L'œuvre d'art (le JPG, MP4, etc.) n'est PAS stockée sur la blockchain. Stocker 1 Mo d'image sur Ethereum coûterait des millions de dollars en frais de Gas (SSTORE).

Ce qui est ON-CHAIN (Sur Ethereum) :

• Le Smart Contract (la "Collection").
• Le registre de propriété (ex: `Mapping(TokenID #4156 -> Adresse 0xABC...)`).
• Un **lien (URI)**.

Ce qui est OFF-CHAIN (Hors-Blockchain) :

• 1. Les Métadonnées (Metadata) : Le smart contract contient une fonction (ex: `tokenURI(4156)`) qui renvoie une URL (ex: `https://api.monsite.com/4156`).
• Ce lien pointe vers un fichier JSON qui décrit l'œuvre :

  {
    "name": "Mon Oeuvre #4156",
    "description": "...",
    "attributes": [ ... ],
    "image": "https://images.monsite.com/4156.jpg"
  }

• 2. L'Image (L'Actif) : L'URL `image` dans le JSON pointe vers le JPG final.

Le Problème de la Centralisation : Si `https://api.monsite.com` tombe en panne ou si l'entreprise fait faillite, tous les NFTs de la collection pointent vers... rien. Le token on-chain est intact, mais il certifie la propriété d'une URL morte.

Solution : IPFS & Arweave. Pour garantir la "permanence", les métadonnées et les images sont souvent stockées sur des réseaux de stockage décentralisés comme IPFS (InterPlanetary File System). L'URI dans le contrat est alors `ipfs://Qm...` (un hash de contenu), qui est permanent et ne peut être censuré.

Composants Clés d'une DAO

1. Smart Contracts (Les Statuts) : Le cœur de la DAO. Ces contrats définissent les règles de l'organisation :
   • Comment la gouvernance fonctionne (qui peut voter ?).
   • Comment les fonds peuvent être dépensés.
   • Comment les règles elles-mêmes peuvent être modifiées.
2. La Trésorerie (Le Coffre) : La DAO possède un "coffre" (un smart contract) qui détient les fonds (ETH, USDC, etc.). **Aucun individu** ne peut dépenser cet argent. Seul un **vote réussi** de la communauté (exécuté par le smart contract) peut initier un transfert.
3. Tokens de Gouvernance (Les "Actions") :
   • Pour voter, les membres de la DAO utilisent des "tokens de gouvernance" (ex: le token UNI pour Uniswap, MKR pour MakerDAO).
   • Le plus souvent, le poids de vote est 1 Token = 1 Voix.
   • Ces tokens sont utilisés pour créer des **Propositions d'Amélioration** (ex: "Proposition : Dépenser 10 000 DAI pour payer un développeur").
   • Les détenteurs de tokens votent ("Oui", "Non", "Abstention").

Le Processus de Gouvernance

1. Proposition : Un membre (détenant assez de tokens) soumet une proposition (ex: "Mettre à jour le taux d'intérêt d'Aave à 5%"). Le code de la proposition est inclus.
2. Vote : Une période de vote (ex: 7 jours) est ouverte. Les détenteurs de tokens votent en signant des transactions (ou via des plateformes comme Snapshot pour des votes "off-chain" sans frais).
3. Quorum & Majorité : La proposition doit atteindre un **Quorum** (ex: 4% de tous les tokens doivent participer) ET une **Majorité** (ex: >50% de Oui).
4. Exécution : Si le vote est réussi, le smart contract de gouvernance exécute *automatiquement* la proposition (ex: il appelle la fonction `setInterestRate(5)` sur le contrat Aave).

Avantages & Inconvénients

• Avantages : Transparence totale (règles et trésorerie visibles), alignement des incitations (les détenteurs de tokens votent dans l'intérêt du protocole qu'ils possèdent), pas d'autorité centrale.
• Inconvénients : Très lent (un vote de 7 jours pour une décision simple), risque d'apathie des votants, ploutocratie (les "baleines" avec le plus de tokens ont le plus de pouvoir), complexité légale.

1. Optimistic Rollups (ex: Arbitrum, Optimism)

Philosophie : "Optimiste" (Confiance puis Vérification).

L'Optimistic Rollup poste le "batch" de transactions sur L1 et dit : "Je jure que ces transactions sont valides".

• Fenêtre de Litige (Fraud Proof) : Le système est "optimiste" et suppose que le batch est valide. S'ouvre alors une "Fenêtre de Litige" (ex: 7 jours).
• Pendant 7 jours, n'importe qui ("Watchers") peut inspecter le batch. S'ils trouvent une fraude, ils peuvent soumettre une "Preuve de Fraude" (Fraud Proof) au L1.
• Litige : Le L1 (Ethereum) exécute la transaction frauduleuse et vérifie. Si la fraude est prouvée, le batch est annulé et le validateur L2 (le "Sequencer") est lourdement pénalisé (son "stake" est slashé).
• Finalité : Si personne ne conteste après 7 jours, le batch est considéré comme final.

Avantage : Simple, compatible EVM (facile de copier/coller des DApps).
Inconvénient : Le temps de retrait (Withdrawal) est de 7 jours (le temps de la fenêtre de litige).

2. ZK-Rollups (Zero-Knowledge) (ex: zkSync, Starknet)

Philosophie : "Pessimiste" (Vérification Cryptographique).

Le ZK-Rollup poste le "batch" de transactions sur L1, accompagné d'une preuve cryptographique (SNARK ou STARK).

• Preuve ZK : Cette preuve (générée par un "Prover" L2, très coûteux en calcul) certifie mathématiquement : "J'ai exécuté ces 1000 transactions, et je vous *prouve* (sans vous montrer les détails, d'où "Zero-Knowledge") que le nouvel état est correct."
• Vérification L1 : Un smart contract sur L1 (le "Verifier") vérifie cette preuve. La vérification d'une preuve ZK est *extrêmement* rapide et peu coûteuse (en Gas), même si la preuve elle-même a été longue à générer.
• Finalité : Dès que le contrat L1 accepte la preuve (quelques minutes), le batch est considéré comme final.

Avantage : Finalité quasi-instantanée (retraits rapides), sécurité basée sur la cryptographie (pas sur la théorie des jeux).
Inconvénient : Technologie extrêmement complexe, difficile à rendre compatible EVM (zEVM), génération de la preuve coûteuse.

La Paire de Clés (Asymétrique)

Chaque utilisateur (EOA) est défini par une paire de clés mathématiquement liées :

• 1. Clé Privée (Private Key) :
  • Un nombre aléatoire immense (256 bits), ex: `E9873D...`
  • C'est votre **MOT DE PASSE MAÎTRE**. Il doit rester ABSOLUMENT SECRET.
  • Elle est utilisée pour **SIGNER** (autoriser) les transactions.
  • "Not your keys, not your coins" : Si vous perdez votre clé privée, vous perdez vos fonds à jamais. Si quelqu'un la vole, il vole vos fonds.
• 2. Clé Publique (Public Key) :
  • Dérivée mathématiquement de la clé privée (via ECDSA).
  • Il est impossible de retrouver la clé privée à partir de la clé publique (sens unique).
  • Elle est utilisée pour **VÉRIFIER** les signatures.
• 3. Adresse Publique :
  • Une version hachée et raccourcie de la Clé Publique (ex: `0x123...abc`).
  • C'est votre **"IBAN"** ou votre "RIB". C'est l'adresse que vous donnez publiquement pour recevoir des fonds.

Signer une Transaction

1. Vous créez une transaction (ex: "Envoyer 1 ETH à Bob").
2. Votre "Wallet" (portefeuille) signe cette transaction en utilisant votre **Clé Privée**.
3. Cela produit une **Signature Numérique**.
4. Vous diffusez la Transaction + la Signature au réseau.
5. Chaque nœud du réseau utilise votre **Clé Publique** (connue de tous) pour vérifier que la Signature correspond bien à la Transaction.
6. Si la vérification réussit, le réseau sait que la transaction a bien été émise par le détenteur de la Clé Privée correspondante, sans que la clé privée n'ait jamais été révélée.

Types de Wallets (Portefeuilles)

Un "Wallet" (portefeuille) est un logiciel ou un matériel qui **gère vos clés privées** et vous permet de signer des transactions.

1. Custodial Wallets (Dépositaire)

• Exemple : Votre compte sur Coinbase, Binance, Kraken.
• Fonctionnement : La plateforme d'échange (la "bourse") gère la clé privée pour vous. Vous vous connectez avec un email/mot de passe.
• Avantages : Simple, familier, récupération de mot de passe possible.
• Inconvénients : **"Not your keys, not your coins"**. Vous ne possédez pas réellement vos cryptos. Vous faites confiance à Coinbase pour ne pas se faire hacker (ex: FTX) ou pour ne pas geler votre compte. Vous n'interagissez pas avec la blockchain, mais avec la BDD de Coinbase.

2. Non-Custodial Wallets (Auto-Garde)

Vous (et vous seul) détenez votre clé privée.

• Software Wallets (Hot) : (ex: Metamask, Rabby, Phantom). La clé privée est stockée (chiffrée) dans une extension de navigateur ou une app mobile. "Chaud" car connecté à Internet.
  • Seed Phrase (Phrase Mnémonique) : Votre clé privée (illisible) est représentée par une suite de 12 ou 24 mots (ex: "chat montagne rivière..."). C'est cette phrase que vous devez sauvegarder (offline) pour récupérer votre compte.
• Hardware Wallets (Cold) : (ex: Ledger, Trezor). La clé privée est stockée sur un appareil physique (une "clé USB" sécurisée) qui n'est **jamais** connecté directement à Internet.
  • Pour signer une transaction, la transaction est envoyée à l'appareil, qui la signe *à l'intérieur* de sa puce sécurisée, et ne renvoie que la signature.
  • C'est la méthode la plus sécurisée pour détenir des actifs, car la clé privée ne quitte jamais l'appareil.