Bitcoin est souvent décrit comme de l'or numérique, impliquant une nature statique et immuable. Cependant, le logiciel qui alimente le réseau Bitcoin est un protocole vivant qui subit des maintenances, des corrections de bugs et des mises à jour. Contrairement au développement de logiciels centralisés où un PDG d'entreprise ou un chef de produit dicte les fonctionnalités, Bitcoin repose sur un réseau décentralisé de participants pour s'accorder sur les changements. Ce processus est délibéré, lent et fortement biaisé vers le statu quo pour assurer la sécurité de milliards de dollars en valeur.
L'évolution du protocole n'est pas régie par un système de vote formel ou une autorité unique. Au lieu de cela, elle fonctionne grâce à une combinaison unique de documentation technique, de revue par les pairs et de consensus communautaire. Comprendre comment une idée passe d'une simple discussion sur une liste de diffusion à un changement de code activé globalement révèle la résilience du réseau Bitcoin. Cela met en lumière un système conçu pour résister à la capture par un seul groupe, qu'il s'agisse de développeurs, de mineurs ou d'intérêts corporatifs.
Au cœur de ce processus évolutif se trouve la Bitcoin Improvement Proposal, ou BIP. C'est le mécanisme principal pour proposer de nouvelles fonctionnalités, recueillir les retours de la communauté sur un problème et documenter les décisions de conception. Un BIP n'est pas un vote contraignant, mais plutôt un document de conception technique. Il fournit des informations à la communauté Bitcoin ou décrit une nouvelle fonctionnalité pour Bitcoin ou ses processus.
Le cadre de la Bitcoin Improvement Proposal
Pour comprendre comment Bitcoin évolue, il faut d'abord comprendre le processus de standardisation. Le système BIP est fortement influencé par le processus Python Enhancement Proposal (PEP). Il sert de moyen formel pour introduire des changements dans le code source ou l'écosystème environnant. N'importe qui peut rédiger un BIP, mais le faire accepter et implémenter est un parcours du combattant rigoureux que peu de propositions survivent.
Définir un BIP
Un BIP est essentiellement un document technique. Il offre une spécification technique concise de la fonctionnalité et une justification pour celle-ci. L'auteur est responsable de construire un consensus au sein de la communauté et de documenter les opinions dissidentes. Il existe trois principaux types de BIPs. Les BIPs de la piste Standards décrivent tout changement affectant la plupart ou la totalité des implémentations Bitcoin, comme un changement du protocole réseau ou un changement des règles de validité des blocs ou des transactions.
Les BIPs Informationnels décrivent un problème de conception Bitcoin, ou fournissent des lignes directrices générales ou des informations à la communauté Bitcoin, mais ne proposent pas de nouvelle fonctionnalité. Les BIPs Processus décrivent un processus entourant Bitcoin, ou proposent un changement à (ou un événement dans) un processus. La grande majorité de l'attention publique va aux BIPs de la piste Standards, car ce sont ces propositions qui modifient les règles de consensus du réseau.
Le cycle de vie d'une proposition
La vie d'un BIP commence bien avant qu'il ne se voie attribuer un numéro. Elle commence généralement par des discussions sur la liste de diffusion de développement Bitcoin. C'est là que l'idée initiale est examinée, critiquée et souvent démolie par d'autres développeurs. Si l'idée survit à cette épreuve initiale par le feu, l'auteur rédige le texte du BIP.
Une fois le brouillon soumis au dépôt BIP, un éditeur lui attribue un numéro. Ce statut est connu sous le nom de « Draft ». De là, la proposition passe par diverses étapes. Si la communauté estime que le travail est précieux, elle peut passer à « Proposed ». Si les changements sont implémentés et activés par le réseau, le BIP devient « Final » ou « Active ». Inversement, les propositions peuvent être « Rejected », « Withdrawn » par l'auteur, ou marquées « Obsolete » si elles sont remplacées par des solutions plus récentes.
Le mécanisme de consensus
L'aspect le plus confus du développement Bitcoin pour les outsiders est l'absence de structure de gouvernance formelle. Il n'existe ni fondation ni leader qui appose un « approuvé » sur un BIP. Au lieu de cela, le réseau repose sur un concept connu sous le nom de « rough consensus ». C'est un terme emprunté à l'Internet Engineering Task Force (IETF). Cela ne signifie pas l'unanimité.
Comprendre le rough consensus
Le rough consensus est atteint lorsque la communauté technique s'accorde généralement sur le fait qu'une proposition est solide et que toutes les objections significatives ont été traitées. C'est une mesure qualitative plutôt qu'un vote quantitatif. Si une proposition a un fort mérite technique mais fait face à des préoccupations de sécurité valides d'une partie significative des développeurs, elle ne progressera pas.
Cette dynamique force les auteurs à s'engager avec les critiques. Ils doivent améliorer leurs propositions jusqu'à ce que les objections soient résolues ou prouvées infondées. Ce processus peut prendre des années. Par exemple, la mise à niveau Taproot a été discutée et affinée pendant une période considérable avant d'être considérée prête pour l'activation. La lenteur est une fonctionnalité, pas un bug, empêchant les décisions hâtives qui pourraient déstabiliser le réseau financier.
Accès aux commits des développeurs
Une idée fausse courante est que les développeurs ayant un « accès aux commits » au dépôt GitHub Bitcoin Core contrôlent Bitcoin. Bien que ces mainteneurs aient la capacité de fusionner du code dans la branche master du logiciel, ils fonctionnent plus comme des concierges que comme des dirigeants. Leur rôle est de s'assurer que le code fusionné reflète le rough consensus de la communauté.
Si un mainteneur fusionnait du code qui changeait fondamentalement Bitcoin contre la volonté des utilisateurs, les opérateurs de nœuds refuseraient simplement de mettre à jour vers cette version. Le réseau continuerait avec la version précédente, et la version du mainteneur serait ignorée. Cela crée un puissant contrôle sur l'influence des développeurs, les maintenant soumis aux désirs du réseau de nœuds.
Chemins d'activation et d'implémentation
Une fois qu'une mise à niveau du protocole est codée et fusionnée dans le logiciel Bitcoin Core, elle reste dormante. Elle doit être « activée » par le réseau. C'est la phase où le consensus théorique interagit avec la réalité physique de la blockchain. L'activation nécessite une coordination parmi les acteurs économiques du système, principalement les mineurs et les opérateurs de nœuds complets.
Signalisation des mineurs et seuils
Historiquement, l'activation utilisait souvent un processus défini dans le BIP 9. Cela implique que les mineurs signalent leur readiness pour une mise à niveau dans les en-têtes de blocs qu'ils minent. Pendant une période spécifique, généralement deux semaines (2016 blocs), le réseau surveille combien de blocs contiennent un signal de soutien pour la mise à niveau.
Si le pourcentage de blocs signalant atteint un seuil défini — souvent 90 % ou 95 % — la mise à niveau est verrouillée. Après une période de grâce subséquente, les nouvelles règles deviennent actives. Ce mécanisme est conçu pour assurer que le réseau se mette à niveau en douceur sans laisser les mineurs derrière. Cependant, il a aussi conduit à des impasses politiques où les mineurs vetoent efficacement les mises à niveau en refusant de signaler, même si la base d'utilisateurs plus large le souhaite.
User Activated Soft Forks
Les limitations de la signalisation des mineurs sont devenues apparentes pendant la « Block Size War » menant à 2017. Lorsque les mineurs ont retardé l'activation de Segregated Witness (SegWit), un mouvement grassroots est apparu proposant un User Activated Soft Fork (UASF), connu sous le nom de BIP 148.
Dans un UASF, les opérateurs de nœuds exécutent un logiciel qui rejette les blocs des mineurs qui ne signalent pas pour la mise à niveau après une certaine date. Cela déplace le pouvoir des mineurs vers la majorité économique des nœuds. Si l'activité économique (échanges, portefeuilles, utilisateurs) passe à la chaîne UASF, les mineurs sont incités économiquement à suivre ou risquent de miner sur une chaîne sans valeur. La menace du BIP 148 a été instrumentale pour forcer l'activation de SegWit.
Dynamiques de fork et compatibilité
Les changements au protocole Bitcoin tombent généralement en deux catégories : soft forks et hard forks. La distinction réside dans la compatibilité rétroactive. Comprendre la différence est crucial pour saisir pourquoi Bitcoin est resté un réseau unique et continu malgré de nombreuses mises à niveau.
Le mécanisme du soft fork
Un soft fork est un changement au protocole qui restreint l'ensemble des blocs valides. Il resserre les règles. Comme les nouvelles règles sont un sous-ensemble des anciennes règles, les anciens nœuds non mis à niveau verront toujours les nouveaux blocs comme valides. Ils ne comprendront peut-être pas les nouvelles fonctionnalités, mais ils accepteront la chaîne.
Cette compatibilité rétroactive est vitale. Elle permet au réseau de se mettre à niveau progressivement. Les utilisateurs ne sont pas forcés de mettre à jour leur logiciel immédiatement pour rester partie du consensus. La plupart des grandes mises à niveau, y compris SegWit et Taproot, ont été implémentées comme des soft forks. Cela assure que le réseau ne se divise pas en deux chaînes incompatibles simplement parce que certains utilisateurs sont lents à se mettre à niveau.
La divergence du hard fork
Un hard fork assouplit les règles ou introduit des règles incompatibles avec l'ancien logiciel. Les anciens nœuds verront les blocs créés sous les nouvelles règles comme invalides et les rejetteront. Pour qu'un hard fork réussisse sans diviser le réseau, 100 % des utilisateurs doivent se mettre à niveau simultanément, ce qui est impossible dans un système décentralisé.
Par conséquent, les hard forks conflictuels aboutissent presque toujours à une division permanente de chaîne. L'exemple le plus célèbre est la création de Bitcoin Cash (BCH) en 2017. Les partisans voulaient augmenter la limite de taille de bloc, un changement de règle incompatible avec le consensus existant de Bitcoin. Cela a résulté en deux réseaux et monnaies distincts. Les hard forks sont généralement évités dans le développement Bitcoin en raison de ce risque de fracturer le réseau et la communauté.
| Attribut de comparaison | Soft Fork | Hard Fork |
|---|---|---|
| Compatibilité | Rétrocompatible | Non rétrocompatible |
| Changement de règle | Resserre/Restreint les règles | Assouplit/Élargit les règles |
| Risque pour le réseau | Faible risque de division de chaîne | Haut risque de division permanente |
Principales mises à niveau du protocole : Segregated Witness
L'un des exemples les plus significatifs d'une proposition passant à l'implémentation est Segregated Witness (SegWit). Activé en août 2017, il a résolu des problèmes de longue date et a préparé le terrain pour un scaling futur. La proposition a fondamentalement changé la façon dont les données de transaction étaient structurées.
Résoudre la malléabilité
Avant SegWit, il était possible de modifier l'ID unique d'une transaction avant sa confirmation sur la blockchain sans invalider la signature. Ce problème, connu sous le nom de transaction malleability, rendait difficile la construction de solutions de seconde couche comme le Lightning Network. Si l'ID de transaction pouvait changer, les contrats intelligents dépendant de cet ID se casseraient.
SegWit a résolu cela en déplaçant les données de signature (witness) en dehors de la partie de la transaction utilisée pour calculer l'ID. En ségréguant le witness, l'ID de transaction est devenu immuable. Cette correction a été la clé qui a permis aux canaux de paiement de fonctionner de manière sécurisée, permettant le développement du Lightning Network.
Le concept d'unité de poids
SegWit a également servi d'augmentation astucieuse de la taille de bloc. Au lieu d'augmenter simplement la limite de 1 Mo — ce qui aurait requis un hard fork — SegWit a changé la façon dont les blocs sont mesurés. Il a introduit le « block weight ».
Les données dans la section witness comptent pour moins de poids que les données dans le bloc de transaction principal. Cela permet aux blocs de dépasser la taille traditionnelle de 1 Mo en termes de données brutes (jusqu'à 4 Mo théoriquement) tout en restant compatibles avec les nœuds legacy qui ne vérifient que les données non-witness. Cela a efficacement augmenté la capacité du réseau et réduit les frais pour les transactions utilisant le format SegWit.
La mise à niveau Taproot
Après SegWit, le prochain changement majeur était Taproot, activé en novembre 2021. Taproot combinait trois BIPs (340, 341 et 342) pour améliorer la confidentialité, l'efficacité et les capacités de script. Il a démontré un processus d'activation plus raffiné connu sous le nom de « Speedy Trial ».
Signatures Schnorr
Au cœur de Taproot se trouve l'implémentation des signatures Schnorr (BIP 340). Ce schéma de signature numérique offre des avantages significatifs par rapport à l'algorithme original Elliptic Curve Digital Signature Algorithm (ECDSA). L'avantage principal est la linéarité.
La linéarité permet l'agrégation de signatures. Dans une transaction multi-signature, plusieurs clés publiques et signatures peuvent être combinées en une seule clé et une seule signature. Pour la blockchain, une transaction complexe impliquant plusieurs parties ressemble à une transaction standard d'un seul utilisateur. Cela améliore la confidentialité en masquant la complexité des arrangements de portefeuilles et économise de l'espace sur la blockchain, réduisant les frais.
Merkelized Abstract Syntax Trees
Taproot a également introduit les Merkelized Abstract Syntax Trees (MAST). Précédemment, si un utilisateur créait un contrat intelligent complexe avec plusieurs conditions de dépense, toutes ces conditions devaient être révélées sur la blockchain lors de la dépense des fonds. Cela était inefficace et mauvais pour la confidentialité.
Avec MAST, les utilisateurs peuvent structurer les conditions de dépense au format arbre. Lors de la dépense, ils n'ont besoin de révéler que la branche spécifique de l'arbre utilisée. Les branches non exécutées restent cachées. Cela permet des contrats intelligents complexes qui sont privés et économes en données, élargissant davantage le potentiel de Bitcoin au-delà du simple transfert de valeur.
Débats actuels : le cas d'OP_CAT
L'évolution de Bitcoin est en cours, avec des discussions actuelles se concentrant sur la restauration de fonctionnalités perdues. L'un des sujets les plus proéminents est OP_CAT. C'est un opcode spécifique (code d'opération) qui faisait partie du logiciel Bitcoin original mais qui a été désactivé par Satoshi Nakamoto en 2010 en raison de préoccupations sur l'utilisation de la mémoire et les vulnérabilités de sécurité.
Comprendre les opcodes
Les opcodes sont les commandes que le langage de script Bitcoin comprend. Ils indiquent au réseau comment traiter une transaction. Certains opcodes permettent l'addition, d'autres vérifient les signatures, et certains vérifient les verrous temporels. Lorsque des opcodes sont désactivés, la capacité d'effectuer ces actions spécifiques est supprimée de la boîte à outils du réseau.
La suppression d'OP_CAT et d'autres a sévèrement limité le langage de script Bitcoin. Cette limitation était intentionnelle à l'époque, priorisant la sécurité et la stabilité sur la fonctionnalité. Cependant, à mesure que la compréhension du protocole a mûri, les développeurs explorent maintenant la réintroduction sûre de ces codes pour activer de nouvelles fonctionnalités.
La proposition de concaténation
OP_CAT permet spécifiquement la concaténation (jonction) de deux chaînes de données. Bien que cela semble simple, cela active une fonctionnalité puissante connue sous le nom de « covenants ». Les covenants permettent aux utilisateurs de placer des restrictions sur la façon dont les bitcoins futurs peuvent être dépensés, pas seulement qui peut les dépenser.
Par exemple, un covenant pourrait imposer qu'un UTXO spécifique ne puisse être envoyé qu'à une liste blanche d'adresses spécifiques. Cela a des implications massives pour les mécanismes de vault, où les utilisateurs pourraient créer des boutons « undo » pour les fonds volés, et pour le bridging Layer 2. Le débat autour d'OP_CAT illustre la nature conservatrice du développement Bitcoin ; même une commande simple nécessite des années d'analyse de sécurité avant réintroduction.
Impact sur les solutions Layer 2
Les propositions de protocole visent souvent la couche de base, mais leur utilité principale est réalisée sur les réseaux Layer 2 (L2). La relation entre la blockchain principale et ces couches secondaires est symbiotique. Les améliorations du protocole de base rendent les L2 moins chères, plus sûres et plus efficaces.
Dépendances du Lightning Network
Le Lightning Network est un exemple parfait de cette dépendance. Il repose sur la sécurité de la couche de base pour régler les transactions. Comme mentionné, la mise à niveau SegWit était une condition préalable pour que Lightning fonctionne de manière fiable. Les mises à niveau futures continuent de viser l'efficacité de Lightning.
Par exemple, des propositions comme « Eltoo » (SIGHASH_ANYPREVOUT) visent à simplifier la gestion des canaux. En modifiant la façon dont les transactions sont signées sur la couche de base, les nœuds Lightning peuvent stocker moins de données et se remettre plus facilement des pannes. Cela montre comment les propositions L1 sont souvent motivées par les besoins de scalabilité L2.
Intégration de sidechains
Les sidechains, comme Liquid ou Rootstock, bénéficient également des mises à niveau du protocole. Les sidechains sont des blockchains indépendantes qui fonctionnent en parallèle à Bitcoin. Elles utilisent un peg bidirectionnel pour transférer de la valeur d'avant en arrière. Actuellement, ces pegs reposent souvent sur des fédérations — groupes de fonctionnaires de confiance.
Des mises à niveau comme OP_CAT ou de nouveaux schémas de signature pourraient permettre des mécanismes de bridging plus sans confiance. Si le script Bitcoin peut vérifier des preuves d'une sidechain (comme des preuves Zero-Knowledge), cela permettrait aux utilisateurs de déplacer des fonds entre chaînes sans faire confiance à une fédération. Cela reste un domaine majeur de recherche et de motivation pour de nouveaux BIPs.
Innovation non intentionnelle : le phénomène Ordinals
Parfois, les mises à niveau du protocole mènent à des résultats complètement inattendus. L'essor des Ordinals témoigne de la loi des conséquences non intentionnelles dans le logiciel open-source. Les Ordinals utilisent les mécaniques de SegWit et Taproot pour inscrire des données directement sur des satoshis individuels.
SegWit a rendu moins cher le stockage des données witness, et Taproot a supprimé la limite de taille sur les pushes de données dans les scripts de transaction. Combinés, ces changements ont permis aux utilisateurs d'intégrer des images, du texte et même des jeux vidéo dans la blockchain Bitcoin. Ce n'était pas l'intention spécifique des développeurs qui ont écrit ces BIPs.
Ce développement a déclenché un débat féroce au sein de la communauté. Certains voient les inscriptions comme du spam qui congestionne le réseau, tandis que d'autres y voient un usage légitime de l'espace de bloc payé par des frais. Indépendamment du point de vue, les Ordinals démontrent que une fois une proposition implémentée, les utilisateurs du réseau utiliseront les nouvelles règles de manières que les auteurs n'avaient peut-être jamais anticipées.
Conclusion
L'anatomie d'une proposition de protocole Bitcoin révèle un système qui priorise la survie avant tout. De la rédaction initiale d'un BIP au processus épuisant de construction d'un rough consensus, chaque étape est conçue pour filtrer les risques. La distinction entre soft forks et hard forks illustre un engagement envers la compatibilité rétroactive, assurant que le réseau reste inclusif même en avançant.
Des mises à niveau comme SegWit et Taproot montrent que Bitcoin peut innover sans sacrifier ses principes fondamentaux. Pendant ce temps, les débats en cours autour d'OP_CAT et l'émergence des Ordinals prouvent que l'écosystème reste vibrant et imprévisible. L'interaction entre mineurs, développeurs et opérateurs de nœuds crée un système de contrôles et contrepoids qu'aucune entité centralisée ne peut outrepasser.
Bitcoin change lentement non pas parce qu'il ne peut pas aller vite, mais parce que le coût de le casser est trop élevé pour être risqué.