L'année 2023 dans Bitcoin a été marquée par l'émergence et le succès des métaprotocoles Ordinals et BRC-20. Ce ne sont en effet pas les demandes d'ETF qui ont animé le plus les discussions au cours de cette année, mais la création et l'échange de jetons fongibles et non fongibles (NFT) par l'intermédiaire de ces standards. Cela s'explique par la vague spéculative ayant eu lieu à propos de ces jetons, et par l'encombrement de l'espace de bloc qu'elle a entraîné, menant à une hausse des frais de transaction considérable. Une certaine tension s'est installée et fait ressurgir des questions comme celle de l'utilisation légitime du protocole ou celle de la censure. C'est ce dont nous parlerons ici, en guise de rétrospective.

Ordinals, le protocole d'inscription et de transfert de NFT

Le protocole Ordinals a été conçu par Casey Rodarmor, développeur reconnu dans la communauté de Bitcoin. Ce protocole permet l'émission et le transfert de jetons non fongibles, aussi appelés NFT pour non-fungible tokens. La particularité de ces « artéfacts numériques » est que toutes leurs données sont inscrites sur la chaîne de blocs et qu'ils sont suivis et transférés via une numérotation des satoshis par nombres ordinaux, d'où le nom du protocole. Créer des NFT sur la chaîne de BTC était déjà possible depuis 2014 par le biais du métaprotocole Counterparty, mais le contenu lié n'était pas conservé sur la chaîne.

Cette possibilité d'inscription, même si elle existait antérieurement sous une forme plus indirecte, a été largement facilitée par la mise à niveau Schnorr-Taproot qui s'est produite le 14 novembre 2021. En effet, les inscriptions Ordinals sont réalisées au sein d'un script de déverouillage placé dans le témoin de la transaction et écrit à l'aide de Tapscript. Les inscriptions sont identifiées à l'aide de la structure particulière du script et en particulier par l'indicateur ord.

Elles bénéficient du calcul des frais lié à SegWit qui pondère les données du témoin de façon quatre fois moins importante que les autres données de la transaction. Cette caractéristique donne a cette méthode un avantage par rapport au schéma d'inscription de données NULLDATA, qui utilise l'opérateur OP_RETURN pour stocker des données dans des sorties « classiques » indépensables. De plus, le fait de passer par Tapscript permettent à ces inscriptions de ne pas être limitées en taille par les restrictions des scripts classiques : celle des 3,6 ko standards, dont le respect est nécessaire à la bonne diffusion de la transaction sur le réseau (règle de mempool), et celle des 10 ko obligatoires, qui doit être respectée pour l'inclusion dans un bloc (règle de consensus). La taille d'une inscription Ordinals est donc plafonnée uniquement par la taille limite des blocs.

Le protocole Ordinals a été lancé officiellement le 20 janvier 2023 (UTC). Il a provoqué immédiatement le débat, comme en témoigne l'article de Pourtreaux publié le 25. Le 2 février, une image de près de 4 Mo a été incluse dans le bloc 774 628, suscitant l'émoi dans la communauté. Il s'agissait d'une image des « Taproot Wizards », détournement du mème de la Magic Internet Money contenant notamment les lunettes de soleil usuellement arborées par Udi Wertheimer, l'un des instigateurs de cette tendance. Le bloc était le plus gros bloc jamais miné sur BTC et l'est toujours aujourd'hui.

Ordinals a connu un succès fulgurant. Présenté comme une nouveauté, ce modèle a tout de suite plu aux artistes et aux spéculateurs en tous genres. Son succès a été tel que le sujet a été abordé par la presse généraliste, particulièrement friande de ce genre de phénomène. Mais il a vite été remplacé par un protocole autrement plus viral : la norme BRC-20.

BRC-20 : des jetons fongibles basés sur les inscriptions Ordinals

Le succès d'Ordinals a donné des idées aux gens. Ç'a été le cas du développeur et analyste domo qui a dévoilé le standard BRC-20 le 9 mars 2023 (UTC). Les jetons BRC-20, appelés comme tels en référence à la norme ERC-20 présente sur Ethereum, sont des jetons fongibles, c'est-à-dire que chaque unité du jeton est interchangeable avec une autre.

Le principe du standard BRC-20 est d'inscrire des fichiers JSON sur la chaîne afin d'effectuer des opérations sur les unités de compte. Trois fonctions existent : deploy, qui permet de créer un nouveau jeton sur le réseau, mint, qui permet de forger de nouvelles unités, et transfer, qui permet de transférer les unités en notre possession. Chaque jeton a son sigle boursier, son plafond d'unités en circulation et sa limite d'émission par transaction. À titre d'illustration, voici le fichier de déploiement du jeton ordi (le premier jeton créé par domo lui-même et leader actuel du marché des BRC-20) inscrit le 8 mars dans le bloc 779 832 :

{ 
  "p": "brc-20",
  "op": "deploy",
  "tick": "ordi",
  "max": "21000000",
  "lim": "1000"
}

Là encore, les jetons fongibles sur Bitcoin ne forment pas quelque chose d'entièrement nouveau. En 2013-2014, on pouvait déjà émettre et utiliser des pièces colorées, qui ont d'ailleurs eu leur petit succès à l'époque, à l'instar des Open Assets de Coinprism, des CoinSpark assets de Coin Sciences, et des Colored Coins de Colu. Les BRC-20 nous rappellent aussi les user currencies qu'il était possible de créer sur le protocole Mastercoin (aujourd'hui appelé Omni), dont faisait partie notamment le stablecoin Tether USD (émis initialement sous le nom de Realcoin en 2014).

L'avantage de la norme BRC-20 est qu'elle est très simple et qu'elle se fonde sur un protocole existant très à la mode. Cependant, elle constitue aussi une piètre implémentation de jetons, non optimisée. Par exemple, les transferts nécessitent deux transactions : l'une pour autoriser le transfert par le biais d'un nouveau fichier JSON et l'autre pour effectuer le déplacement des satoshis à l'adresse souhaitée. Il est donc nécessaire de réécrire à chaque fois toutes les données liées au jeton (l'indicateur ord, le format du fichier, et le fichier lui-même) sur la chaîne. De plus, des clients d'indexation doivent être déployés pour suivre la distribution des jetons, ce qui est une charge non négligeable.

Dès le début, domo lui-même expliquait dans un avertissement précédant la description technique de son protocole :

« Il s'agit uniquement d'une norme expérimentale amusante démontrant qu'il est possible de créer des états de solde en dehors de la chaîne à l'aide d'inscriptions. Elle ne doit en aucun cas être considérée comme LA norme pour la fongibilité sur Bitcoin avec Ordinals, car je pense qu'il est très certainement possible de faire des meilleurs choix de conception et des optimisations. Par conséquent, il s'agit d'une expérience extrêmement évolutive, et je déconseille fortement de prendre des décisions financières à partir de ce modèle. »

domo, brc-20 experiment, 10 mars 2023

La réelle particularité des BRC-20 est leur procédé d'émission. En effet, les jetons sont forgés par des transactions Bitcoin, contenant l'inscription liée à l'instruction mint. Une limite d'émission par transaction est déterminée dès le début (pour l'ordi il s'agit de 1000 unités) ainsi qu'un plafond total (21 millions pour l'ordi). N'importe qui peut donc participer à la création initiale des jetons. Une fois qu'ils ont tous été forgés, il n'est plus possible d'en créer de nouveaux, à moins de modifier la norme BRC-20 elle-même.

Cette particularité donne une certaine rareté aux unités et c'est ce qui semble plaire. À ma connaissance, aucun BRC-20 n'a de cas d'utilisation revendiqué. Il s'agit essentiellement de memecoins servant de support à la spéculation.

L'envolée des frais de transaction

Comme on le sait, la taille des blocs de BTC est limitée par un paramètre appelé la limite de poids. Le poids d'une transaction est défini comme étant la moyenne pondérée de la taille des données de base et de la taille du témoin contenant les signatures, cette dernière impactant quatre fois moins la métrique. Le poids d'un bloc est la somme du poids des transactions qu'il contient. Le total est limité à 4 millions d'unités, ce qui correspond à environ 1,8 Mo pour un bloc contenant des transactions « normales » et qui peut aller jusqu'à 4 Mo pour un bloc incluant des transactions « atypiques ». Même si cette limite est complexe à appréhender, elle rend l'espace de bloc rare, ce qui peut soumettre les utilisateurs à une rude concurrence pour la confirmation de leurs transactions et conduire à une hausse significative des frais.

Le succès des Ordinals, et a fortiori des BRC-20, a eu pour effet de remplir l'espace de bloc disponible. Dès février, les inscriptions ont abreuvé les mempools des nœuds et ont commencé à prendre la place des transactions financières dans les blocs de la chaîne. Puis les jetons BRC-20 ont progressivement supplanté les artéfacts numériques au sein des blocs, faisant monter les frais en flèche au début du mois de mai.

Cette tendance s'explique par le fonctionnement particulier de ces jetons, décrit ci-dessus. Ces derniers sont forgés par les utilisateurs qui publient des transactions : quand leur prix monte sur le marché, il est rentable de publier de nouvelles transactions pour s'en procurer, ce qui mène in fine à un encombrement de l'espace de bloc.

Ainsi, c'est la spéculation autour de ces jetons qui est responsable de la montée record des frais qui a suivi. Cette spéculation a été nourrie par le déploiement de places de marché. Dès avril, des services d'échange ont commencé à émerger, comme Ordswap OTC ou UniSat Marketplace. RelayX, un service de swap fonctionnant sur Bitcoin SV, s'est vite adapté pour prendre en charge les principaux BRC-20. Puis des plateformes de change reconnues sont rentrées dans la dance : Gate.io a commencer à intégrer les BRC-20 à son offre avec l'ordi le 8 mai, BitMart l'a fait le 9 mai, OKX le 20 mai et KuCoin le 1^er juin. À l'automne, après quelques mois d'accalmie, la tendance est revenue. C'est alors que Binance a listé l'ordi le 7 novembre 2023, ce qui a lancé une nouvelle vague spéculative. Le cours du jeton ordi est passé de 0,10 $ en avril à près de 20 $ en mai, puis est redescendu et est remonté pour atteindre 75 $ le 26 décembre.

Les frais de transaction sont montés en conséquence. Ils ont connu un premier pic en mai, mois durant lequel les frais médians ont pu atteindre 20 $ par transaction au maximum. Puis une nouvelle hausse à eu lieu durant l'automne, bien plus importante et durable que la précédente, et les frais médians ont ainsi effleuré les 25 $ le 16 décembre !

Ces épisodes de hausse de frais ont posé des problèmes fondamentaux, non pas en raison de leur niveau mais de leur volatilité. Après tout, les frais médians gravitaient autour des 50 centimes pendant toute l'année, et personne ne s'attendait à ce qu'ils descendent. C'est leur variation brutale qui vient perturber le bon fonctionnement du système : du jour au lendemain, certains cas d'usage sont anéantis et certaines pièces (UTXO) deviennent « indépensables ».

