Qui gère le bitcoin ?

Par Gérard Dréan.

 

Une question revient souvent dans les débats sur le bitcoin : « quelle est l’autorité centrale qui le gère ? » La réponse, connue même si elle n’est pas toujours bien comprise, est : « il n’y en a pas, c’est un réseau pair à pair décentralisé et les règles de gestion sont inscrites dans le code ».

Pour beaucoup, cette réponse ne fait que déplacer le problème : « quelle est alors l’autorité centrale qui gère le code ? » demandent-ils. La réponse à cette deuxième question est beaucoup moins connue : « Il n’y en a pas non plus, les règles d’évolution du code sont elles aussi inscrites dans le code ».

L’explication nécessite un assez long détour par la technique, notamment par le protocole de construction de la « blockchain », qui est très mal connu bien qu’il forme le véritable cÅ“ur du système. Pour beaucoup, cette opération se résume à la constitution des « blocs » de transactions, alors que la phase suivante d’assemblage des blocs, qui est encore plus vitale pour la sécurité du système, est largement ignorée. Comme si on réduisait la construction de la Tour Eiffel à la fabrication de ses éléments dans les ateliers de Levallois, en ignorant son montage sur le Champ de Mars. C’est donc à cette deuxième phase que le présent article est consacré.

L’architecture générale du système

Au fond, le système informatique Bitcoin ne fait qu’une seule chose : enregistrer des transactions dans une sorte de grand Livre-Journal, sous une forme définitive et accessible à tous, après en avoir vérifié la validité. Il comporte aussi des fonctions secondaires permettant par exemple de créer des transactions ou d’y avoir accès, mais qui ne peuvent en aucune façon modifier celles qui ont été inscrites dans ce Grand Livre.

Ce Livre-journal est formé d’une suite de blocs enchaînés les uns aux autres, regroupant chacun les transactions effectuées dans une certaine période, d’où son nom de « blockchain ».

Le système Bitcoin repose sur un réseau de plusieurs milliers d’ordinateurs. Conformément aux principes d’un réseau pair à pair, chacun de ces ordinateurs peut tenir à jour sa propre version de la blockchain. De fait, il existe actuellement de l’ordre de 6000 exemplaires de la blockchain (actuellement) tenus à jour indépendamment sur autant d’ordinateurs appelés « noeuds complets » du réseau.

Le protocole informatique utilisé par chaque nœud complet vise à ce que tous ces exemplaires soient identiques, bien que construits indépendamment. La technique de consensus utilisée à cet effet constitue une fonction essentielle du système, qui sera développée dans cet article.

Ce grand nombre d’exemplaires de la blockchain permet le secours réciproque en cas d’incident, la protection contre les fraudes, la correction des erreurs ou des désaccords temporaires, ainsi que des opérations de service comme la resynchronisation d’un ordinateur après déconnexion du réseau. Les nÅ“uds complets forment la colonne vertébrale du système.

Entre le moment où elle est créée et son inscription définitive dans la blockchain de chaque nÅ“ud, chaque transaction fait l’objet de nombreuses vérifications. Dans un souci de généralité et de souplesse, à chaque type de transaction est associé un processus de vérification qui dépend de la nature de la transaction et est référencé par un indicateur présent dans chaque transaction. Une même blockchain peut ainsi contenir des transactions de natures différentes, et la même technologie d’enregistrement peut être utilisée~pour autre chose que des transactions monétaires. Dans ce qui suit, nous présenterons le protocole de construction de la blockchain indépendamment du type de transaction, en supposant qu’à chaque type de transaction est associé un certain processus de validation.

Entre le moment où elle est créée et son inscription définitive dans la blockchain, chaque transaction est diffusée de proche en proche à travers le réseau. Chaque nœud vérifie la validité de chaque transaction qu’il reçoit, la stocke dans un pool local de transactions « brutes », puis la retransmet à ses voisins.

L’inscription des transactions dans la blockchain se fait en deux opérations bien distinctes, réalisées par deux populations différentes de nÅ“uds.

