Les Bitcoins sont "frappés" lors de la création de chaque bloc à un taux fixe et décroissant. Chaque bloc, généré en moyenne toutes les 10 minutes, contient des bitcoins entièrement nouveaux, créés à partir de rien. Tous les 210 000 blocs, soit environ tous les quatre ans, le taux d’émission des devises est diminué de 50 %. Pendant les quatre premières années de fonctionnement du réseau, chaque bloc contenait 50 nouveaux bitcoins.

En novembre 2012, le nouveau taux d’émission de bitcoins a été réduit à 25 bitcoins par bloc. En juillet 2016, il a été réduit à 12,5 bitcoins par bloc, et en mai 2020, il a de nouveau été réduit à 6,25 bitcoins par bloc. Le taux de nouvelles pièces diminue ainsi de manière exponentielle sur 32 "halvings" (ou "réductions de moitié") jusqu’au bloc 6 720 000 (miné environ en 2137), lorsqu’il atteint l’unité monétaire minimale de 1 satoshi. Enfin, après 6,93 millions de blocs, en 2140 environ, près de 2 099 999 997 690 000 satoshis, soit près de 21 millions de bitcoins, seront émis. Par la suite, les blocs ne contiendront plus de nouveaux bitcoins et les mineurs seront récompensés uniquement par les frais de transaction. Offre de monnaie bitcoin au fil du temps basée sur un taux d’émission géométriquement décroissant montre le bitcoin total en circulation au fil du temps, à mesure que l’émission de devises diminue.

Dans l’exemple de code dans Un script pour calculer la quantité totale de bitcoins qui sera émise, nous calculons le montant total de bitcoin qui sera émis.

Exécuter le script max_money.py affiche la sortie produite en exécutant ce script.

L’émission finie et décroissante crée une masse monétaire fixe qui résiste à l’inflation. Contrairement à une monnaie fiduciaire, qui peut être imprimée en nombre infini par une banque centrale, le bitcoin ne peut jamais être gonflé par l’impression.

La première transaction d’un bloc est une transaction spéciale, appelée transaction coinbase. Cette transaction est construite par le nœud de Jing et contient sa récompense pour l’effort de minage.

Le nœud de Jing crée la transaction coinbase en tant que paiement sur son propre portefeuille : "Pay Jing’s address 25.09094928 bitcoin." Le montant total de la récompense que Jing collecte pour l’extraction d’un bloc est la somme de la récompense coinbase (25 nouveaux bitcoins) et des frais de transaction (0,09094928) de toutes les transactions incluses dans le bloc, comme indiqué dans Transaction coinbase.

Contrairement aux transactions régulières, la transaction coinbase ne consomme pas (ne dépense pas) d’UTXO comme entrées. Au lieu de cela, il n’a qu’une seule entrée, appelée coinbase, qui crée du bitcoin à partir de rien. La transaction coinbase a une sortie, payable à la propre adresse Bitcoin du mineur. La sortie de la transaction coinbase envoie la valeur de 25,09094928 bitcoin à l’adresse Bitcoin du mineur ; dans ce cas c’est 1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N.

Pour construire la transaction coinbase, le nœud de Jing calcule d’abord le montant total des frais de transaction en ajoutant toutes les entrées et sorties des 418 transactions qui ont été ajoutées au bloc. Les frais sont calculés comme suit :

Dans le bloc 277 316, le total des frais de transaction est de 0,09094928 bitcoin.

Ensuite, le nœud de Jing calcule la récompense correcte pour le nouveau bloc. La récompense est calculée en fonction de la hauteur du bloc, à partir de 50 bitcoins par bloc et réduite de moitié tous les 210 000 blocs. Parce que ce bloc est à la hauteur 277 316, la récompense correcte est de 25 bitcoins.

Le calcul peut être vu dans la fonction GetBlockSubsidy dans le client Bitcoin Core, comme indiqué dans Calcul de la récompense de bloc—Fonction GetBlockSubsidy, Client Bitcoin Core, main.cpp.

La subvention initiale est calculée en satoshis en multipliant 50 par la constante COIN (100 000 000 satoshis). Cela fixe la récompense initiale (nSubsidy) à 5 milliards de satoshis.

Ensuite, la fonction calcule le nombre de halvings qui se sont produits en divisant la hauteur actuelle du bloc par l’intervalle de halving (ou réduction de moitié) (SubsidyHalvingInterval). Dans le cas du bloc 277 316, avec un intervalle de moitié tous les 210 000 blocs, le résultat est 1 moitié.

Le nombre maximum de moitiés autorisé est de 64, donc le code impose une récompense nulle (ne renvoie que les frais) si les 64 moitiés sont dépassées.

Ensuite, la fonction utilise l’opérateur binaire de décalage vers la droite pour diviser la récompense (nSubsidy) par deux pour chaque cycle de réduction de moitié. Dans le cas du bloc 277 316, cela entraînerait un décalage binaire vers la droite de la récompense de 5 milliards de satoshis une fois (une réduction de moitié) et donnerait 2,5 milliards de satoshis, soit 25 bitcoins. L’opérateur de décalage binaire vers la droite est utilisé car il est plus efficace que plusieurs divisions répétées. Pour éviter un bogue potentiel, l’opération de décalage est ignorée après 63 moitiés et la subvention est définie sur 0.

Enfin, la récompense coinbase (nSubsidy) est ajoutée aux frais de transaction (nFees), et la somme est restituée.

Avec ces calculs, le nœud de Jing construit ensuite la transaction coinbase pour se payer 25,09094928 bitcoins.

Comme vous pouvez le voir dans Transaction coinbase, la transaction coinbase a un format spécial. Au lieu d’une entrée de transaction spécifiant un UTXO précédent à dépenser, il a une entrée "coinbase". Nous avons examiné les entrées de transaction dans [tx_in_structure]. Comparons une entrée de transaction régulière avec une entrée de transaction coinbase. La structure d’une entrée de transaction "normale" montre la structure d’une entrée de transaction normale, tandis que La structure d’une entrée de transaction coinbase montre la structure de l’entrée de la transaction coinbase.

Dans une transaction coinbase, les deux premiers champs sont définis sur des valeurs qui ne représentent pas une référence UTXO. Au lieu d’un "hachage de transaction", le premier champ est rempli de 32 octets tous mis à zéro. "L’index de sortie" est rempli de 4 octets tous mis à 0xFF (255 décimal). Le "script de déverrouillage" (scriptSig) est remplacé par les données coinbase, un champ de données utilisé par les mineurs, comme nous le verrons ensuite.

Les transactions coinbase n’ont pas de champ de script de déverrouillage (aka, scriptSig). Au lieu de cela, ce champ est remplacé par des données coinbase, qui doivent être comprises entre 2 et 100 octets. À l’exception des premiers octets, le reste des données de coinbase peut être utilisé par les mineurs comme ils le souhaitent ; ce sont des données arbitraires.

Dans le bloc de genèse, par exemple, Satoshi Nakamoto a ajouté le texte "The Times 03/Jan/2009 Chancellor on bound of second bailout for banks" dans les données coinbase, l’utilisant comme preuve de la date et pour transmettre un message. Actuellement, les mineurs utilisent les données coinbase pour inclure des valeurs nonce supplémentaires et des chaînes identifiant le bassin de minage.

Les premiers octets de la coinbase étaient auparavant arbitraires, mais ce n’est plus le cas. Conformément à BIP-34, les blocs de version 2 (blocs avec le champ de version défini sur 2) doivent contenir l’index de hauteur de bloc en tant qu’opération "push" (pousser) de script au début du champ coinbase.

Dans le bloc 277 316, nous voyons que le coinbase (voir Transaction coinbase), qui se trouve dans le script de déverrouillage ou le champ scriptSig de l’entrée de transaction, contient la valeur hexadécimale 03443b0403858402062f503253482f. Décodons cette valeur.

Le premier octet, 03, indique au moteur d’exécution de script de pousser les trois octets suivants sur la pile de script (voir [tx_script_ops_table_pushdata]). Les trois octets suivants, 0x443b04, sont la hauteur de bloc encodée au format little-endian (petit-boutiste, octet le moins significatif en premier). Inversez l’ordre des octets et le résultat est 0x043b44, soit 277 316 en décimal.