Ces périodes de congestion du réseau ont également montré les limites des solutions de seconde couche ayant pour but de résoudre le problème du passage à l'échelle. En effet, les hausses des frais ont perturbé l'usage du réseau Lightning, en décuplant parfois le coût d'ouverture et de fermeture des canaux. Les soldes trop petits et les canaux à la capacité trop faible perdaient leur caractéristique de minimisation de la confiance, ceux-ci étant à la merci d'une fermeture non coopérative par un tiers.

La tentation de la censure

Le succès des NFT Ordinals et des jetons BRC-20 a déclenché un fort rejet, qui a été exprimé sous sa forme la plus extrême par le développeur luke-jr, contributeur de longue date à Bitcoin Core et mainteneur de l'implémentation alternative Bitcoin Knots. En effet, en limitant l'espace de blocs et en faisant augmenter les frais, ces épisodes ont réduit l'utilité de Bitcoin en tant que monnaie, ce qui n'a pas manqué d'attiser les tensions. En raison de leur caractère principalement spéculatif, ces jetons ont été qualifiés de « spam », de « déni de service » ou d'« attaque ». La possibilité d'inscription a été elle appelée un « bug » et une « vulnérabilité ».

Ce rejet a fait naître la tentation de procéder à des actions concrètes pour limiter voire supprimer cette activité jugée indésirable. Ces actions préconisées ont été communément appelées de la censure, même si chacune d'entre elles s'appliquait à un niveau différent.

La première action proposée était le non-relai des transactions contenant des inscriptions Ordinals dans les mempools des nœuds. Cette proposition s'est matérialisée par un « correctif » appelé Ordirespector, publié par luke-jr le 1^er février pour Bitcoin Core et adapté pour Umbrel et Citadel deux semaines plus tard. Néanmoins, la mesure s'arrêtait au relai de ces transactions : il s'agissait d'une règle de gestion pratique, un filtrage au niveau de la mempool du nœud, et les blocs contenant des inscriptions Ordinals continuaient à être acceptés. Une utilisation généralisée de ce « correctif » aurait permis de gêner la diffusion des inscriptions jusqu'aux mineurs, sans pour autant l'empêcher totalement : on peut parfaitement imaginer que les mineurs, ayant intérêt à miner ces transactions en raison de leurs frais, auraient pu mettre en place un nœud public spécial pour les recevoir.

La deuxième action préconisée et appliquée a été le déploiement de ce rejet au sein d'une coopérative minière, menant à la production de blocs ne contenant pas d'inscription Ordinals. Le déploiement a été réalisé au sein de la coopérative Ocean, lancée le 28 novembre 2023 par luke-jr et Jack Dorsey (ancien PDG de Twitter), qui se voulait être l'héritière de l'ancienne coopérative Eligius, gérée par le même luke-jr entre 2011 et 2017. Ocean se basait initialement sur Bitcoin Knots, qui rejetait les inscriptions Ordinals : cela fait que les quelques blocs qu'elle a produit en 2023 ne contenaient pas ces inscriptions mais uniquement des « transactions financières réelles » (ce qui impliquait tout de même les transferts de NFT). De plus, l'implémentation limitait aussi les sorties NULLDATA à 40 octets de données utiles, de sorte qu'elle ignorait aussi d'autres transactions comme les transactions de répartition (« tx0 ») du service de mélange Whirlpool de Samourai Wallet. Il s'agit ici d'une censure passive, qui consiste à confirmer des transactions selon une logique non strictement économique. Depuis le 21 décembre cependant, Ocean est revenu sur cette mesure et les hacheurs de la coopérative peuvent désormais choisir la politique qu'ils appliquent à leurs blocs entre trois possibilités (Knots, Core + Ordisrespector, Core par défaut).

Enfin, la troisième proposition d'action a été celle de procéder à un soft fork pour remédier au problème d'Ordinals, partiellement ou totalement. Ce soft fork aurait été appliqué par les mineurs (vraisemblablement) suite à la demande d'une partie de l'économie. Il s'agissait ni plus ni moins de réaliser une censure active des transactions contenant des inscriptions, en invalidant les blocs incluant de telles transactions. Ce soft fork aurait pu conduire à une scission dans le cas où il n'aurait pas été appliqué par la puissance de calcul majoritaire.

Heureusement, un tel soft fork n'a pas eu lieu et il est peu probable qu'on en arrive là. Cependant, si cette solution peut paraître drastique et contraire aux principes de Bitcoin, elle n'est pas impossible et il est toujours enrichissant de voir comment elle peut émerger, y compris au sein de la communauté de Bitcoin elle-même. Les gens trouvent toujours des raisons pour vouloir censurer l'autre. À titre d'illustration, en janvier 2012, luke-jr avait réalisé une attaque de censure complète avec sa coopérative Eligius contre le système Coiledcoin, qui était miné en combinaison avec Bitcoin ; il n'est pas exclus qu'il recommence un jour si le besoin s'en fait ressentir.

Désapprouver et décourager, mais ne pas rejeter

Les protocoles Ordinals et BRC-20 ont donc marqué l'année 2023. Ils ont fait augmenter les frais de manière drastique et fait surgir des discussions qui ne manqueront pas de réapparaître dans les années à venir. La censure a probablement été le sujet central, celle-ci trouvant des partisans plus ou moins zélés au sein de la communauté.

Rappelons que l'essence de Bitcoin est la résistance à la censure. Se proposer de juger quelles transactions sont légitimes ou pas en commençant à appliquer des mesures, c'est s'engager sur une pente savonneuse. Même si l'entrave de la diffusion sur le réseau et le filtrage des transactions au sein des blocs ne forment un problème grave, ces actions préparent le terrain pour une forme de censure autrement plus menaçante : la censure active imposée par le régulateur financier aux différentes coopératives conformistes.

Cela étant dit, ne pas prôner la censure des inscriptions ne veut pas dire qu'elles ne doivent pas être critiquées. Les jetons BRC-20 par exemple sont des objets spéculatifs illustrant la dégénérescence du monde de la cryptomonnaie, dégénérescence qui a pour effet de perturber l'adoption durable et pérenne des commerçants. Ne pas les empêcher ne signifie pas les approuver : tout ce qu'un bitcoineur peut faire (si tant est qu'il doive faire quelque chose), c'est décourager cette tendance, en l'ignorant en premier lieu, puis en expliquant calmement à quel point elle est superficielle et sans fondement, et qu'elle a vocation à tomber dans l'oubli comme tous les autres engouements futiles avant elle. Bitcoin, de son côté, survivra.

Satoshi Nakamoto a conceptualisé Bitcoin en 2008 et a inventé au passage un algorithme de consensus novateur fondé sur la preuve de travail. Ce dernier permet aux nœuds du réseau pair-à-pair d'arriver à un accord sur le registre de propriété et d'assurer le traitement décentralisé des transactions.

Mais cet algorithme est parfois le sujet d'une certaine confusion. D'un côté, il arrive qu'on le confonde avec le mécanisme de preuve de travail lui-même, ou bien avec la fonction de hachage SHA-256 qui intervient dans le procédé. De l'autre, une erreur répandue est de penser qu'il repose sur une application naïve du principe de la « chaîne la plus longue », tel que décrit dans le livre blanc de Bitcoin. Voyons ce qu'il en est réellement.

 

La preuve de travail

Contrairement à ce que l'on pense, la preuve de travail n'est pas un moyen d'arriver au consensus sur le réseau, même si elle joue un rôle essentiel dans ce processus.

La preuve de travail est en effet un mécanisme de résistance aux attaques Sybil, qui empêche un acteur de multiplier les identités à l'excès pour prendre le contrôle du réseau, ici la confirmation des transactions. Une attaque Sybil est une attaque intervenant au sein d'un réseau ouvert basé sur un système de réputation qui consiste à se dupliquer à moindre coût pour en altérer le fonctionnement. C'est un problème particulièrement présent sur les médias sociaux par exemple, où les comptes de robots sont utilisés en masse pour augmenter la visibilité d'un contenu donné.

La preuve de travail résout ce problème en demandant aux utilisateurs de démontrer de manière objective et quantifiable qu’ils ont dépensé de l’énergie et en discriminant ainsi les participants entre eux¹. Dans le cas de Bitcoin, elle sélectionne le mineur qui choisit le nouveau bloc de transactions étant ajouté à la chaîne. Comme l'écrivait Satoshi :

« La preuve de travail résout [...] le problème de la détermination de la représentation dans la prise de décision majoritaire. Si la majorité était basée sur le principe de vote par adresse IP (une adresse IP, une voix), elle pourrait être détournée par toute personne capable de s'octroyer de nombreuses adresses IP. La preuve de travail est essentiellement basée sur la puissance de calcul : un processeur, une voix. La décision majoritaire est représentée par la chaîne la plus longue, sur laquelle le plus grand effort de preuve de travail a été investi. »

L'idée est de requérir une dépense d'énergie externe pour ajouter un bloc à la chaîne, en échange de quoi le mineur reçoit une récompense composée de bitcoins issus de la création monétaire et des frais de transaction.

Plus précisément, la preuve de travail est réalisée par les hachages successifs de l'entête du bloc candidat via la double application² de la fonction de hachage SHA-256, qui produit des empreintes de 256 bits, soit 32 octets. La preuve consiste à trouver une empreinte qui soit inférieure à une valeur cible déterminée par le protocole, ce qui constitue une collision partielle de la fonction de hachage et rappelle Hashcash. En termes mathématiques, il s'agit de trouver un nonce (n) tel que :

SHA256d( ENTÊTE( n ) ) ⩽ valeur_cible

Puisque la fonction de hachage est supposée impossible à inverser algorithmiquement, le mineur doit se contenter d'essayer un grand nombre de possibilités au hasard pour trouver une empreinte satisfaisant cette inégalité. La probabilité de tomber sur un résultat correct étant connue, cela permet d'estimer une quantité moyenne de travail effectué pour arriver à la solution.

L'empreinte résultante commence nécessairement par un grand nombre de zéros et constitue l'identifiant du bloc. Par exemple, le bloc 630 000 de la chaîne de BTC a pour identifiant :

000000000000000000024bead8df69990852c202db0e0097c1a12ea637d7e96d

Ainsi, la preuve de travail est le bloc lui-même et chaque membre du réseau peut la vérifier facilement en calculant son identifiant.

 

Le principe de la chaîne la plus longue

Un algorithme de consensus est un mécanisme permettant de parvenir à un accord au sein d'un réseau distribué, qui résout de ce fait le problème des généraux byzantins. Dans le cas des cryptomonnaies, il s'agit de se mettre d'accord sur le registre de propriété qui décrit qui possède quoi. L'algorithme de consensus de Bitcoin s'appelle l'algorithme de consensus de Nakamoto par preuve de travail, en hommage à son créateur, Satoshi Nakamoto.

