Règles de consensus

Imaginez que quelqu’un utilise les mêmes fonds issus d’un paiement antérieur pour vous payer, puis pour régler un commerçant. Les deux dépenses ne peuvent pas appartenir à un historique valide. Pour le vérifier, le nœud suit les sorties des transactions : des enregistrements de montants assortis de conditions de dépense. Lorsqu’un nœud reçoit un bloc, il vérifie sa conformité aux règles qu’il applique, et non l’identité de celui qui le recommande. Il contrôle notamment la disponibilité des sorties à dépenser, les conditions de Bitcoin Script et les signatures exigées, le Proof of Work et la rémunération autorisée du mineur. Une règle enfreinte entraîne le rejet. Le soutien d’une entreprise ou une majorité de votes sur internet n’y change rien. [1]

Le mineur sélectionne des transactions et cherche un bloc ; le Full Node vérifie son résultat indépendamment. Les développeurs peuvent proposer une modification et publier un logiciel, mais la publication d’un logiciel ne suffit pas à modifier les règles des autres nœuds. Chaque opérateur choisit le logiciel qu’il exécute. Ce choix détermine ce que son propre nœud accepte, pas ce que tous les autres doivent accepter. [2] [1]

Un nœud dispose aussi de règles pour les transactions non confirmées : lesquelles conserver dans son Mempool, son ensemble local de transactions en attente de confirmation, et lesquelles transmettre aux autres nœuds. Ces règles locales, appelées policy, peuvent être plus strictes que le consensus. Un rejet du mempool ne signifie donc pas à lui seul que la transaction serait invalide dans un bloc. La politique de relais ne s’applique pas à la validation des blocs. [3]

Un Soft Fork resserre les règles : les blocs valides selon les nouvelles règles respectent aussi les anciennes. Les anciens nœuds ne vérifient toutefois pas les nouvelles conditions. Un Hard Fork peut, au contraire, autoriser un bloc rejeté par les anciens nœuds. Le mécanisme d’activation aide à coordonner le changement ; il ne garantit pas l’accord de tous et ne remplace pas le choix de logiciel des opérateurs. [4]

Votre propre Full Node vous permet de vérifier les blocs reçus plutôt que de vous fier à un site d’exploration de blocs. Un nœud peut connaître plusieurs branches, c’est-à-dire différentes suites d’un historique commun. Parmi les branches valides, il choisit selon le chainwork : la somme du travail attribué à chaque bloc en fonction de sa difficulté de minage. Il ne s’agit ni de mesurer l’électricité réellement consommée ni simplement de compter les blocs. Un travail plus important ne justifie pas une violation des règles. Pour obtenir le même résultat, les nœuds doivent appliquer les règles de façon cohérente, même dans les cas inhabituels. Un bogue peut les amener à accepter des blocs différents. [4] [5]

Un nœud peut refuser de relayer une transaction dont les frais sont trop faibles. Mais si un mineur l’inclut dans un bloc et que transaction et bloc respectent le consensus, le nœud accepte le bloc. Si le mineur s’attribue davantage que la quantité autorisée de nouveaux bitcoins, appelée Block Subsidy, et les frais des transactions du bloc réunis, le nœud rejette le bloc même avec un Proof of Work valide. La différence tient au motif du rejet, pas à la réputation du mineur. [3] [1]