Les quelques chiffres hexadécimaux suivants (0385840206) sont utilisés pour coder un nonce supplémentaire (voir La solution nonce (nombre aléatoire) supplémentaire), ou valeur aléatoire, utilisée pour trouver une solution de preuve de travail appropriée.

La partie finale de la donnée coinbase (2f503253482f) est une chaîne de caractères ASCII encodées /P2SH/, ce qui indique que le nœud de minage qui a miné ce bloc prend en charge l’amélioration P2SH définie dans BIP-16. L’introduction de la capacité P2SH a nécessité une signalisation par les mineurs pour approuver le BIP-16 ou le BIP-17. Ceux qui approuvaient la mise en œuvre du BIP-16 devaient inclure la chaîne /P2SH/ dans leurs données coinbase. Ceux qui approuvaient l’implémentation BIP-17 de P2SH devaient inclure la chaîne p2sh/CHV dans leurs données coinbase. Enfin, le BIP-16 a été élu vainqueur, et de nombreux mineurs ont continué à inclure la chaîne /P2SH/ dans leur coinbase pour indiquer qu’ils prennent en charge cette fonctionnalité.

Extraire les données coinbase du bloc genesis utilise la bibliothèque libbitcoin introduite dans [alt_libraries] pour extraire les données coinbase du bloc de genèse, affichant le message de Satoshi. Notez que la bibliothèque libbitcoin contient une copie statique du bloc de genèse, de sorte que l’exemple de code peut récupérer le bloc de genèse directement à partir de la bibliothèque.

Nous compilons le code avec le compilateur GNU C++ et exécutons l’exécutable résultant, comme indiqué dans Compilation et exécution de l’exemple de code satoshi-words.

Un algorithme de hachage prend une entrée de données de longueur arbitraire et produit un résultat déterministe de longueur fixe, c-à-d une empreinte numérique de l’entrée. Pour toute entrée spécifique, le hachage résultant sera toujours le même et peut être facilement calculé et vérifié par toute personne mettant en œuvre le même algorithme de hachage. La principale caractéristique d’un algorithme de hachage cryptographique est qu’il est impossible de trouver deux entrées différentes qui produisent la même empreinte digitale (appelée collision). En corollaire, il est également pratiquement impossible de sélectionner une entrée de manière à produire une empreinte digitale souhaitée, autrement qu’en essayant des entrées aléatoires.

Avec SHA256, la sortie a toujours une longueur de 256 bits, quelle que soit la taille de l’entrée. Dans Exemple SHA256, nous utiliserons l’interpréteur Python pour calculer le hachage SHA256 de la phrase "Je suis Satoshi Nakamoto".

Exemple SHA256 montre le résultat du calcul du hachage de "Je suis Satoshi Nakamoto" : 5d7c7ba21cbbcd75d14800b100252d5b428e5b1213d27c385bc141ca6b47989e. Ce nombre de 256 bits est le résultat de hachage ou prétraitement de la phrase et dépend de chaque partie de la phrase. L’ajout d’une seule lettre, d’un signe de ponctuation ou de tout autre caractère produira un hachage différent.

Maintenant, si nous changeons la phrase, nous devrions nous attendre à voir des hachages complètement différents. Essayons cela en ajoutant un nombre à la fin de notre phrase, en utilisant le script Python simple dans Script SHA256 pour générer de nombreux hachages en itérant sur un nonce.

L’exécution de ceci produira les hachages de plusieurs phrases, rendues différentes en ajoutant un nombre à la fin du texte. En incrémentant le nombre, nous pouvons obtenir différents hachages, comme indiqué dans Sortie SHA256 d’un script pour générer de nombreux hachages en itérant sur un nombre aléatoire.

Chaque phrase produit un résultat de hachage complètement différent. Ils semblent complètement aléatoires, mais vous pouvez reproduire les résultats exacts de cet exemple sur n’importe quel ordinateur avec Python et voir les mêmes hachages exacts.

Le nombre utilisé comme variable dans un tel scénario est appelé un nonce (ou nombre aléatoire). Le nonce est utilisé pour faire varier la sortie d’une fonction cryptographique, dans ce cas pour faire varier l’empreinte SHA256 de la phrase.

Pour relever le défi de cet algorithme, fixons-nous un objectif : trouver une phrase qui produit un hachage hexadécimal commençant par un zéro. Heureusement, ce n’est pas difficile ! Sortie SHA256 d’un script pour générer de nombreux hachages en itérant sur un nombre aléatoire montre que la phrase "I am Satoshi Nakamoto13" produit le hash 0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5, ce qui correspond à nos critères. Il a fallu 13 tentatives pour le trouver. En termes de probabilités, si la sortie de la fonction de hachage est uniformément distribuée, nous nous attendrions à trouver un résultat avec un 0 comme préfixe hexadécimal une fois tous les 16 hachages (un sur 16 chiffres hexadécimaux de 0 à F). En termes numériques, cela signifie trouver une valeur de hachage inférieure à 0x100000000000000000000000000000000000000000000000000000000000. Nous appelons ce seuil la cible et le but est de trouver un hachage qui est numériquement égal ou inférieur à la cible. Si nous diminuons la cible, la tâche de trouver un hachage inférieur à la cible devient de plus en plus difficile.

Pour donner une analogie simple, imaginez un jeu où les joueurs lancent une paire de dés à plusieurs reprises, en essayant de lancer autant ou moins qu’une cible spécifiée. Au premier tour, l’objectif est de 11. À moins que vous ne lanciez un double-six, vous gagnez. Au tour suivant, l’objectif est de 10. Les joueurs doivent lancer 10 ou moins pour gagner, encore une fois une tâche facile. Disons que quelques tours plus tard, l’objectif est tombé à 5. Maintenant, plus de la moitié des lancers de dés dépasseront l’objectif et seront donc invalides. Il faut exponentiellement plus de lancers de dés pour gagner, plus la cible est basse. Finalement, lorsque l’objectif est de 2 (le minimum possible), un seul lancer sur 36, soit 2 % d’entre eux, produira un résultat gagnant.

Du point de vue d’un observateur qui sait que la cible du jeu de dés est 2, si quelqu’un a réussi à lancer un lancer gagnant, on peut supposer qu’il a tenté, en moyenne, 36 lancers. En d’autres termes, on peut estimer la quantité de travail nécessaire pour réussir à partir de la difficulté imposée par la cible. Lorsque l’algorithme est basé sur une fonction déterministe telle que SHA256, l’entrée elle-même constitue la preuve qu’une certaine quantité de travail a été effectuée pour produire un résultat égal ou inférieur à la cible. Par conséquent, la Preuve de travail.

Dans Sortie SHA256 d’un script pour générer de nombreux hachages en itérant sur un nombre aléatoire, le "nonce" gagnant est 13 et ce résultat peut être confirmé par n’importe qui indépendamment. N’importe qui peut ajouter le nombre 13 comme suffixe à la phrase "Je suis Satoshi Nakamoto" et calculer le hachage, en vérifiant qu’il est inférieur à la cible. Le résultat réussi est également une preuve de travail, car cela prouve que nous avons fait le travail pour trouver ce nonce. Alors qu’il ne faut qu’un seul calcul de hachage pour vérifier, il nous a fallu 13 calculs de hachage pour trouver un nonce qui a fonctionné. Si nous avions une cible inférieure (difficulté plus élevée), il faudrait beaucoup plus de calculs de hachage pour trouver un nonce approprié, mais un seul calcul de hachage pour que quiconque puisse le vérifier. De plus, en connaissant la cible, n’importe qui peut estimer la difficulté à l’aide de statistiques et donc savoir combien de travail a été nécessaire pour trouver un tel nonce.

