Règles de consensus et règles de mempool : quelle différence pour Bitcoin ?

Bitcoin est un protocole, c’est-à-dire un ensemble de règles appelées règles de consensus, partagées par tous les nœuds du réseau, qui entraînent l’émergence d’un accord commun à propos du contenu de la chaîne et qui permettent aux utilisateurs de communiquer de la valeur. Cependant, il existe un autre ensemble de règles qui est spécifique à chaque nœud et qui concerne les transactions non confirmées : les règles de mempool. Voyons quelles sont les différences entre ces deux ensembles de règles.

Les règles de consensus Bitcoin

Le premier ensemble de règles dans Bitcoin est celui des règles de consensus. Comme leur nom l’indique, ces règles permettant aux nœuds du réseau de converger vers un consensus sur le réseau à propos du contenu de la chaîne de blocs. Les règles de consensus sont donc globales.

Les règles de consensus déterminent la validité des blocs et des transactions. Ainsi, si un mineur construit un bloc qui n’est pas conforme ou qui inclut une transaction invalide, alors ce bloc ne sera pas ajouté à la chaîne, et le mineur ne percevra pas la récompense attendue. Ce mécanisme permet au système d’avoir un équilibre fort.

Dans BTC, les règles de consensus sont très diverses et sont usuellement définies par l’implémentation logicielle de référence, Bitcoin Core. Il est de ce fait quasiment impossible de les lister de manière exhaustive, mais nous pouvons en citer quelques unes.

Pour les blocs, nous retrouvons par exemple les règles suivantes :

• Un bloc doit posséder un format bien défini : les transactions du bloc doivent être précédées d’un entête constitué d’un numéro de version, de l’identifiant du bloc précédent, de la racine de Merkle de l’arbre des transactions, d’un horodatage, de la difficulté et d’un nonce.
• La chaîne de blocs doit être sélectionnée par le principe de la chaîne la plus longue, c’est-à-dire que la chaîne valide est celle qui possède le plus de preuve de travail accumulée.
• La première transaction du bloc est la transaction de récompense (ou coinbase transaction) qui est créée par le mineur pour se rémunérer par la création monétaire et les frais des transactions incluses.
• Un mineur doit attendre le minage de 100 blocs supplémentaires avant de pouvoir déplacer sa récompense (maturité).
• La création de nouveaux bitcoins doit subir une réduction de moitié (halving) tous les 210 000 blocs : elle doit être inférieure à 50 bitcoins par bloc pour les 210 000 premiers blocs, 25 bitcoins par bloc pour les 210 000 blocs suivants, etc.
• Le poids des blocs, qui détermine la capacité transactionnelle du réseau, doit être inférieur à 4 millions d’unités de poids, comme définies par SegWit.

De même, nous avons des règles de consensus qui concernent les transactions :

• Une transaction doit posséder un format bien défini. Une transaction classique doit comporter un numéro de version, une ou plusieurs entrées, une ou plusieurs sorties et un temps de verrouilage absolu. Une transaction SegWit doit comporter de plus un octet marqueur, un octet de signal ainsi qu’un témoin contenant les éléments de déverrouillage (signatures).
• La double dépense est interdite : une transaction ne peut pas faire intervenir en entrée une sortie transactionnelle déjà dépensée dans une transaction confirmée.
• Le montant en entrée d’une transaction doit être supérieur au montant en sortie. La différence entre les deux est payée au mineur en tant que frais de transaction.
• Les scripts des entrées (ou les témoins correspondants) doivent permettre de déverrouiller les sorties transactionnelles précédentes. La plupart du temps, cela consiste à fournir une signature valide qui est conforme à la clé publique correspondant à l’adresse sur laquelle se trouvent les fonds.
• La transaction doit être finalisée : les temps de verrouillage (le temps de verrouillage absolu de transaction – nLocktime – et les temps de verrouillage relatifs des entrées – nSequence) doivent être désactivés, ou bien être passés du point de vue de la hauteur ou du temps passé médian du bloc.

Ces règles sont définies par les nœuds du réseau, et ont vocation à rester les mêmes à court et moyen terme. Cependant, elles ne sont pas fixes à long terme, et peuvent être modifiées avec l’accord global des nœuds comme l’a montré l’activation de SegWit en août 2017. On devrait les voir à nouveau changer avec l’intégration de Taproot au protocole en novembre 2021.

>> Exposez vous au Bitcoin sur Binance, 10% de réduction des frais avec ce lien (lien commercial) <<

Les règles de mempool

