121 / 691IBD

Initial block download

IBD est la première synchronisation d’un nouveau nœud avec l’histoire de Bitcoin. Elle réunit acquisition des données, validation des blocs et construction de l’état des sorties non dépensées, au-delà du transfert de fichiers.

IBD dépasse le téléchargement de fichiers. Un Full Node construit un ensemble UTXO validé depuis l’histoire ; les anciens contrôles de scripts dépendent aussi d’assumevalid.

Le nœud découvre des adresses de pairs et synchronise les en-têtes. Un en-tête relie l’histoire et contient Proof of Work, mais ne prouve pas seul la validité de toutes les transactions du bloc. [Bitcoin Developer Guide — Initial Block Download] [Satoshi Nakamoto — Bitcoin whitepaper]

Le travail cumulé désigne une branche candidate à valider. Ni le plus grand nombre d’en-têtes ni l’affirmation d’un pair ne remplace le travail et les contrôles complets. [Bitcoin Developer Guide — Initial Block Download] [Bitcoin Core — validation] [Satoshi Nakamoto — Bitcoin whitepaper]

Les blocs peuvent être téléchargés en parallèle depuis plusieurs pairs. Leur rattachement à la chaîne valide respecte l’état précédent : les sorties exigent l’histoire nécessaire pour être vérifiées. [Bitcoin Developer Guide — Initial Block Download] [Bitcoin Core — validation]

Un Full Node contrôle notamment structure, Merkle root, règles de dépense et limites d’émission. Les règles de consensus s’appliquent selon hauteur et activations ; les en-têtes ne sont pas une validation complète. [Bitcoin Core — validation] [Bitcoin Core — chainstate]

Rattacher des blocs retire les sorties dépensées et ajoute de nouveaux UTXO. La base décrit les possibilités actuelles de dépense, pas toutes les transactions historiques ni des soldes par adresse. [Bitcoin Core — validation] [Bitcoin Core — chainstate]

Sous des conditions d’histoire connue suffisamment profonde, assumevalid peut omettre d’anciens contrôles de scripts. Il n’accepte pas une histoire arbitraire sans contrôle ; assumevalid=0 désactive cette optimisation. [Bitcoin Core — validation]

L’élagage supprime les anciens fichiers de blocs après traitement et conserve l’ensemble UTXO et les métadonnées nécessaires. Il économise le stockage durable, pas l’acquisition et le traitement de l’histoire pendant IBD ordinaire. [Bitcoin Core — validation] [Bitcoin Core — chainstate]

Bitcoin Core v29.0 utilise l’âge de la pointe, le travail minimal et l’état du chargement ; après achèvement, l’indicateur ne revient pas à true dans ce processus. C’est une heuristique opérationnelle, pas la preuve de la dernière pointe globale. [Bitcoin Core — validation] [Bitcoin Core — getblockchaininfo]

La durée dépend du processeur, de la mémoire, du disque, du réseau et des pairs. verificationprogress de getblockchaininfo estime le travail de vérification, pas une échéance garantie ni simplement la proportion d’octets reçus. [Bitcoin Developer Guide — Initial Block Download] [Bitcoin Core — getblockchaininfo]

AssumeUTXO peut utiliser un instantané UTXO pris en charge pour fonctionner plus tôt à la pointe. L’histoire est validée en arrière-plan et comparée à l’instantané ; une disponibilité précoce n’est pas une validation historique achevée. [Bitcoin Core — validation] [Bitcoin Core — AssumeUTXO design]

Pour une vision complète, lisez aussi Pruned node, AssumeUTXO, Block propagation, Compact block relay. Cette entrée est également citée par Pruned node, AssumeUTXO.

DOC · 001Bitcoin Developer Guide — Initial Block DownloadDocumentation ↗DOC · 002Bitcoin Core — validationDocumentation ↗DOC · 003Bitcoin Core — chainstateDocumentation ↗DOC · 004Bitcoin Core — AssumeUTXO designDocumentation ↗DOC · 005Bitcoin Core — getblockchaininfoDocumentation ↗DOC · 006Satoshi Nakamoto — Bitcoin whitepaperSource primaire ↗
Sources d’abord · Pas un conseil financier