Un Full Node est un programme qui vérifie lui-même les règles de Bitcoin. Il fonctionne sur un ordinateur, reçoit des blocs et des transactions et détermine lesquels peuvent intégrer un historique valide. Avec votre propre nœud, vous n’avez pas à vous fier aux affirmations d’un mineur ou d’un serveur extérieur pour cette vérification. Mais votre portefeuille doit réellement utiliser ce nœud comme source de données pour en bénéficier.
Votre portefeuille affiche un paiement reçu. Comment sait-il que la transaction appartient réellement à l’historique de Bitcoin et respecte les règles ? Il peut interroger un serveur extérieur ou utiliser votre nœud. Le Full Node donne un sens concret à cette seconde possibilité : il vérifie lui-même la validité des données reçues. Il ne demande pas à la majorité des ordinateurs connectés comment décider. Si quelqu’un lui envoie un bloc contraire aux règles, il le rejette. Le nombre de connexions ne remplace donc pas la vérification. Votre nœud vous permet de contrôler les données sur lesquelles reposent vos paiements. [1] [3]
Le nœud vérifie l’enchaînement des blocs, leurs en-têtes et Proof of Work, la preuve de calcul exigée pour un bloc. Pour les transactions, il contrôle notamment qu’elles font référence à des fonds existants, qu’ils ne sont pas dépensés deux fois et que les conditions de dépense sont remplies. Ces conditions sont écrites dans des scripts, de petits ensembles de règles informatiques. Il vérifie aussi la quantité de nouveaux bitcoins créés. Le résultat tenu à jour est l’UTXO set, l’ensemble des sorties de transactions non dépensées : un relevé des fonds précis encore utilisables. Davantage de travail cumulé peut départager deux branches valides, mais ne rend pas valide un bloc qui ne l’est pas. [1]
Non. Un Full Node vérifie les blocs et les transactions ; la simple vérification courante ne donne pas de récompense de bloc. Le mineur, lui, prépare une proposition de bloc et répète des calculs jusqu’à trouver un résultat satisfaisant. Il utilise un hash, l’empreinte numérique de l’en-tête du bloc. Les deux rôles peuvent travailler ensemble : le mineur doit savoir quel historique il prolonge et quelles transactions il peut inclure. Cela ne signifie pas que chaque nœud doit miner. La vérification et la compétition pour trouver le prochain bloc sont deux activités distinctes. [5] [1]
Un nouveau nœud doit d’abord rattraper l’historique du réseau. Il télécharge les blocs et traite leurs données : c’est la synchronisation initiale. Deux accélérations possibles doivent être distinguées. Dans certaines conditions, assumevalid permet à Bitcoin Core d’omettre d’anciennes vérifications de scripts ; assumevalid=0 désactive cette optimisation. AssumeUTXO permet plutôt de charger un snapshot, un état enregistré des fonds non dépensés à un bloc donné, dont l’empreinte est comparée à une valeur inscrite dans le code source. L’historique antérieur est ensuite vérifié en arrière-plan. Un état actuel utilisable ne signifie donc pas, à lui seul, que la vérification historique est terminée. [1] [2]
Un Full Node n’a pas à garder tous les anciens fichiers de blocs indéfiniment. Le Pruning en supprime une partie après traitement, mais conserve l’UTXO set actuel et les données récentes nécessaires. Le nœud continue à vérifier les nouveaux blocs. Un nœud d’archive garde les anciens blocs pour les fournir à d’autres ou les parcourir à nouveau. Économiser du disque n’équivaut donc pas à devenir un client SPV, qui utilise une vérification simplifiée des paiements. Celui-ci ne contrôle pas toutes les transactions et leur état comme un Full Node. La différence porte sur ce que l’on vérifie, pas seulement sur les fichiers conservés. [3]
Lors d’une synchronisation ordinaire, un nœud élagué télécharge et traite les blocs historiques avant de pouvoir les supprimer progressivement. Le Pruning ne sert donc pas à sauter leur vérification, mais à économiser du stockage. Les optimisations évoquées plus haut sont une question distincte : assumevalid peut omettre d’anciens contrôles de scripts sous certaines conditions, tandis qu’AssumeUTXO permet d’utiliser un snapshot avant la fin de la vérification historique. Pour savoir si votre nœud est prêt, examinez sa méthode de synchronisation et sa progression réelle, pas seulement la taille des données sur le disque. [3] [2]
Le portefeuille a besoin d’informations sur les transactions et les confirmations. S’il les obtient d’un serveur extérieur, il lui envoie des requêtes qui peuvent révéler des éléments sur ses paiements. Le connecter à votre Full Node permet de recevoir des données vérifiées par votre nœud sans ces requêtes au serveur extérieur. Mais installer et démarrer un nœud ne reconfigure pas automatiquement le portefeuille. Tout dépend de la source qu’il prend réellement en charge et utilise. Votre nœud ne garantit pas non plus l’anonymat : la confidentialité dépend aussi d’autres données réseau et de votre manière d’utiliser le portefeuille. [3] [4]
Un nœud peut fonctionner sans vos clés privées. Les clés permettent de signer les paiements ; le nœud vérifie le respect des règles par les transactions et les blocs. Ces tâches n’ont pas à être confiées au même appareil. Ne vérifiez donc pas uniquement que votre nœud fonctionne quelque part : assurez-vous aussi de la provenance des données du portefeuille et du chemin de diffusion de ses transactions. Vérifier soi-même ne remplace pas une sauvegarde sûre des clés et n’efface pas toutes les informations que les communications réseau peuvent révéler. Cela répond à une partie précise du processus : contrôler les données Bitcoin de façon indépendante. [3] [4]
Le nœud possède deux interfaces différentes. Les connexions P2P lui permettent d’échanger des blocs et des transactions avec d’autres nœuds. RPC est l’interface par laquelle des applications lui donnent des commandes et peuvent éventuellement contrôler son portefeuille. Ouvrir un port P2P entrant n’est donc pas la même chose qu’exposer RPC à des inconnus. Bitcoin Core recommande de ne pas exposer directement RPC à l’internet public. Pour l’accès local, il utilise normalement des identifiants dans un fichier .cookie, qui établissent l’autorisation de l’application. Ce n’est pas un cookie de suivi de navigateur. [4]
Les commandes du nœud permettent de vérifier plus qu’une icône verte. Dans getblockchaininfo, regardez le réseau, blocks pour les blocs traités, headers pour les en-têtes connus et initialblockdownload pour l’état de la synchronisation initiale. Avec un snapshot, getchainstates aide à distinguer l’état actuel de la vérification historique en arrière-plan. Le nombre de connexions ne prouve pas une vérification complète. Vérifiez enfin que le nœud n’est pas resté à un sommet de chaîne dépassé et que le portefeuille utilise bien ses données. C’est ainsi que sa vérification indépendante bénéficie à votre usage du portefeuille. [2] [1]
Pour une vision complète, lisez aussi Bitcoin, Timechain / Blockchain, Transaction, UTXO, Proof of Work. Cette entrée est également citée par Bitcoin, Satoshi Nakamoto, Timechain / Blockchain, Proof of Work.