La preuve de travail de Bitcoin est très similaire au défi présenté dans Sortie SHA256 d’un script pour générer de nombreux hachages en itérant sur un nombre aléatoire. Le mineur construit un bloc candidat rempli de transactions. Ensuite, le mineur calcule le hachage de l’en-tête de ce bloc et voit s’il est égal ou inférieur à la cible actuelle. Si le hachage est supérieur à la cible, le mineur modifiera le nonce (généralement en l’incrémentant simplement de un) et réessayera. À la difficulté actuelle du réseau Bitcoin, les mineurs doivent essayer des quadrillions de fois avant de trouver un nonce qui se traduit par un hachage d’en-tête de bloc suffisamment bas.

Un algorithme de preuve de travail très simplifié est implémenté en Python dans Mise en œuvre simplifiée de la preuve de travail.

En exécutant ce code, vous pouvez définir la difficulté souhaitée (en bits, combien de bits de tête doivent être nuls) et voir combien de temps il faut à votre ordinateur pour trouver une solution. Dans Exécution de l’exemple de preuve de travail pour diverses difficultés, vous pouvez voir comment cela fonctionne sur un ordinateur portable moyen.

Comme vous pouvez le constater, augmenter la difficulté de 1 bit entraîne un doublement du temps nécessaire pour trouver une solution. Si vous pensez à l’ensemble de l’espace numérique de 256 bits, chaque fois que vous contraignez un bit de plus à zéro, vous réduisez l’espace de recherche de moitié. Dans Exécution de l’exemple de preuve de travail pour diverses difficultés, il faut 84 millions de tentatives de hachage pour trouver un nonce qui produit un hachage avec 26 bits de tête en zéro. Même à une vitesse de plus de 120 000 hachages par seconde, il faut tout de même 10 minutes sur un portable pour trouver cette solution.

Au moment de la rédaction, le réseau tente de trouver un bloc dont le hachage d’en-tête est égal ou inférieur à :

Comme vous pouvez le voir, il y a beaucoup de zéros au début de cette cible, ce qui signifie que la plage acceptable de hachages est beaucoup plus petite, il est donc plus difficile de trouver un hachage valide. Il faudra en moyenne plus de 1,8 zêta de hachages (mille milliards de milliards de hachages) pour que le réseau découvre le bloc suivant. Cela semble être une tâche impossible, mais heureusement, le réseau apporte 3 exa-hachages par seconde (EH/sec) de puissance de traitement, ce qui permettra de trouver un bloc en environ 10 minutes en moyenne.

Dans Utiliser la ligne de commande pour récupérer le bloc 277,316, nous avons vu que le bloc contient la cible, dans une notation appelée "bits cible" ou simplement "bits", qui dans le bloc 277 316 a la valeur 0x1903a30c. Cette notation exprime la cible de preuve de travail sous la forme d’un format coefficient/exposant, avec les deux premiers chiffres hexadécimaux pour l’exposant et les six chiffres hexadécimaux suivants pour le coefficient. Dans ce bloc, par conséquent, l’exposant est 0x19 et le coefficient est 0x03a30c.

La formule pour calculer la cible de difficulté à partir de cette représentation est :

En utilisant cette formule et la valeur des bits de difficulté 0x1903a30c, nous obtenons :

qui en décimal est :

retour en hexadécimal :

Cela signifie qu’un bloc valide pour la hauteur 277 316 est celui qui a un hachage d’en-tête de bloc inférieur à cette cible. En binaire, ce nombre doit avoir plus de 60 bits de tête mis à zéro. Avec ce niveau de difficulté, un seul mineur traitant 1 billion de hachages par seconde (1 terahash par seconde ou 1 TH/sec) ne trouverait une solution qu’une fois tous les 8 496 blocs ou une fois tous les 59 jours, en moyenne.

Comme nous l’avons vu, la cible détermine la difficulté et affecte donc le temps qu’il faut pour trouver une solution à l’algorithme de preuve de travail. Cela conduit à des questions évidentes : pourquoi la difficulté est-elle ajustable, qui l’ajuste et comment ?

Les blocs de Bitcoin sont générés toutes les 10 minutes, en moyenne. C’est le battement de cœur de bitcoin et sous-tend la fréquence d’émission de devises et la rapidité de règlement des transactions. Il doit rester constant non seulement à court terme, mais sur une période de plusieurs décennies. Au cours de cette période, on s’attend à ce que la puissance des ordinateurs continue d’augmenter à un rythme rapide. De plus, le nombre de participants à l’exploitation minière et les ordinateurs qu’ils utilisent changeront également constamment. Pour maintenir le temps de génération de bloc à 10 minutes, la difficulté de minage doit être ajustée pour tenir compte de ces changements. En fait, la cible de preuve de travail est un paramètre dynamique qui est périodiquement ajusté pour atteindre un objectif d’intervalle de bloc de 10 minutes. En termes simples, l’objectif est défini de sorte que la puissance minière actuelle se traduise par un intervalle de bloc de 10 minutes.

Comment, alors, un tel ajustement s’effectue-t-il dans un réseau totalement décentralisé ? Le reciblage se produit automatiquement et sur chaque nœud indépendamment. Tous les 2 016 blocs, tous les nœuds reciblent la preuve de travail. L’équation de reciblage mesure le temps qu’il a fallu pour trouver les 2 016 derniers blocs et le compare au temps prévu de 20 160 minutes (2 016 blocs multipliés par l’intervalle de bloc de 10 minutes souhaité). Le rapport entre la durée réelle et la durée souhaitée est calculé et un ajustement proportionnel (à la hausse ou à la baisse) est apporté à la cible. En termes simples : si le réseau trouve des blocs plus rapidement que toutes les 10 minutes, la difficulté augmente (la cible diminue). Si la découverte de blocs est plus lente que prévu, la difficulté diminue (la cible augmente).

L’équation peut se résumer ainsi :

Reciblage de la preuve de travail avec CalculateNextWorkRequired() dans pow.cpp montre le code utilisé dans le client Bitcoin Core.

Les paramètres Interval (2 016 blocs) et TargetTimespan (deux semaines en 1 209 600 secondes) sont définis dans chainparams.cpp.

Pour éviter une volatilité extrême de la difficulté, l’ajustement de reciblage doit être inférieur à un facteur quatre (4) par cycle. Si l’ajustement cible requis est supérieur à un facteur de quatre, il sera ajusté d’un facteur de 4 et pas plus. Tout autre ajustement sera effectué au cours de la prochaine période de reciblage, car le déséquilibre persistera au cours des 2 016 prochains blocs. Par conséquent, des écarts importants entre la puissance de hachage et la difficulté peuvent nécessiter plusieurs cycles de blocs de 2 016 pour s’équilibrer.

Notez que la cible est indépendante du nombre de transactions ou de la valeur des transactions. Cela signifie que la quantité de puissance de hachage et donc d’électricité dépensée pour sécuriser le bitcoin est également entièrement indépendante du nombre de transactions. Bitcoin peut évoluer et parvenir à une adoption plus large et rester sécurisé sans aucune augmentation de la puissance de hachage par rapport au niveau actuel. L’augmentation de la puissance de hachage représente les forces du marché alors que de nouveaux mineurs entrent sur le marché pour concourir pour la récompense. Tant qu’une puissance de hachage suffisante est sous le contrôle des mineurs agissant honnêtement à la recherche de la récompense, cela suffit pour empêcher les attaques de "prise de contrôle" et, par conséquent, il en est suffisant pour sécuriser le bitcoin.

La difficulté du minage est étroitement liée au coût de l’électricité et au taux de change du bitcoin vis-à-vis de la monnaie utilisée pour payer l’électricité. Les systèmes de minage hautes performances sont à peu près aussi efficaces que possible avec la génération actuelle de fabrication de silicium, convertissant l’électricité en calcul de hachage au taux le plus élevé possible. La principale influence sur le marché minier est le prix d’un kilowattheure d’électricité en bitcoin, car cela détermine la rentabilité du minage et donc les incitations à entrer ou à sortir du marché minier.

