Synchronisation bloc par bloc

Personne ne synchronise plus de cette façon, et la raison est arithmétique. Un téléchargement strictement séquentiel ne peut pas utiliser la vitesse de téléversement de plus d'un pair, et en 2015 la chaîne était déjà trop volumineuse pour que cela se termine en un temps raisonnable. La technique subsiste comme solution de repli dans le protocole et comme source de confusion dans la documentation ancienne.

Comment cela fonctionne

Statut : la synchronisation bloc par bloc a été remplacée par la synchronisation des en-têtes d'abord dans Bitcoin Core 0.10.0, publiée le 16 février 2015. Les messages qu'elle utilisait font toujours partie du protocole pair-à-pair et reçoivent toujours une réponse, mais aucun client actuel ne s'appuie sur eux pour rattraper la chaîne.

L'échange était une boucle entre deux machines. Votre nœud envoyait un message getblocks contenant les hachages des blocs qu'il possédait déjà. Le pair répondait par un inventaire listant jusqu'à 500 hachages de blocs suivants. Votre nœud demandait ces blocs avec getdata, les recevait, validait chacun intégralement, puis envoyait un nouveau getblocks pour demander la suite. Répétez plusieurs milliers de fois.

Trois problèmes découlaient de cette conception. Il n'y avait aucun parallélisme, car vous ne pouviez pas raisonnablement demander à un second pair des blocs dont l'existence ne vous avait pas encore été signalée, si bien que toute la synchronisation avançait à la vitesse du pair auquel vous vous trouviez parler. Il n'y avait aucun moyen de savoir quelle distance il restait à parcourir, puisque la chaîne se révélait 500 hachages à la fois, ce qui explique pourquoi les anciens clients ne pouvaient pas afficher de barre de progression utile. Et un pair lent ou hostile pouvait simplement vous fournir les données au compte-gouttes, sans moyen simple pour votre nœud de savoir qu'une meilleure chaîne était disponible ailleurs.

La synchronisation des en-têtes d'abord a résolu ces trois problèmes en séparant la preuve peu coûteuse de la preuve coûteuse. Récupérez et vérifiez d'abord la chaîne d'en-têtes, soit 27 mégaoctets pour tout l'historique en décembre 2014, et vous connaissez à la fois la forme de la meilleure chaîne et sa longueur avant de télécharger la moindre transaction. Les corps peuvent alors être demandés à de nombreux pairs simultanément. L'effet secondaire a été que les blocs ont commencé à arriver dans le désordre et à être écrits sur le disque dans le désordre, ce qui explique que le répertoire de données créé par la version 0.10.0 ne puisse pas être lu par une version plus ancienne.

Où vous le rencontrez

Vous rencontrerez la synchronisation bloc par bloc dans la documentation plutôt que dans un logiciel.

Les documents de référence rédigés avant 2015, dont une bonne partie du contenu pour développeurs qui circule encore, décrivent la boucle séquentielle comme si c'était ainsi que bitcoin fonctionne. Ce n'est pas le cas, et les pages qui décrivent une synchronisation initiale comme un téléchargement séquentiel auprès d'un seul pair sont tout simplement obsolètes. Bitcoin Core continue de répondre aux requêtes getblocks pour les clients anciens ou inhabituels, si bien que ces messages apparaissent dans les captures de paquets et dans les spécifications de protocole.

Pour quiconque exploite un nœud aujourd'hui, il n'y a rien à configurer et rien à choisir. Votre client récupère les en-têtes d'abord parce que toutes les implémentations maintenues le font.

Synchronisation bloc par bloc vs synchronisation des en-têtes d'abord

La synchronisation bloc par bloc et la synchronisation des en-têtes d'abord diffèrent par ce qu'elles demandent en premier, et tout le reste en découle. La synchronisation bloc par bloc demandait des blocs complets dans l'ordre et découvrait la forme de la chaîne en cours de route, si bien qu'elle découvrait la meilleure chaîne et la téléchargeait au cours de la même passe lente. La synchronisation des en-têtes d'abord sépare le travail : établir quelle chaîne porte le plus de preuve de travail à l'aide de 80 octets par bloc, puis collecter les corps en parallèle auprès de quiconque veut bien les envoyer. La validation appliquée à chaque bloc est identique dans les deux cas. Ce qui a changé, c'est l'ordre des opérations, et cela seul a fait passer une synchronisation initiale de plusieurs semaines à quelques heures.