La première opération consiste à puiser dans le pool de transactions pour les regrouper en « blocs » de quelques centaines à quelques milliers, structurés de façon à faciliter l’accès aux transactions qu’ils contiennent, et protégés contre toute modification.

La méthode choisie pour rendre cette protection particulièrement efficace est fortement consommatrice de temps machine. Cette opération est donc l’affaire de matériels spécialisés, et elle est rémunérée par création de bitcoins, d’où sa désignation par le terme de « mining » et de « mineurs » pour ceux qui l’entreprennent, par analogie avec l’extraction de l’or. Les blocs ainsi constitués, qui ne pourront plus être modifiés de quelque façon que ce soit, sont à leur tour diffusés de proche en proche à tous les ordinateurs du réseau.

Dans une deuxième opération, chaque nœud met à jour son propre exemplaire local de la blockchain, en y ajoutant les blocs au fur et à mesure qu’ils sont fournis par les mineurs.

Alors que la première opération est bien connue, probablement parce que c’est elle qui donne lieu à la création monétaire dans ce système, la deuxième l’est beaucoup moins. C’est pourtant la plus fondamentale car la seule qui modifie la blockchain, mais c’est aussi la plus complexe, et pour cette même raison.

Dans la conception initiale, tous les nÅ“uds étaient dotés de toutes les fonctions, et étaient censés tenir leur propre blockchain. Assez rapidement, le mining est devenu l’affaire de matériels spécialisés de très haute performance, et les fonctions logicielles correspondantes ont été retirées du logiciel standard pour devenir des extensions optionnelles. De même, la tenue à jour d’une blockchain locale est fortement consommatrice d’espace de stockage, ce qui a entraîné l’apparition de nÅ“uds simplifiés qui ne tiennent plus à jour leur propre blockchain, mais utilisent un protocole appelé SPV (simple payment verification) pour demander aux nÅ“uds voisins les transactions dont ils ont besoin. Ceci a entraîné une réduction significative du nombre de nÅ“uds complets.

Il est très difficile de connaître le nombre de mineurs, qui peuvent accéder au système à travers un nœud simplifié ou en se regroupant en pools partageant un même nœud complet. Les estimations vont de quelques centaines à plusieurs milliers, mais la presque totalité des blocs effectivement incorporés à la blockchain proviennent d’environ deux cents pools ou mineurs indépendants.

Le protocole exécuté à la réception d’un bloc.

La blockchain est un ensemble de blocs, protégés contre toute modification, dont chacun contient l’identificateur de son prédécesseur. Comme nous le verrons, elle peut avoir la forme d’un arbre doté de plusieurs branches. La plus longue de ces branches, appelée branche principale, est identifiée par l’identificateur de son bloc terminal. À partir de cet identificateur, il est possible de remonter cette branche principale jusqu’au bloc d’origine « Genesis », créé par « Satoshi Nakamoto » le 3 janvier 2009, et de retrouver ainsi toutes les transactions enregistrées depuis.

Chaque nÅ“ud du réseau reçoit en permanence toutes sortes de messages, dont certains proposent de nouveaux blocs à ajouter à la blockchain. Un principe de sécurité fondamental est de faire l’hypothèse que les autres nÅ“uds du système peuvent être défectueux ou frauduleux. Chaque nÅ“ud doit donc considérer tout ce qu’il reçoit des autres nÅ“uds comme suspect par principe, en déterminer lui-même la nature et le valider de façon indépendante avant de l’utiliser.

Si un message contient un bloc, celui-ci est soumis à un protocole qui l’ajoutera ou non à la blockchain locale, et dont la complexité tient à ce qu’il doit traiter tous les cas particuliers, même ceux qui semblent a priori les plus improbables.

Outre des transactions, chaque bloc contient une somme de contrôle (« hash ») qui le protège contre les modifications, et lui sert également d’identificateur. Il contient également l’identificateur du bloc qui le précède dans la blockchain du mineur qui l’a créé, ainsi qu’une mesure de la quantité de travail qui a été utilisée pour le produire. La première étape consiste donc à éliminer le nouveau bloc s’il est mal formé (syntaxe incorrecte) ou s’il a déjà été reçu, et donc a déjà été traité.