Dans la section 5 du livre blanc, Satoshi décrivait son algorithme en se basant sur le principe de la chaîne la plus longue. Si ce principe est faillible comme on va le voir, il est néanmoins utile pour se représenter le fonctionnement général du consensus. Voici le processus.

 

Coordination

« Les nœuds considèrent toujours que la chaîne la plus longue est la chaîne correcte, et continuent à travailler pour la prolonger. »

Tout d'abord, le réseau se comporte de manière attendue : les nœuds se coordonnent en sélectionnant la chaîne la plus longue et les mineurs travaillent à la prolonger. Tout se passe bien et il n'y a qu'une seule branche.

 

Embranchement

« Si deux nœuds transmettent simultanément des versions différentes du bloc suivant, certains nœuds peuvent recevoir l'une ou l'autre version en premier. Dans ce cas, ils travaillent sur la première version qu'ils ont reçue, mais conservent l'autre branche au cas où elle deviendrait plus longue. »

Puis, un conflit a lieu. Celui-ci peut être créé par un acteur malveillant, mais est généralement engendré de manière accidentelle, à cause de la latence du réseau : deux mineurs valident un bloc à peu près au même moment ce qui fait que les nœuds ne reçoivent pas le même bloc en premier.  On assiste alors à un embranchement (appelé fork en anglais) : deux branches différentes également correctes coexistent et il est impossible de déterminer laquelle il faut prolonger.

Notez que ce type d'embranchement accidentel est commun et se produit de temps en temps sur le réseau pour des raisons de latence.

 

Recoordination

« L'égalité est rompue lorsque la preuve de travail suivante est trouvée et qu'une branche devient plus longue ; les nœuds qui travaillaient sur l'autre branche passent alors sur la chaîne la plus longue. »

Le conflit est enfin résolu lorsqu'une chaîne plus longue (contenant une plus grande quantité de travail accumulée) est partagée sur le réseau. Il se produit alors ce qu'on appelle une recoordination (ou reorganization en anglais) qui réconcilie les nœuds du réseau entre eux.

Les blocs de la branche minoritaire (dits « orphelins ») sont rejetés.

 

Le fonctionnement de cet algorithme de consensus a deux conséquences :

• La sécurité de confirmation du réseau repose sur la supposition qu'une majorité de la puissance de calcul (« 51 % ») est honnête, et donc sur la concurrence entre les mineurs ;
• La sécurité d'une transaction est statistique, son degré de finalité dépendant de la profondeur à laquelle elle se trouve dans la chaîne (un segment plus long sera plus difficile à récrire pour annuler la transaction).

Bien que l'algorithme de Nakamoto ait des défauts, il est important que ce critère objectif reste en place car il fait partie des éléments qui donnent à Bitcoin sa robustesse. Si un cloisonnement persistant du réseau venait à avoir lieu, par exemple dans le cas extrême où « un pays se [couperait] délibérément et totalement du reste du monde », alors il serait possible pour les deux parties du réseau de se réconcilier une fois la connexion rétablie.

 

L'ajustement de la difficulté et la quantité de travail accumulée

Dans le livre blanc, Satoshi supposait que la chaîne la plus longue, était nécessairement celle sur laquelle « le plus grand effort de preuve de travail [avait] été investi ». C'est pour cela qu'il a implémenté naïvement le principe de la chaîne la plus longue dans le protocole originel. Ce n'est que le 25 juillet 2010, dans la version 0.3.3 du logiciel, qu'il a redéfini l'algorithme de consensus pour prendre en compte la notion de travail.

Le principe strict de la chaîne la plus longue est bien valide lorsque la difficulté de minage est constante, car alors la quantité moyenne d'énergie dépensée est fonction du nombre de blocs minés. Néanmoins, la difficulté dans Bitcoin n'est pas fixe et subit un ajustement régulier pour faire en sorte que le temps de bloc moyen reste de 10 minutes et que la politique monétaire établie soit respectée.

La difficulté du minage est définie comme une quantité évoluant de manière inversement proportionnelle à la valeur cible du protocole³. Quand la valeur cible diminue, la difficulté à trouver une empreinte satisfaisant l'inégalité augmente. À l'inverse, quand la valeur cible augmente, la difficulté diminue.

Lorsqu'ils minent un bloc, les mineurs incluent dans le bloc un horodatage (timestamp). Cela permet au réseau d'avoir une idée du temps qui passe. Depuis 2016, le temps réseau est le temps médian passé (MTP), qui est défini comme la médiane des horodatages des 11 derniers blocs et qui retarde donc d'environ une heure (6 blocs) sur l'heure UTC. Notez aussi qu'un horodatage ne peut pas se trouver plus de deux heures dans le futur par rapport au temps subjectif du nœud.

L'ajustement de la difficulté se produit tous les 2016 blocs, c'est-à-dire (hormis grosse variation du taux de hachage) toutes les 2 semaines dans le monde réel. L'algorithme d'ajustement est simple : si le temps mesuré dans la période de 2016 blocs est inférieur à 20 160 minutes (temps attendu), alors la difficulté augmente pour se conformer à la puissance de calcul supposée ; s'il est supérieur, alors la difficulté diminue⁴. Le reciblage est limité à un facteur 4 (multiplication comme division) pour éviter les instabilités. La difficulté de BTC est aujourd'hui 29 570 milliards de fois plus élevée qu'au lancement du réseau en janvier 2009.

Puisque la difficulté a subi une considérable hausse, il aurait été possible d'exploiter le principe de la chaîne la plus longue. Un attaquant disposant d'une certaine puissance de calcul aurait pu générer une branche partant d'un point de la chaîne où la difficulté était très basse⁵ (typiquement le bloc de genèse), en réécrivant les horodatages pour avoir des intervalles de 10 minutes, et miner une quantité énorme de blocs à la fin pour rattraper la chaîne principale, la difficulté ne pouvant que quadrupler tous les 2016 blocs. L'attaque n'aurait pas été gratuite, mais aurait suffi à détruire Bitcoin dans le cas où une autre solution n'aurait pas été trouvée (ce qui est improbable).

C'est pour cela l'algorithme de consensus a été revu pour prendre en considération le travail, qui est défini comme le nombre moyen de hachages nécessaires pour miner un bloc ou une chaîne de blocs⁶, plutôt que la longueur de la chaîne pour arriver à un accord sur le réseau. Depuis le 25 juillet 2010, la chaîne à suivre est ainsi déterminée par sa quantité de travail (ou de « preuve de travail ») : la chaîne correcte est la chaîne possédant le plus de travail accumulé. Aujourd'hui le travail de la chaîne de BTC représente plus de 15 000 yottahachages, soit 15 milliards de milliards de milliards de hachages.

 

Conclusion

Pour que les nœuds du réseau se mettent d'accord sur son registre de propriété, Bitcoin dispose d'un algorithme de consensus appelé l'algorithme de consensus de Nakamoto par preuve de travail. Cet algorithme est à différencier du concept de preuve de travail qui sert de mécanisme de résistance aux attaques Sybil pour sélectionner les mineurs, de sa mise en œuvre qui consiste à produire une collision partielle d'une fonction de hachage et de la fonction de hachage elle-même.

Le consensus se base sur la sélection d'une chaîne de blocs selon sa quantité de travail accumulée, et non strictement de son nombre de blocs comme on l'entend parfois. En effet, si le principe de la chaîne la plus longue tient la route dans une certaine mesure, il ne suffit pas à garantir la robustesse de Bitcoin.

 

Notes

