🛰️ Node Operations & Infrastructure

Architecture Post-Merge (Ethereum PoS)

Depuis "The Merge" (le passage au Proof-of-Stake), un nœud Ethereum n'est plus un seul logiciel, mais **deux clients** qui travaillent ensemble :

2. Nœud Archive (Archive Node) - "L'Historien"

• Rôle : Un Nœud Complet qui a été configuré avec le "flag" --gcmode archive.
• Stockage : Il **NE FAIT PAS** d'élagage (pruning). Il stocke l'**intégralité de l'historique de tous les états** depuis le Bloc Génésis.
• Taille (Ethereum) : Massive. 16 To+ (Téraoctets) et en augmentation rapide. Extrêmement coûteux.
• Confiance : 100% "Trustless".
• Usage (Critique) :
  • Explorateurs de Blocs (Etherscan) : Pour pouvoir répondre à la question "Quel était le solde d'Alice au bloc #5,000,000 ?".
  • Plateformes d'Analyse (Dune, TheGraph) : Pour indexer l'historique (l'ETL).
  • Outils de "debugging" (débogage) complexes.

3. Client Léger (Light Client) - "Le Consommateur"

• Rôle : Un client qui ne participe pas à la validation complète.
• Stockage : Il ne télécharge **que les En-têtes de Bloc (Block Headers)** (très léger, quelques Go). Il n'a *pas* l'état (les soldes, le stockage) ni le corps des blocs.
• Confiance : "Trust-minimized". Il doit **faire confiance** à un Nœud Complet (auquel il se connecte) pour lui *donner* l'état.
• Sécurité (SPV) : Il se protège en utilisant les **Arbres de Merkle**. Pour vérifier son propre solde, il demande au Nœud Complet : "Donne-moi mon solde ET la Preuve de Merkle (Merkle Proof) qui prouve que ce solde est bien inclus dans l'en-tête de bloc #XXXX que je possède."
• Usage : Wallets Mobiles, Portefeuilles Navigateur (Metamask dans sa configuration "légère"), appareils IoT.

2. Appels d'Écriture (Payants)

Un nœud RPC public (comme Infura) ne détient pas votre clé privée. Il est "trustless". Vous ne pouvez pas lui dire "Envoyez 1 ETH de ma part".

Votre DApp (via Metamask/Ethers.js) doit **signer la transaction localement** (avec la clé privée), puis envoyer la transaction **brute et signée** (la "raw transaction") au nœud RPC. Le nœud n'a plus qu'à la *vérifier* et la *propager*.

Exemple : eth_sendRawTransaction

// 1. DApp (Ethers.js) + Metamask (Signer)
//    - Crée la Tx: { to: "0x...", value: 1 ETH, gasLimit: 21000, ... }
//    - Metamask la SIGNE (avec la clé privée) -> "0xf86...abc" (longue string hex)

// 2. DApp -> Nœud RPC
// REQUÊTE :
{
    "jsonrpc": "2.0",
    "method": "eth_sendRawTransaction",
    "params": [
        "0xf86...abc" // La transaction brute et signée
    ],
    "id": 3
}

// 3. Nœud RPC -> DApp
// RÉPONSE (immédiate) :
{
    "jsonrpc": "2.0",
    "id": 3,
    "result": "0xe670...192b" // Le HASH de la transaction (le "reçu")
}
// Le nœud dit: "OK, j'ai reçu votre tx, je la propage au Mempool.
// Voici son ID (hash) pour que vous puissiez la suivre."

2. La Solution : Node-as-a-Service (NaaS)

Exemples : Infura (ConsenSys), Alchemy, QuickNode, Ankr.

Analogie : C'est le **"AWS du Web3"**. Au lieu de gérer votre propre serveur physique (Nœud), vous louez l'accès à une flotte de serveurs gérés par un expert.

Architecture (Ex: Infura)

Infura n'est pas "un" nœud. C'est une architecture complexe :

[ DApp (Ethers.js) ]
          |
          |  (Requête RPC)
          ▼
[ Load Balancer (Répartiteur de Charge) ]
  (https://mainnet.infura.io/v3/API_KEY)
          |
          |
    /-----|-----\
    |     |     |
    ▼     ▼     ▼
[ Nœud 1 ] [ Nœud 2 ] ... [ Nœud 500 ]
 (Geth)     (Geth)          (Geth)

• API Key : Infura vous donne une clé API. C'est votre "endpoint" RPC.
• Load Balancer : Ce "endpoint" est un répartiteur de charge qui reçoit votre requête (ex: `eth_getBalance`) et la redirige vers le nœud le *moins* occupé de leur flotte de *milliers* de nœuds Full/Archive.
• Auto-Scaling : Si un nœud tombe, le load balancer l'exclut. Si le trafic augmente, Infura démarre de nouveaux nœuds.

Le Compromis : Le Retour de la Centralisation

• Avantages : Fiabilité (99.99% Uptime), Scalabilité (millions de RPS), Zéro Maintenance.
• Inconvénients ("La Décentralisation en Danger") :
  • Point de Défaillance (SPOF) : Si Infura "tombe en panne" (c'est arrivé), ~80% des DApps de l'écosystème (Metamask, Uniswap, Aave...) tombent en panne en même temps.
  • Censure : Infura est une entreprise américaine (ConsenSys). Elle *doit* se plier à la loi (OFAC). En 2022, Infura a dû bloquer les requêtes RPC provenant d'IPs de certaines juridictions (ex: Iran, Corée du Nord) et a dû bloquer les requêtes `eth_call` demandant l'état du contrat sanctionné "Tornado Cash".
  • Surveillance : Ils voient votre IP, votre adresse de wallet, et toutes les requêtes que vous faites (ils peuvent lier votre IP à votre wallet).

2. Incitations (Récompenses)

Un validateur est payé pour faire son travail (être en ligne 24/7, valider, proposer). Les récompenses proviennent de deux sources :

• 1. Récompenses d'Émission (Inflation) :
  • Le protocole *crée* (minte) de nouveaux ETH à chaque "epoch" (~6.4 min) et les distribue aux validateurs qui ont voté (attesté) correctement.
  • C'est le "rendement de base" (ex: ~3-4% APY). C'est le paiement pour la *sécurité* du réseau.
• 2. Frais de Transaction (Revenus) :
  • "Priority Fees" (Pourboires) : Les frais (le "tip") que les utilisateurs paient (via EIP-1559) pour que leur transaction soit incluse en priorité. Ces frais vont *directement* au Validateur qui a proposé le bloc.
  • MEV (Maximal Extractable Value) : (Voir 4.1). Les "bribes" (pots-de-vin) payés par les "Searchers/Builders" (via Flashbots) pour que le Validateur inclue leurs "bundles" (ex: un arbitrage ou un "sandwich attack").

Le revenu total d'un validateur est `Récompenses d'Émission + Pourboires + MEV`.

3. Risques (La Pénalité : Le "Slashing")

Le "Stake" de 32 ETH est une **caution**. Il garantit que le validateur a un "jeu économique" (skin in the game). Il peut perdre cet argent s'il se comporte mal.

Type 1 : Pénalité (Légère) - "Inactivity Leak"

• Faute : Le validateur est **hors-ligne (offline)**. (Ex: panne de courant, bug logiciel).
• Conséquence : Le validateur "fuit" (leaks) une petite partie de son stake, équivalente aux récompenses qu'il *aurait* dû gagner. C'est une petite tape sur les doigts pour l'inciter à revenir en ligne.

Type 2 : Pénalité (Sévère) - "Slashing"

• Détection : C'est une faute *cryptographiquement prouvable*. Un autre validateur (un "whistleblower") voit les deux messages signés contradictoires et les publie sur la chaîne.
• Conséquence (Le "Slashing") :
  1. Le protocole **détruit (brûle)** immédiatement une partie du stake du validateur (ex: 1/32ème, soit 1 ETH).
  2. Le validateur est "flagué" (marqué) et subit une pénalité de "fuite" (leak) *massive* jusqu'à ce qu'il soit éjecté (ce qui peut lui coûter 50% ou plus de son stake).
  3. Le "whistleblower" (le dénonciateur) reçoit une récompense (une partie de l'ETH slashé).
• Objectif : Rendre une attaque (ex: 51%) économiquement suicidaire. L'attaquant perdrait des milliards de dollars (son stake) s'il était détecté.

2. Staking-as-a-Service (SaaS)

• Acteur : Vous + un service (ex: Kiln, BloxStaking, Firedancer).
• Capital Requis : 32 ETH.
• Mécanisme : Vous avez les 32 ETH. Vous *générez* vos clés de staking, mais vous **déléguez** la *tâche d'exécution* (le "node ops") à une entreprise spécialisée.
• Avantages :
  • **Non-Custodial** (vous détenez la clé de *retrait*, l'entreprise ne détient que la clé de *signature*).
  • Pas de maux de tête techniques (ils gèrent l'uptime 24/7).
• Inconvénients :
  • Coûteux (le service prend une **commission** sur vos récompenses, ex: 10%).
  • Illiquide (vos 32 ETH sont toujours bloqués).

3. Pooled Staking (Centralisé / CEX)

• Acteur : Vous + une Bourse (Binance, Kraken, Coinbase).
• Capital Requis : 0.01 ETH (ou moins).
• Mécanisme : Vous déposez 0.1 ETH sur votre compte "Staking" Binance. Binance "poole" (regroupe) les ETH de 1 million d'utilisateurs, crée des validateurs de 32 ETH, et gère tout.
• Avantages :
  • **Extrêmement simple.** (2 clics).
  • Accessible (pas de minimum de 32 ETH).
• Inconvénients :
  • **Custodial (Risque Maximal) :** "Not your keys, not your coins." Vous donnez vos ETH à Binance. Si Binance fait faillite (FTX), vos ETH sont **perdus**.
  • Risque de Centralisation : Si 80% des utilisateurs stakent via 3 CEX, ces 3 CEX contrôlent 80% du consensus Ethereum (risque de censure).
  • Opaque (vous ne savez pas ce qu'ils font avec vos ETH).

4. Pooled Staking (Décentralisé / Liquide)

• Acteur : Vous + un Protocole (Lido, Rocket Pool).
• Capital Requis : 0.01 ETH (ou moins).
• Mécanisme : (Détaillé en 3.3). Vous déposez vos ETH dans un **smart contract** (le pool).
• Avantages :
  • Accessible (pas de minimum de 32 ETH).
  • **Non-Custodial** (vous détenez un token LST, pas une promesse d'un CEX).
  • **LIQUIDE !** C'est l'avantage clé. Vous recevez un "reçu" (ex: stETH) que vous pouvez utiliser en DeFi.
• Inconvénients :
  • Risque de Smart Contract : Si le contrat Lido est hacké, tout le pool est drainé.
  • Risque de Centralisation (Protocole) : Lido est devenu si dominant (>30% du stake) qu'il représente un risque systémique pour Ethereum (voir 3.3).

2. Le "Money Lego" : stETH en DeFi

Vous avez maintenant 10 stETH (valeur 10 ETH), et ce solde génère ~3.5% APY (le rendement du staking).

Le $stETH est **liquide** et **composable**. Vous pouvez maintenant :

• Vendre : Aller sur Curve et "swapper" vos 10 stETH contre 10 ETH (ou 9.99 ETH, s'il y a un léger "depeg"). Vous avez quitté votre position de staking instantanément.
• Prêter (Lending) : Déposer vos 10 stETH comme **collatéral** sur Aave (qui l'accepte).
• Emprunter (Leverage) :
  1. Déposer 10 stETH (valeur $20k) sur Aave.
  2. Emprunter $10k d'ETH (contre votre stETH).
  3. Déposer ces 5 ETH (valeur $10k) *à nouveau* dans Lido, pour recevoir 5 stETH.
  4. Vous avez maintenant 15 stETH (gagnant 3.5% sur 15 ETH) et une dette de 5 ETH (payant 2% d'intérêts). Vous avez créé un "levier" (leverage) sur le rendement du staking.

C'est le "Liquid Staking Loop", qui rend le capital de staking (autrefois mort) productif.

3. Les Risques du Staking Liquide

• Risque de Smart Contract : Si le contrat Lido est hacké, *tout* l'ETH du pool (des milliards) est volé.
• Risque de Slashing : Si les Opérateurs de Nœuds de Lido se comportent mal (en masse) et sont "slashés", la valeur du stETH baissera (car le pool aura moins d'ETH). Lido utilise une assurance pour couvrir cela.
• Risque de "Depeg" : Le prix `stETH / ETH` n'est pas 1:1. C'est un marché secondaire (sur Curve). Si beaucoup de gens veulent "sortir" (vendre stETH) et qu'il y a peu d'acheteurs (de déposants), le prix peut "depeg" (ex: 1 stETH = 0.95 ETH, comme lors du crash de Celsius/3AC). Si vous avez utilisé stETH comme collatéral, ce "depeg" peut vous liquider.
• Risque de Centralisation (Systémique) : C'est le plus grand risque. Lido contrôle plus de **30%** de *tous* les validateurs Ethereum. S'il atteignait 51% (ou 66%), la DAO Lido (relativement centralisée) aurait le pouvoir de censurer ou de "forker" la chaîne Ethereum. C'est une menace majeure pour la neutralité du protocole.

La Solution : Flashbots & PBS (Proposer-Builder Separation)

Problème (Guerre de Gas) : Ce "jeu" du MEV (front-running, etc.) encombrait le réseau. Les bots se battaient en augmentant les frais de Gas, faisant payer *tous* les utilisateurs (externalité négative).

Solution (Flashbots) : Flashbots a créé un **canal de communication privé (une "enchère scellée")** pour le MEV.

Le Marché (Pré-PBS)

• Searchers (Chercheurs) : Des bots qui *trouvent* les opportunités de MEV (le "sandwich").
• Bundles (Paquets) : Le Searcher crée un "paquet" de transactions (ex: [Mon Achat, Tx d'Alice, Ma Vente]).
• Bribe (Pot-de-vin) : Le Searcher attache un "pot-de-vin" (ex: 0.1 ETH) au paquet, payé directement au Validateur.
• Flashbots Relay (Relais) : Le Searcher envoie ce "bundle" au Relais Flashbots (un Mempool privé), *pas* au Mempool public.
• Validateur (Proposeur) : Le Validateur (qui exécute un logiciel spécial, `mev-boost`) reçoit les "bundles" de Flashbots, choisit les plus rentables (ceux avec les plus grosses bribes), et les inclut en tête de son bloc.
• Résultat : La "guerre de Gas" (visible) a disparu, remplacée par une "guerre de bribes" (invisible, privée).

L'Étape Finale : PBS (Proposer-Builder Separation)

C'est la formalisation de ce mécanisme dans le protocole Ethereum lui-même (à venir).

• Le Validateur (Proposeur) : N'a plus qu'un seul travail : être en ligne et signer. Il ne "voit" même plus les transactions du Mempool.
• Le Builder (Constructeur) : Un *nouveau rôle* (des entités spécialisées, ex: Flashbots). Les Builders sont en compétition pour construire le **bloc le plus rentable** (en agrégeant les bribes des Searchers et les tx normales).
• L'Enchère : Les Builders (ex: 10) soumettent leur "offre" (le montant total des bribes qu'ils sont prêts à payer) au Proposeur.
• Le Choix : Le Proposeur (Validateur) choisit simplement l'offre la plus élevée (ex: "Le Builder A m'offre 1.5 ETH"), signe l'en-tête du bloc (sans voir le contenu, pour éviter le vol), et empoche la récompense.

Conséquence : Cela sépare les rôles (complexité) et rend le MEV plus efficace et démocratique, tout en augmentant les revenus des Stakers (Validateurs).