Nœuds élagués et clients légers (SPV)

Curiosité

1. Comment un nœud peut-il valider l’ensemble de l’histoire de Bitcoin sans conserver chaque bloc indéfiniment ?
2. Quel mécanisme cryptographique précis permet à un portefeuille mobile de vérifier son solde sans télécharger des centaines de gigaoctets de données ?
3. Pourquoi les filtres d’origine, censés protéger la vie privée des utilisateurs de portefeuilles légers, ont-ils exposé leur identité, et comment ce défaut a-t-il été corrigé ?

Explorer

1. Validation complète et stockage complet sont dissociables. Tout nœud qui valide doit traiter chaque bloc une fois pour constituer l’ensemble actuel des sorties non dépensées, mais il n’est pas tenu de conserver les anciens blocs par la suite. Certains clients vont plus loin et renoncent entièrement à la validation, se contentant de vérifier que les transactions figurent dans des blocs dotés d’une preuve de travail suffisante. Ces choix arbitrent entre l’espace disque, la bande passante et la confidentialité d’un côté, et l’indépendance de l’autre.
2. Un nœud élagué effectue la même validation initiale de chaque bloc depuis le bloc de genèse, mais supprime ensuite les anciennes données de blocs pour économiser de l’espace disque. Le paramètre `prune` de Bitcoin Core conserve au moins 550 Mo de blocs récents et supprime les plus anciens une fois vérifiés. Il reste un validateur complet, capable de faire respecter les règles de consensus et de protéger le portefeuille de son propriétaire grâce à une vérification indépendante. En revanche, il ne peut plus fournir de blocs historiques aux autres pairs ni prendre en charge les fonctionnalités nécessitant des recherches profondes dans la chaîne, comme `txindex`.
3. Les clients légers, ou nœuds SPV, adoptent une approche différente en ne validant pas l’ensemble des règles. Ils ne téléchargent que les en-têtes de blocs, qui contiennent la racine de Merkle de toutes les transactions du bloc. Pour vérifier l’inclusion d’une transaction donnée, le client demande une preuve de Merkle à un pair et la vérifie par rapport à la racine figurant dans l’en-tête. Cette approche repose sur l’hypothèse que la chaîne comportant le plus de travail cumulé est valide, et sacrifie l’application indépendante des règles au profit d’une réduction drastique des besoins en stockage et en bande passante.
4. Les premières implémentations SPV utilisaient les filtres de Bloom du BIP37 pour permettre aux portefeuilles de ne demander à leurs pairs que les transactions pertinentes. Le portefeuille envoyait un filtre décrivant ses adresses ; les pairs parcouraient leur mempool et renvoyaient les transactions correspondantes. Cette conception portait atteinte à la confidentialité : en observant les filtres, un pair malveillant pouvait déduire quelles adresses appartenaient à l’utilisateur et suivre son activité. Bitcoin Core a cessé de servir les filtres de Bloom par défaut en 2019 (version 0.19).
5. Les filtres de blocs compacts (BIP157/158) ont inversé ce flux pour rétablir la confidentialité. Au lieu que le portefeuille révèle ses adresses, les nœuds complets publient un filtre compact pour chaque bloc ; le client télécharge ces filtres et les teste localement avec ses propres clés. Lorsqu’un filtre correspond, le client télécharge le bloc entier, car demander une seule transaction la révélerait au pair. Les pairs ne peuvent ainsi pas savoir quelles adresses le portefeuille surveille, ce qui améliore considérablement la confidentialité de l’utilisateur tout en conservant une synchronisation efficace.
6. De nombreux portefeuilles mobiles s’appuient sur un serveur tiers, par exemple un serveur Electrum, pour obtenir les données, tout en vérifiant eux-mêmes les preuves de Merkle par rapport aux en-têtes de blocs. Le compromis est clair : commodité et faible consommation de ressources d’un côté, vérification indépendante et confidentialité de l’autre. Un utilisateur qui fait tourner un nœud élagué conserve une capacité de validation complète, mais ne peut servir qu’un historique limité ; un portefeuille SPV conserve une empreinte minimale, mais dépend des pairs pour lui montrer chaque transaction pertinente et suppose, sans le vérifier, que la chaîne comportant le plus de travail est valide.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• Satoshi Nakamoto, 'Bitcoin: A Peer-to-Peer Electronic Cash System' (2008), Section 8
• BIP37: Connection Bloom filtering
• BIP157: Client Side Block Filtering
• BIP158: Compact Block Filters for Light Clients
• Bitcoin Core release notes 0.11.0 (pruning)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 10