Assumeutxo

L'instantané répertorie chaque bitcoin dépensable à une hauteur de bloc donnée, et son hachage est compilé dans le logiciel plutôt que téléchargé avec lui. Bitcoin Core 28,0 a ajouté des paramètres mainnet pour la hauteur 840 000, la première hauteur pour laquelle un instantané peut être chargé sur le réseau réel. Votre portefeuille devient utilisable bien avant que l'historique complet ait été vérifié, pendant que le nœud vérifie discrètement les blocs ignorés derrière lui.

Comment cela fonctionne

Assumeutxo divise un nœud en deux chainstates et les exécute en même temps.

Vous remettez un fichier d'instantané au RPC loadtxoutset. Bitcoin Core crée un second chainstate pour l'y charger, en gardant le premier actif pendant que le contenu est lu et vérifié. Une fois le chainstate de l'instantané chargé et validé, il devient le chainstate actif, un répertoire appelé chainstate_snapshot apparaît dans le répertoire de données, et le nœud commence à se synchroniser depuis le bloc de base de l'instantané vers la pointe du réseau. Dans ce répertoire se trouve un petit fichier appelé base_blockhash, qui enregistre le bloc auquel l'instantané a été pris, afin que la configuration survive à un redémarrage.

Le hachage, c'est toute l'histoire de la confiance. La documentation de Core indique elle-même qu'il n'existe pas de source canonique pour les instantanés, et que tout instantané que vous téléchargez est comparé à une valeur codée en dur dans le code source. Vous ne faites donc pas confiance à celui qui a hébergé le fichier. Vous faites confiance à la même version que vous avez déjà choisie d'exécuter, et un fichier dont le hachage ne correspond pas à la valeur compilée est rejeté avant même de devenir votre chainstate.

Pendant ce temps, le chainstate d'origine continue d'avancer depuis le bloc de genèse avec toutes les règles appliquées. Lorsqu'il atteint le bloc de base de l'instantané, il hache son propre ensemble de sorties non dépensées et compare le résultat au paramètre compilé. Le cache est attribué à la chaîne qui en a le plus besoin : la chaîne de l'instantané est prioritaire pendant qu'elle court vers la pointe, et la chaîne d'arrière-plan reçoit la plus grande part ensuite. Le RPC getchainstates montre les deux.

Le nettoyage a lieu au redémarrage suivant plutôt qu'immédiatement. Core renomme chainstate_snapshot en chainstate, supprime les données d'arrière-plan, et à partir de ce moment le nœud est indiscernable d'un nœud construit de manière traditionnelle. Le fichier base_blockhash reste comme trace de son point de départ.

Pourquoi cela compte quand vous achetez du bitcoin

Assumeutxo attaque le seul inconvénient qui empêche la plupart des acheteurs de valider leurs propres bitcoins.

Sur les 41 portefeuilles examinés sur ce site, Bitcoin Core est le seul qui télécharge et vérifie lui-même toute la chaîne, ce qui explique pourquoi notre avis lui attribue la note de 4,7 et cite encore comme premier inconvénient que la première synchronisation télécharge et vérifie toute la chaîne, ce qui coûte des heures et beaucoup d'espace disque. Cette phrase est la raison pour laquelle la plupart des gens n'essaient jamais. Un instantané ne fait pas disparaître le coût, il le déplace : les heures ont toujours lieu, elles ont simplement lieu après que votre portefeuille fonctionne déjà au lieu d'avant.

Le moment où cela paie, c'est le retrait. Vous achetez sur l'une des 63 plateformes d'échange recensées ici, vous envoyez les bitcoins vers des clés que vous contrôlez, et vous voulez ensuite savoir qu'ils sont arrivés. Sans nœud à vous, les deux parties que vous pouvez interroger sont la plateforme d'échange qui vient de les envoyer et un explorateur de blocs public qui connaît désormais votre adresse. Avec un nœud, la réponse vient de calculs que votre propre machine a effectués.

Cela change aussi ce que coûte le démarrage d'une installation sérieuse. Notre avis sur Sparrow, noté 4,7 lui aussi, décrit la connexion directe à Bitcoin Core comme backend, et ce couplage signifiait auparavant attendre la fin d'une synchronisation complète avant que Sparrow ait de quoi communiquer. Un instantané comprime la journée d'installation en une soirée utilisable, et la vérification que vous avez reportée se termine d'elle-même pendant que vous dormez.

