Compact Block Filters

Anna rouvre son portefeuille mobile après une absence. L’application doit déterminer si quelqu’un lui a payé de l’argent depuis la dernière connexion ou si certains fonds ont été dépensés. Elle télécharge de petits filtres plutôt que toutes les transactions, puis les compare aux conditions des sorties surveillées. Une sortie est la partie d’une transaction qui fixe un montant et les conditions de sa dépense ultérieure. En cas de correspondance, l’application demande le bloc entier et cherche la transaction réelle. Elle ne doit pas augmenter le solde sur la seule foi du filtre. Celui-ci n’est ni relevé de compte ni preuve de propriété. Avant la recherche, le client synchronise les en-têtes, données succinctes identifiant les blocs, et les en-têtes liés des filtres. [1]

Avec l’ancienne approche BIP 37, le client envoyait à un pair un filtre construit à partir des données à surveiller. Ici, le sens s’inverse : le serveur fournit le filtre du bloc, Anna cherche localement. Pour un même bloc et un même type de filtre, les clients reçoivent le même contenu. Ils n’ont donc pas à révéler directement leurs scripts recherchés à chaque serveur. Cela ne rend pas anonyme : le pair peut encore voir l’adresse IP, les horaires et les blocs complets demandés ensuite. Répartir les téléchargements entre plusieurs pairs limite les informations réunies par chacun, sans supprimer toute possibilité de corrélation. [1]

Les Compact Block Filters sélectionnent les blocs à examiner. Compact Blocks, selon BIP 152, traite un autre problème : économiser des données lors du transfert d’un bloc grâce à de courts identifiants de transactions souvent déjà connues du destinataire. Celui-ci les retrouve dans son Mempool, sa réserve locale de transactions non confirmées, et demande celles qui manquent. Aucun des deux outils ne vérifie à lui seul toutes les règles de Bitcoin. Un Full Node, ou nœud complet, valide indépendamment blocs et transactions selon les règles du réseau. Un portefeuille léger qui ne contrôle que les en-têtes et l’inclusion de sa transaction effectue une vérification plus restreinte. Économie de données et validation complète sont distinctes. [1] [5]

BIP 158 définit le format. Le filtre basic inclut le scriptPubKey, le script fixant les conditions de dépense, des nouvelles sorties, sauf celles commençant par OP_RETURN. Il comprend aussi les scripts des sorties antérieures dépensées dans le bloc. Pour les entrées, l’exception est la coinbase, première transaction du bloc distribuant la rémunération du mineur, qui ne dépense pas de sorties antérieures ordinaires. Ses nouvelles sorties suivent les mêmes règles d’inclusion que les autres nouvelles sorties. Les éléments vides sont omis. Le portefeuille doit convertir une adresse dans le bon script ; chercher son texte imprimé ne suffit pas. Le filtre n’est pas un moteur général de recherche de txid, les identifiants de transactions, de données witness telles que les signatures, ou de notes arbitraires. [2] [3]

Après téléchargement, Anna peut constater que rien dans le bloc ne la concerne. Cette fausse correspondance est le compromis normal d’un filtre compact, pas à elle seule la preuve d’une erreur. Les éléments sont transformés en empreintes numériques, triés, puis leurs écarts sont stockés de façon compacte par codage Golomb-Rice. Pour basic, P=19 et M=784931. Une requête portant sur un élément absent a une probabilité de correspondance d’environ 1/M ; davantage d’éléments surveillés multiplient les occasions. Ce n’est pas un taux d’erreur fixe pour tout le portefeuille. Un filtre correctement construit ne manque pas un élément inclus. Un résultat négatif exige toutefois un filtre correct, un type de données couvert et la bonne requête. [2]

BIP 157 définit le transport des filtres et leurs en-têtes liés. Chaque en-tête relie le hash, empreinte cryptographique du filtre actuel, à l’en-tête précédent. Modifier le filtre rompt le lien attendu. Mais cette chaîne ne fait pas partie de l’en-tête du bloc Bitcoin, et son contenu n’est pas directement engagé par le minage. Un pair malhonnête peut préparer de faux filtres accompagnés d’empreintes liées correctement calculées. Il ne modifie pas Bitcoin, mais peut cacher des informations à un client isolé. La vérification des liens mathématiques doit donc s’accompagner de celle des données elles-mêmes. [1]

BIP 157 repose sur la comparaison de plusieurs pairs, dont au moins une source honnête. En cas de désaccord, le client peut trouver la première divergence et vérifier le filtre avec les données sous-jacentes. Construire basic peut nécessiter plus que le nouveau bloc : il faut aussi les scripts des sorties antérieures dépensées par ses transactions. Une réorganisation demande un traitement particulier : le réseau passe à une autre branche de blocs valides accumulant davantage de travail. Le portefeuille doit rattacher les filtres à la nouvelle branche et actualiser historique et solde. Une même hauteur, donc une même position dans la chaîne, ne désigne pas forcément le même bloc. [1] [3]

Le portefeuille a besoin de filtres disponibles et d’un moyen d’obtenir les blocs complets sélectionnés. Un nœud peut supprimer d’anciens blocs après avoir créé leurs filtres ; une autre source devra alors les fournir. Dans Bitcoin Core, getblockfilter renvoie le filtre et son en-tête pour un bloc donné si l’index correspondant est activé. L’existence de cette commande ne prouve ni un service public P2P pour les autres nœuds ni l’accès à tout l’historique. Les filtres des blocs existants n’annoncent pas non plus les transactions non confirmées du Mempool. Afficher un paiement en attente nécessite un autre mécanisme. Ces détails déterminent si un portefeuille léger fonctionne réellement bien. [1] [4]