Compact Block Filters

Anna attend un paiement dans le portefeuille de son téléphone. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Les blocs sont des ensembles de transactions, mais le téléphone n’a pas besoin de tous les télécharger intégralement. Il peut d’abord parcourir de petits filtres, comme on consulte l’index d’un livre avant d’ouvrir la page utile. Pour un même bloc et un même type de filtre, tous reçoivent le même résumé ; la sélection propre à Anna se fait sur son téléphone. Les documents techniques BIP 157 et BIP 158 se partagent les tâches : le premier définit l’obtention et le contrôle des filtres, le second leur contenu et leur construction. Le portefeuille vérifie d’abord les en-têtes de blocs, les données essentielles qui les relient en une chaîne, puis récupère les données de contrôle des filtres et les filtres eux-mêmes. S’il trouve une correspondance, il télécharge le bloc entier et cherche la transaction réelle. Malgré leur nom proche, les Compact Blocks du BIP 152 répondent à un autre besoin : transmettre rapidement les nouveaux blocs entre nœuds. Un nœud est un logiciel qui vérifie les transactions et les blocs et communique avec les autres participants du réseau. [1] [2] [5] [6]

Une transaction Bitcoin crée des sorties : des montants assortis de conditions pour les dépenser plus tard. Le code de ces conditions s’appelle scriptPubKey. Une entrée d’une nouvelle transaction désigne une ancienne sortie qu’elle dépense. Le filtre basic, identifié par 0x00, inclut donc les scripts des nouvelles sorties et ceux des anciennes sorties dépensées dans le bloc. Anna peut ainsi rechercher des fonds reçus ou dépensés. Les nouveaux scripts commençant par OP_RETURN, une instruction qui rend la sortie indépensable, sont exclus. L’entrée spéciale de la transaction coinbase l’est aussi : cette transaction attribue la récompense au mineur sans dépenser de sortie antérieure. Les éléments vides sont omis et les doublons ne comptent qu’une fois. Ce n’est pas une liste de tous les identifiants de transaction txid, des adresses en texte ou des données witness comme les signatures. La construction correcte du filtre nécessite aussi les anciennes sorties dépensées, pas seulement le nouveau bloc. [2]

Un serveur pourrait envoyer à Anna un résumé omettant volontairement son paiement. Le portefeuille contrôle donc aussi les liens avec les filtres précédents. Un hash est une courte empreinte numérique de données. Appliquer deux fois SHA-256 au filtre enregistré produit son double-SHA256. On joint cette empreinte à l’en-tête du filtre précédent et on répète le calcul pour obtenir l’en-tête suivant. Modifier un ancien filtre change donc les données de contrôle qui suivent. Mais l’en-tête du bloc, protégé par le minage, ne contient pas d’empreinte de cette chaîne auxiliaire de filtres. Si tous les serveurs fournissent la même fausse chaîne, ses empreintes peuvent parfaitement s’enchaîner. La cohérence mathématique ne prouve pas, à elle seule, que le résumé correspond au bloc réel. [1]

BIP 157 recommande donc plusieurs connexions à des nœuds indépendants, appelés peers dans cet échange. Une connexion sécurisée à un nœud de confiance, par exemple le sien, est une autre possibilité. Face à des chaînes de filtres contradictoires, le portefeuille repère la première divergence. Il peut reconstruire le filtre correct avec le bloc concerné et les anciennes sorties nécessaires. La garantie d’identifier les bons filtres suppose au moins un peer honnête ; plusieurs connexions au même attaquant ne suffisent pas. La chaîne elle-même peut changer : lors d’une réorganisation, les nœuds remplacent une partie de sa fin par une branche cumulant davantage de travail démontré. Le portefeuille doit suivre les filtres de cette branche et réexaminer les paiements concernés. Une confirmation déjà trouvée dépend toujours de la chaîne acceptée par le réseau. [1] [2]