Exemple concret : générer un instantané avec dumptxoutset

Générer un instantané assumeutxo est une opération délibérée sur un nœud auquel vous faites déjà confiance, pas un fichier que vous allez chercher.

Le RPC dumptxoutset le produit, soit à la pointe actuelle avec le type "latest", soit à une hauteur récente avec le type "rollback". Pendant la majeure partie de son exécution, le nœud se trouve dans un état temporaire qui ne reflète pas la réalité, marquant comme invalides des blocs qu'il sait corrects, et l'activité réseau est coupée et chaque pair déconnecté à cause de cet état. La documentation de Core recommande -rpcclienttimeout=0 parce que le dump prend du temps quel que soit le matériel et quel que soit le type choisi, et elle déconseille de toucher au nœud pour autre chose entre-temps.

Deux détails prennent les gens au dépourvu. Un instantané n'est utilisable que si sa hauteur a déjà un hachage listé dans les paramètres de la chaîne, donc choisir une autre hauteur signifie modifier ce code et recompiler, et le type "rollback" sert aussi à vérifier un hachage codé en dur en régénérant l'instantané et en comparant. Et Bitcoin Core 28,0 a changé la sérialisation : les dumps dans l'ancien format ne sont plus pris en charge et doivent être recréés sur un nœud 28,0 ou ultérieur avant que loadtxoutset ne les accepte.

Bitcoin Core 29,0 a ajouté un outil associé, contrib/utxo-tools/utxo_to_sqlite.py, qui convertit un instantané sérialisé de façon compacte en base de données SQLite3. Cela n'a rien à voir avec la synchronisation d'un nœud et tout à voir avec ce qu'est réellement un instantané : une image complète et autonome de qui possède quoi à une hauteur donnée, ce qui s'avère une chose utile à interroger.

Assumeutxo vs téléchargement initial de la chaîne

Assumeutxo ne remplace pas le téléchargement initial de la chaîne, il change l'ordre dans lequel le travail se fait.

Un nœud qui a chargé un instantané effectue toujours un téléchargement initial complet de la chaîne depuis le bloc de genèse dans son chainstate d'arrière-plan, qui est le chainstate chargé de la validation complète de la portion de chaîne que l'instantané lui a permis de supposer. Rien n'est ignoré définitivement. Ce que l'instantané apporte, c'est que le portefeuille cesse d'être inutile pendant l'attente, parce que le chainstate actif connaît déjà l'état actuel de chaque adresse qui vous intéresse. La région entre la genèse et la hauteur de l'instantané est suivie comme supposée valide plutôt que discrètement comptée comme vérifiée, ce qui explique pourquoi Core porte deux chainstates au lieu d'un drapeau sur un seul. Un nœud qui a chargé un instantané et n'a jamais terminé la synchronisation d'arrière-plan est dans un état réel et nommé, pas caché.

Assumeutxo vs un nœud élagué

Assumeutxo et l'élagage réduisent tous deux ce qu'un nœud doit gérer, et ils réduisent des choses opposées.

L'élagage concerne le disque après la validation : un nœud élagué vérifie chaque bloc, puis supprime les fichiers bruts dont il n'a plus besoin. Assumeutxo concerne le temps avant la validation : il reporte des vérifications qu'il effectuera quand même. Les deux se combinent, et Core assouplit l'une de ses propres règles pour le permettre. Le plancher habituel pour -prune est de 550 MiB, et un nœud qui charge un instantané ignore ce minimum et utilise au moins 1100 MiB à la place. L'espace n'est pas le seul poste : pendant que la synchronisation d'arrière-plan s'exécute, il y a temporairement deux répertoires de chainstate, chacun de plusieurs gigaoctets et susceptible de devenir plus volumineux que l'instantané que vous avez téléchargé.

Les index sont le point où les deux divergent le plus. Un index ne gagne rien d'un instantané, parce que les index commencent toujours à se construire depuis le bloc de genèse et ne peuvent appliquer les blocs que dans l'ordre, donc un index n'atteint la pointe qu'une fois que la validation d'arrière-plan a fait dépasser le bloc de l'instantané au nœud. L'élagage accentue cela : un index qui prend en charge l'élagage, s'il le fait, ne permet au nœud de supprimer que les blocs qu'il a déjà indexés, donc un instantané ancien laisse sur le disque un tas de blocs téléchargés, non indexés et non supprimables jusqu'à ce que l'indexation rattrape son retard.