Un objectif fondamental du protocole de construction de la blockchain est que tous ses exemplaires soient identiques, bien que construits indépendamment. Il vise donc à obtenir un consensus sur une même version du journal des transactions pour tous les ordinateurs du réseau. Le principe retenu est de choisir, parmi les versions possibles de la blockchain, celle dont la construction a demandé la plus grande somme de travail, ce qui vise notamment à dissuader les fraudeurs éventuels en exigeant d’eux un travail supérieur à celui des nÅ“uds « honnêtes ».

Si le nouvel arrivant est conservé, la suite dépend du bloc qu’il indique comme son prédécesseur. Si celui-ci n’est pas indiqué, le nouveau bloc est conservé parmi les blocs « orphelins ». S’il est indiqué mais n’existe pas dans la blockchain locale, le nouveau bloc est également rangé parmi les blocs « orphelins », mais de plus son prédécesseur est réclamé aux nÅ“uds voisins. Cette étape permet par exemple la reconstitution de la blockchain d’un nÅ“ud qui a été arrêté pendant un certain temps. Dans les deux cas, le programme se remet en attente d’un nouveau bloc. En effet, tous les blocs reçus sont traités de la même façon quelle que soit leur origine.

Si le prédécesseur indiqué est l’extrémité actuelle de la branche principale, le programme tente d’y ajouter le nouveau bloc. Pour cela, il vérifie que chaque transaction du bloc est valide syntaxiquement, n’est pas déjà présente dans la blockchain et satisfait la condition de validité indiquée par son code « version » . Dès qu’une transaction est invalide, le processus est abandonné. Sinon, l’identificateur du nouveau bloc remplace l’identificateur de l’extrémité de la blockchain, toutes les transactions de ce bloc sont éliminées du pool des transactions en attente et ce bloc est envoyé aux nÅ“uds voisins, qui exécuteront le même processus.

Si le prédécesseur indiqué est un autre bloc que le bloc terminal de la blockchain courante, deux cas peuvent se présenter selon que la séquence de blocs qui aboutit au nouveau bloc a demandé plus ou moins de travail que la branche principale actuelle. Si elle a demandé moins de travail, la blockchain courante n’est pas modifiée, et le nouveau bloc est simplement conservé en mémoire, formant l’amorce d’une branche secondaire. Si cette nouvelle branche a demandé plus de travail, c’est elle qui doit devenir la blockchain de référence. Pour cela, le programme remonte à la bifurcation, et à partir de là, essaie d’ajouter successivement chacun des blocs de la nouvelle branche qui ont été mis en attente sans être validés, en vérifiant comme ci-dessus la validité et la légitimité des transactions qu’il contient.

S’il y parvient sans rencontrer de bloc ou de transaction illégitime, il met à jour le pool des transactions en attente (en en retirant les transactions qui sont maintenant dans la nouvelle branche principale et en y remettant celles qui étaient dans l’ancienne branche principale et ne sont pas dans la nouvelle), il remplace l’identificateur de l’extrémité de la blockchain et diffuse le bloc aux nÅ“uds voisins. Sinon, il laisse la blockchain en l’état, tout en conservant le nouveau bloc en attente comme précédemment.

Enfin, si le nouveau bloc est indiqué par un ou plusieurs blocs orphelins comme leur prédécesseur, le protocole tente de rattacher à travers lui les blocs orphelins à la blockchain en lui appliquant de façon récursive le protocole ci-dessus.

Le protocole en fonctionnement normal

En fonctionnement normal, la blockchain est identique sur tous les nÅ“uds, et le nouveau bloc désigne comme prédécesseur le bloc terminal de la blockchain existante. Chaque nÅ“ud va donc ajouter à l’extrémité de sa branche principale le premier bloc valide qu’il reçoit. Or les mineurs travaillent en parallèle et il n’existe pas de règle générale concernant la sélection des transactions à incorporer dans un bloc. À partir d’un même pool de transactions brutes, les mineurs peuvent donc proposer des blocs différents, que chaque nÅ“ud va continuer à recevoir après celui qu’il a ajouté à son exemplaire de la blockchain, qui désigneront le même prédécesseur et contiendront en partie les mêmes transactions. Il les conservera donc sans les vérifier, en en faisant l’amorce de branches latérales secondaires.