Parce que la chaîne de blocs est une structure de données décentralisée, différentes copies de celle-ci ne sont pas toujours cohérentes. Les blocs peuvent arriver à différents nœuds à des moments différents, ce qui amène les nœuds à avoir différentes perspectives de la chaîne de blocs. Pour résoudre ce problème, chaque nœud sélectionne et tente toujours d’étendre la chaîne de blocs qui représente le plus de preuve de travail, également connue sous le nom de chaîne la plus longue ou de chaîne de travail cumulative la plus importante. En additionnant le travail enregistré dans chaque bloc d’une chaîne, un nœud peut calculer la quantité totale de travail qui a été dépensée pour créer cette chaîne. Tant que tous les nœuds sélectionnent la plus grande chaîne de travail cumulatif, le réseau mondial Bitcoin finit par converger vers un état cohérent. Les fourches se produisent sous forme d’incohérences temporaires entre les versions de la chaîne de blocs, qui sont résolues par une éventuelle reconvergence à mesure que d’autres blocs sont ajoutés à l’une des fourches.

Dans les quelques diagrammes suivants, nous suivons la progression d’un événement d'"embranchement" (ou de fourche) à travers le réseau. Le diagramme est une représentation simplifiée du réseau Bitcoin. À des fins d’illustration, différents blocs sont représentés sous différentes formes (étoile, triangle, triangle inversé, losange), répartis sur le réseau. Chaque nœud du réseau est représenté par un cercle.

Chaque nœud a sa propre perspective de la chaîne de blocs mondiale. Au fur et à mesure que chaque nœud reçoit des blocs de ses voisins, il met à jour sa propre copie de la chaîne de blocs, en sélectionnant la plus grande chaîne de travail cumulée. À des fins d’illustration, chaque nœud contient une forme qui représente le bloc qui, selon lui, est actuellement la pointe de la chaîne principale. Donc, si vous voyez une forme d’étoile dans le nœud, cela signifie que le bloc en étoile est la pointe de la chaîne principale, en ce qui concerne ce nœud.

Dans le premier diagramme (Avant la bifurcation, tous les nœuds ont la même perspective), le réseau a une perspective unifiée de la chaîne de blocs, avec le bloc étoile comme pointe de la chaîne principale.

Un "embranchement" (ou une "fourche") se produit chaque fois qu’il y a deux blocs valides différents à la même hauteur de bloc en compétition pour former la chaîne de blocs la plus longue. Cela se produit dans des conditions normales chaque fois que deux mineurs résolvent l’algorithme de preuve de travail dans un court laps de temps l’un de l’autre. Alors que les deux mineurs découvrent une solution pour leurs blocs candidats respectifs, ils diffusent immédiatement leur propre bloc "gagnant" à leurs voisins immédiats qui commencent à propager le bloc sur le réseau. Chaque nœud qui reçoit un bloc valide l’incorpore dans sa chaîne de blocs, étendant la chaîne de blocs d’un bloc. Si ce nœud voit plus tard un autre bloc valide étendre le même parent (à la même hauteur de bloc), il connecte le deuxième bloc sur une chaîne secondaire, bifurquant sa chaîne principale. En conséquence, certains nœuds "verront" un bloc gagnant en premier, tandis que d’autres nœuds verront l’autre bloc gagnant en premier, et deux versions concurrentes de la chaîne de blocs émergeront.

Dans Visualisation d’un événement d’embranchement (fourche) de la chaîne de blocs: deux blocs trouvés simultanément, on voit deux mineurs (Nœud X et Nœud Y) qui minent deux blocs différents presque simultanément. Ces deux blocs sont des enfants du bloc étoile et étendent la chaîne en s’appuyant sur le bloc étoile. Pour nous aider à le suivre, l’un est visualisé comme un bloc triangulaire provenant du nœud X, et l’autre est représenté comme un bloc triangulaire inversé provenant du nœud Y.

Supposons, par exemple, que le mineur Nœud X trouve une solution de preuve de travail pour un bloc "triangle" qui étend la chaîne de blocs, en s’appuyant sur le bloc parent "étoile". Presque simultanément, le mineur Nœud Y qui étendait également la chaîne du bloc "étoile" trouve une solution pour le bloc "triangle inversé", son bloc candidat. Maintenant, il y a deux blocs possibles ; un que nous appelons "triangle", originaire du Nœud X ; et un que nous appelons "triangle inversé", originaire du nœud Y. Les deux blocs ont été extraits avec succès, les deux blocs sont valides (contiennent une solution valide à la preuve de travail), et les deux blocs étendent le même parent (bloc "étoile"). Les deux blocs contiennent probablement la plupart des mêmes transactions, avec seulement peut-être quelques différences dans l’ordre des transactions.

Au fur et à mesure que les deux blocs se propagent, certains nœuds reçoivent d’abord le bloc "triangle" et d’autres reçoivent le bloc "triangle inversé" en premier. Comme indiqué dans Visualisation d’un événement d’embranchement de la chaîne de blocs : deux blocs se propagent, divisant le réseau, le réseau se scinde en deux perspectives différentes de la chaîne de blocs; un côté surmonté du bloc triangle, l’autre du bloc triangle renversé.

Dans Visualisation d’un événement d’embranchement de la chaîne de blocs : deux blocs se propagent, divisant le réseau, le mineur Nœud X a extrait (créé) le bloc triangulaire et a étendu la chaîne d’étoiles avec. Par conséquent, le Nœud X considère initialement la chaîne avec le bloc "triangle" comme la chaîne principale. Plus tard, le Nœud X a également reçu le bloc "triangle inversé" qui a été extrait par le Nœud Y. Puisqu’il a été reçu en deuxième, il est supposé avoir "perdu" la course. Pourtant, le bloc "triangle inversé" n’est pas écarté. Il est lié au bloc parent "étoile" et forme une chaîne secondaire. Alors que le Nœud X suppose que sa chaîne principale est la chaîne gagnante, il conserve la chaîne "perdante" afin qu’il dispose des informations nécessaires pour reconverger si la chaîne "perdante" finit par "gagner".

De l’autre côté du réseau, le mineur Nœud Y construit une chaîne de blocs basée sur sa propre perspective de la séquence des événements. Le mineur Nœud Y a extrait (créé) le "triangle inversé" et considère initialement cette chaîne comme la chaîne principale (la chaîne "gagnante"). Lorsqu’il a ensuite reçu le bloc "triangle" extrait par le Nœud X, il l’a connecté au parent du bloc "étoile" en tant que chaîne secondaire.

Aucun des deux côtés n’est "correct" ou "incorrect". Les deux sont des perspectives valables de la chaîne de blocs. Ce n’est qu’avec le recul qu’une seule l’emportera, en fonction de la façon dont ces deux chaînes concurrentes sont prolongées par des travaux supplémentaires.

Chaque nœud de minage dont la perspective ressemble au Nœud X commencera immédiatement à miner un bloc candidat qui étend la chaîne avec un "triangle" comme pointe. En liant "triangle" en tant que parent de leurs blocs de candidats, ils votent avec leur pouvoir de hachage. Leur vote soutient la chaîne qu’ils ont élue comme chaîne principale.

Tout nœud minier dont la perspective ressemble au Nœud Y commencera à construire un bloc candidat avec un "triangle inversé" comme parent, étendant la chaîne qu’ils croient être la chaîne principale. Et voilà, la course recommence.

Les fourches sont presque toujours résolues en un bloc de temps (10 minutes en moyenne). Alors qu’une partie de la puissance de hachage du réseau est dédiée à la construction au-dessus du "triangle" en tant que parent, une autre partie de la puissance de hachage est concentrée sur la construction au-dessus du "triangle inversé". Même si la puissance de hachage est presque également répartie, il est probable qu’un groupe de mineurs trouvera une solution et la propagera avant que l’autre groupe de mineurs ait trouvé des solutions. Disons, par exemple, que les mineurs construisant au-dessus du "triangle" trouvent un nouveau bloc "losange" qui prolonge la chaîne (par exemple, étoile-triangle-losange). Ils propagent immédiatement ce nouveau bloc et l’ensemble du réseau le considère comme une solution valide, comme indiqué dans Visualisation d’un événement d’un embranchement de la chaîne de blocs : un nouveau bloc étend une fourche, reconvergeant le réseau. Le Nœud X et le Nœud Y considèrent maintenant le bloc "triangle inversé" comme un bloc obsolète..

