Utreexo

Anna veut envoyer à Peter des bitcoins reçus auparavant. Sa transaction fait donc référence à ce paiement antérieur. Un enregistrement distinct d’un montant et des conditions de sa dépense s’appelle une sortie ; tant qu’elle n’est pas dépensée, c’est un UTXO. Une entrée de la nouvelle transaction contient une référence à cette sortie antérieure et les données nécessaires pour la dépenser. Le nœud doit vérifier que l’enregistrement existe et qu’Anna ne l’a pas déjà dépensé. Il tient habituellement l’UTXO set, une base de toutes les sorties actuellement non dépensées, et non des comptes personnels avec leurs soldes. Sa croissance augmente le travail du disque. Thaddeus Dryja a présenté Utreexo en 2019 pour réduire cette charge locale. [1] [6] [8]

Chaque enregistrement est d’abord haché pour produire une courte empreinte de ses données. Dans un arbre de Merkle, les empreintes sont regroupées par paires puis hachées à nouveau, jusqu’à l’empreinte du sommet, la racine. Utreexo utilise plusieurs de ces arbres ; un nœud vérificateur peut conserver leurs racines plutôt que la liste entière. Pour la sortie d’Anna, il reçoit les données et une preuve contenant les empreintes voisines nécessaires. Il recalcule le chemin jusqu’à la racine et compare le résultat à l’état qu’il suit déjà. L’affirmation de l’expéditeur ne suffit donc pas. Cette structure s’appelle un accumulateur cryptographique : elle prouve qu’un enregistrement appartient à un ensemble. Les racines ne sont toutefois pas une sauvegarde compressée que l’on pourrait décompresser pour retrouver tous les enregistrements. [1] [2]

Les données reçues sont hachées, puis la preuve permet de vérifier leur lien avec l’état suivi par le nœud. Une preuve invalide ne peut pas être acceptée simplement parce qu’elle vient d’un serveur connu. 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é. Un script définit les conditions à remplir pour dépenser une sortie. Même une preuve d’appartenance valide ne remplace pas les contrôles des signatures, scripts, montants et autres règles de transaction et de bloc. Utreexo change le stockage de l’état, sans autoriser à sauter ces vérifications. [2] [5] [8]

Quelqu’un doit toujours conserver assez de données pour construire les preuves. La documentation de la bibliothèque distingue le prover, qui garde toute la forêt d’arbres, du verifier, auquel les racines suffisent. Un vérificateur peut mettre certaines preuves en cache, mais les racines seules ne permettent pas de produire n’importe quelle preuve. Les données ne disparaissent donc pas ; leur répartition entre participants change. [2]

Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Lorsqu’une sortie est dépensée, elle est retirée de l’ensemble suivi, tandis que de nouvelles sorties non dépensées sont ajoutées. Les preuves évoluent aussi. Une preuve sauvegardée pour un état antérieur peut devoir être actualisée après de nouveaux blocs. Lors d’une réorganisation, le réseau adopte une autre branche valide de la chaîne, qui remplace une partie de l’historique précédent. L’implémentation doit gérer la mise à jour des preuves, les transactions simultanées et les retours en arrière lors d’une réorganisation de la chaîne. Ce n’est pas un certificat téléchargé une fois et valable pour toujours. [2] [3]

Un Pruned Node supprime les anciennes données de blocs après validation, mais conserve traditionnellement la base UTXO actuelle. Utreexo vise précisément cette base. Il s’agit donc de deux économies différentes, qui peuvent se combiner. Ni l’élagage ni un petit accumulateur ne signifient à eux seuls que le nœud a vérifié le passé sans le traiter. L’historique des blocs, l’état actuel et la méthode de vérification initiale sont trois choses distinctes. [6] [5]

Imaginons un nouveau nœud qui démarre avec un état fourni par quelqu’un d’autre au lieu de vérifier les blocs depuis le début. Il suppose cet état initial correct. Un petit accumulateur ne supprime pas cette confiance : les preuves suivantes sont justement vérifiées par rapport à l’état accepté. Avec AssumeUTXO, il faut donc distinguer l’acceptation d’un snapshot, un instantané de l’état à un moment donné, de la validation ultérieure de l’historique en arrière-plan. La documentation d’utreexod décrit un démarrage par défaut depuis un état fixé dans le programme. Cela seul n’est pas une vérification autonome de tous les blocs antérieurs. Le mode de démarrage est un choix distinct, pas une propriété inhérente à Utreexo. [7] [3]

L’implémentation utreexod utilise Utreexo pour valider le réseau Bitcoin. Lors de la vérification du 17 octobre 2026, sa documentation la décrit comme une version bêta et déconseille son utilisation avec des montants non négligeables sur le mainnet. Elle indique aussi --noassumeutreexo pour désactiver le démarrage depuis un état supposé. Ce n’est pas une recommandation d’installation : avant utilisation, il faut vérifier la version, le mode, la provenance du logiciel et les possibilités de récupération. [3]

La conception de base n’exige ni de réécrire les règles monétaires de Bitcoin ni de modifier les blocs existants. Mais quelqu’un doit créer, transmettre et actualiser les preuves : les nœuds participants ont donc besoin de logiciels et de communications adaptés. Un état local réduit peut aider les appareils moins coûteux. Cela n’implique pas automatiquement davantage de transactions par bloc, des frais plus faibles pour tous ou l’adoption du nouveau format par tous les nœuds. [1] [4]

Moins de données sur disque peuvent signifier davantage de données transférées et une dépendance à leur disponibilité au bon moment. Un nœud qui vérifie correctement rejette une preuve falsifiée. Un fournisseur peut néanmoins retenir les données nécessaires et ralentir la validation. L’exploitant compare donc l’ensemble : stockage, transferts, cache, vérification de l’état initial et comportement en cas de panne. Utreexo peut rendre la validation autonome moins coûteuse ; il ne rend pas les données manquantes sans importance. [3] [4]