Si tous les nœuds du réseau reçoivent les blocs des mineurs dans le même ordre, la blockchain reste la même sur tous les noeuds, bien que chacun en ait construit sa propre version indépendamment. Mais il peut arriver que deux ou plusieurs mineurs émettent des blocs différents en un temps inférieur au temps de propagation des blocs dans le réseau. Ces blocs arrivent alors dans un ordre différent selon les nœuds récepteurs, qui retiendront chacun dans sa branche principale le premier arrivé, les blocs suivants étant greffés tel quel sur le côté. Les nœuds se séparent alors en deux populations (voire plus) et il y a bifurcation (« fork ») de la blockchain. En particulier, les mineurs de chaque population travaillent maintenant à partir de blockchains différentes.

Cette situation est généralement résolue par les blocs suivants. En effet, la situation qui a donné naissance à cette bifurcation est très improbable, et il est de moins en moins probable qu’elle se renouvelle à l’étape suivante. Il arrivera un moment où le premier bloc reçu sera le même pour tous, et l’application du protocole décrit ci-dessus fera que lui et ses prédécesseurs deviendront alors la branche principale pour tous. À ce moment, des transactions qui figuraient dans l’ancienne branche principale, et qui ont donc été considérées comme définitives, peuvent ne plus figurer dans la nouvelle. C’est pourquoi il est recommandé de ne considérer une transaction comme définitive que si le bloc dans lequel elle figure est à une certaine distance du bloc courant (6 blocs pour les transactions normales importantes, 100 pour les transactions de « minage » créatrices de nouveaux bitcoins).

Les cas de fraude

Normalement tous les acteurs de ce processus ont le même objectif : assurer le bon fonctionnement du système. Mais n’importe qui peut librement émettre des transactions, devenir mineur ou nÅ“ud du système, y compris avec l’intention de nuire ou avec des versions non standard des logiciels. Aucun participant ne peut donc écarter l’hypothèse que ce qu’il reçoit est erroné voire carrément frauduleux ou dangereux, et chacun doit en vérifier la validité à toutes les étapes. Les transactions ou les blocs erronés ou frauduleux n’ont pratiquement aucune chance d’échapper à ces contrôles et de parvenir jusqu’à la blockchain, et le fraudeur se retrouve très vite isolé.

Un nÅ“ud peut créer des transactions frauduleuses. Mais la seule façon possible de les introduire dans les multiples exemplaires de la blockchain est de les incorporer dans un bloc et de soumettre ce nouveau bloc aux autres nÅ“uds du réseau par la voie normale. En l’absence de modifications tout aussi frauduleuses dans les protocoles de construction des blocs et dans les processus de validation des transactions, ces transactions ne seront pas validées et incorporées dans des blocs légitimes, ni acceptées par les autres nÅ“uds. Les blockchains des nÅ“uds « honnêtes » ne seront donc pas affectées et la fraude sera sans conséquences autres que locales au nÅ“ud fraudeur.

Pour modifier un bloc existant dans le registre, la seule façon est de créer un nouveau bloc contenant éventuellement une partie des transactions de l’ancien, et de tenter de le greffer à sa place.  Ce nouveau bloc sera bien greffé (sans vérification) à côté du bloc qu’il cherche à remplacer, mais la branche principale restera inchangée.

Pour qu’il devienne partie de la branche principale, il faudrait lui greffer de nouveaux blocs plus vite qu’à la vraie branche principale pour que cette nouvelle branche finisse par la dépasser. Or, pendant ce temps, le reste du réseau continue à allonger la branche principale. Chacun des nouveaux blocs devant être recalculé ex nihilo y compris sa somme de contrôle, il faudrait que le(s) fraudeur(s) mobilise(nt) une puissance totale de validation supérieure à celle de tout le reste du réseau. De plus, chacun de ces blocs, ainsi que la validité et la légitimité des transactions qu’il contient, seraient vérifiés par rapport à la partie de la blockchain située en amont de la bifurcation. On voit mal quelles modifications frauduleuses pourraient échapper à ces contrôles, sachant de plus que toutes les transactions doivent obligatoirement être signées cryptographiquement par l’utilisateur débité.

