Initial Block Download

Vous lancez chez vous un Full Node : un logiciel qui vérifie lui-même les blocs et les transactions de Bitcoin. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Les autres participants disposent déjà d’un long historique ; votre nouveau nœud ne l’a pas encore. Il récupère d’abord les en-têtes, de courts ensembles de données reliant les blocs. Ils contiennent aussi le Proof of Work, la preuve d’un travail de calcul. Les mineurs cherchent cette preuve en répétant des calculs ; les autres peuvent rapidement vérifier le résultat. La liste des en-têtes ressemble au sommaire d’un livre : il permet de se repérer, mais le posséder ne signifie pas avoir lu et vérifié toutes les pages. [1] [7]

Si les voisins proposent différentes branches de l’historique, le nœud ne compte pas les voix. Les en-têtes lui permettent de comparer le travail de calcul cumulé et de choisir une candidate à vérifier plus avant. Davantage de blocs ne signifie pas forcément davantage de travail. Même un travail considérable ne dispense pas les transactions invalides de respecter les règles : le contenu de la branche choisie reste à contrôler. [1] [2] [6]

Le nœud peut obtenir des blocs auprès de plusieurs voisins simultanément, sans dépendre du débit d’un seul expéditeur. Pour les intégrer à son historique validé, il lui faut toutefois connaître l’état précédent. Les entrées d’un paiement désignent des montants antérieurs qu’il veut dépenser. Le nœud doit vérifier qu’ils existent et n’ont pas déjà été dépensés. Un bloc plus récent, déjà téléchargé, peut donc attendre le traitement d’un bloc antérieur. Télécharger les données et terminer la synchronisation sont deux choses différentes. [1] [2]

Le nœud compare le contenu du bloc à l’empreinte des transactions inscrite dans son en-tête, calculée grâce à un Merkle Tree. Il contrôle aussi, par exemple, l’enchaînement des dépenses et le respect du montant autorisé pour la récompense du mineur. Il applique les règles en vigueur à cet endroit de l’historique. Une signature numérique prouve l’autorisation d’un paiement à l’aide d’une clé privée, une valeur numérique secrète, sans révéler cette clé. Les anciennes vérifications de signatures et d’autres conditions de dépense ont un réglage particulier, assumevalid, expliqué plus bas. Des en-têtes ou un fichier provenant d’un voisin apparemment fiable ne remplacent pas cet ensemble de contrôles. [2] [3]

À chaque bloc traité, le nœud retire les sorties dépensées et ajoute les nouvelles. Une sortie correspond à un montant précis assorti de conditions pour le dépenser plus tard. Tant qu’elle n’a pas été dépensée, on l’appelle UTXO. L’ensemble de ces sorties permet de vérifier le prochain paiement sans relire chaque fois tout l’historique. Ce n’est ni une liste de comptes bancaires ni une copie de toutes les transactions passées. [2] [3]

Sous certaines conditions, Bitcoin Core peut omettre d’anciennes vérifications de scripts, c’est-à-dire de signatures et d’autres conditions de dépense. Le réglage assumevalid désigne un bloc connu dont l’historique a été vérifié extérieurement ; sa place dans la chaîne, une quantité suffisante de travail et la chaîne construite au-dessus de lui comptent aussi. Les autres contrôles nécessaires subsistent, mais une partie du résultat est tenue pour acquise. Une hypothèse erronée n’est donc pas sans risque. assumevalid=0 désactive cette optimisation, au prix de davantage de travail pour votre ordinateur. [2]

Un Pruned Node supprime les anciens fichiers de blocs après leur traitement, en conservant les UTXO actuels et les autres données nécessaires. Durant l’IBD ordinaire, il récupère et traite toujours l’historique ; il ne le conserve simplement pas en entier de façon permanente. Cela économise de l’espace disque, pas automatiquement le volume du premier téléchargement. Une tâche ultérieure nécessitant des blocs supprimés peut demander de les récupérer à nouveau. [2] [7]

Bitcoin Core v29.0 tient notamment compte de l’ancienneté du dernier bloc accepté, d’un minimum de travail cumulé et de l’état du chargement. Une fois cet indicateur de fonctionnement passé à false (qui signifie que la synchronisation initiale est terminée), il ne revient plus à true (qui signifie qu’elle est encore en cours) pendant la même exécution. Il sert à guider le logiciel, pas à prouver qu’aucun bloc plus récent n’existe ailleurs. Même une perte de connexion ultérieure n’en fait pas un indicateur fiable de mise à jour. [2] [5]

Une connexion rapide aide, mais l’ordinateur doit aussi calculer et écrire sur le disque. Processeur, mémoire, stockage et disponibilité des voisins influencent la durée. Dans la sortie technique de getblockchaininfo, verificationprogress estime l’avancement de la vérification. Ce n’est ni une promesse de minutes restantes ni simplement la proportion d’octets téléchargés. Après un arrêt propre, le prochain démarrage peut reprendre la progression sauvegardée au lieu de tout recommencer. [5] [7]

AssumeUTXO permet d’utiliser un instantané UTXO pris en charge : un état enregistré à un bloc donné. Le logiciel compare son contenu à une empreinte attendue et peut rejoindre plus tôt le présent à partir de cet état, tout en traitant l’historique en arrière-plan. Il compare ensuite également l’état issu de cette vérification historique. Ce n’est ni une base de données quelconque fournie par un inconnu ni un moyen de ne jamais vérifier le passé. Pouvoir utiliser le nœud plus tôt et avoir achevé la validation historique sont deux étapes distinctes. [4] [8]