1. ↑ Il existe d'autres mécanismes de résistance aux attaques Sybil dans les systèmes cryptoéconomiques, ces derniers reposant soit sur l'identification (auquel cas on parle de « preuve d'autorité »), soit sur une quantité d'unités internes au système (auquel cas on parle de « preuve d'enjeu »). La « preuve d'espace » constitue une variante de la preuve de travail, qui repose également sur une énergie externe au système.

2. ↑ Dans le minage, la fonction de hachage SHA-256 est toujours appliquée deux fois, supposément pour éviter les attaques par extension de longueur. La véritable fonction de hachage considérée est donc le double SHA-256.

3. ↑ La difficulté est définie comme diff = cible_max / cible où la valeur cible maximale du réseau est :

cible_max = 0x00ffff × 256(0x1d - 3)
          = 0x00000000ffff0000000000000000000000000000000000000000000000000000

4. ↑ La formule d'ajustement de la difficulté est :

nouvelle_cible = ancienne_cible × temps_réel_écoulé / (14 × 24 × 60 × 60)

Le temps réel écoulé est mesuré à partir des horodatages des 2016 derniers blocs, ce qui correspond à 2015 intervalles de temps. L'algorithme est donc défectueux et surestime la puissance de calcul déployée.

5. ↑ Une telle réécriture de chaîne ne pourrait réalistiquement pas être faite aujourd'hui, car des points de contrôle ont été introduits manuellement dans le code pour empêcher une recoordination trop profonde (pratique initiée par Satoshi le 17 juillet 2010). Puisque le dernier point de contrôle est le bloc 295 000 miné le 9 avril 2014, la difficulté est trop haute (6 119 726 089) pour pouvoir rattraper le retard pris sur la chaîne principale.

Il semble également infaisable d'abaisser la difficulté (en espaçant les blocs sur la branche concurrente) pour procéder à la même technique par la suite : le retard pris pour réduire la difficulté serait trop grand.

6. ↑ Le travail d'un bloc est le quotient du nombre d'empreintes possibles (2²⁵⁶) par le nombre d'empreintes satisfaisant le problème :

travail_du_bloc = 2256 / (cible + 1)

Le travail d'une chaîne est la somme des travaux de tous les blocs la composant.

Lorsqu'il a conçu le prototype de Bitcoin en janvier 2009, Satoshi Nakamoto a dû construire un premier bloc à partir duquel la chaîne s'est allongée. Ce bloc il l'a appelé le bloc de genèse (« genesis block » en anglais) en référence au premier livre de la Torah et de la Bible, qui raconte la création du monde par Dieu.

Par convention, on considère qu'il s'agit du bloc de hauteur 0 (ou « bloc 0 ») au-dessus duquel les autres blocs sont successivement empilés. Examinons plus en détail ce que contient cet élément fondateur de Bitcoin en procédant à une dissection minutieuse !

 

Un bloc fondateur

Le bloc de genèse est une donnée essentielle du protocole Bitcoin car il constitue la base à partir de laquelle on peut déterminer la chaîne la plus longue (c'est-à-dire celle ayant le plus de preuve de travail accumulée) et par conséquent la validité des transactions du registre. Il est théoriquement le seul bloc à devoir être inscrit en dur dans le protocole, même si d'autres l'ont été par la suite.

Tel que l'écrivait Satoshi Nakamoto :

« La chaîne de blocs est une structure en forme d'arbre qui a pour racine le bloc de genèse, chaque bloc pouvant avoir plusieurs candidats à sa suite. »

Le code de novembre 2008 (fourni par Satoshi à Hal Finney, Ray Dillinger et James A. Donald notamment) contenait déjà une première version du bloc de genèse, horodatée au 10 septembre 2008, 18:02:08 UTC. Néanmoins, un nouveau bloc a été construit en janvier 2009 spécialement pour le lancement du prototype.

Le bloc de genèse que nous connaissons est ainsi présent dans la version 0.1 du logiciel de Bitcoin, publiée le 8 janvier 2009. Un commentaire au sein du code le décrit :

Genesis Block:
GetHash()      = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
txNew.vin[0].scriptSig     = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854
txNew.vout[0].nValue       = 5000000000
txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG
block.nVersion = 1
block.nTime    = 1231006505
block.nBits    = 0x1d00ffff
block.nNonce   = 2083236893
CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
  CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
    CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
  vMerkleTree: 4a5e1e

Ce bloc pèse très exactement 285 octets. Le voici représenté en hexadécimal brut :

0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

Le bloc de genèse est composé d'un entête de 80 octets et d'une unique transaction, la transaction de récompense. Son identifiant (le résultat du hachage de l'entête par double SHA-256) est 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. Les zéros qui débutent cet identifiant indiquent qu'une preuve de travail a été réalisée.

Notez que les différentes informations contenues dans le bloc sont souvent transmises avec un ordre des octets inverse (dit « little-endian » ou « petit-boutiste »). Nous donnerons ici les informations dans l'ordre ordinaire (qu'on appelle « big-endian » ou « gros-boutiste ») à l'aide du préfixe 0x.

 

L'entête

Comme tous les blocs dans le protocole, le bloc de genèse possède un entête donnant 6 informations différentes. Voici cet entête en détail :

01000000 - version
0000000000000000000000000000000000000000000000000000000000000000 - identifiant du bloc précédent
3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a - racine de Merkle
29ab5f49 - horodatage
ffff001d - valeur cible
1dac2b7c - nonce

 

La version du bloc

0x00000001

La version du bloc indique l'ensemble des règles respectées par le bloc. Cette version 1 indiquait un respect des règles du protocole originel défini par Satoshi. D'autres versions ont été introduites plus tard : la version 2 pour l'application du BIP-34 en mars 2013, la version 3 pour l'activation du BIP-66 en juillet 2015, et la version 4 pour celle du BIP-65 en décembre 2015. Le champ de version a par la suite été utilisé pour que les mineurs signalent leur intention d'appliquer un soft fork (conformément au BIP-9).

 

L'identifiant du bloc précédent

0x0000000000000000000000000000000000000000000000000000000000000000

Puisqu'il s'agit du premier bloc de la chaîne, le champ utilisé pour donner l'identifiant du bloc précédent est fixé à zéro par convention.

 

La racine de Merkle

0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

La racine de Merkle correspond à l'empreinte finale de l'arbre de Merkle des transactions. Puisqu'il n'y a qu'une seule transaction dans le bloc de genèse, il s'agit simplement de l'identifiant de cette transaction.

 

L'horodatage

0x495fab29

L'horodatage indique la date et l'heure à laquelle le mineur a trouvé le bloc. Il est donné par le nombre de secondes depuis le 1^er janvier 1970 00:00:00 UTC. Ici, le nombre correspond à 1 231 006 505 secondes : le bloc de genèse est donc horodaté au 3 janvier 2009 à 18:15:05 UTC.

Toutefois, il ne faut pas croire que cet horodatage indique l'instant précis du lancement effectif du réseau. Ce dernier a en effet été réalisé un peu plus tardivement : le bloc 1 est ainsi horodaté au 9 janvier 2009 à 02:54:25 UTC, soit 5 jours, 8 heures, 39 minutes et 20 secondes plus tard.

 

La valeur cible

0x1d00ffff

La valeur cible est la valeur minimale que l'identifiant du bloc peut avoir pour que ce dernier constitue une solution au problème de preuve de travail de Bitcoin. Moins cette valeur cible est haute, plus il est facile de trouver une solution et de miner un bloc. Elle est donc inversement proportionnelle à la difficulté du réseau.

La valeur cible du bloc de genèse correspond à la plus grande valeur possible dans Bitcoin, ou la difficulté la plus basse pour le dire autrement. Elle est encodée comme un nombre flottant où le premier octet représente un exposant et où la mantisse est déterminée par les 3 octets suivants. Ici, elle est égale à 0x00ffff × 256(0x1d - 3) c'est-à-dire 0x00000000ffff0000000000000000000000000000000000000000000000000000.

La preuve de travail du bloc est valide car l'identifiant est effectivement (largement) inférieur à cette valeur cible :

0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f ≤
0x00000000ffff0000000000000000000000000000000000000000000000000000

On définit la difficulté du minage comme l'inverse de la valeur cible multipliée par la valeur cible de base :

difficulté = cible_de_base / cible

La difficulté du bloc de genèse est donc de 1.

Après le lancement du réseau, la difficulté a stagné à ce niveau pendant près d'un an avant d'enfin commencer à augmenter le 30 décembre 2009.

Au sein du code, le champ de la valeur cible est appelé nBits, car ce paramètre désignait (avant que Satoshi n'en modifie le sens) le nombre de bits de tête à mettre à zéro pour que la solution soit valide. Dans la version de novembre 2008, le champ était en effet fixé à 20, ce qui correspondait à 5 zéros de tête en représentation hexadécimale, soit une valeur cible de 0x00000fffff....

 

Le nonce

0x7c2bac1d

Le nonce (mot qui provient de l'expression anglaise « for the nonce » signifiant « pour la circonstance, pour l'occasion ») désigne le nombre que le mineur fait varier pour calculer la preuve de travail. Il n'a aucune signification particulière, étant déterminé au hasard.

 

L'ensemble des transactions

L'ensemble des transactions forme la seconde partie du bloc. Le voici en détail :

01 - nombre de transactions
01000000 - version
01 - nombre d'entrées
0000000000000000000000000000000000000000000000000000000000000000 - identifiant de transaction de la sortie précédente
ffffffff - index de la sortie précédente
4d - taille du script de déverrouillage
04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73 - script de déverrouillage
ffffffff - numéro de séquence
01 - nombre de sorties
00f2052a01000000 - montant
43 - taille du script de verrouillage
4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac - script de verrouillage
00000000 - temps de verrouillage

 

Le nombre de transactions

0x01

Le bloc contient une seule transaction : la transaction de récompense qui rémunère le mineur (ici Satoshi) pour la preuve de travail réalisée. Le bloc ne comporte ainsi aucune autre transaction, tout comme les blocs minés dans les premiers jours. Il a fallu attendre le 12 janvier et le bloc 170 pour voir la première transaction effective du réseau être confirmée : celle entre Satoshi et Hal Finney.

Toutes les données restantes du bloc appartiennent à la transaction de récompense.

 

La version de la transaction

0x00000001

La version de la transaction indique comment celle-ci doit être interprétée. Elle est fixée à 1 conformément au protocole initial. Aujourd'hui, il existe également une version 2 qui autorise l'usage des verrous temporels relatifs (voir BIP-68).

 

Le nombre d'entrées de la transaction

0x01

La transaction contient une seule entrée : la base de pièce, ou coinbase, qui permet de créer ex nihilo les nouveaux bitcoins et de recueillir les frais de transaction. Cette entrée est donc purement superflue, mais permet de conserver une certaine cohérence dans l'implémentation logicielle. Elle est constituée des champs identifiant la sortie précédente (théorique), d'un script de déverrouillage et d'un numéro de séquence.

 

L'identifiant de transaction de la sortie précédente

0x0000000000000000000000000000000000000000000000000000000000000000

Ce champ est utilisé dans les transactions pour dire à quel sortie transactionnelle correspond une entrée, en donnant l'identifiant de la transaction qui a créé la sortie. Puisqu'il s'agit d'une transaction de récompense qui ne fait pas référence à une sortie transactionnelle précédente, ce champ est fixé à 0 par convention.

 

L'index de la sortie précédente

0xffffffff

Ce champ est utilisé dans les transactions pour dire à quel sortie transactionnelle correspond une entrée, en donnant la position de la sortie dans la transaction qui l'a créée. Puisqu'il s'agit d'une transaction de récompense qui ne fait pas référence à une sortie transactionnelle précédente, ce champ est fixé au maximum par convention.

 

Le script de déverrouillage (scriptSig)

0x04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

Dans Bitcoin, le script de déverouillage est combiné à un script de verrouillage précédent et détermine la validité d'une dépense. Il contient généralement les signatures nécessaires à la dépense d'une pièce et est par conséquent souvent appelé scriptSig. Dans le cas d'une transaction de récompense, l'entrée ne fait référence à aucune sortie transactionnelle existante et ce script peut donc contenir des données arbitraires.

Ici, le script se présente de la manière suivante :

<valeur cible> <nonce supplémentaire> <chaîne de caractères>

Ainsi, il est constitué de trois informations :

• Tout d'abord, la valeur cible du bloc, donnée en sens inverse, conformément à la façon dont elle est représentée dans le code : 0xffff001d
• Ensuite, un nonce supplémentaire (0x04), ou extra nonce, mis en place par Satoshi dans le code du logiciel. Le nonce supplémentaire du bloc de genèse a pour valeur 4, et ceux des blocs suivants sont croissants : celui du bloc 1 est aussi égal à 4, celui du bloc 2 à 11, celui du bloc 3 à 14, etc. La variation de ce nonce supplémentaire au sein des blocs a permis de mettre en évidence un motif particulier, appelé le « Patoshi Pattern », qui détermine précisément les blocs minés par Satoshi et qui démontre que sa fortune s'élève à plus de 1 125 150 bitcoins.
• Enfin, une chaîne de caractères aujourd'hui emblématique, encodée en UTF-8, qui est :

  The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

  Cette courte phrase correspond à la une du Times du 3 janvier 2009, qui annonçait que le ministre des finances du Royaume-Uni était sur le point de renflouer les banques pour la deuxième fois. Le Times étant un quotidien anglais, cela a mené à des spéculations quant à l'identité de Satoshi, qui écrivait également dans un anglais britannique.

Cette phrase présente dans le script de la transaction de récompense possède un rôle double :

• Premièrement, elle prohibe l'antidatage : sa présence dans le premier bloc, à partir duquel toute la chaîne est construite, prouve que le réseau de Bitcoin n'a pas été lancé avant le 3 janvier 2009. Cependant, cela ne veut pas dire que le bloc de genèse date bien du 3 janvier : en effet, il a pu être construit entre le 3 janvier (date de l'horodatage déclaré) et le 8 janvier (date de publication du code).
• Deuxièmement, elle indique symboliquement ce à quoi Bitcoin s'oppose en faisant référence au contexte monétaire et financier de l'époque : le renflouement des grandes banques d'investissement par les États et par les banques centrales suite à la crise financière de 2007-2008. Il est d'ailleurs possible que Satoshi ait choisi cette date précisément pour sélectionner cette une.

Ce script de la base de pièce est encore utilisé de nos jours par les mineurs pour de multiples raisons. À l'instar de Satoshi, ils peuvent inclure des informations arbitraires dans le bloc et faire passer un message public au monde. Ç'a été le cas de la coopérative F2Pool qui, le 11 mai 2020, a évoqué l'injection de liquidité de la Réserve Fédérale en réaction à la crise du covid-19 au sein du bloc 629 999 (le bloc précédant le troisième halving) :

NYTimes 09/Apr/2020 With $2.3T Injection, Fed's Plan Far Exceeds 2008 Rescue

Les regroupements de mineurs peuvent également s'identifier en indiquant leur nom, ce qui permet de juger de la décentralisation du réseau, même si cette pratique reste purement déclarative.

Enfin, les mineurs se servent encore de ce champ pour faire varier un nonce supplémentaire, le nonce de l'entête ne permettant plus depuis 2012 d'essayer suffisamment de possibilités par rapport à la difficulté élevée du réseau.

 

Le numéro de séquence (nSequence)

0xffffffff

Le numéro de séquence de l'entrée est maximal, ce qui fait que la transaction est considérée comme finale.

À l'origine, le numéro de séquence dans les entrées avait pour objectif de permettre les échanges répétés au sein de contrats, tels que les canaux de paiement. Ce modèle imaginé par Satoshi n'était pas suffisamment sécurisé et a par conséquent été abandonné. Cependant, la règle de finalité, qui fait que la transaction est considérée comme finale (pas de temps de verrouillage) si les numéros de séquence de toutes les entrées sont maximaux (comme ici), a été conservée.

Aujourd'hui, ce numéro de séquence est utilisé pour déterminer le temps de verrouillage relatif d'une entrée et pour signaler Replace-by-Fee.

 

Le nombre de sorties de la transaction

0x01

La transaction contient une seule sortie, celle créditant Satoshi de son revenu de minage. Cette sortie est constituée d'un montant et d'un script de verrouillage.

 

Le montant

0x000000012a05f200

Le montant de la sortie est donné dans la plus petite unité du système, unité qu'on a appelé le satoshi en hommage au créateur de Bitcoin. Ce montant correspond ici à 5 milliards de satoshis, soit 50 bitcoins. Il s'agit de la limite maximale du taux de création monétaire de l'époque (50 bitcoins par bloc).

 

Le script de verrouillage (scriptPubKey)

0x4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac

Le scrpt de verrouillage est l'ensemble des conditions à fournir pour pouvoir dépenser la pièce correspondante. Ici, il possède la forme :

<clé publique> CHECKSIG

où la clé publique est 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f. Il s'agit donc d'une sortie transactionnelle de type Pay to Public Key (P2PK), un schéma utilisé dans les débuts de Bitcoin, qui demande une simple signature pour débloquer les fonds. Cela explique le nom donné couramment à ce script : scriptPubKey.

Bien souvent, cette sortie est rétrospectivement attribuée à l'adresse 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, obtenue en prenant l'empreinte de la clé publique. Cela est néanmoins purement esthétique car c'est bien la clé publique elle-même qui a servi à recevoir les bitcoins, pas l'adresse.

Fait intéressant : cette sortie transactionnelle n'est pas considérée comme dépensable par le protocole en raison de la façon dont le bloc de genèse est exprimé dans le code. Cette erreur de programmation pourrait être corrigée par un hard fork, mais cela ne serait ni utile (Satoshi n'a pas touché à ses bitcoins depuis qu'il a disparu), ni même souhaitable (incompatibilité du protocole). Les 50 premiers bitcoins créés sont donc probablement brûlés à tout jamais.

 

Le temps de verrouillage (nLocktime)

0x00000000

Le temps de verrouillage (donnée globale appartenant à la transaction) détermine la date à partir de laquelle cette transaction pourra être confirmée. En étant fixé à zéro, celui-ci est désactivé.

 

Les autres chaînes

Si le bloc de genèse constitue un fondement du protocole Bitcoin, il sert également de base aux différentes branches minoritaires de Bitcoin qui possèdent le même historique jusqu'à leurs scissions respectives : Bitcoin Cash, Bitcoin SV, Bitcoin Gold ou encore eCash/XEC. D'autres protocoles possèdent leur propre bloc de genèse et certains d'entre eux ont également incorporé la une d'un journal ou d'un magazine pour garantir que le lancement du réseau ne s'est pas réalisé avant la date donnée. Ainsi, le bloc de genèse de Litecoin (datant du 7 octobre 2011) contient la phrase suivante :

NY Times 05/Oct/2011 Steve Jobs, Apple’s Visionary, Dies at 56

Celui de Dash (datant du 19 janvier 2014) inclut la une suivante :

Wired 09/Jan/2014 The Grand Experiment Goes Live: Overstock.com Is Now Accepting Bitcoins

 

---

Source

Bitcoin Wiki, Genesis block

Bitcoin est un concept de monnaie numérique fonctionnant sur Internet qui a été créé en 2008 par Satoshi Nakamoto. Mis en application à partir du 3 janvier 2009, il a parcouru un long chemin qui l’a mené à devenir ce qu’il est aujourd’hui, à la fois d’un point de vue technique, économique et social. Néanmoins, il existe toujours des incompréhensions à son égard, y compris chez ceux qui pensent avoir saisi ses principes de base. C’est en particulier le cas de son modèle de sécurité qui reste flou pour beaucoup de personens.

Dans Bitcoin, une foule de notions interviennent. Le système est fondé sur un réseau public et décentralisé de nœuds qui font tourner un logiciel open source. Ces nœuds vérifient des opérations cryptographiques et entretiennent un registre distribué et horodaté appelé la chaîne de blocs, registre où sont enregistrées toutes les transactions d’une unité de compte, le bitcoin. Au sein de ce réseau, un certain nombre d’acteurs, appelés des mineurs, utilisent la puissance de calcul de leurs machines afin de valider les transactions effectuées par le réseau, et reçoivent en échange une rémunération en bitcoins. Tout cela forme un tout harmonique qui permet à Bitcoin d’exister depuis quasiment douze ans.

Cependant, ce qui sécurise Bitcoin, ce n’est pas la cryptographie, la chaîne de blocs, le logiciel libre, la décentralisation ou la puissance de calcul. Ce qui sécurise Bitcoin, c’est l’action combinée d’individus, de personnes de chair et d’os mues par leurs intérêts, de gens qui prennent des décisions et qui s’exposent à des risques personnels. Bitcoin est en effet un système économique et, en tant que tel, base sa sécurité sur le comportement intéressé des êtres humains¹.

 

Qu’est-ce qui préserve la qualité de l’infrastructure logicielle ?

Bitcoin est un protocole de communication qui permet l’existence et la circulation d’une unité de compte numérique, le bitcoin. Ce protocole est un ensemble de règles et ne peut donc pas directement être utilisé par un individu : il faut pour cela qu’il existe une implémentation logicielle, à savoir un programme qui respecte et vérifie ces règles.

L’écosystème autour de Bitcoin repose donc sur ces implémentations logicielles, qui peuvent être complètes (nœuds du réseau) ou partielles (portefeuilles légers). Bien évidemment, les implémentations complètes sont les plus essentielles à la sécurité de Bitcoin, puisque ce sont elles qui servent à valider les transactions et à miner les blocs. En particulier, Bitcoin Core, l’implémentation de référence de Bitcoin (BTC), joue un rôle central dans l’infrastructure du réseau.

Comme tous les programmes informatiques complexes, Bitcoin Core n’est pas exempt de faiblesses, ce qui au cours de son histoire s’est matérialisé par deux incidents majeurs :

• En août 2010, une faille dans le système des transactions (value overflow) avait permis à une personne de créer plus de 184 milliards de bitcoins à partir de rien ! Cet incident avait heureusement pu être corrigé dans les heures qui avaient suivi grâce à la mobilisation des mineurs qui avaient appliqué un patch correctif. À l’époque, cela n’avait pas été dommageable pour Bitcoin, qui ne gérait que peu de valeur.
• En mars 2013, un défaut contenu dans la mise à jour du code avait provoqué la séparation accidentelle du réseau pendant plusieurs heures. Bitcoin était alors beaucoup plus utilisé et cette séparation momentanée avait notamment entraîné la réalisation d’une double dépense par un utilisateur.

C’est pour cela qu’il est crucial que le logiciel derrière Bitcoin soit bien maintenu, optimisé, amélioré. Bitcoin représente aujourd’hui près de 300 milliards de dollars et déplace des dizaines de milliards de dollars chaque jour, et par conséquent il serait désastreux qu’un dysfonctionnement majeur survienne.

Pour assurer la sécurité du logiciel, il existe donc des dizaines de personnes, identifiées ou anonymes, qui s’attellent à scruter et à perfectionner le code, à temps plein ou à temps partiel. Puisque Bitcoin Core est un logiciel libre disponible en source ouverte sur Internet, n’importe qui peut consulter le code, vérifier qu’il est conforme au résultat attendu ou même proposer de le modifier pour l’améliorer ! Tel que l’expliquait Satoshi Nakamoto en décembre 2009 :

Être accessible en source ouverte signifie que n’importe qui peut examiner le code de manière indépendante. S’il s’agissait d’une source fermée, personne ne pourrait vérifier la sécurité. Je pense qu’il est essentiel pour un programme de cette nature d’être open source.

Cette ouverture, couplée à une dette technique limitée, donne à Bitcoin une sûreté plus grande que de nombreux systèmes informatiques. En effet, au vu des sommes en jeu, la récompense pour l’exploitation réussie d’une faille dans le code serait énorme, ce qui renforce la confiance qu’on peut avoir dans le logiciel au cours du temps (effet Lindy).

De plus, les failles dans le code sont, outre leur rareté, le plus souvent très subtiles, ce qui fait que ce sont les développeurs bienveillants qui les découvrent et qui les rapportent. On peut par exemple citer le bogue d’inflation trouvé et révélé en septembre 2018 par Awemany, développeur pour Bitcoin Unlimited, ou la faille permettant des attaques par déni de service rapportée en juin 2018 par Braydon Fuller, développeur pour Bcoin, et révélée publiquement plus deux ans plus tard, en septembre 2020.

Enfin, il faut spécifier que l’infrastructure logicielle n’est pas maintenue gratuitement et qu’elle est soutenue financièrement par les organisations et les individus dont l’activité dépend de la qualité du fonctionnement du réseau. C’est ainsi que des entreprises impliquées dans Bitcoin acceptent de rémunérer les principaux développeurs de Bitcoin Core, pas par charité, mais parce qu’elles ont quelque chose à gagner.

Tout ceci fait que la sécuité du logiciel s’améliore au cours du temps, que les vulnérabilités sont détectées et maîtrisées et que, en presque douze ans d’existence, seules deux d’entre elles ont provoqué un incident majeur. Bitcoin ne repose donc pas sur des logiciels magiques qui fonctionneraient parfaitement bien, mais sur l’action des développeurs qui maintiennent des implémentations faillibles et sur l’aide des mécènes qui financent ce développement.

 

Qu’est-ce qui assure le bon traitement des transactions ?

Bitcoin permet à quiconque d’envoyer des fonds à n’importe qui d’autre, quel que soit le moment, où que se trouve le destinataire dans le monde pourvu qu’il dispose d’un accès à Internet. Il est ainsi résistant à la censure, c’est-à-dire qu’il est très difficile pour une entité d’empêcher arbitrairement une transaction d’être réalisée.

La résistance à la censure est très importante car si Bitcoin n’avait pas cette propriété, il ne pourrait tout simplement pas survivre. Il deviendrait en effet un système bancaire comme un autre, soumis aux réglementations invasives des États : il devrait s’adapter à l’instar de PayPal, ou mourir sous les coups des interventions étatiques, destin funeste qu’ont connu e-gold ou Liberty Reserve en leur temps.

Le bon traitement des transactions dans Bitcoin implique donc deux garanties qui le distinguent des systèmes bancaires traditionnels :

• Toute transaction qui paie un montant correct de frais ne peut pas être délaissée (sécurité a priori) ;
• Toute transaction qui a été confirmée doit demeurer dans le registre et ne peut pas faire l’objet d’une double dépense (sécurité a posteriori).

Ce bon traitement est assuré par ce qu’on appelle le minage. Les mineurs, qui font partie du réseau, reçoivent les transactions des utilisateurs et les incluent dans des blocs. Ils rattachent ces blocs à la chaîne par la résolution d’un problème mathématique nécessitant une dépense d’énergie électrique (preuve de travail) et sont en échange récompensés par les bitcoins nouvellement créés (6,25 bitcoins par bloc actuellement) et par les frais payés par les transactions. Pour déterminer la chaîne valide les nœuds suivent le principe de la chaîne la plus longue, c’est-à-dire qu’ils considèrent que la chaîne contenant le plus de preuve de travail (grosso modo celle avec le plus de blocs) est la chaîne valide. Cela permet au réseau d’arriver à un consensus sur l’état du système.

Bitcoin repose donc sur la dépense d’énergie pour fonctionner, car c’est elle qui détermine le caractère infalsifiable de la chaîne et des bitcoins créés. Le taux de hachage, qui désigne le nombre de calculs par seconde réalisés par le réseau, atteint aujourd’hui les 130 EH/s, à savoir 130 milliards de milliards de calculs par seconde. Cette considérable force de calcul consomme aujourd’hui, selon certaines estimations, plus de 82 TWh par an, soit une dépense énergétique égalant la consommation d’électricité de pays comme la Belgique ou la Finlande.

 

 

Néanmoins, en dépit de son rôle central, ce n’est pas sur cette énergie que se fonde la sécurité du minage. En effet, la sécurité vient de la concurrence entre les mineurs, et pas de l’énergie totale dépensée. Comme l’écrivait Satoshi Nakamoto dans le livre blanc de Bitcoin en 2008 :

Le système est sécurisé tant que les nœuds honnêtes contrôlent collectivement plus de puissance de calcul qu’un groupe de nœuds qui coopéreraient pour réaliser une attaque.

L’important ce n’est pas que le taux de hachage de Bitcoin soit le plus haut possible, c’est que les mineurs disposant d’une puissance de calcul non négligeable soient « honnêtes », c’est-à-dire qui soient prêts à miner systématiquement toutes les transactions payant un montant correct de frais (pas de censure a priori) et à toujours construire leurs blocs à partir de la plus longue chaîne (pas de réorganisation de chaîne).

Imaginons (cas pessimiste) que les États membres de l’ONU se mettent d’accord sur la dangerosité de Bitcoin et décrètent l’interdiction de certaines transactions sur Bitcoin, les transactions de mélange de pièces au nom de la lutte contre le blanchiment d’argent par exemple. Dans ce cas, les mineurs pourraient être soumis à de fortes pressions de la part de leurs autorités respectives, et devraient faire le choix de continuer à être honnêtes en se déplaçant dans un pays non concerné ou en minant illégalement, ce qui constitue dans les deux cas un risque, ou de devenir des attaquants en suivant la loi. Cette réglementation des mineurs par les États permettrait, si leur matériel représentaient plus de la moitié de la puissance de calcul du réseau, d’empêcher toute confirmation d’une transaction illégale par le biais d’une attaque des 51 % mondiale.

La solution au problème proviendrait des individus et des groupes d’individus qui seraient prêts à miner des transactions déclarées comme illégales, et qui resteraient donc honnêtes du point de vue de Bitcoin. Le risque pris par ces mineurs pourrait alors être compensé par les frais des transactions censurées, qui pourraient s’avérer être très élevés, surtout si des montants astronomiques étaient en jeu.

C’est pour cela que la bon fonctionnement des transactions vient du comportement des mineurs, pas uniquement de la puissance de calcul du réseau. Pour que Bitcoin soit correctement sécurisé, il faut donc que les mineurs soient nombreux (partage du risque) et se trouvent à des endroits différents du monde (décentralisation).

 

 

 

Qu’est-ce qui garantit la limite des 21 millions de bitcoins ?

Lorsqu’on entend parler du bitcoin, il ne faut pas attendre longtemps avant que sa politique monétaire singulière soit évoquée. Le bitcoin suit en effet un processus d’émission très précis qui limite sa quantité d’unités en circulation à 21 000 000 : les fameux 21 millions de bitcoins.

Bien que le principe soit brièvement décrit dans le livre blanc, cette politique monétaire n’a été définie rigoureusement par Satoshi Nakamoto que le 8 janvier 2009 dans son annonce du lancement de Bitcoin :

La circulation totale sera de 21 000 000 de pièces. Elle sera distribué aux nœuds du réseau lorsqu’ils créeront des blocs, le montant étant divisé par deux tous les 4 ans.

les 4 premières années : 10 500 000 pièces
les 4 années suivantes : 5 250 000 pièces
les 4 années suivantes : 2 625 000 pièces
les 4 années suivantes : 1 312 500 pièces
etc…

Cela fait du bitcoin une monnaie dure à produire à l’inverse des monnaies fiat imposées par les États, comme l’euro ou le dollar, dont la gestion de la masse monétaire est déléguée à des banques centrales. Bitcoin donne ainsi aux individus la possibilité d’épargner une monnaie qui ne perd pas en valeur au cours du temps, et qui empêche au passage les acteurs financiers proches du pouvoir de profiter de l’effet Cantillon.

La politique monétaire du bitcoin constitue donc une propriété révolutionnaire qui n’a même pas été appliquée par le passé et beaucoup la mettent en valeur comme une propriété gravée dans le marbre qui ne pourrait absolument pas être modifiée. Néanmoins ce n’est pas le cas, et cette « résistance à l’inflation » doit être, tout comme la résistance à la censure, sécurisée par des individus qui agissent en ce sens.

Bitcoin est un protocole de communication, un ensemble de règles qui permettent à des gens de transférer de la valeur entre eux, et en cela il peut évoluer. Les règles de consensus qui définissent Bitcoin ne sont en effet pas figées et peuvent faire l’objet de changements, comme l’ont montré les différentes améliorations qui ont jalonné l’existence de Bitcoin telles que P2SH, les verrous temporels ou SegWit.

De plus, l’évolution du protocole peut se faire dans un sens non prévu originellement, ce qui a eu lieu à de multiples reprises dans l’histoire des cryptomonnaies.

En juin 2016, Ethereum a ainsi violé l’immuabilité de sa propre chaîne en annulant le piratage d’un contrat autonome (TheDAO) où 3,6 millions d’éthers, qui représentaient plus de 45 millions d’euros. Cette somme dérobée représentait 4,4 % de la quantité totale d’éthers en circulation, et une majorité économique (à commencer par Vitalik Buterin) a donc décidé de revenir sur ce transfert le 20 juin. Un groupe dissident a refusé, ce qui a créé une autre chaîne où le piratage était toujours présent, qui s’appelle aujourd’hui Ethereum Classic.

De même, Bitcoin a changé depuis ses débuts et n’est plus le même qu’en 2011. Le principal changement n’est pas un modification du protocole en soi, mais un changement de vision : les visions d’une monnaie d’échange et d’un moyen de transfert anonyme, qui étaient prédominantes aux débuts de Bitcoin, se sont estompées au profit de la vision d’un or numérique qui servirait de monnaie de réserve. Même si les premières visions subsistent au travers du projet Lightning et des logiciels dédiés à la confidentialité (Wasabi, Samourai, JoinMarket), elles sont devenues néanmoins minoritaires dans la communauté de Bitcoin. En effet, les gens s’enthousiasment plus aujourd’hui pour les investissements de grandes entreprises comme MicroStrategy et Square, ou pour l’intégration 100 % custodiale du bitcoin dans PayPal, que pour l’échange commercial ou pour l’usage réalisé sur le dark web.

 

 

Ce changement de narration s’est accompagné d’un maintien conservateur du protocole, notamment par le biais d’une restriction de sa capacité transactionnelle. Cette restriction a pour effet de préserver la décentralisation du minage donc la sécurité de la chaîne, mais aussi d’accroître considérablement les frais de transaction payés par les utilisateurs, qui peuvent actuellement être de plusieurs euros en moyenne pour un traitement rapide par le réseau².

Face à ces changements, nous sommes donc en droit de nous demander quelle est la force qui empêche la politique monétaire de Bitcoin d’être modifiée, ce qui nous amène naturellement à la question plus générale de la gouvernance de Bitcoin, c’est-à-dire la manière dont il est dirigé. Qui décide de l’avenir du protocole ?

D’une part, certains pensent que la gouvernance est la prérogative des développeurs du protocole, que ceux-ci sont en charge de ce qui doit ou non être intégré. Pour Bitcoin, ce serait le cas de l’implémentation de référence, Bitcoin Core, et de son mainteneur principal, Wladimir van der Laan, qui possèdent les droits sur le dépôt GitHub. Il est en effet vrai que les développeurs ont une certaine influence sur le protocole en acceptant ou en refusant d’inclure une modification : par effet d’inertie, ils ont un poids dans les choix qui vont être faits, car tout changement non consenti par eux devrait être implémenté par une nouvelle équipe peut-être moins expérimentée et moins bien financée. Néanmoins, si un changement majeur et controversé en venait à être proposé (comme le serait probablement une violation de la politique monétaire du bitcoin), les développeurs n’auraient aucune chance de voir leur modification être acceptée. C’est notamment ce qui s’est passé pour Bitcoin ABC, l’implémentation principale du protocole Bitcoin Cash, qui se voit aujourd’hui être exclue pour avoir tenté de rediriger 8 % de la récompense de bloc à ses fins.

D’autre part, une opinion assez répandue suppose que ce sont les mineurs qui doivent décider de l’évolution du protocole, notamment par le biais de votes proportionnés à leur puissance de calcul. Ces mineurs sont en effet garants de l’intégrité de la chaîne de blocs et possèdent un rôle majeur dans Bitcoin. Il est donc évident qu’une version de Bitcoin privilégiée par les mineurs a plus de chances de prospérer qu’une version concurrente qui serait plus sensible à la censure. Cependant, ce ne sont pas les mineurs qui possèdent le réel pouvoir sur le protocole, pour la simple et bonne raison que ce ne sont pas eux qui contribuent à valoriser l’unité de compte. En raisonnant par l’absurde, on pourrait dire que si les mineurs étaient réellement en charge du protocole, le système économique de Bitcoin serait voué à l’échec : ils seraient en effet incités à augmenter leurs revenus par la création monétaire à l’instar des banques centrales.

Tout ceci nous amène à la troisième catégorie d’acteurs impliqués dans Bitcoin : les utilisateurs, ou plutôt les marchands, c’est-à-dire les personnes qui acceptent le bitcoin comme moyen de paiement pour un bien ou un service. Cette catégorie des marchands est à prendre au sens large et inclut, outre les commerçants classiques, les épargnants et les spéculateurs qui échangent de l’euro contre du bitcoin. Le fait est que ce sont ces utilisateurs qui, par l’usage direct ou indirect d’un nœud complet, décident réellement de la direction dans laquelle Bitcoin doit aller, car ce sont eux qui apportent de la valeur au bitcoin.

Lorsqu’en novembre 2017 il a été question de doubler la capacité transactionnelle de Bitcoin par le biais d’une mise à niveau appelée SegWit2X, les utilisateurs ont refusé. Cette proposition, soutenue par la majorité des mineurs et par une grande part des entreprises du milieu, a été annulée avant son activation au vu de l’impopularité de celle-ci. Ainsi, c’est le sectarisme des utilisateurs et des détenteurs de bitcoins, attisé par un certain nombre d’influenceurs, qui a prévalu dans l’affaire, chose que pressentait Satoshi Nakamoto dès décembre 2010 :

Les utilisateurs de Bitcoin pourraient devenir de plus en plus sectaires à propos de la limitation de la taille de la chaîne pour que son accès reste facile pour beaucoup d’utilisateurs et pour les petits appareils.

Le modèle économique de Bitcoin est ainsi protégé par ces marchands qui, par le biais d’une conservation plus ou moins longue, sont incités à faire en sorte que la valeur du bitcoin ne baisse pas, et même qu’elle augmente. Il est donc dans leur intérêt de ne pas modifier la politique monétaire déflationniste du bitcoin. De plus, la limite des 21 millions de bitcoins est un point de Schelling fort qui dévantagerait toute tentative de changement.

Néanmoins, ce modèle n’est pas magique et, tout comme le minage, repose essentiellement sur la résistance individuelle des marchands aux pressions, qu’elles soient intérieures (la proposition d’une émission monétaire pour protéger la chaîne par exemple) ou extérieures.

Le cas d’une pression extérieure est le plus parlant. De manière pessimiste, on pourrait imaginer qu’un décret appliqué par les États membres de l’ONU impose par la loi une création monétaire qui reviendrait à une banque centrale mondiale, et qui rendrait illégale la version déflationniste de Bitcoin. Dans ce dernier cas, le destin de Bitcoin serait entre les mains aux marchands, qui devraient faire preuve de courage en refusant ce décret et en acceptant le bitcoin interdit, soit en toute illégalité dans leur pays, soit dans un pays non concerné.

Ainsi, à l’instar du bon traitement des transactions qui est garanti par les mineurs et renforcé par la décentralisation du minage, la défense de la politique monétaire est assurée par les marchands et affermie grâce à leur degré d’indépendance : moins il y a de marchands capables de continuer leur activité dans l’illégalité ou depuis des lieux non réglementés, notamment par la gestion de leur propre nœud complet, moins le bitcoin est résistant à l’inflation.

 

Conclusion

Bitcoin est un système économique basé sur l’action d’individus libres. Sa sécurité ne provient donc pas des concepts sous-jacents à son fonctionnement comme la cryptographie, la chaîne de blocs, le logiciel libre, la décentralisation ou la puissance de calcul, mais de la volonté humaine des personnes qui œuvrent chaque jour à sa survie. Bitcoin ne serait pas là sans ses développeurs bienveillants, ses mineurs soucieux de la résistance de la chaîne et ses marchands prêts à tout pour conserver un protocole sain.

Bitcoin peut ainsi être dénigré, réglementé, interdit, attaqué, combattu, mais il ne pourra pas être détruit dans son principe tant qu’il y aura des gens derrière lui. C’est pourquoi sa communauté est si cruciale : même dans les pires moments de doute, il y aura toujours des personnes prêtes à programmer, à miner et à valoriser le bitcoin. Ainsi, malgré les restrictions imposées par les États et les efforts des banques centrales pour le singer, Bitcoin est là pour rester. Et c’est tant mieux.

 

---

Notes

1. ↑ Je tire cette réflexion de la théorie d’Eric Voskuil et en particulier de son texte sur le principe du partage du risque dans lequel il observe que le risque individuel d’accepter ou de miner le bitcoin dépend du nombre de gens qui le prennent.

2. ↑ Ces deux changements, relatifs à Bitcoin et à Ethereum, ne sont pas forcément de mauvaises évolutions : le monde a probablement besoin d’une réserve de valeur à hauts frais très sécurisée et très stable (surtout lorsqu’on constate les derniers agissements des États et des banques centrales) et d’une plateforme de contrats autonomes qui puisse être modifiée socialement dans le cas où 5 % des fonds sont concernés. Néanmoins, ces changements indiquent que certains principes peuvent s’éroder et que les protocoles peuvent effectivement évoluer dans un sens non prévu originellement.

Bitcoin est un système de monnaie programmable et constitue la première implémentation de ce qu’on appelle les smart contracts ou contrats autonomes. À chaque transaction, des scripts sont exécutés pour vérifier que les fonds dépensés remplissent les conditions voulues par l’utilisateur précédent. De nombreuses conditions sont peuvent être mises en place (divulgation d’un secret, verrou temporel, multisignature), même si le plus souvent les fonds sont simplement dépensés grâce à la signature d’un utilisateur unique.

Bitcoin repose sur un modèle de pièces (UTXO), où chaque pièce est verrouillée par un script incomplet écrit sur la chaîne. Lors d’une transaction, les pièces de bitcoin en entrée sont déverrouillées par un script complémentaire. Puis, de nouvelles pièces sont créées à partir des anciennes grâce à de naouveaux scripts de verrouillage, ce qui perpétue le caractère programmable du système.

Lorsque j’ai découvert comment les transactions fonctionnaient et ce qu’elles permettaient, j’ai été fasciné par l’élégance de cette solution. Néanmoins, en approfondissant ma recherche, j’ai été perturbé par l’existence d’une chose qui différait des autres, une exception : le schéma Pay to Script Hash, qu’on abrège couramment en P2SH.

 

Les différents schémas : P2PK, P2PKH, P2MS et P2SH

Des scripts sont impliqués dans chaque transaction du réseau Bitcoin. Le langage de script est constitué de plus d’une centaine de codes opération, de sorte qu’un large éventail de possibilités s’offre à nous vis-à-vis des conditions qu’on souhaite imposer.

Cependant, dans le but d’améliorer la communication entre les différentes applications et de limiter le risque de perte, certains standards de scripts, ou schémas, ont émergé.

 

P2PK : Pay to Public Key

Le premier schéma s’appelle Pay to Public Key (P2PK), qu’on peut traduire littéralement en français par « payer à la clé publique ». Il s’agit d’envoyer des fonds vers la clé publique (public key) d’un utilisateur, que lui seul pourrait dépenser en signant avec sa clé privée. Le script de verrouillage (parfois appelé scriptPubKey) permettant ce type d’envoi est :

<clé publique> CHECKSIG

Au moment de la dépense, l’utilisateur doit utiliser un script de déverrouillage (parfois appelé scriptSig) contenant simplement sa signature :

<signature>

Pour l’expliquer en français, l’exécution successive de ces deux scripts permet de vérifier que la signature fournie par l’utilisateur correspond à sa clé publique, auquel cas elle est valide.

Si le schéma P2PK était utilisé dans les premiers jours de Bitcoin, notamment pour recevoir les gains de minage, il est aujourd’hui tombé en désuétude au profit d’un schéma rival : P2PKH.

 

P2PKH : Pay to Public Key Hash

Pay to Public Key Hash (P2PKH), littéralement « payer à l’empreinte de la clé publique », est le deuxième type de schéma apparu dans Bitcoin dès le début, grâce à la conception de Satoshi Nakamoto. Ce schéma permet non pas de réaliser un paiement vers une clé publique, mais vers l’empreinte d’une clé publique, et de faire en sorte que le système de script de Bitcoin vérifie quand même que la signature correspond à la clé publique lors de la dépense des fonds. L’empreinte de la clé publique est alors considérée comme la donnée essentielle de l’adresse, qui dans ce cas commence toujours par un 1, comme par exemple 1DzxhUphLFq8FZPGbFgLF8Ssz3hMX9EuMp.

Le script de verrouillage ici est :

DUP HASH160 <empreinte de la clé publique> EQUALVERIFY CHECKSIG

Et le script de déverrouillage est :

<signature> <clé publique>

Pour le dire en français, l’exécution des deux scripts permet de :

• Vérifier que le passage de la clé publique fournie par la fonction de hachage HASH160 (l’empreinte) est égale à l’empreinte qui est spécifiée dans le script ;
• Vérifier la signature fournie correspond à la clé publique fournie.

L’avantage de ce schéma est qu’il permet d’avoir des adresses plus courtes (l’information à encoder n’est que de 20 octets au lieu de 65 octets pour une clé publique), chose pour laquelle Satoshi Nakamoto l’a implémenté. De plus, en ne révélant la clé publique qu’au moment de la dépense, ce schéma accroît aussi la sécurité contre la menace (très hypothétique) de l’ordinateur quantique.

 

P2MS : Pay To MultiSig

Le schéma Pay To MultiSig (P2SH), littéralement « payer à la multisignature », s’est popularisé début 2012. Il s’agit essentiellement d’un schéma qui permet d’exiger la signature de M personnes faisant partie d’un groupe de N participants, via le script de verrouillage :

M <clé publique 1> ... <clé publique N> N CHECKMULTISIG

Le script de déverrouillage correspondant est :

<leurre (0)> <signature 1> ... <signature M>

Pour plus d’informations sur la multisignature, je vous invite à lire mon article sur les adresses multisignatures.

C’est ce schéma, particulièrement exigeant au niveau de la mise en place, qui a motivé la création du schéma P2SH.

 

P2SH

Pay to Script Hash (P2SH), littéralement « payer à l’empreinte du script ». Ce schéma reprend l’idée derrière P2PKH, à la seule différence que la donnée hachée ici n’est pas une clé publique, mais le script lui-même ! Le script en question est alors appelé script de règlement (redeem script) et son empreinte est la donnée constituante de l’adresse, cette dernière commençant toujours par un 3 à l’instar de 3DyDCGSC59yYY46dnRH7Vw1iKbV8zeW36q.

Ce type de schéma a pour avantage de permettre à un utilisateur d’y inclure n’importe quel script et de pouvoir recevoir des fonds de la quasi-totalité des portefeuilles existants. Le fardeau de la construction et du déverrouillage du script revient donc au détenteur de l’adresse, non à celui qui envoie les fonds, ce qui simplifie grandement la communication.

Le script de verrouillage pour le schéma P2SH est :

HASH160 <empreinte du script de règlement> EQUAL

Et le script de déverrouillage est un script de la forme :

[éléments de déverrouillage] <script de règlement>

En français, cela veut dire que le système de script originel de Bitcoin va vérifier que le hachage du script de règlement est égal à l’empreinte inscrite dans le script. Et c’est tout.

Comment ça, « c’est tout » ? Le script de règlement n’est pas exécuté ? N’importe qui connaissant le script pourrait dépenser les bitcoins ?

Comme on va le voir, ce n’est pas le cas et le script de règlement est bien exécuté, bien que ce ne soit pas indiqué explicitement.

 

Règles et exceptions : OP_EVAL et P2SH

Dans la vie, il y a souvent une manière élégante de faire les choses, qui demande parfois plus d’efforts initiaux mais qui préserve l’ordre et la simplicité, et une manière grossière, plus facile à implémenter mais qui complique les choses et crée le désordre.

Ainsi, dans le système législatif d’un pays, il est plus facile de créer et de faire voter de nouvelles lois execeptionnelles que de réformer en profondeur le système. Cette tendance à l’inflation législative fait qu’on se retrouve avec des pays comme la France, qui cumule 73 codes juridiques en vigueur et qui vit de 214 taxes et impôts ainsi que d’une myriade de cotisations sociales.

En informatique comme en droit, l’ajout de nouvelles exceptions crée de la dette technique, rendant le système plus complexe à appréhender, plus difficile à maintenir et plus susceptible de ne pas fonctionner comme attendu. P2SH fait partie de ces exceptions.

 

Le code opération mort-né : OP_EVAL

L’idée d’implémenter un schéma de script qui utilise l’empreinte d’un autre script comme identifiant est née en 2011, afin de reproduire ce qui est réalisé dans la schéma P2PKH. Toutefois, cette idée n’a pas été développée initialement comme P2SH, mais à travers OP_EVAL, un nouveau code opération permettant l’exécution récursive d’un script à l’intérieur d’un autre script.

L’ajout de ce code opération, proposé le 18 octobre 2011 par Gavin Andresen, devait être implémenté comme un soft fork, via le remplacement de l’instruction nulle OP_NOP1.

Un schéma standard aurait également été ajouté. Le script de verrouillage imaginé pour ce schéma était :

DUP HASH160 <empreinte du script de règlement> EQUALVERIFY EVAL

Le script de déverrouillage correspondant était :

[éléments de déverrouillage] <script de règlement>

Pour le dire en français, l’exécution des deux scripts côte à côte aurait permis de :

• Vérifier que le hachage du script de règlement soit égal à l’empreinte spécifiée dans le script de verrouillage ;
• Vérifier que l’exécution du script de règlement combiné aux éléments de déverrouillage soit bien valide.

Néanmoins cette solution n’a pas été acceptée, celle-ci ayant été jugée trop dangereuse au niveau du pouvoir de récursion. À la place c’est un autre modèle, plus restrictif, qui a prévalu : le schéma P2SH.

 

Comment fonctionne P2SH ?

P2SH a été proposé le 3 janvier 2012 comme alternative à OP_EVAL et à d’autres propositions. Il a été intégré au protocole Bitcoin le 1^er avril sous la forme d’un soft fork activé par les mineurs.

L’exécution de ce type de script fonctionne exactement comme le schéma lié à OP_EVAL, à l’exception qu’une partie du script n’est pas explicitement indiquée. D’une part, la vérification de la correspondance entre l’empreinte indiquée et le script de règlement est bien réalisée par le script de verrouillage. En effet, celui-ci devient (comme on l’a vu) :

DUP HASH160 <empreinte du script de règlement> EQUALVERIFY EVAL

D’autre part, l’évaluation du script de règlement est effectuée implicitement grâce à une exception ajoutée au code source. Dès que les nœuds du réseau reconnaissent le schéma, ils l’interprètent différemment. Ainsi dans Bitcoin Core, on peut observer la condition suivante au sein de la fonction VerifyScript de l’interpréteur :

// Additional validation for spend-to-script-hash transactions:
if ((flags & SCRIPT_VERIFY_P2SH) && scriptPubKey.IsPayToScriptHash())
{
    ...
}

Cette exception permet l’exécution du script de règlement après l’exécution des deux scripts (déverrouillage et verrouillage). D’où le fait qu’on indique les éléments de déverrouillage avant de pousser le script de règlement dans le script de déverrouillage :

[éléments de déverrouillage] <script de règlement>

Si cette solution est pratique, elle crée une complexité et n’est pas très élégante. Comme l’a dit Gavin Andresen dans l’explication du BIP-16 :

Reconnaître une forme « spéciale » de scriptPubKey et réaliser une validation supplémentaire quand elle est détectée, c’est laid. Cependant, l’avis général est que les alternatives sont soit encore plus laides, soit plus complexes à implémenter, et/ou étendent le pouvoir du langage d’expression de manière dangereuse.

L’implémentation initiale de P2SH a donc compliqué les choses. Mais cela ne s’est pas arrêté pas là, car l’activation de SegWit en 2017 a ajouté de la complexité au modèle.

 

SegWit, P2SH-P2WPKH et P2SH-P2WSH

En août 2017, la mise à niveau SegWit a été intégrée à Bitcoin (BTC) sous la forme d’un soft fork. Celle-ci avait pour objectif de corriger la malléabilité des transactions, d’augmenter la capacité transactionnelle, d’améliorer la vérification des signatures et de faciliter les modifications futures du protocole.

Pour ce faire, SegWit implémentait un nouveau modèle de transaction, où les signatures sont situées dans une partie séparée de la transaction appelée le témoin (d’où le nom de Segregated Witness). Afin d’implémenter ce changement comme un soft fork, il a été nécessaire d’introduire un moyen d’accéder au nouveau type de transaction sans briser la compatibilité avec les anciennes adresses.

C’est ainsi que 4 nouveaux types d’adresse ont vu le jour : deux nouveaux types « natifs », P2WPKH (Pay to Witness Public Key Hash) et P2WSH (Pay to Witness Script Hash), incompatibles avec portefeuilles ne supportant pas SegWit ; et deux types « imbriqués » associés, P2SH-P2WPKH et P2SH-P2WSH, qui permettent la transition grâce à l’emploi de P2SH.

Pour ces deux derniers types d’adresse, le schéma utilisé est P2SH avec un script de règlement de la forme :

<version SegWit> <empreinte>

Dans la version 0 de SegWit (la seule qui existe pour le moment), l’empreinte est affectée à une clé publique ou à un script selon sa longueur : si elle est de 20 octets, elle est interprétée comme une empreinte de clé publique ; si elle est de 32 octets, elle est interprétée comme une empreinte de script. Cette empreinte est aussi appelée « programme ».

Ce script est anyone-can-spend puisque le script de règlement suffit à déverrouiller la pièce :

<script de règlement>

Comme pour P2SH, la connaissance du script de règlement ne suffit pourtant pas à dépenser les fonds, car une nouvelle exception est ajoutée au code de façon à ce que les éléments de déverrouillage soient transférées dans le témoin. Dans Bitcoin Core, cette exception se traduit par :

// P2SH witness program
if (flags & SCRIPT_VERIFY_WITNESS) {
    ...
}

SegWit a ainsi apporté un nouveau lot de complexité, et notamment un deuxième niveau de récursion. Dans le cas du schéma P2SH-P2WSH, on a en effet une série de 3 scripts imbriqués. Le premier script est le script de déverrouillage que l’on a présenté au début de cet article :

HASH160 <empreinte du script de règlement> EQUAL

Le deuxième script est le script de règlement spécifique à P2SH :

<version SegWit> <empreinte du script SegWit>

Le troisième est le script SegWit, indiqué dans le témoin avec les éléments de déverrouillage au moment de la dépense des fonds. Par exemple, il peut s’agir d’un script de multisignature comme vu précédemment :

2 <clé publique 1> <clé publique 2> 2 CHECKMULTISIG

qu’on complète avec les éléments :

0 <signature 1> <signature 2>

 

Conclusion

Pay to Script Hash (P2SH) est donc une manière imparfaite mais très pratique de permettre aux utilisateurs de payer à l’empreinte d’un script, c’est-à-dire à une adresse simple qui correspond à un script. La récursion qui intervient dans l’exécution du script aurait pu être implémentée de manière plus élégante grâce au code opération OP_EVAL, mais ce dernier a été jugé trop dangereux par la communauté pour voir le jour.

En ajoutant une nouvelle exception au protocole pour être exécuté, le schéma P2SH représente un vecteur de complexité. De plus, cette complexité est démultipliée par l’incorporation de SegWit, qui ajoute de nouvelles exceptions rigides à P2SH et qui finit de détourner complètement le fonctionnement originel du système de script de Bitcoin.

Néanmoins, ce qui est fait est fait, et aujourd’hui ces changements commencent à être connus dans l’écosystème, et on peut donc espérer que cette complexité n’impacte pas trop les nouveaux développeurs. En particulier, le schéma P2SH est répandu dans tout l’écosystème, par les protocoles associés à Bitcoin tel que Bitcoin Cash, Litecoin ou Dash. Seuls les développeurs de Bitcoin SV ont se sont opposés à cette particularité de manière catégorique et ont choisi de désactiver P2SH en février 2020.

Ce qu’il faut retenir de tout ceci, c’est que Bitcoin, au-delà de son aspect technique, est un système économique et social. Il évolue selon les exigences de ses utilisateurs, si bien qu’il est impossible de le comprendre sans appréhender les dynamiques sous-jacentes qui ont été à l’œuvre dans le passé.

 

---

Sources

Gavin Andresen, BIP-11 (M-of-N Standard Transactions), 18 octobre 2011.
Gavin Andresen, BIP-12 (OP_EVAL), 18 octobre 2011.
Gavin Andresen, BIP-16 (Pay to Script Hash), 3 janvier 2012.
Mike Hearn, On consensus and forks, 12 août 2015.
Eric Lombrozo, Johnson Lau et Pieter Wuille, BIP-141 (Segregated Witness), 21 décembre 2015.