Glossaire / Nœuds et logiciels
Synchronisation par en-têtes d'abord
- Qu'est-ce que la synchronisation par en-têtes d'abord ?
- La synchronisation par en-têtes d'abord est la stratégie de démarrage dans laquelle un nœud télécharge et vérifie toute la chaîne d'en-têtes de 80 octets avant de demander le moindre corps de bloc, puis récupère ces corps en parallèle.
Diviser le téléchargement en deux est ce qui rend une première synchronisation praticable. Bitcoin Core fonctionne ainsi depuis la version 0.10.0, publiée en février 2015, qui a fait passer la récupération des blocs d'une file unique et ordonnée à une tâche répartie entre tous les pairs connectés. Si vous faites tourner votre propre nœud pour vérifier votre propre solde, voilà pourquoi la synchronisation initiale se termine en heures plutôt qu'en jours.
Comment cela fonctionne
La synchronisation par en-têtes d'abord commence par demander des en-têtes aux pairs, pas des blocs.
Le nœud envoie un message getheaders portant un localisateur de blocs, une liste compacte de hachages qui décrit où il pense se trouver. Un pair répond par un message headers contenant jusqu'à 2 000 en-têtes de 80 octets chacun, si bien qu'une seule réponse couvre environ deux semaines de chaîne. Pour chaque en-tête, le nœud vérifie qu'il pointe vers un parent qu'il possède déjà et que son hachage atteint la difficulté annoncée par son champ nBits, puis il redemande depuis le nouveau sommet jusqu'à ce qu'aucun pair n'ait plus rien de récent à proposer.
Ce n'est qu'une fois ce squelette en place que le téléchargement des corps commence. Comme le nœud connaît déjà le hachage de chaque bloc qu'il veut, il peut demander différentes portions à plusieurs pairs en même temps au lieu de faire la queue derrière une seule connexion. Bitcoin Core limite le nombre de demandes de blocs laissées en attente auprès d'un même pair, seize dans le code actuel, et déconnecte un pair qui bloque cette fenêtre. Les blocs qui arrivent avant leurs parents sont simplement conservés, ce qui a mis fin à l'ancienne habitude de stocker des données non vérifiées sur le disque.
Deux garde-fous accompagnent les en-têtes. Le logiciel ne s'engage sur une chaîne que lorsque les en-têtes qu'il détient totalisent une preuve de travail accumulée supérieure à un minimum compilé dans la version, de sorte qu'un pair ne peut pas attirer un nœud récent sur une chaîne secondaire bon marché faite de blocs faciles. Par ailleurs, le réglage assumevalid désigne un hachage de bloc récent fourni avec chaque version : les signatures des blocs enfouis sous ce hachage ne sont pas revérifiées, ce qui supprime des heures de calcul sur courbe elliptique alors que toute règle dépendant de l'état actuel de la chaîne reste appliquée.
Où le voir
La synchronisation par en-têtes d'abord se manifeste par deux compteurs qui divergent pendant qu'un nœud rattrape son retard.
Appelez getblockchaininfo pendant une première synchronisation et le champ headers se trouvera loin devant le champ blocks, souvent de plusieurs centaines de milliers. Le client graphique dit la même chose en langage courant : il ne peut estimer une heure de fin qu'une fois les en-têtes arrivés, car jusque-là il ne sait pas quelle distance il lui reste à parcourir. Regarder ces deux nombres converger est la barre de progression honnête.
Les logiciels légers s'arrêtent délibérément après la première moitié. Un portefeuille SPV, un client à filtres compacts ou un nœud Lightning fonctionnant sans sa propre chaîne ne conservent que les en-têtes et empilent par-dessus des preuves de Merkle ou des filtres. C'est toute la raison pour laquelle un portefeuille mobile peut vérifier son propre historique via les données mobiles : les en-têtes sont petits et de taille fixe, les corps de blocs ne le sont ni l'un ni l'autre.
Synchronisation par en-têtes d'abord vs synchronisation par blocs d'abord
La synchronisation par en-têtes d'abord apprend la forme de la chaîne avant d'en télécharger le contenu, tandis que la synchronisation par blocs d'abord tentait de faire les deux à la fois. L'ancienne méthode envoyait un message getblocks, recevait un inv listant au plus 500 hachages de blocs et les tirait un par un depuis le pair qui avait répondu, si bien qu'une seule connexion lente freinait tout ce qui suivait. Tout ce qui arrivait dans le désordre n'avait nulle part où aller sinon dans une réserve en mémoire qu'un attaquant pouvait remplir de données inutiles. Bitcoin Core ne se synchronise plus de cette façon depuis 0.10.0, bien qu'il comprenne encore ces messages pour que les logiciels plus anciens puissent lui parler.