Résumé des nouveaux développements technologiques ayant provoqué une nouvelle flambée du bitcoin
TechFlow SélectionTechFlow Sélection
Résumé des nouveaux développements technologiques ayant provoqué une nouvelle flambée du bitcoin
Le problème de conflit entre l'application à grande échelle et les capacités que le Bitcoin devrait posséder a toujours existé dans la technologie d'origine du Bitcoin.
Dédié à des analyses Web3 approfondiesRédaction : Fu Shaoqing, SatoshiLab, Île des Mille Choses Studio BTC
1. Explorations et conflits techniques initiaux du Bitcoin
Les technologies d'origine du Bitcoin ont toujours été confrontées à un conflit entre son application à grande échelle et les capacités qu'il devrait posséder. Une utilisation massive et une augmentation du volume des transactions impliquent-elles nécessairement des instructions de transaction plus complexes et un espace transactionnel accru ? Cela signifie-t-il qu'il faille absolument intégrer toutes les fonctionnalités dans un système unique comme celui du Bitcoin ? Au début, avec un écosystème technique encore immature, ces phénomènes semblaient tous être des problèmes inhérents au Bitcoin lui-même. À mesure que la technologie progresse, de nombreuses questions trouvent désormais des réponses plus claires.
Dans cet article, nous examinons certains problèmes clés ainsi que leur genèse et leurs solutions. Grâce à cette analyse, il est possible de comprendre les liens entre ces enjeux et les technologies associées, ainsi que l’évolution de la chaîne principale du Bitcoin et des différentes « chaînes-test » connexes. Les technologies du Bitcoin sont continuellement explorées par divers projets et équipes (y compris Ethereum, qui constitue une exploration face aux limites du Bitcoin), bien que les changements sur le réseau principal soient longtemps restés peu visibles. Ce n’est que grâce à l’apparition de technologies telles que Taproot, et par la suite des protocoles comme Ordinals, que le Bitcoin est entré dans une nouvelle phase de développement intense.
En observant l’ensemble de ce processus évolutif et des technologies qui en découlent, on peut identifier leurs interconnexions et anticiper davantage de directions futures ainsi que l’architecture globale.
1.1. Le langage de script du Bitcoin et les suppressions d’instructions
Le langage de programmation du Bitcoin est un langage de script utilisant la notation polonaise inverse, dépourvu d’instructions de boucle ou de contrôle conditionnel (bien que Taproot et Taproot Script aient étendu cette capacité). Ainsi, on dit couramment que le langage de script du Bitcoin n’est pas Turing-complet, ce qui impose certaines limitations.
Ces limitations empêchent toutefois les pirates d’écrire des boucles infinies (qui pourraient paralyser le réseau) ou des codes malveillants susceptibles de provoquer des attaques par déni de service (DoS), évitant ainsi les surcharges du réseau. Les développeurs du Bitcoin considèrent également qu’une blockchain fondamentale ne devrait pas être Turing-complète afin d’éviter ces risques.
Cependant, ces mêmes limitations rendent impossible l’exécution de programmes complexes sur le réseau Bitcoin, limitant sa capacité à accomplir des fonctions « utiles ». D’autres blockchains ultérieures, conçues pour répondre à des besoins spécifiques, ont directement contourné cette contrainte. Par exemple, le langage utilisé par Ethereum est Turing-complet.
Types courants d'instructions de script Bitcoin :
Mots-clés :
1. Constantes. Ex. : OP_0, OP_FALSE
2. Contrôle de flux. Ex. : OP_IF, OP_NOTIF, OP_ELSE, …
3. Pile. Ex. : OP_TOALTSTACK (déplace l’entrée vers le sommet de la pile secondaire et la supprime de la pile principale), …
4. Chaînes de caractères. Ex. : OP_CAT (concatène deux chaînes, désactivé), OP_SIZE (empile la taille de la chaîne située au sommet sans l’enlever)
5. Logique bit à bit. Ex. : OP_AND, OP_OR, OP_XOR
6. Logique arithmétique. Ex. : OP_1ADD (ajoute 1 à la valeur d’entrée), OP_1SUB (soustrait 1 à la valeur d’entrée)
7. Cryptographie. Ex. : OP_SHA1 (hache l’entrée via SHA-1), OP_CHECKSIG ()
8. Pseudo-mots-clés
9. Mots-clés réservés
Types courants de scripts Bitcoin :
Scripts :
1. Transaction standard vers adresse Bitcoin (pay-to-pubkey-hash)
2. Transaction standard de création Bitcoin (pay-to-pubkey)
3. Sorties prouvées non dépensables / effaçables
4. Sorties Anyone-Can-Spend
5. Transactions basées sur des énigmes
Les cinq types standards de scripts de transaction incluent : paiement vers hachage de clé publique (P2PKH), paiement vers clé publique, signatures multiples (limitées à 15 clés maximum), paiement vers hachage de script (P2SH), et sortie de données (OP_RETURN).
Pour plus de détails, consulter : https://en.bitcoin.it/wiki/Script
Suppressions d'instructions supportées par Bitcoin
Bitcoin a connu plusieurs suppressions d'instructions au fil de son histoire. Dans les tableaux ci-dessous, les parties rouges indiquent les instructions supprimées.
(1) Opérations sur chaînes de caractères
(2)
(3) Opérations arithmétiques
Pourquoi supprimer des instructions ? La sécurité n’est qu’un aspect. En adoptant une approche de conception en couches, la suppression apparaît comme une décision rationnelle permettant de rendre le protocole de base plus simple et plus stable. Peut-être que Nakamoto avait déjà conscience de cela, expliquant pourquoi il a volontairement supprimé certaines instructions. Contrairement à la pensée commune qui vise à construire un petit système autonome doté d'instructions complètes répondant directement aux besoins des utilisateurs, la conception d'un grand protocole nécessite collaboration et modularité.
Cela aboutit à un constat : seul Bitcoin convient comme couche 1. Comme analysé dans mon article « Un prix élevé du Bitcoin favoriserait l'émergence d'une chaîne alternative », il existe potentiellement des alternatives au Bitcoin, tant du point de vue économique que technique. Toutefois, compte tenu des caractéristiques fondamentales du Bitcoin et de sa conception en couches, aucun autre acteur ne peut véritablement rivaliser avec lui comme infrastructure de base. Toute alternative ne serait alors qu’un produit de niveau 1.5, voire une copie approximative — si Bitcoin est l’original, les autres chaînes ne seraient guère plus que des contrefaçons.
1.2. Histoire des forkings du Bitcoin, causes et significations
Outre les suppressions d'instructions, un autre sujet majeur dans l’histoire du Bitcoin concerne la controverse sur la taille des blocs, source fréquente de hard forks.
Au lancement du BTC, aucune limite de taille de bloc n’était fixée afin de traiter un nombre maximal de transactions simultanément. Mais lorsque le prix du BTC était très bas, le coût des transactions malveillantes l’était aussi. Pour y remédier, Nakamoto a supervisé un soft fork le 12 septembre 2010, imposant une limite de 1 Mo par bloc. Il précisa toutefois que cette restriction était temporaire, et pourrait être augmentée progressivement selon les besoins de mise à l’échelle.
Voici l’historique des forkings du Bitcoin :
Avec la popularité croissante du Bitcoin, les congestions réseau et les délais de confirmation se sont aggravés. En 2015, Gavin Andresen et Mike Hearn annoncèrent leur intention d’intégrer la proposition BIP-101 dans BitcoinXT, prévoyant d’augmenter la limite à 8 Mo. Cette initiative fut rejetée par des développeurs clés tels que Greg Maxwell, Luke Jr et Pieter Wuille, qui craignaient une hausse du seuil requis pour exécuter un nœud complet, entraînant des conséquences incontrôlables. Ce débat s’est rapidement étendu à des cercles plus larges.
Comme mentionné précédemment, Nakamoto avait indiqué que la limite de taille était temporaire et pouvait être relevée progressivement. Mais quand faut-il procéder à un forking pour supporter des blocs plus grands ? Créer une chaîne séparée avec de plus gros blocs suffit-il à résoudre le problème ? Ces questions ont suscité de nombreux cas concrets. Par exemple, BCH a une taille de bloc de 8 Mo, portée ensuite à 32 Mo ; BSV atteint 128 Mo. Outre BCH (et ultérieurement BSV), cette période a vu naître de nombreuses autres variantes du BTC. Selon BitMEXResearch, au moins 50 nouvelles chaînes issues de forkings sont apparues dans l’année suivant le fork de BCH.
Nous verrons plus tard que SegWit et Taproot ont également permis, dans une certaine mesure, d’augmenter l’espace disponible par bloc sur la chaîne principale, passant effectivement de 1 Mo à 4 Mo.
Les forkings du Bitcoin représentent une forme d’exploration, cherchant à s’adapter aux besoins croissants. Ils reflètent des intérêts variés : utilisateurs, mineurs, investisseurs, développeurs, etc.
1.3. Quelques explorations emblématiques dans l’évolution du Bitcoin
Après le départ de Nakamoto, Gavin Andresen, son successeur, a dirigé la création de Bitcoin Core et de la Fondation Bitcoin. Depuis lors, des explorations autour de l’évolutivité du BTC ont eu lieu, notamment dans le domaine de l’émission d’actifs.
(1) Colored Coins (« pièces colorées »)
Le PDG d’eToro, Yoni Assia, a introduit le concept de « pièces colorées » dans un article publié le 27 mars 2012. L'idée s'est développée sur des forums comme Bitcointalk, jusqu’à ce que Meni Rosenfeld publie, le 4 décembre 2012, un livre blanc détaillé sur les colored coins.
L'idée consiste à marquer certaines parties du Bitcoin afin de représenter d'autres actifs ou valeurs. Deux grandes catégories d'implémentations sont apparues :
1) Basé sur OP_RETURN : Open Assets, proposé par Flavien Charlon en 2013, utilise OP_RETURN (introduit dans Bitcoin v0.9.0, permettant d’inscrire de petites données, initialement limitées à 40 octets, puis à 80). Les données sont stockées dans le script et lues par des systèmes externes pour réaliser le « coloriage » et les transferts (approche similaire à Ordinals, où la validité des actifs est déterminée par indexation externe).
2) Basé sur OP_RETURN : EPOBC Protocol, lancé par ChromaWay en 2014. Les informations supplémentaires des actifs EPOBC sont stockées dans le champ nSequence des transactions Bitcoin. La catégorie et la validité de chaque actif doivent être retracées depuis la transaction initiale (genesis).
(2) MasterCoin (OMNI)
JR Willett a présenté MasterCoin le 6 janvier 2012, qualifié de « deuxième livre blanc du Bitcoin ». Le projet a été officiellement lancé en juillet 2013 via un ICO, levant 5120 BTC (alors 500 000 USD). Contrairement aux colored coins, MasterCoin repose sur une couche complète de nœuds qui scanne les blocs Bitcoin pour maintenir une base de données d’état, hébergée en dehors de la blockchain. Cette architecture permet des fonctionnalités avancées : création d’actifs, bourse décentralisée, mécanismes automatiques de fixation des prix, etc. En 2014, Tether a utilisé le protocole Mastercoin pour émettre sa stablecoin sur Bitcoin, connue sous le nom de Tether USD (OMNI).
(3) Counterparty
Counterparty a été lancé en 2014. Il utilise également OP_RETURN pour stocker des données sur le réseau BTC. Contrairement aux colored coins, les actifs n’existent pas sous forme UTXO, mais sont transférés via des signatures sur des transactions contenant des données spécifiques. Cette méthode permet d’émettre et d’échanger des actifs, et même de proposer une plateforme compatible avec les contrats intelligents d’Ethereum.
Certains considèrent également Ethereum, Ripple et BitShares comme faisant partie d’un concept élargi de « Bitcoin 2.0 ».
1.4. Les imperfections du Bitcoin et la conception en couches
Les lacunes perçues du Bitcoin (ou ses limitations) peuvent être regroupées en plusieurs points (selon la synthèse du livre blanc d’Ethereum, sans pour autant refléter des défauts réels).
1. Le système de comptes UTXO du Bitcoin
Dans les projets blockchain actuels, deux modèles dominent : le modèle solde/compte et le modèle UTXO. Bitcoin utilise ce dernier, tandis qu’Ethereum, EOS, etc., utilisent le premier.
Bien que les portefeuilles Bitcoin affichent un solde, le système originel de Nakamoto ne connaît pas ce concept. Ce « solde » est une abstraction créée par les applications. L’UTXO (Unspent Transaction Output) est un concept central dans la génération et la vérification des transactions. Toutes les transactions légitimes peuvent être tracées jusqu’à une ou plusieurs sorties antérieures, dont les origines remontent aux récompenses de minage, et dont les extrémités sont les UTXO actuels non dépensés.
Ainsi, dans le monde réel, il n’y a pas de Bitcoin, seulement des UTXO. Chaque transaction consomme une entrée et crée une sortie, cette dernière devenant un nouvel UTXO.
L’utilisation d’UTXO pose de graves problèmes pour les contrats intelligents. Gavin Wood, concepteur du Yellow Paper d’Ethereum, comprenait profondément cette limite. Étant donné que les contrats intelligents étaient une nouveauté majeure, implémenter un langage Turing-complet sur UTXO s’avérait difficile. Le modèle de compte, naturellement orienté objet, enregistre chaque transaction via un nonce incrémenté. Un état global est introduit pour simplifier la gestion des comptes, chaque transaction modifiant cet état — ce qui correspond mieux à notre réalité physique. C’est pourquoi Ethereum a adopté ce modèle, suivi par la plupart des blockchains ultérieures.
Un autre défaut majeur de l’UTXO est son incapacité à offrir un contrôle fin du montant pouvant être retiré d’un compte, comme souligné dans le livre blanc d’Ethereum.
2. Langage de script non Turing-complet
Bien que le script Bitcoin prenne en charge plusieurs calculs, il ne peut pas tout exécuter. L’absence de boucles et de conditions en fait un langage non Turing-complet, limitant ses capacités. Cette limitation empêche les hackers d’écrire des boucles infinies ou du code malveillant causant des attaques DoS. Les développeurs jugent donc préférable qu’une blockchain fondamentale ne soit pas Turing-complète, pour éviter les blocages. Cependant, cela empêche aussi d’exécuter des programmes complexes. L’interdiction des boucles vise à éviter les boucles infinies durant la validation.
La justification par la sécurité pour refuser la complétude Turing n’est pas entièrement convaincante. Un langage non Turing-complet reste fortement limité dans ses possibilités.
3. Autres imperfections : sécurité et extensibilité
Problème de centralisation minière : l’algorithme de minage consiste à modifier légèrement l’en-tête du bloc jusqu’à obtenir un hachage inférieur à une cible. Ce processus est vulnérable à deux formes de centralisation. Premièrement, les ASICs (circuits intégrés spécialisés) sont des milliers de fois plus efficaces pour miner le Bitcoin, rendant l’activité inaccessible aux petits acteurs. Deuxièmement, la majorité des mineurs ne valident plus localement les blocs, mais dépendent de pools centralisés. Ce problème est grave : les trois plus grands pools contrôlent indirectement environ 50 % de la puissance de calcul du réseau.
La scalabilité est un autre défi majeur. Le réseau Bitcoin croît d’environ 1 Mo par heure. S’il devait traiter 2000 transactions/seconde comme Visa, il grossirait de 1 Go/h, soit 8 To/an. Le faible débit de transactions alimente les controverses au sein de la communauté, car des blocs plus grands améliorent les performances mais augmentent les risques de centralisation.
Du point de vue du cycle de vie d’un produit, certaines imperfections mineures du Bitcoin pourraient être corrigées dans le système existant, mais ces améliorations sont limitées par l’architecture actuelle. Si elles peuvent être résolues dans un nouveau système, on peut ignorer ces contraintes. Dès lors, concevoir une nouvelle blockchain permet d’intégrer dès le départ ces améliorations fonctionnelles.
Conception en couches
La conception en couches est une méthodologie humaine pour gérer les systèmes complexes. En divisant un système en niveaux fonctionnels interconnectés, on améliore sa modularité, sa maintenabilité et son extensibilité, accroissant ainsi l’efficacité et la fiabilité de la conception.
Pour un protocole vaste et complexe, cette approche présente des avantages manifestes : elle facilite la compréhension, la division du travail et les améliorations modulaires. Par exemple, le modèle OSI comporte sept couches, bien que dans la pratique, certaines soient fusionnées (comme TCP/IP, qui en utilise quatre). Les avantages incluent : indépendance entre couches, flexibilité, segmentation structurelle, facilité d’implémentation, maintenance aisée et promotion de la standardisation.
Du point de vue de la conception en couches, le fait que Bitcoin occupe la couche fondamentale signifie que ses caractéristiques — UTXO, absence de complétude Turing, temps de bloc long, petite taille de bloc, disparition du créateur — ne sont pas des défauts, mais des attributs essentiels à une infrastructure de base.
Note : l’auteur fournit une explication plus détaillée de la conception en couches dans « Un guide pour comprendre l’écosystème des couches 2 du Bitcoin – Version 1.5 ».
2. Nouvelles technologies importantes dans l’évolution du Bitcoin (extension de bloc et extension des capacités)
Dans la section précédente, nous avons exploré les conflits techniques initiaux et quelques cas d’exploration, souvent aboutissant à des hard forks ou à de nouvelles blockchains hétérogènes. Sur la blockchain Bitcoin elle-même, ces explorations ont également porté leurs fruits, essentiellement sous forme d’extension de bloc et d’amélioration des capacités, notamment :
2.1. OP_RETURN
Les développeurs du Bitcoin ont cherché à étendre ses capacités de plusieurs manières :
(1) Utilisation de OP_RETURN
OP_RETURN est un opcode de script destiné à terminer l’exécution et renvoyer la valeur au sommet de la pile, similaire à une instruction return dans un langage de programmation. Historiquement, son fonctionnement a été modifié plusieurs fois. Aujourd’hui, il sert principalement à stocker des données arbitraires sur la blockchain.
À l’origine, OP_RETURN servait à interrompre prématurément l’exécution du script. Un bogue exploitable a été rapidement corrigé par Nakamoto.
Évolutions ultérieures de OP_RETURN :
Lors de la mise à jour v0.9.0 de Bitcoin Core, les sorties OP_RETURN sont devenues un type standard, permettant d’attacher des données à des sorties non dépensables. La taille maximale des données était initialement limitée à 40 octets, puis portée à 80.
Stockage de données sur la blockchain :
Le fait que OP_RETURN retourne toujours false a conduit à un usage inattendu : puisque les opcodes suivants ne sont pas évalués, les utilisateurs ont commencé à y insérer des données arbitraires.
Sur Bitcoin Cash (BCH), entre le 1er août 2017 et le 15 novembre 2018, la taille autorisée pour OP_RETURN a été étendue à 220 octets, favorisant des innovations comme la publication de contenus sur une blockchain sociale.
Sur BSV, cette limite de 220 octets a été brièvement conservée. Puis, en janvier 2019, les opérateurs de nœuds ont décidé d’augmenter la taille maximale de transaction à 100 Ko, car OP_RETURN met fin au script sans vérifier la taille totale (limite habituelle de 520 octets). Cela a donné plus de liberté aux développeurs, permettant par exemple d’archiver un site web entier dans le registre BSV.
Malgré ces extensions, OP_RETURN reste limité. D’où l’émergence de SegWit.
(2) SegWit (Witness isolé)
SegWit (Segregated Witness), proposé par Pieter Wuille (développeur Bitcoin Core et cofondateur de Blockstream) en décembre 2015, est devenu le BIP 141. Il modifie légèrement la structure des données des transactions pour résoudre plusieurs problèmes :
1) Problème de malléabilité des transactions.
2) Rend optionnel le transfert de la signature dans les preuves SPV, réduisant la quantité de données dans les preuves Merkle.
3) Augmente effectivement la capacité des blocs.
Les deux premiers points concernent la sécurité et les performances. Le troisième a le plus grand impact : l’augmentation effective de la capacité des blocs (via le concept de « poids du bloc ») a jeté les bases de l’extension des capacités du Bitcoin, préparant le terrain à Taproot (SegWit version 2).
Bien que SegWit augmente la capacité, il reste soumis à des limites. Initialement, les blocs étaient limités à 1 Mo. Les données de witness étant exclues de cette limite, celle-ci a été remplacée par un nouveau concept : le poids du bloc (Block weight) :
Poids du bloc = Taille de base × 3 + Taille totale
Taille de base : taille du bloc sans les données de witness.
Taille totale : taille du bloc sérialisé selon BIP 144, incluant données de base et de witness.
La limite de poids du bloc est fixée à ≤ 4 Mo.
SegWit a également permis techniquement le développement du réseau Lightning. Nous n’aborderons pas ici ce point en détail.
(3) Taproot : SegWit version 2
Beaucoup perçoivent Taproot comme un concept nouveau, mais il s’agit en réalité de la deuxième version de SegWit. Les BIP associés sont 340, 341 et 342 : BIP 340 (Signatures Schnorr pour secp256k1), BIP 341 (Taproot : règles de dépense SegWit v1), BIP 342 (Validation des scripts Taproot).
En novembre 2021, Taproot a été activé via un soft fork. Cette mise à jour combinée introduit : BIP 340 avec les signatures Schnorr, remplaçant ECDSA, permettant de valider plusieurs transactions simultanément, augmentant la capacité du réseau et la vitesse des transactions groupées, ouvrant la voie à des contrats intelligents complexes ; BIP 341 avec l’arbre syntaxique abstrait Merkellisé (MAST), optimisant le stockage des données ; BIP 342 (Tapscript), étendant les capacités natives du langage de script du Bitcoin.
Grâce à l’extension d’espace permise par SegWit et Taproot, les technologies Schnorr, MAST et Taproot Scripts ont vu le jour, élargissant fondamentalement les fonctionnalités de la chaîne principale du Bitcoin.
2.2. Schnorr, MAST, Taproot Scripts
Comme vu dans la section 2.1, les efforts constants du Bitcoin pour s’étendre ont abouti à Taproot et à des technologies clés comme Schnorr, MAST et Taproot Scripts, ouvrant véritablement de nouvelles perspectives.
(1) Signature Schnorr
Le développement de Taproot a exigé une nouvelle approche des signatures, conduisant à l’adoption des signatures Schnorr, remplaçant ECDSA. Proposées par Claus Schnorr en 1991, ces signatures sont appréciées pour leur simplicité, leur sécurité prouvée et leur linéarité.
Avantages des signatures Schnorr :
1) Haute efficacité, meilleure confidentialité, tailles de signature réduites, validation plus rapide, résistance accrue à certaines attaques, tout en conservant les fonctionnalités et hypothèses de sécurité d’ECDSA.
2) Agrégation de clés : plusieurs signatures peuvent être combinées en une seule, valide pour la somme des clés publiques. Cela permet de fusionner plusieurs signatures en une seule, occupant le même espace qu’une signature unitaire, réduisant ainsi les frais et améliorant l’évolutivité (notamment pour les canaux Lightning).
3) Immuabilité : protection contre la modification des signatures.
4) Confidentialité accrue : les multisignatures deviennent indiscernables des signatures simples. Dans un schéma n-sur-m, il devient plus difficile d’identifier quels participants ont signé.
Implémentées via BIP-340, les signatures Schnorr ont été activées le 14 novembre 2021 au bloc 709 63
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Waterdrip Capital
