Ce qui manque au bitcoin, et à qui confier son ajout

Curiosité

1. Pourquoi Bitcoin n’a-t-il aucun équivalent de l’« approbation » de tokens ?
2. Que perd-on lorsqu’un langage de script devient assez expressif pour compiler n’importe quel programme ?
3. Comment un marché peut-il exister sans une partie centrale qui détienne les clés ou fixe les règles ?

Explorer

Partie ICe que Bitcoin élimine déjà, et ce qui lui manque

1. Bitcoin élimine l’administrateur. Il n’y a pas de clés d’administration, pas d’approbations de tokens et pas de contrats évolutifs. L’émission est plafonnée à 21 millions de pièces et suit un calendrier prévisible, la subvention étant divisée par deux (halving) tous les 210 000 blocs. Les règles ne peuvent être modifiées que par un large consensus entre des milliers de nœuds indépendants. Cette conception élimine toute une catégorie d’attaques présentes dans d’autres systèmes : s’il n’y a ni clé à voler ni contrat à mettre à jour, il n’y a rien qu’un administrateur puisse exploiter ni qu’une entreprise puisse saisir.
2. Le modèle UTXO rend chaque dépense explicite. Une transaction consomme des sorties précédentes précises et en crée de nouvelles. Il n’existe pas de soldes de compte qu’un contrat pourrait débiter ultérieurement. Cette structure empêche les approbations de type « drainer », où un utilisateur signe une autorisation générale permettant à une autre partie de déplacer plus tard des fonds sans limite. Avec le type de signature par défaut (SIGHASH_ALL), la signature engage exactement ces entrées et ces sorties ; d’autres modes de signature peuvent laisser les sorties ouvertes, et des arnaques les ont exploités. Si l’utilisateur ne signe pas la transaction suivante, rien ne bouge.
3. Ce qui manque à Bitcoin, c’est l’expressivité et la vitesse. Le script est délibérément limité : il ne peut pas effectuer de calculs arbitraires ni boucler indéfiniment. Les blocs arrivent environ toutes les dix minutes, ce qui rend le règlement lent par rapport aux chaînes qui produisent des blocs en quelques secondes. Le protocole de la couche de base n’offre aucune prise en charge native des tokens ni des marchés. Ces contraintes sont des compromis délibérés : limiter les capacités du script empêche que des bugs ne deviennent des exploits capables de briser le consensus, et des blocs plus lents permettent une validation robuste par un réseau décentralisé de nœuds complets.
4. La question de conception est de savoir comment ajouter des marchés sans réintroduire les faiblesses que Bitcoin a évitées. Ajouter un langage de script complexe ouvre la porte aux vulnérabilités des smart contracts. Ajouter des blocs rapides exige souvent une centralisation ou des validateurs autorisés pour assurer la finalité. Introduire des tokens natifs peut créer de nouvelles surfaces d’attaque propices à l’inflation ou à la manipulation. Toute extension doit préserver la propriété selon laquelle aucune entité unique ne contrôle l’émission ou les règles de l’actif, même si cela implique d’accepter un règlement plus lent ou des frais plus élevés.
5. Les solutions de couche 2 et les métaprotocoles tentent de combler cet écart. Ils ajoutent des fonctionnalités comme les paiements rapides ou l’émission de tokens, tout en ancrant leur sécurité dans le consensus de Bitcoin. Cependant, ces couches introduisent de nouveaux modèles de confiance : certaines reposent sur des fédérations de signataires, d’autres sur des jeux de vérification optimistes où au moins un opérateur honnête doit contester la fraude. Chaque approche arbitre différemment entre décentralisation et vitesse. L’objectif n’est pas de faire de Bitcoin un ordinateur généraliste, mais d’étendre son utilité sans compromettre le modèle de sécurité fondamental qui l’a rendu résilient.
6. Ouvrez un explorateur de blocs et recherchez n’importe quelle transaction récente. Examinez les entrées et les sorties. Notez comment chaque entrée fait référence à une sortie précédente précise par son ID de transaction et son index. Comparez maintenant avec une chaîne fondée sur des comptes, où les soldes ne sont que des nombres dans un état global. La différence est structurelle : le modèle de Bitcoin oblige chaque mouvement de valeur à être explicite, auditable et lié à une signature précise, sans laisser de place à des contournements administratifs cachés ni à des autorisations générales.

Partie IILes couches 2 de Bitcoin et leurs modèles de confiance