Avec l’ancienne méthode BIP 37, le portefeuille envoyait au serveur son propre filtre décrivant les données à surveiller. Les Compact Block Filters inversent la démarche : le portefeuille télécharge des données générales et effectue sa sélection personnelle chez lui. Cela limite la divulgation des scripts surveillés. Le fournisseur voit néanmoins quels blocs complets Anna demande ensuite et peut relier ces demandes à son adresse IP, l’adresse réseau de sa connexion. Des visites répétées peuvent révéler d’autres habitudes. BIP 157 recommande donc de choisir aléatoirement les sources de blocs parmi les nœuds auxquels le portefeuille a ouvert des connexions. Le bloc peut provenir d’un autre nœud que son filtre. La confidentialité s’améliore, sans garantie d’anonymat. [1]

Les filtres décrivent des blocs déjà intégrés à la chaîne. Ils ne couvrent pas le Mempool courant, c’est-à-dire les transactions non confirmées qu’un nœud garde pour les relayer ou les miner. Une correspondance ne prouve pas non plus qu’Anna possède la clé nécessaire pour dépenser les fonds repérés. Une clé privée est une valeur numérique secrète dont le portefeuille se sert pour créer une signature numérique autorisant une dépense. Le portefeuille doit vérifier la transaction réelle et son inclusion dans le bloc. Un client léger ne vérifie pourtant pas chaque transaction de chaque bloc selon toutes les règles, comme le fait un Full Node. L’économie de ressources implique donc un véritable compromis de sécurité. La disponibilité est une autre question : un Pruned Node peut supprimer d’anciens blocs après vérification tout en conservant leurs filtres. Anna obtient alors le résumé, mais doit chercher le bloc complet ailleurs. L’élagage seul ne signifie pas que le nœud cesse de vérifier toutes les règles. [1] [5]

La petite taille a une contrepartie : le filtre peut répondre « peut-être » alors que l’élément recherché n’est pas dans le bloc. C’est un faux positif. Anna télécharge alors un bloc inutilement, mais son portefeuille n’y trouve pas le paiement supposé et ne doit pas le comptabiliser. Un filtre correct ne manque aucun élément effectivement couvert par ses règles ; cela ne rend pas fiables les données fabriquées par un serveur malhonnête. Techniquement, SipHash-2-4 transforme les éléments en nombres dans un intervalle de taille N × M, où N est leur nombre. On trie ces nombres et on enregistre leurs écarts de façon compacte avec le codage Golomb-Rice. P=19 règle le codage ; M=784931 influe sur les correspondances accidentelles, dont la probabilité est d’environ 1/M pour une recherche unique hors de l’ensemble. L’octet est une unité courante de mesure des données. La clé SipHash correspond aux premiers 16 octets du hash du bloc en ordre little-endian, les octets les moins significatifs en premier. Ce n’est pas une clé secrète du portefeuille. Ici, SipHash transforme les éléments en nombres pour le filtre, sans les chiffrer. Le filtre enregistré commence par N au format CompactSize, destiné aux entiers non négatifs. [2]

Lors de la révision du 2026-10-17, les deux documents ont le statut Deployed : le protocole est déployé, mais pas nécessairement pris en charge par tous les portefeuilles. L’exemple de configuration suivant concerne précisément Bitcoin Core 29.0. -blockfilterindex construit l’index local. -peerblockfilters active le service aux autres nœuds et exige un index basic ; NODE_COMPACT_FILTERS annonce cette capacité. L’interface de programmation RPC permet à getblockfilter de renvoyer les champs filter et header d’un bloc choisi. Une requête RPC réussie ne prouve donc pas que les autres nœuds peuvent obtenir les filtres sur le réseau. Pour lire la spécification : getcfilters/cfilter transporte les filtres, getcfheaders/cfheaders les données d’enchaînement, et getcfcheckpt/cfcheckpt les points de contrôle de cette chaîne auxiliaire. Ce sont des noms de messages réseau, pas des commandes à saisir dans un portefeuille mobile. [3] [4]