Sur le réseau pair-à-pair, les nœuds se partagent des informations concernant le système. Ils réalisent ce partage grâce à un protocole de communication qui peut être modifié sans affecter le consensus.

En particulier, les nœuds diffusent les éléments de base de la chaîne (blocs et transactions) avant leur ajout éventuel à ladite chaîne. Ces éléments sont également gardés en réserve dans le cas où ils ne sont pas intégrés directement au registre. C’est le cas des blocs « orphelins », c’est-à-dire les blocs valides appartenant à des branches possédant moins de preuve de travail que la chaîne centrale. Et c’est aussi le cas des transactions non confirmées, qui sont conservées dans ce qu’on appelle la mempool, chose qui nous intéresse ici.

La mempool, ou zone mémoire, est donc la réserve de transactions non confirmées entretenue par un nœud du réseau. Puisqu’un nœud est libre de sélectionner les transactions qu’il veut conserver en mémoire et celles qu’il souhaite relayer aux autres nœuds, chaque nœud du réseau possède une mempool spécifique et potentiellement différente. Les règles de mempool sont donc locales.

Ces règles ont deux rôles : éviter la surcharge du nœud et les attaques par déni de service, et faire émerger un standard clair permettant de faciliter l’implémentation du protocole et de limiter les erreurs dues à la nature programmable de Bitcoin.

Le premier rôle est évident : si tous les nœuds acceptaient toutes les transactions sans discrimination, alors il serait enfantin de faire en sorte que le réseau Bitcoin arrête de fonctionner. Parmi les règles de mempool ayant pour but de restreindre l’afflux de transactions, on peut citer les exigences suivantes :

• Les frais minimaux payés par une transaction sont de 1000 satoshis par kilooctet virtuel, soit 1 sat/ov ou 4 sat/wu.
• Le montant d’une sortie doit être supérieur à un montant plancher, typiquement 546 satoshis.
• Une transaction peut être remplacée par une transaction contradictoire (dépensant une même sortie) si l’entrée concernée est signalée comme telle par : nSequence ≤ 0xfffffffd. Cette fonctionnalité est appelée Replace-by-Fee.
• Les transactions doivent être finalisées : une transaction qui n’est pas finalisée mais qui le sera à l’avenir est rejetée de la mempool.
• Le nombre maximal de transactions ascendantes dans la mempool est de 25.
• La taille d’une transaction est limitée à 400 000 unités de poids (100 ko pour une transaction classique).
• Le nombre de vérifications de signatures est limité à 15 opérations.

Le second rôle concerne l’aspect programmable du système, chose qui est parfois totalement méconnue dans la communauté. Dans Bitcoin, chaque sortie contient un script (dit « de verrouillage ») qui est complété par un second script (dit « de déverrouillage ») et exécuté lors de la dépense en tant qu’entrée. Cela permet théoriquement d’effectuer un large éventail d’actions, restreint uniquement par les capacités du langage de programmation. Néanmoins, à la fin de l’année 2010, ces possibilités de programmation ont été restreintes considérablement afin d’éviter l’exploitation de potentielles failles contenues dans le code du logiciel.

De cette manière, seuls certains scripts spécifiques sont autorisés par le protocole pour être valides. Les types de script de verrouillage généralement acceptés par les nœuds dans leur mempool sont :

• Pay-to-Public-Key (P2PK) qui possède la forme suivante : <clé publique (32/64 octets)> CHECKSIG.
• Pay-to-Public-Key-Hash (P2PKH), le schéma le plus répandu et qui a la forme : DUP HASH160 <empreinte de clé publique (20 o)> EQUALVERIFY CHECKSIG.
• Pay-to-Multi-Signature (P2MS) aussi appelé « bare multisig », qui consiste à écrire le schéma de multisignature directement dans le script de sortie : M <clé publique 1 (32/64 o)> ... <clé publique N (32/64 o)> N CHECKMULTISIG. Les règles de mempool limitent usuellement le nombre de participants à 3 sous forme brute, et à 15 par l’intermédiaire de P2SH. Les règles de consensus autorisent ce nombre à aller jusqu’à 20.
• Pay-to-Script-Hash (P2SH), un schéma permettant d’intégrer un autre script et par lequel est réalisée la programmabilité avancée depuis 2012 (et qui est lui-même soumis à certaines règles) : HASH160 <empreinte du script de règlement (20 o)> EQUAL.
• Null Data, qui est un type de script permettant d’écrire 80 octets de données arbitraires dans la sortie transactionnelle : RETURN <données>. La sortie transactionnelle résultante est considérée comme indépensable par les règles de consensus. La mempool ne tolère qu’une seule sortie de ce type par transaction.
• Pay-to-Witness-Public-Key-Hash (P2WPKH), qui est semblable à P2PKH dans sa manière de fonctionner et qui bénéficie des avantages de SegWit : 0 <empreinte de clé publique (20 o)>.
• Pay-to-Witness-Script-Hash (P2WSH), qui est semblable à P2SH dans sa manière de fonctionner et qui bénéficie des avantages de SegWit : 0 <empreinte de script (32 o)>.