7. Les canaux du Lightning Network étendent les capacités de paiement de Bitcoin sans confier les pièces à un dépositaire. Le livre blanc de Joseph Poon et Thaddeus Dryja a été rédigé pour la première fois en 2015 et publié dans sa version définitive en 2016 ; l’utilisation sur le mainnet a suivi en 2018. Chaque canal verrouille des fonds dans un état partagé entre deux parties ; si l’une triche, l’autre diffuse une transaction de pénalité sur Bitcoin. Ce modèle minimise la confiance, car aucun tiers ne détient les clés, mais il reste de point à point. Il résout la finalité des paiements, pas la liquidité partagée ni la tenue de marché.
8. Liquid, lancé par Blockstream en 2018, fonctionne comme une sidechain fédérée. Un groupe fixe de « functionaries » signe les blocs et gère le peg entre les actifs Liquid et le bitcoin de la couche de base. Un bloc est produit chaque minute et atteint la finalité en environ deux minutes, et des actifs peuvent être émis nativement. Le compromis est explicite : les utilisateurs doivent faire confiance à une supermajorité de functionaries (le peg utilise une multisignature 11 sur 15) pour ne pas s’entendre afin de voler les dépôts ou de bloquer les retraits. C’est rapide, mais cela réintroduit un groupe de confiance.
9. Stacks fait tourner sa propre chaîne, ancrée à Bitcoin en inscrivant les hashs de ses blocs dans des transactions Bitcoin (Proof of Transfer). Son peg sBTC, ouvert aux dépôts depuis décembre 2024 et aux retraits depuis avril 2025, émet des tokens adossés à des bitcoins natifs verrouillés, gérés par un ensemble de signataires. Cette approche permet des smart contracts expressifs sur Stacks (en Clarity, un langage délibérément décidable), tandis qu’un ensemble de signataires, dont un seuil doit approuver les retraits, détient les bitcoins. Les utilisateurs échangent la flexibilité d’exécution contre une dépendance à l’intégrité de l’ensemble de signataires et à la continuité opérationnelle du pont.
10. BitVM représente un choix architectural différent, qui vise à apporter le calcul généraliste à Bitcoin sans soft fork. La proposition de Robin Linus en 2023 utilisait une vérification optimiste entre deux parties ; BitVM2 (2024) permet à n’importe qui de contester. Des projets comme Citrea, en service depuis janvier 2026, s’appuient sur ce modèle, dans lequel un seul participant honnête parmi de nombreux autres peut arrêter la fraude. Ce modèle d’« honnêteté 1-sur-n » fait passer la confiance d’un consensus majoritaire à la présence d’un seul contestataire vigilant, mais les opérateurs doivent immobiliser ou avancer des capitaux, et les retraits doivent attendre la fin des périodes de contestation.
11. La comparaison de ces modèles révèle des profils de risque distincts. Lightning ne nécessite aucune tierce partie mais offre une utilité limitée pour les marchés partagés. Liquid et Stacks dépendent de fédérations ou d’ensembles de signataires où la collusion constitue la principale menace. Les rollups BitVM reposent sur l’honnêteté concurrentielle entre les opérateurs. La variable cruciale dans tous les cas est la garde des clés : qui détient les clés privées du bitcoin sous-jacent, et que se passe-t-il si cette entité échoue, est piratée ou décide de frauder ?
12. Les mécanismes de sortie définissent le véritable modèle de confiance. Sur Lightning, sortir signifie fermer le canal sur la chaîne ; si l’autre partie ne répond pas, les fonds reviennent après l’expiration d’un timelock. Sur Liquid ou Stacks, sortir nécessite une demande de rachat traitée par la fédération ou les signataires ; s’ils tardent ou refusent, les utilisateurs restent bloqués. Pour les ponts BitVM, la sortie repose sur au moins un opérateur actif qui paie l’utilisateur ; les demandes de remboursement des opérateurs font ensuite l’objet d’une période de contestation. Un utilisateur qui ne peut pas sortir sans faire confiance à un tiers n’est pas réellement en auto-conservation, quel que soit le degré de décentralisation apparent du réseau.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• S. Nakamoto, 'Bitcoin: A Peer-to-Peer Electronic Cash System' (2008)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• BIP-341: Taproot (activated 2021)
• J. Poon & T. Dryja, 'The Bitcoin Lightning Network' (2016)
• Blockstream Liquid Documentation
• Stacks sBTC Technical Documentation (December 2024)
• R. Linus, 'BitVM: Compute Anything on Bitcoin' (2023)