Tous les nœuds qui avaient choisi "triangle" comme vainqueur au tour précédent étendront simplement la chaîne d’un bloc supplémentaire. Cependant, les nœuds qui ont choisi "triangle inversé" comme gagnant verront désormais deux chaînes : étoile-triangle-losange et étoile-triangle inversé. La chaîne étoile-triangle-losange est maintenant plus longue (plus de travail cumulé) que l’autre chaîne. En conséquence, ces nœuds définiront la chaîne étoile-triangle-losange comme chaîne principale et transformeront la chaîne étoile-triangle inversé en une chaîne secondaire, comme indiqué dans Visualisation d’un événement d’embranchement de la chaîne de blocs : le réseau reconverge sur une nouvelle chaîne la plus longue. Il s’agit d’une reconvergence en chaîne, car ces nœuds sont obligés de revoir leur vision de la chaîne de blocs pour intégrer les nouvelles preuves d’une chaîne plus longue. Tous les mineurs travaillant à l’extension de la chaîne étoile-inversée-triangle arrêteront désormais ce travail car leur bloc candidat est désormais considéré comme un enfant d’un bloc périmé, car son parent "triangle-inversé" n’est plus sur la chaîne la plus longue . Étant donné que le bloc triangle inversé est désormais obsolète, le mineur Nœud Y (qui a miné ce bloc) ne pourra pas dépenser la récompense de minage pour ce bloc, même si ce bloc était valide et a été miné avec succès. Les transactions dans le "triangle inversé" qui ne sont pas dans le "triangle" sont réinsérées dans le mempool pour être incluses dans le bloc suivant pour devenir une partie de la chaîne principale. L’ensemble du réseau reconverge sur une seule chaîne de blocs étoile-triangle-losange, avec "losange" comme dernier bloc de la chaîne. Tous les mineurs commencent immédiatement à travailler sur des blocs candidats qui font référence à "losange" comme parent pour étendre la chaîne étoile-triangle-losange.

Il est théoriquement possible qu’une fourche s’étende à deux blocs, si deux blocs sont trouvés presque simultanément par des mineurs sur les "côtés" opposés d’une fourche précédente. Cependant, la probabilité que cela se produise est très faible. Alors qu’une fourche à un bloc peut se produire tous les jours, une fourche à deux blocs se produit au plus une fois toutes les quelques semaines.

L’intervalle de bloc de Bitcoin de 10 minutes est un compromis de conception entre des temps de confirmation rapides (règlement des transactions) et la probabilité d’une fourche. Un temps de bloc plus rapide rendrait les transactions plus rapides mais conduirait à des fourches de chaîne de blocs plus fréquentes, tandis qu’un temps de bloc plus lent réduirait le nombre de fourches mais ralentirait le règlement.

Depuis 2012, l’extraction de bitcoins a évolué pour résoudre une limitation fondamentale dans la structure de l’en-tête de bloc. Au début du bitcoin, un mineur pouvait trouver un bloc en parcourant le nonce jusqu’à ce que le hachage résultant soit égal ou inférieur à la cible. Au fur et à mesure que la difficulté augmentait, les mineurs parcouraient souvent les 4 milliards de valeurs du nonce sans trouver de bloc. Cependant, cela a été facilement résolu en mettant à jour l’horodatage du bloc pour tenir compte du temps écoulé. Étant donné que l’horodatage fait partie de l’en-tête, la modification permettrait aux mineurs de parcourir à nouveau les valeurs du nonce avec des résultats différents. Cependant, une fois que le matériel de minage a dépassé 4 GH/sec, cette approche est devenue de plus en plus difficile car les valeurs nonce ont été épuisées en moins d’une seconde. Alors que l’équipement de minage ASIC commençait à pousser puis à dépasser le taux de hachage TH/sec, le logiciel de minage avait besoin de plus d’espace pour les valeurs nonce afin de trouver des blocs valides. L’horodatage pourrait être un peu étiré, mais le déplacer trop loin dans le futur rendrait le bloc invalide. Une nouvelle source de "changement" était nécessaire dans l’en-tête du bloc. La solution consistait à utiliser la transaction coinbase comme source de valeurs nonce supplémentaires. Étant donné que le script coinbase peut stocker entre 2 et 100 octets de données, les mineurs ont commencé à utiliser cet espace comme espace nonce supplémentaire, leur permettant d’explorer une gamme beaucoup plus large de valeurs d’en-tête de bloc pour trouver des blocs valides. La transaction coinbase est incluse dans l’arborescence de Merkle, ce qui signifie que tout changement dans le script coinbase entraîne la modification de la racine de Merkle. Huit octets de nonce supplémentaires, plus les 4 octets de nonce "standard" permettent aux mineurs d’explorer un total de 2⁹⁶ (8 suivis de 28 zéros) possibilités par seconde sans avoir à modifier l’horodatage. Si, à l’avenir, les mineurs pouvaient parcourir toutes ces possibilités, ils pourraient alors modifier l’horodatage. Il y a également plus d’espace dans le script coinbase pour l’expansion future de l’espace nonce supplémentaire.

Dans cet environnement hautement concurrentiel, les mineurs travaillant seuls (également appelés mineurs solo) n’ont aucune chance. La probabilité qu’ils trouvent un bloc pour compenser leurs coûts d’électricité et de matériel est si faible que cela représente un pari, comme jouer à la loterie. Même le système minier ASIC grand public le plus rapide ne peut pas suivre les systèmes commerciaux qui empilent des dizaines de milliers de ces puces dans des entrepôts géants à proximité de centrales hydroélectriques. Les mineurs collaborent désormais pour former des groupes de minage, mettant en commun leur pouvoir de hachage et partageant la récompense entre des milliers de participants. En participant à un groupe, les mineurs obtiennent une plus petite part de la récompense globale, mais sont généralement récompensés tous les jours, ce qui réduit l’incertitude.

Prenons un exemple précis. Supposons qu’un mineur ait acheté du matériel de minage avec un taux de hachage combiné de 14 000 gigahachages par seconde (GH/s), soit 14 TH/s. En 2017, cet équipement coûte environ 2 500 $ US. Le matériel consomme 1375 watts (1,3 kW) d’électricité lorsqu’il fonctionne, 33 kW-heures par jour, à un coût de 1 $ à 2 $ par jour à des tarifs d’électricité très bas. À la difficulté actuelle du bitcoin, le mineur pourra extraire un bloc en solo environ une fois tous les 4 ans. Comment calcule-t-on cette probabilité ? Il est basé sur un taux de hachage à l’échelle du réseau de 3 EH/sec (en 2017) et le taux du mineur de 14 TH/sec :

…​où 210 240 est le nombre de blocs en quatre ans. Le mineur a une probabilité de 98 % de trouver un bloc sur quatre ans, sur la base du taux de hachage global au début de la période.

Si le mineur trouve un seul bloc dans ce délai, le paiement de 6,25 bitcoins, à environ 1 000 $ par bitcoin, se traduira par un paiement unique de 6 250 $, ce qui produira un bénéfice net d’environ 750 $. Cependant, la chance de trouver un bloc dans une période de 4 ans dépend de la chance du mineur. Il pourrait trouver deux blocs en 4 ans et faire un profit plus important. Ou il pourrait ne pas trouver de bloc pendant 5 ans et subir une grosse perte financière. Pire encore, la difficulté de l’algorithme Bitcoin de preuve de travail est susceptible d’augmenter considérablement au cours de cette période, au rythme actuel de croissance de la puissance de hachage, ce qui signifie que le mineur a au plus un an pour atteindre le seuil de rentabilité avant que le matériel soit effectivement obsolète et que ce dernier soit remplacé par du matériel de minage plus puissant. Financièrement, cela n’a de sens qu’à très faible coût d’électricité (moins de 1 cent par kWh) et uniquement à très grande échelle.

