AssumeUTXO accélère la mise en service d’un nœud Bitcoin en chargeant un instantané, c’est-à-dire l’état enregistré à un bloc donné. Il s’appuie temporairement sur une empreinte attendue de cet état intégrée au logiciel. Le nœud traite ensuite lui-même l’historique et compare le résultat ; l’instantané ne remplace pas ce travail.
Pierre démarre son premier Full Node, un logiciel qui vérifie lui-même les règles de Bitcoin. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Un démarrage classique exige d’abord de parcourir une longue histoire. AssumeUTXO permet de partir d’un ensemble UTXO préparé : les sorties de transactions encore non dépensées, chacune indiquant un montant et les conditions de sa dépense. L’instantané représente l’état après un bloc précis. Ce n’est ni l’archive de tous les paiements ni la preuve que l’ordinateur de Pierre a déjà vérifié tout le passé. [1] [3]
Le nom d’un fichier ne suffit pas à rendre un instantané fiable. Lors du chargement par loadtxoutset, Bitcoin Core v29.0 contrôle son format, son bloc de base (celui auquel correspond l’instantané) et les paramètres pris en charge. Il calcule aussi le hash du contenu UTXO, une empreinte cryptographique, et le compare à la valeur attendue avant l’activation. Un contenu modifié ne passe donc pas le contrôle simplement parce que le fichier porte un nom rassurant. [2] [3] [6]
Après acceptation de l’instantané, le nœud poursuit à partir de cet état, vérifie les blocs suivants et peut atteindre l’extrémité actuelle de la chaîne. Il ne les accepte pas sur parole : les conditions de dépense et la création autorisée de nouveaux bitcoins restent contrôlées. Cette voie vers l’activité présente n’a donc pas besoin d’attendre la fin de l’histoire antérieure. Cela ne signifie pas que cette histoire a déjà été vérifiée localement. [1] [6]
En parallèle, un second état se construit à partir des blocs historiques, du début jusqu’à la base de l’instantané. Il s’agit d’un calcul indépendant à partir de l’histoire, pas d’une nouvelle copie de l’inventaire téléchargé. Le logiciel maintient donc temporairement deux états dont la progression diffère. La commande technique getchainstates permet de les voir ; un état actif arrivé aux derniers blocs ne prouve pas à lui seul que le travail en arrière-plan est terminé. [1] [8]
Le hash attendu et le bloc de base pris en charge appartiennent à une version précise du programme. Tant que le nœud de Pierre n’a pas refait lui-même le parcours historique, il se fie à l’exactitude de cette information intégrée. La comparaison des hash permet de vérifier si les contenus correspondent, mais ne prouve pas à elle seule qu’ils résultent d’un historique valide. Si l’état attendu était erroné, l’utilisation anticipée reposerait sur cette hypothèse incorrecte. Voilà pourquoi la vérification historique ultérieure ne se confond pas avec le contrôle du fichier au chargement. [2] [6]
Le fichier peut venir d’un autre opérateur, sans que celui-ci puisse décider de l’état accepté. C’est la correspondance avec la valeur prise en charge par le logiciel qui compte, pas sa promesse. Tous les instantanés de tous les blocs ne sont pas acceptés : cela dépend de la version et du réseau. Le contrôle du hash ne garantit pas la livraison du fichier et ne dispense pas du temps, de la bande passante et de l’espace nécessaires à son téléchargement et à son traitement. [2] [4] [7]
Quand le travail en arrière-plan atteint le même bloc de base, le nœud calcule le hash de l’ensemble UTXO qu’il a construit et le compare au hash attendu de l’instantané. Il ne compare pas l’état actuel à une vieille photographie : les deux correspondent au même point de l’histoire. S’ils diffèrent, l’implémentation décrite ici arrête le nœud et cesse d’utiliser l’état issu de l’instantané. Elle ne masque pas l’écart et ne le présente pas comme une vérification réussie. [1] [6]
AssumeUTXO change surtout le délai avant de pouvoir utiliser le nœud. Le téléchargement et la vérification historiques continuent, et deux bases de données d’état coexistent temporairement. Cela sollicite processeur et disque. Un Pruned Node économise de l’espace en supprimant les anciens fichiers de blocs déjà traités, sans renoncer à vérifier les règles. Un Pruned Node peut aussi utiliser un instantané, mais les économies de stockage ont leurs propres limites. Certains index auxiliaires doivent traiter l’histoire depuis le début : un nœud disponible plus tôt ne rend pas toutes les applications connectées immédiatement prêtes. [5] [7]
L’ensemble UTXO contient des informations sur les sorties non dépensées, pas les clés privées autorisant les dépenses. 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é. L’ensemble UTXO n’est pas une sauvegarde du portefeuille et il ne restitue pas une Seed Phrase perdue, les mots de récupération d’un portefeuille qui utilise ce mécanisme. Les anciens paiements peuvent aussi tarder à apparaître : les retrouver peut nécessiter des blocs antérieurs à l’instantané. Sauvegarder les clés, retrouver l’histoire d’un portefeuille et vérifier l’état du réseau sont des tâches distinctes. [1] [7]
La ressemblance des noms peut prêter à confusion. AssumeUTXO part d’un état chargé et reconstruit l’histoire antérieure en arrière-plan. assumevalid peut, sous certaines conditions, omettre une partie des contrôles historiques de scripts, donc des conditions de dépense, signatures comprises. Cette optimisation est indépendante et peut aussi concerner la vérification historique ; terminer AssumeUTXO ne signifie pas qu’elle était désactivée. Dans un guide, distinguez donc le point de départ du nœud, ce qu’il vérifie réellement et la fin de chaque contrôle. [5] [6]
Pour une vision complète, lisez aussi Initial Block Download, Pruned Node, Block Propagation, Nakamoto Consensus, Bitcoin, Bitcoin Core. Cette entrée est également citée par Initial Block Download, Pruned Node, Utreexo.