Au final, même si un fraudeur parvenait à introduire des modifications de ce type dans certains nÅ“uds, il créerait ainsi un petit groupe d’utilisateurs isolés du reste du réseau et qui ne pourraient échanger qu’entre eux, ce dont on voit mal l’intérêt. Le reste du réseau ne serait pas affecté. De plus, la manÅ“uvre serait forcément visible, d’autant plus que le bloc remplacé est plus ancien, puisqu’elle consisterait en la création anormalement rapide de blocs venant se greffer en amont de l’extrémité courante. Le fraudeur aurait toutes chances d’être éliminé, et les blockchains atteintes seraient réparées à partir de celles qui sont restées intactes

Le cas du changement de logiciel

Il peut arriver que deux ou plusieurs sous-populations de nœuds adoptent plus ou moins durablement des branches principales différentes. Les blocs construits par un mineur appartenant à une des populations ne seront pas acceptés par les nœuds des autres populations, ce qui entraîne que les transactions émises par un nœud d’une population ne seront acceptées que par les nœuds de la même population. Tout se passe alors comme si ces sous-populations utilisaient des monnaies distinctes qui ne permettent de transactions qu’à l’intérieur de chacune.

Cette situation se présente par exemple aux changements de version du logiciel. Puisque chaque utilisateur décide par lui-même des mises à jour de son équipement, la nouvelle version ne sera pas installée simultanément sur tous les nœuds. Plusieurs cas peuvent alors se produire :

Si la nouvelle version ne comprend pas de changements dans les protocoles de construction et de validation des transactions et des blocs, les transactions et les blocs construits par toutes les populations seront acceptés par les nÅ“uds de toutes les populations. L’introduction de ce nouveau logiciel ne provoque pas de bifurcation. Ceci définit toute une classe de modifications que chaque utilisateur peut décider d’installer ou non sans compromettre le fonctionnement d’ensemble du système.

Si la nouvelle version comporte des changements relatifs aux transactions et aux blocs, mais qui ne rendent pas invalides les transactions et les blocs existants (compatibilité ascendante), les transactions et les blocs produits par l’ancien système seront acceptés par le nouveau, mais certaines transactions, et donc probablement tous les blocs produits par le nouveau système ne seront pas acceptés par les nÅ“uds qui ont conservé l’ancien. Il y aura donc séparation entre les nÅ“uds utilisant la nouvelle version et ceux qui continuent à utiliser l’ancienne, et bifurcation de la blockchain. Toutefois, au fur et à mesure que les utilisateurs installent la nouvelle version, le protocole décrit ci-dessus les fera changer de blockchain et basculer automatiquement d’une population à l’autre.

Les mineurs installeront probablement très tôt la nouvelle version, donc très rapidement seuls des blocs cohérents avec cette version seront produits, et seuls les nÅ“uds utilisant la nouvelle version auront une blockchain à jour. Les autres prendront un retard qu’ils auront intérêt à rattraper au plus vite.

Enfin, si la nouvelle version comporte des changements qui rendent invalides les transactions existantes, il y aura aussi séparation en deux populations, mais les transactions et les blocs produits par l’une des populations ne seront acceptés que par cette population, et aucun rattrapage automatique ne sera possible. La bifurcation sera définitive (« hard fork »). Les utilisateurs de chaque population ne pourront réaliser de transactions qu’avec ceux de cette même population, ce qui revient à définir deux monnaies distinctes qui seront dorénavant en concurrence, et pourront être l’objet d’opérations de change semblables à celles entre le bitcoin et les monnaies conventionnelles.

Cette situation peut être créée de façon délibérée pour utiliser le même logiciel et la même blockchain (ou Alt-chain) pour supporter des monnaies ou des types de transactions différents. Elle se produit aussi si un utilisateur installe sur un nœud une version frauduleuse du logiciel, ce qui isole automatiquement ce nœud du reste du réseau.