Les "pools" ou groupes de minage coordonnent plusieurs centaines ou milliers de mineurs, sur des protocoles de minage de groupe spécialisés. Les mineurs individuels configurent leur équipement minier pour se connecter à un serveur de pool et spécifient une adresse Bitcoin, qui recevra leur part des récompenses. Leur matériel de minage reste connecté au serveur du pool pendant le minage, synchronisant leurs efforts avec les autres mineurs. Ainsi, les mineurs du pool partagent l’effort d’extraction d’un bloc, puis partagent les récompenses.

Les blocs réussis paient la récompense à une adresse Bitcoin de groupe, plutôt qu’à des mineurs individuels. Le serveur de groupe effectuera périodiquement des paiements aux adresses Bitcoin des mineurs, une fois que leur part des récompenses aura atteint un certain seuil. En règle générale, le serveur de groupe facture un pourcentage des récompenses pour la fourniture du service de minage de groupe.

Les mineurs participant à un groupe se partagent le travail de recherche d’une solution à un bloc candidat, gagnant des "actions" pour leur contribution minière. Le groupe de minage fixe un objectif plus élevé (difficulté moindre) pour gagner une part, généralement plus de 1 000 fois plus facile que l’objectif du réseau Bitcoin. Lorsqu’un membre du groupe exploite avec succès un bloc, la récompense est gagnée par le groupe, puis partagée avec tous les mineurs proportionnellement au nombre d’actions qu’ils ont contribué à l’effort.

Les groupes sont ouvertes à tout mineur, grand ou petit, professionnel ou amateur. Un groupe aura donc certains participants avec une seule petite machine de minage, et d’autres avec un garage rempli de matériel de minage haut de gamme. Certains exploiteront quelques dizaines de kilowatts d’électricité, d’autres exploiteront un centre de données consommant un mégawatt d’électricité. Comment un groupe de minage mesure-t-il les contributions individuelles, de manière à répartir équitablement les récompenses, sans possibilité de tricherie ? La réponse est d’utiliser l’algorithme de preuve de travail de Bitcoin pour mesurer la contribution de chaque mineur du groupe, mais avec une difficulté inférieure afin que même les plus petits mineurs du groupe gagnent une part suffisamment fréquemment pour qu’il soit intéressant de contribuer au groupe. En fixant une difficulté inférieure pour gagner des actions, le groupe mesure la quantité de travail effectué par chaque mineur. Chaque fois qu’un mineur de groupe trouve un hachage d’en-tête de bloc égal ou inférieur à la cible du groupe, il prouve qu’il a effectué le travail de hachage pour trouver ce résultat. Plus important encore, le travail de recherche de parts contribue, de manière statistiquement mesurable, à l’effort global pour trouver un hachage égal ou inférieur à la cible du réseau Bitcoin. Des milliers de mineurs essayant de trouver des hachages de faible valeur finiront par en trouver un suffisamment bas pour satisfaire la cible du réseau Bitcoin.

Revenons à l’analogie d’un jeu de dés. Si les joueurs de dés lancent des dés avec un objectif de lancer égal ou inférieur à quatre (la difficulté globale du réseau), un groupe fixerait un objectif plus facile, en comptant combien de fois les joueurs du groupe ont réussi à lancer égal ou inférieur à huit. Lorsque les joueurs du pool lancent un nombre égal ou inférieur à huit (l’objectif de partage du groupe) mais supérieur à quatre (supérieur à la difficulté globale du réseau), ils gagnent des parts, mais ni eux ni le groupe ne gagnent la partie car ils n’y parviennent pas à atteindre la cible (égale ou inférieure à quatre). Les joueurs de groupe atteindront beaucoup plus souvent l’objectif de groupe le plus facile, leur faisant gagner des parts très régulièrement, même s’ils n’atteignent pas l’objectif plus difficile de gagner la partie. De temps en temps, l’un des joueurs du groupe lancera les dés combinés égal ou inférieur à quatre, le joueur du groupe gagne une part et l’ensemble du groupe gagne la partie. Ensuite, les gains peuvent être distribués aux joueurs du groupe en fonction du nombre de parts que chacun a gagné. Même si l’objectif de huit ou moins n’était pas gagnant, c’était un moyen juste de mesurer les lancers de dés pour les joueurs, et cela produit parfois un lancer de quatre ou moins.

De même, un groupe de minage définira une cible de groupe (plus élevée et plus facile) qui garantira qu’un mineur de groupe individuel peut trouver des hachages d’en-tête de bloc qui sont souvent égaux ou inférieurs à la cible du pool, gagnant ainsi des actions. De temps en temps, l’une de ces tentatives produira un hachage d’en-tête de bloc égal ou inférieur à la cible du réseau Bitcoin, ce qui en fait un bloc valide et l’ensemble du groupe gagne.

Dans Fourches de chaîne de blocs nous avons examiné comment le réseau Bitcoin peut brièvement diverger, avec deux parties du réseau suivant deux branches différentes de la chaîne de blocs pendant une courte période. Nous avons vu comment ce processus se produit naturellement, dans le cadre du fonctionnement normal du réseau et comment le réseau reconverge sur une chaîne de blocs commune après le minage d’un ou plusieurs blocs.

Il existe un autre scénario dans lequel le réseau peut diverger en deux chaînes suivantes : un changement dans les règles de consensus. Ce type de fourche ou embranchement est appelé embranchement divergent (hard fork), car après l’embranchement ou la fourche, le réseau ne reconverge pas sur une seule chaîne. Au lieu de cela, les deux chaînes évoluent indépendamment. Les embranchements divergents se produisent lorsqu’une partie du réseau fonctionne selon un ensemble de règles de consensus différent du reste du réseau. Cela peut se produire à cause d’un bogue ou à cause d’un changement délibéré dans l’implémentation des règles de consensus.

Les embranchements divergents peuvent être utilisés pour modifier les règles du consensus, mais ils nécessitent une coordination entre tous les participants au système. Tous les nœuds qui ne se mettent pas à niveau vers les nouvelles règles de consensus ne peuvent pas participer au mécanisme de consensus et sont forcés à une chaîne distincte au moment de l’embranchement divergent. Ainsi, un changement introduit par un embranchement divergent peut être considéré comme non « compatible en aval », dans la mesure où les systèmes non mis à niveau ne peuvent pas traiter les nouvelles règles de consensus après l’événement d’embranchement divergent.

Examinons les mécanismes d’un embranchement divergent avec un exemple spécifique.

Une chaîne de blocs avec des fourches montre une chaîne de blocs avec deux fourches. À la hauteur de bloc 4, une fourche à un bloc se produit. C’est le type de fourche spontané que nous avons vu dans Fourches de chaîne de blocs. Avec le minage du bloc 5, le réseau reconverge sur une chaîne et l’embranchement est résolu.

Plus tard, cependant, à la hauteur de bloc 6, une bifurcation divergente se produit. Supposons qu’une nouvelle implémentation du client soit publiée avec un changement dans les règles de consensus. À partir de la hauteur de bloc 7, les mineurs exécutant cette nouvelle implémentation accepteront un nouveau type de signature numérique, appelons-le une signature "Smores", qui n’est pas basée sur ECDSA. Immédiatement après, un nœud exécutant la nouvelle implémentation crée une transaction qui contient une signature Smores et un mineur avec le logiciel mis à jour mine le bloc 7b contenant cette transaction.

Tout nœud ou mineur qui n’a pas mis à jour le logiciel pour valider les signatures Smores est désormais incapable de traiter le bloc 7b. De leur point de vue, la transaction qui contenait une signature Smores et le bloc 7b qui contenait cette transaction sont invalides, car ils les évaluent sur la base des anciennes règles de consensus. Ces nœuds rejetteront la transaction et le bloc et ne les propageront pas. Tous les mineurs qui utilisent les anciennes règles n’accepteront pas le bloc 7b et continueront à exploiter un bloc candidat dont le parent est le bloc 6. En fait, les mineurs utilisant les anciennes règles peuvent même ne pas recevoir le bloc 7b si tous les nœuds auxquels ils sont connectés sont obéissant également aux anciennes règles et donc ne propageant pas le bloc. À terme, ils pourront exploiter le bloc 7a, qui est valide selon les anciennes règles et ne contient aucune transaction avec des signatures Smores.

