Règles de consensus et validation

Curiosité

1. Qu’est-ce qui empêche le mineur le plus puissant de créer une quantité infinie de pièces ?
2. Pourquoi une transaction que votre nœud refuse de relayer peut-elle tout de même figurer dans un bloc valide ?
3. Si le code de consensus change, tout le monde doit-il mettre à jour exactement à la même seconde ?

Explorer

1. Les règles de consensus sont les critères stricts que chaque nœud complet applique pour valider les blocs. Elles définissent ce qui est techniquement possible : le calendrier d’émission, la limite de poids de bloc de 4 000 000 d’unités, la difficulté de la preuve de travail et la validité des signatures. Un bloc qui enfreint une seule de ces règles est rejeté par tous les nœuds honnêtes, quelle que soit la puissance de hachage qui l’a produit. Les mineurs proposent des blocs ; les nœuds décident s’ils comptent. Cette séparation garantit qu’aucune entité ne peut modifier unilatéralement l’état du registre.
2. Les règles de politique (policy) déterminent ce qu’un nœud relaie à ses pairs avant le minage. Elles comprennent les seuils de poussière (dust), les frais minimaux de relais et les types de scripts standard. Une transaction qui enfreint ces règles est écartée par la plupart des nœuds, mais reste valide si un mineur l’inclut dans un bloc. Cette distinction compte : compter sur le rejet par la politique de relais pour assurer la sécurité est risqué, car un acteur déterminé peut contourner les filtres des pairs et soumettre directement ses transactions aux mineurs, forçant ainsi le réseau à accepter des transactions non standard tant qu’elles respectent le consensus.
3. Le code est la spécification. Les règles sont celles que les logiciels de nœud largement utilisés appliquent réellement, cas limites compris ; c’est pourquoi le code de consensus évolue lentement et fait l’objet d’une revue plus poussée que tout le reste de Bitcoin Core. Les bugs de consensus sont traités comme des urgences : le bug de dépassement de valeur (value overflow) de 2010 et le bug d’inflation de 2018 ont tous deux été corrigés dans l’urgence, avec des versions coordonnées.
4. Toute modification de ces règles nécessite une adoption coordonnée. Les soft forks resserrent les règles, de sorte que les nœuds non mis à jour acceptent toujours les nouveaux blocs ; les hard forks les assouplissent ou les modifient, si bien que chaque nœud doit se mettre à jour ou se retrouver séparé. Une leçon ultérieure aborde les deux en détail. SegWit (août 2017) était un soft fork ; Bitcoin Cash (août 2017) est issu d’un hard fork né d’un désaccord sur la limite de taille des blocs.
5. Produire un bloc coûte cher ; en vérifier un ne coûte presque rien. Un mineur qui produit un bloc invalide perd la récompense et l’énergie dépensée, car tous les nœuds qui valident le rejetteront, ce qui fait de la violation des règles un pari coûteux. Ce coût renforce la rigueur de la validation : la sécurité du réseau repose sur des milliers de nœuds indépendants qui vérifient chaque en-tête et chaque transaction, de sorte qu’aucun point de défaillance unique ne puisse corrompre l’état partagé.
6. Ouvrez un explorateur de blocs comme mempool.space ou blockchain.com. Sélectionnez un bloc récent et examinez son champ « weight » (poids). Comparez cette valeur à la limite de 4 000 000 d’unités de poids définie dans le BIP141. Observez à quel point les blocs actuels s’approchent de ce plafond, signe que les mineurs maximisent leur revenu par octet tout en respectant les contraintes de consensus que chaque nœud applique.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 12
• E. Lombrozo, J. Lau & P. Wuille, BIP141: Segregated Witness (Consensus layer) (2015)
• Bitcoin Core source code: validation.cpp and policy.cpp
• Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, section 5