Décisions et pouvoir

Sur ces bases, nous pouvons revenir aux questions relatives aux mécanismes de décision et aux relations de pouvoir dans l’univers Bitcoin.

Ce sont les mineurs, plus précisément les logiciels de « mining », qui décident d’accepter ou non les transactions dans les blocs, et les logiciels en fonction sur les nÅ“uds complets qui décident d’accepter ou non les blocs dans la blockchain. Les critères sont inscrits dans le code. Rappelons que ce sont deux populations différentes, de plusieurs centaines pour les mineurs et de plusieurs milliers pour les nÅ“uds complets.

Or tout le monde peut définir et modifier le code, et chaque utilisateur décide par lui-même quel code il utilise sur ses propres matériels. En effet, tous les logiciels du système Bitcoin sont des logiciels libres, c’est-à-dire gratuits et librement utilisables, et surtout dont le code source est lui-même public et où chacun a droit de l’examiner, de le modifier et de distribuer ces versions modifiées.

Il existe donc autour de Bitcoin toute une population de développeurs volontaires et de testeurs volontaires qui identifient les problèmes et les opportunités d’extensions, imaginent des solutions et produisent des modifications et des extensions aux systèmes existants, voire des systèmes alternatifs entièrement nouveaux.

Cette activité est structurée par toute une discipline de développement et d’intégration de nouvelles fonctions et de nouvelles versions, portée par quelques sites spécialisés qui fournissent  les outils nécessaires à la coordination et à l’intégration d’une multitude d’initiatives décentralisées et autonomes, y compris les échanges d’idées, les discussions préalables, la gestion des développements en cours sous leurs différentes versions, les tests et l’intégration des modifications, la publication des travaux en cours, et enfin la construction, la distribution et la maintenance des systèmes opérationnels. Les erreurs ou les failles sont signalées en temps réel à toute la communauté, et sont rapidement corrigés. De même, les suggestions d’extensions et modifications sont soumises à la communauté, et développées par des volontaires.

Les propriétaires de mineurs et de nÅ“uds trouvent donc à tout instant des versions alternatives des logiciels qui réalisent chaque fonction du système, et leur nombre ira croissant. On y trouve des logiciels de production dûment testés, des versions expérimentales et des logiciels complémentaires plus ou moins fiables, mais aussi des versions frauduleuses ou malignes. Chacun décide pour lui-même en totale autonomie d’utiliser tel ou tel code, y compris des saboteurs et des fraudeurs. La concertation préalable et la consultation démocratique sont certes possibles, ainsi d’ailleurs que le complot et la collusion. La discussion publique peut éclairer les choix, limiter les alternatives et permettre de qualifier les différentes approches proposées. Mais quels que soient les accords et la façon dont ils ont été atteints, il n’existe aucun moyen de les imposer et il faut toujours faire l’hypothèse qu’ils peuvent ne pas être respectés.

Ce qui décide du sort de ces alternatives, c’est l’intégration des comportements réels des nÅ“uds du système, qui à travers les phénomènes de bifurcation décrits ci-dessus, aboutiront soit à l’adoption progressive d’une variante unique, soit au contraire à l’isolation totale et à l’élimination d’une alternative, qu’elle soit honnête ou frauduleuse, soit encore à une coexistence durable de solutions différentes. C’est ainsi que seront résolues deux controverses actuelles sur la discipline de création monétaire d’une part, sur la taille des blocs d’autre part. Les concertations préalables et les votes peuvent établir un certain équilibre des forces, mais in fine les choix de logiciels seront le fruit d’un ordre spontané résultant des choix en action des participants au système. Un autre aspect du système, avec l’idée de concurrence entre monnaies, qui le rattache véritablement à la tradition hayekienne.

Références

• Le document théorique fondateur : http://bitcoin.org/bitcoin.pdf
• L’article de wikipedia : http://fr.wikipedia.org/wiki/Bitcoin
• Un site français sur bitcoin: http://www.bitcoin.fr/
• Le protocole de traitement des messages et des blocs reçus par les nÅ“uds du réseau : https://en.bitcoin.it/wiki/Protocol_rules