Les deux chaînes continuent de diverger à partir de ce point. Les mineurs de la chaîne "b" continueront d’accepter et d’exploiter les transactions contenant des signatures Smores, tandis que les mineurs de la chaîne "a" continueront d’ignorer ces transactions. Même si le bloc 8b ne contient aucune transaction signée Smores, les mineurs de la chaîne "a" ne peuvent pas le traiter. Pour eux, il semble être un bloc orphelin, car son parent "7b" n’est pas reconnu comme un bloc valide.

Pour les développeurs de logiciels, le terme "fourche" a une autre signification, ajoutant de la confusion au terme "fourche divergente". Dans les logiciels à source libre, une fourche se produit lorsqu’un groupe de développeurs choisit de suivre une feuille de route logicielle différente et démarre une implémentation concurrente d’un projet à source libre. Nous avons déjà discuté de deux circonstances qui conduiront à un embranchement divergent en Bitcoin : un bogue dans les règles de consensus et une modification délibérée des règles de consensus. Dans le cas d’une modification délibérée des règles de consensus, une fourche logicielle précède l’embranchement divergent. Cependant, pour que ce type d’embranchement divergent se produise, une nouvelle implémentation logicielle des règles de consensus doit être développée, adoptée et lancée.

Des exemples de fourches logicielles qui ont tenté de modifier les règles de consensus incluent Bitcoin XT, Bitcoin Classic et, plus récemment, Bitcoin Unlimited. Cependant, aucun de ces fourches logiciels n’a abouti à un embranchement divergent. Bien qu’une fourche logicielle soit une condition préalable nécessaire, il n’est pas suffisant en soi pour qu’un embranchement divergent se produise. Pour qu’un embranchement divergent se produise, l’implémentation concurrente doit être adoptée et les nouvelles règles activées, par les mineurs, les portefeuilles et les nœuds intermédiaires. A l’inverse, il existe de nombreuses implémentations alternatives de Bitcoin Core, et même des fourches logiciels, qui ne changent pas les règles de consensus, et sauf par bogue, peuvent coexister sur le réseau et interagir sans provoquer d’embranchement divergent.

Les règles de consensus peuvent différer de manière évidente et explicite, dans la validation des transactions ou des blocs. Les règles peuvent également différer de manière plus subtile, dans la mise en œuvre des règles de consensus telles qu’elles s’appliquent aux scripts bitcoin ou aux primitives cryptographiques telles que les signatures numériques. Enfin, les règles de consensus peuvent différer de manière imprévue en raison des contraintes de consensus implicites imposées par les limitations du système ou les détails de mise en œuvre. Un exemple de ce dernier a été vu dans l’embranchement divergent imprévu lors de la mise à niveau de Bitcoin Core 0.7 vers 0.8, qui a été causé par une limitation de l’implémentation de Berkeley DB utilisée pour stocker les blocs.

Conceptuellement, nous pouvons considérer qu’un embranchement divergent se développe en quatre étapes : une fourche logiciel, une fourche du réseau, une fourche de minage et une fourche de chaîne.

Le processus commence lorsqu’une implémentation alternative du client, avec des règles de consensus modifiées, est créée par les développeurs.

Lorsque cette implémentation fourchée est déployée dans le réseau, un certain pourcentage de mineurs, d’utilisateurs de portefeuille et de nœuds intermédiaires peuvent adopter et exécuter cette implémentation. Une fourche résultante dépendra de l’application ou non des nouvelles règles de consensus aux blocs, aux transactions ou à tout autre aspect du système. Si les nouvelles règles de consensus concernent les transactions, un portefeuille créant une transaction selon les nouvelles règles peut précipiter une fourche réseau, suivi d’un embranchement divergent lorsque la transaction est extraite dans un bloc. Si les nouvelles règles concernent les blocs, le processus d’embranchement divergent commencera lorsqu’un bloc sera miné selon les nouvelles règles.

Tout d’abord, le réseau bifurquera. Les nœuds basés sur l’implémentation d’origine des règles de consensus rejetteront toutes les transactions et tous les blocs créés selon les nouvelles règles. De plus, les nœuds qui suivent les règles de consensus d’origine seront temporairement bannis et déconnectés de tous les nœuds qui leur envoient ces transactions et blocs invalides. En conséquence, le réseau va se partitionner en deux : les anciens nœuds ne resteront connectés qu’aux anciens nœuds et les nouveaux nœuds ne seront connectés qu’aux nouveaux nœuds. Une transaction ou un bloc unique basé sur les nouvelles règles se répercutera sur le réseau et entraînera la partition en deux réseaux.

Une fois qu’un mineur utilisant les nouvelles règles exploite un bloc, la puissance et la chaîne de minage bifurqueront également. Les nouveaux mineurs exploiteront le nouveau bloc, tandis que les anciens mineurs exploiteront une chaîne distincte basée sur les anciennes règles. Le réseau partitionné fera en sorte que les mineurs opérant selon des règles de consensus distinctes ne recevront probablement pas les blocs les uns des autres, car ils sont connectés à deux réseaux distincts.

Alors que les mineurs divergent pour exploiter deux chaînes différentes, la puissance de hachage est répartie entre les chaînes. La puissance minière peut être répartie dans n’importe quelle proportion entre les deux chaînes. Les nouvelles règles ne peuvent être suivies que par une minorité, ou par la grande majorité de la puissance minière.

Supposons, par exemple, une répartition de 80 % à 20 %, la majorité de la puissance minière utilisant les nouvelles règles de consensus. Supposons également que la fourche se produise immédiatement après une période de reciblage.

Les deux chaînes hériteraient chacune de la difficulté de la période de reciblage. Les nouvelles règles consensuelles auraient 80 % de la puissance minière précédemment disponible qui leur serait engagée. Du point de vue de cette chaîne, la puissance minière a subitement reculé de 20 % par rapport à la période précédente. Des blocs seront trouvés en moyenne toutes les 12,5 minutes, ce qui représente la baisse de 20 % de la puissance minière disponible pour prolonger cette chaîne. Ce taux d’émission de blocs se poursuivra (sauf modification de la puissance de hachage) jusqu’à ce que les blocs de 2016 soient extraits, ce qui prendra environ 25 200 minutes (à 12,5 minutes par bloc), soit 17,5 jours. Après 17,5 jours, un reciblage se produira et la difficulté s’ajustera (réduite de 20%) pour produire à nouveau des blocs de 10 minutes, en fonction de la quantité réduite de puissance de hachage dans cette chaîne.

La chaîne minoritaire, minant selon les anciennes règles avec seulement 20 % de la puissance de hachage, sera confrontée à une tâche beaucoup plus difficile. Sur cette chaîne, les blocs seront désormais minés toutes les 50 minutes en moyenne. La difficulté ne sera pas ajustée pour les blocs de 2016, qui prendront 100 800 minutes, soit environ 10 semaines à miner. En supposant une capacité fixe par bloc, cela se traduira également par une réduction de la capacité de transaction par un facteur de 5, car il y a moins de blocs par heure disponibles pour enregistrer les transactions.

C’est l’aube du développement de logiciels consensuels. Tout comme le développement à source libre a changé à la fois les méthodes et les produits des logiciels et a créé de nouvelles méthodologies, de nouveaux outils et de nouvelles communautés dans son sillage, le développement de logiciels consensuels représente également une nouvelle frontière en informatique. Des débats, des expériences et des tribulations de la feuille de route de développement du bitcoin, nous verrons émerger de nouveaux outils, pratiques, méthodologies et communautés de développement.

Les fourches dures sont considérées comme risquées car elles obligent une minorité à se mettre à niveau ou à rester sur une chaîne minoritaire. Le risque de scinder l’ensemble du système en deux systèmes concurrents est considéré par beaucoup comme un risque inacceptable. En conséquence, de nombreux développeurs hésitent à utiliser le mécanisme d’embranchement divergent pour mettre en œuvre des mises à niveau des règles de consensus, à moins qu’il n’y ait un soutien quasi unanime de l’ensemble du réseau. Toutes les propositions d’embranchement divergent qui ne bénéficient pas d’un soutien quasi unanime sont considérées comme trop "controversées" à tenter sans risquer une partition du système.