De même les scripts de déverrouillage doivent suivre certaines règles pour que la transaction soit acceptée dans la mempool, comme le fait que seuls les scripts ne contenant pas de code opération sont acceptés (seules les données poussées sur la pile sont autorisées). .

Les règles de mempool sont donc diverses et variées. Cependant, comme toutes les transactions n’ont pas besoin d’être relayées par tous les nœuds du réseau, il arrive parfois que des transactions étranges apparaissent sur la chaîne. C’est ce qu’on appelle les transactions non standardes.

Les transactions non-standard

L’appelation « standard » provient des fonctions IsStandard() et IsStandardTx() présentes dans le code du logiciel Bitcoin Core, qui déterminent respectivement l’acceptabilité des sorties transactionnelles et celle des transactions. Les transactions dites « non standardes » sont les transactions qui ne rentrent pas dans les règles de mempool de la configuration par défaut de Bitcoin Core, mais qui finissent quand même par être ajoutées sur la chaîne.

Voici quelques exemples de transactions non standardes :

• Les transactions gratuites, dont le montant en entrée est égal au montant en sortie.
• Les transactions contenant une sortie Null Data dont la tailel des données est strictement supérieure à 80 octets, ou impliquant plusieurs sorties Null Data (hors coinbase).
• Les transactions impliquant des schémas de multisignature de plus de 3 participants pour le P2MS et de plus de 16 participants pour P2SH, par exemple 20.
• Les transactions impliquant un script de type Pay-to-Hash, type qui consiste à fournir la donnée hachée pour déverrouiller une sortie, par exemple : HASH256 <empreinte (32 o)> EQUAL.

Les transactions non standardes ont fait l’objet de différents articles et papiers, car elles montrent les bizarreries de Bitcoin, qui ont le mérite d’attirer l’attention. Dans l’historique de la chaîne, on retrouve notamment des transactions contenant des scripts, disons, originaux.

Premièrement, ces script peuvent être dûs à des erreurs de manipulations. Par exemple, le 28 octobre 2011, la plateforme d’échange Mt. Gox a verrouillé par erreur 2609 bitcoins par un script de verrouillage ayant la forme de P2PKH mais dont l’empreinte était 0 : DUP HASH160 0 EQUALVERIFY CHECKSIG.

Il y a aussi eu le bug de P2Pool en 2012 qui a fait que 0,60280235 bitcoins se sont retrouvés (quelques dollars à l’époque) bloqués par le script invalide suivant :

IFDUP IF 2SWAP VERIFY 2OVER DEPTH

Si l’on examine le script (0x736372697074 en hexadécimal), on s’aperçoit que son encaodage en ASCII correspond au mot « script » !

Secondement, il existe d’autres scripts fantaisistes sur la chaîne, dont le rôle probable a été de permettre à leurs auteurs d’essayer la machine virtuelle de Bitcoin voire de la pousser dans ses retranchements. Par exemple, on peut citer ce script qui a servi à recevoir 0,09 BTC en août 2013 et qui est vraisemblablement l’œuvre de Gregory Maxwell :

DUP 0 LESSTHAN VERIFY ABS 1 16 WITHIN TOALTSTACK <clé publique : 0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71> CHECKSIGVERIFY FROMALTSTACK

Les 0,09 BTC ont pu être dépensés en fournissant la signature et le nombre -1 :

<signature : 3045022100d92e4b61452d91a473a43cde4b469a472467c0ba0cbd5ebba0834e4f4762810402204802b76b7783db57ac1f61d2992799810e173e91055938750815b6d8a675902e01> 1NEGATE

Ainsi, Bitcoin est plus complexe qu’il n’en a l’air. Bien qu’il existe des règles de consensus assez bien connues et respectées strictement par tous, il y a aussi des règles de mempool qui déterminent l’acceptation et le relais des transactions par les nœuds. Ces normes font qu’il existe tout un tas de transactions étranges dites « non standardes » qui font entrevoir les possibilités réelles du protocole.