La question des embranchements divergents est très controversée dans la communauté du développement de Bitcoin, en particulier en ce qui concerne toute modification proposée aux règles de consensus contrôlant la limite de taille de bloc maximale. Certains développeurs sont opposés à toute forme d’embranchement divergent, le considérant comme trop risqué. D’autres considèrent le mécanisme d’embranchement divergent comme un outil essentiel pour mettre à niveau les règles de consensus d’une manière qui évite la "dette technique" et offre une rupture nette avec le passé. Enfin, certains développeurs voient les embranchements divergents comme un mécanisme qui devrait être utilisé rarement, avec beaucoup de planification préalable et uniquement sous un consensus quasi unanime.

Nous avons déjà vu l’émergence de nouvelles méthodologies pour faire face aux risques d’embranchements divergents. Dans la section suivante, nous examinerons les embranchements convergents et les méthodes BIP-34 et BIP-9 pour la signalisation et l’activation des modifications de consensus.

Tous les changements de règles de consensus ne provoquent pas un embranchement divergent. Seuls les changements de consensus qui sont incompatibles en aval provoquent un embranchement ou fourche. Si la modification est implémentée de telle manière qu’un client non mis à niveau voit toujours la transaction ou le bloc comme valide selon les règles précédentes, la modification peut se produire sans fourche.

Le terme embranchement convergent (soft fork) a été introduit pour distinguer cette méthode de mise à niveau d’un "embranchement divergent" (hard fork). En pratique, un embranchement convergent n’est pas du tout un embranchement ou une fourche. Un embranchement convergent est une modification compatible avec les règles de consensus qui permet aux clients non mis à niveau de continuer à fonctionner en consensus avec les nouvelles règles.

Un aspect des embranchements convergents qui n’est pas immédiatement évident est que les mises à niveau d’embranchement convergent ne peuvent être utilisées que pour restreindre les règles de consensus, pas pour les étendre. Afin d’être compatibles en aval, les transactions et les blocs créés selon les nouvelles règles doivent également être valides selon les anciennes règles, mais pas l’inverse. Les nouvelles règles ne peuvent que limiter ce qui est valide; sinon, ils déclencheront un embranchement divergent s’ils sont rejetés selon les anciennes règles.

Les embranchements convergents peuvent être implémentés de plusieurs façons - le terme ne spécifie pas une méthode particulière, mais plutôt un ensemble de méthodes qui ont toutes une chose en commun : elles ne nécessitent pas la mise à niveau de tous les nœuds ou ne forcent pas les nœuds non mis à niveau hors de consensus.

Les embranchements convergents basés sur les opcodes NOP sont relativement peu controversés. Les opcodes NOP ont été placés dans Bitcoin Script dans le but explicite de permettre des mises à niveau non perturbatrices.

Cependant, de nombreux développeurs craignent que d’autres méthodes de mises à niveau d’embranchements convergents ne fassent des compromis inacceptables. Les critiques courantes des changements d’embranchement convergent incluent:

La première implémentation, dans BIP-34, utilisait le champ de version de bloc pour permettre aux mineurs de signaler qu’ils étaient prêts pour un changement de règle de consensus spécifique. Avant le BIP-34, la version du bloc était définie par la valeur "1" par convention non appliquée par consensus.

BIP-34 a défini un changement de règle de consensus qui exigeait que le champ de données coinbase d’une entrée de transaction coinbase contienne la hauteur du bloc. Avant le BIP-34, les données coinbase pouvaient contenir toutes les données arbitraires que les mineurs choisissaient d’inclure. Après l’activation de BIP-34, les blocs valides devaient contenir une hauteur de bloc spécifique au début des données coinbase et être identifiés par un numéro de version supérieur ou égal à "2".

Pour signaler le changement et l’activation de BIP-34, les mineurs ont défini la version du bloc à "2" au lieu de "1". Cela n’a pas immédiatement rendu les blocs de la version "1" invalides. Une fois activés, les blocs de la version "1" deviendraient invalides et tous les blocs de la version "2" devraient contenir la hauteur du bloc dans la coinbase pour être valides.

BIP-34 a défini un mécanisme d’activation en deux étapes, basé sur une fenêtre glissante de 1000 blocs. Un mineur signalerait sa préparation individuelle pour le BIP-34 en construisant des blocs avec "2" comme numéro de version. À proprement parler, ces blocs n’avaient pas encore à se conformer à la nouvelle règle de consensus consistant à inclure la hauteur de bloc dans la transaction coinbase car la règle de consensus n’avait pas encore été activée. Les règles de consensus activées en deux étapes :

Après une signalisation et une activation réussies selon les règles BIP-34, ce mécanisme a été utilisé deux fois de plus pour activer les embranchements convergents :

Après l’activation de BIP-65, le mécanisme de signalisation et d’activation de BIP-34 a été retiré et remplacé par le mécanisme de signalisation BIP-9 décrit ci-après.

La norme est définie dans BIP-34 (Block v2, Height in Coinbase).

Le mécanisme utilisé par BIP-34, BIP-66 et BIP-65 a réussi à activer trois embranchements convergents. Cependant, il a été remplacé car il présentait plusieurs limitations :

Le BIP-9 a été proposé pour surmonter ces défis et améliorer le rythme et la facilité de mise en œuvre des changements futurs.

BIP-9 interprète la version de bloc comme un champ de bits au lieu d’un entier. Étant donné que la version de bloc était à l’origine utilisée comme entier, versions 1 à 4, seuls 29 bits restent disponibles pour être utilisés comme champ de bits. Cela laisse 29 bits qui peuvent être utilisés pour signaler indépendamment et simultanément la disponibilité sur 29 propositions différentes.

BIP-9 fixe également un temps maximum pour la signalisation et l’activation. De cette façon, les mineurs n’ont pas besoin de signaler indéfiniment. Si une proposition n’est pas activée dans le délai TIMEOUT (défini dans la proposition), la proposition est considérée comme rejetée. La proposition peut être soumise à nouveau pour signalisation avec un bit différent, renouvelant la période d’activation.

De plus, après que le TIMEOUT est passé et qu’une fonctionnalité a été activée ou rejetée, le bit de signalisation peut être réutilisé pour une autre fonctionnalité sans confusion. Ainsi, jusqu’à 29 changements peuvent être signalés en parallèle et après TIMEOUT les bits peuvent être "recyclés" pour proposer de nouveaux changements.

Les modifications proposées sont identifiées par une structure de données contenant les champs suivants :

Contrairement à BIP-34, BIP-9 compte la signalisation d’activation dans des intervalles entiers en fonction de la période de reciblage de difficulté de 2016 blocs. Pour chaque période de reciblage, si la somme des blocs signalant une proposition dépasse 95 % (1 916 sur 2016), la proposition sera activée une période de reciblage plus tard.

BIP-9 propose un diagramme d’état de proposition pour illustrer les différentes étapes et transitions d’une proposition, comme indiqué dans BIP-9 diagramme de transition d’état.

Les propositions commencent dans l’état DEFINED, une fois que leurs paramètres sont connus (définis) dans le logiciel bitcoin. Pour les blocs avec MTP après l’heure de début, l’état de la proposition passe à STARTED. Si le seuil de vote est dépassé dans une période de reciblage et que le délai d’attente n’a pas été dépassé, l’état de la proposition passe à LOCKED_IN. Une période de reciblage plus tard, la proposition devient ACTIVE. Les propositions restent perpétuellement dans l’état ACTIVE une fois qu’elles atteignent cet état. Si le délai d’attente s’est écoulé avant que le seuil de vote n’ait été atteint, l’état de la proposition passe à FAILED, indiquant une proposition rejetée. Les propositions FAILED restent perpétuellement dans cet état.

BIP-9 a d’abord été implémenté pour l’activation de CHECKSEQUENCEVERIFY et des BIP associés (68, 112, 113). La proposition nommée "csv" a été activée avec succès en juillet 2016.

La norme est définie dans BIP-9 (Version bits with timeout and delay).