Décryptage du BitVM : l'aube de la programmabilité du Bitcoin
TechFlow SélectionTechFlow Sélection
Décryptage du BitVM : l'aube de la programmabilité du Bitcoin
Bien que BitVM en soit encore à un stade préliminaire, étant essentiellement un concept de machine virtuelle non encore concrétisé, il a déjà suscité un grand intérêt et de nombreuses déclarations de la part de divers projets.
Dédié à des analyses Web3 approfondiesRédaction : IOSG Ventures
*Remerciements : Merci à Momir et Xinshu pour leurs précieux commentaires et suggestions sur cet article
TL;DR
-
Les modifications au noyau de Bitcoin sont généralement résistées pour plusieurs raisons : a) une préférence pour utiliser Bitcoin comme réserve de valeur plutôt que comme monnaie ; b) une priorité donnée à la stabilité et à la prévisibilité plutôt qu’à l’innovation rapide ; c) la difficulté d’atteindre un consensus au sein d’une communauté diversifiée.
-
De nombreux projets affirment avoir des solutions pour résoudre les problèmes d’évolutivité de Bitcoin sans nécessiter de modification de la chaîne principale. Récemment, nous avons assisté à une véritable inflation de « L2 » Bitcoin.
-
Bien que bon nombre de ces affirmations soient trompeuses ou purement marketing, nous reconnaissons l’émergence d’un nouveau paradigme computationnel susceptible d’apporter la programmabilité à Bitcoin : BitVM.
-
La meilleure solution d’évolutivité prise en charge par BitVM repose sur des hypothèses de sécurité similaires à celles des OP-Rollups (avec toutefois certaines nuances supplémentaires).
-
Le succès de BitVM et d’initiatives similaires dépendra de la faisabilité technique, du soutien communautaire, et de la capacité à se distinguer des projets « surexploités marketing ».
Bitcoin a été conçu comme une blockchain de transactions, dont le langage de script est intentionnellement sans état (stateless), afin de minimiser la surface d’attaque et garantir la sécurité du réseau. En raison de son absence de complétude Turing, il n’est pas possible d’introduire directement des contrats intelligents sur la blockchain sans procéder à un fork et mettre à jour le noyau Bitcoin.
La communauté traditionnelle de Bitcoin résiste aux changements pour plusieurs raisons :
Une narration axée sur la réserve de valeur plutôt que sur la monnaie circulante : La communauté Bitcoin privilégie délibérément la préservation du réseau comme système de paiement pair-à-pair, en mettant la sécurité et la décentralisation avant une innovation accélérée. Comme l’a dit Michael Saylor, célèbre détenteur de Bitcoin : « Personne n’essaie d’acheter un café avec une fraction d’un immeuble sur la Cinquième Avenue. » Cette phrase reflète bien la préférence de la communauté pour considérer Bitcoin comme un outil de stockage de valeur plutôt que comme une monnaie quotidienne.
-
La stabilité du système prime sur l’innovation : Pour un actif perçu comme une excellente réserve de valeur, la prévisibilité est essentielle. Par exemple, même si le réseau ne connaissait que 10 mises à niveau majeures, chacune ayant un taux de réussite de 90 %, la probabilité d’au moins un échec serait d’environ 65 % ! Selon la théorie des accidents normaux : « Dans les systèmes complexes, on doit s’attendre à ce que des facteurs mineurs, habituellement négligeables, provoquent occasionnellement des événements majeurs ». Ainsi, la communauté Bitcoin vise à réduire autant que possible les voies potentielles d’erreur.
Une communauté diversifiée : De nombreux détenteurs de Bitcoin interprètent celui-ci sous différents angles et l’apprécient pour des raisons variées. Atteindre un consensus au sein d’une communauté décentralisée et hétérogène est intrinsèquement difficile, ce qui ralentit encore davantage l’innovation. Pour illustrer cette diversité, il suffit d’observer les réactions divergentes face aux inscriptions et aux Ordinals. Alors qu’une partie de la communauté célèbre le succès des ordinaux, les voyant comme le moment « CryptoKitties » de Bitcoin, une autre partie les considère comme un bug devant être corrigé.
1. L’inflation rapide des solutions d’évolutivité Bitcoin
Étant donné ce contexte, pourquoi assistons-nous soudainement à un afflux massif de nouvelles solutions « L2 » Bitcoin ?
Récemment, nous avons observé une explosion des solutions dites « L2 » Bitcoin (selon https://l2.watch/, plus de 50 existent déjà !). Pourtant, la communauté explore depuis des années différentes approches d’évolutivité :
-
Des sidechains comme Stacks offrent des capacités de contrats intelligents et un large éventail d’applications, bien qu’avec un mécanisme de consensus indépendant, difficile à faire accepter largement.
-
Des projets basés sur la validation client comme RGB exploitent le modèle UTXO de la chaîne principale pour effectuer des transactions complexes hors chaîne, mais leur interaction avec la chaîne principale manque de stabilité.
-
Des canaux d’état comme le réseau Lightning, étroitement lié aux développeurs principaux de Bitcoin, sont considérés comme une méthode d’évolutivité plus orthodoxe.
Première génération de solutions d’évolutivité BTC
Par rapport aux solutions existantes, quelle nouveauté apportent les méthodes récentes d’évolutivité ? À nos yeux, les innovations les plus prometteuses viennent de la possibilité de coder des programmes sur Bitcoin (via BitVM) et de staker du BTC sans confiance (par exemple via Babylon). Cet article se concentrera principalement sur la première.
2. BitVM - Aperçu général
Pour expliquer ce qu’est BitVM, nous devons d’abord présenter la primitive qui l’a permis et inspiré : la mise à jour Taproot de Bitcoin.
Taproot est une mise à jour majeure du protocole Bitcoin, activée en novembre 2021. Grâce à Taproot, le hachage d’un script est par défaut soumis sur la chaîne. Lorsqu’un chemin particulier du script est exécuté, seul ce chemin est révélé sur la chaîne. Cela améliore non seulement l’efficacité (la taille des transactions ne croît pas avec celle du script), mais renforce aussi la confidentialité (seul le chemin pris est révélé, pas l’ensemble du script).
Comprenant le potentiel énorme débloqué par Taproot, Robin Linus a lancé BitVM, une innovation révolutionnaire dans l’écosystème Bitcoin.
BitVM est un paradigme computationnel qui exploite la mise à jour Taproot pour permettre des contrats Turing-complets sur Bitcoin, sans modifier les règles de consensus du réseau. Il permet la vérification de calculs (plutôt que leur exécution), de manière similaire aux Optimistic Rollups.
BitVM minimise l’empreinte sur chaîne en soumettant un programme à une adresse Taproot, tout en activant des calculs complexes hors chaîne – l’exécution sur chaîne n’étant nécessaire que lors d’un litige.
Ce processus implique de soumettre le circuit binaire du programme à une adresse Taproot, puis d’utiliser un mécanisme de défi-réponse pour valider les résultats. En résumé, BitVM rend possible la création de contrats Turing-complets sur Bitcoin, et surtout :
-
BitVM ne nécessite pas de fork ni aucune modification du protocole Bitcoin.
-
BitVM n’engorge pas la blockchain Bitcoin, car les calculs ne sont pas exécutés sur Bitcoin, mais uniquement validés via le réseau en cas de litige (Dispute).
Construire des circuits binaires sur Bitcoin
La construction de circuits binaires consiste à représenter un calcul ou un programme à l’aide de portes logiques binaires (comme ET, OU, NON), capables d’exécuter toute fonction calculable.
BitVM revient à simuler de manière complexe le passage du courant à travers les portes logiques d’une puce informatique (ces petites structures qui décident, selon la présence ou non d’un courant, si un signal passe ou non — allumé ou éteint) en utilisant le langage de Bitcoin.
En essence, tout programme informatique, d’un jeu à un système d’exploitation Linux complet, résulte d’un agencement complexe de ces portes logiques. Toutes les choses numériques reposent fondamentalement sur des chiffres binaires — 0 et 1. En combinant ces chiffres binaires avec des portes logiques (comme ET et NON), nous créons divers circuits, y compris des unités logiques et arithmétiques (ALU) et des systèmes de mémoire. Cette technologie de base nous permet d’écrire et d’exécuter des programmes pour accomplir une grande variété de tâches.
Source : Stepping Through Logic Gates ; Portes logiques de base (F pour 0, T pour 1)
L’hypothèse centrale de BitVM est d’utiliser le script Bitcoin pour s’engager sur des calculs hors chaîne (en soumettant le hachage d’un calcul à une adresse Taproot), en décomposant tout programme en une combinaison de circuits binaires, et en activant la vérification d’exécution. Ce processus utilise le script Bitcoin, mais le script lui-même n’exécute pas toute la logique de calcul.
Le script Bitcoin peut réaliser des engagements sur des bits (bit-value commitments), ce qui est crucial pour pouvoir révéler et punir les comportements de contradiction (Equivocation). Il assure l’immutabilité, car il permet à une personne de soumettre une valeur que personne d’autre ne peut modifier.
Cette méthode consiste à utiliser deux hachages pour représenter chaque bit d’entrée : un hachage pour la valeur 0, un autre pour la valeur 1. Lorsqu’un utilisateur veut exécuter un programme, il révèle un antécédent (pre-image) pour indiquer l’entrée. La valeur sera convertie en 0 ou 1 selon la comparaison entre le hachage de l’antécédent et les deux hachages prédéfinis pour 0 et 1.
Si les entrées et sorties ne correspondent pas, le vérificateur a le droit de sanctionner le fournisseur en confisquant ses fonds.
Mécanisme de défi-réponse
La vérification se fait généralement hors chaîne, sous l’hypothèse optimiste que le prouveur est honnête. En cas de litige, le processus passe sur chaîne et déclenche un cycle de défi-réponse. Ce mécanisme garantit qu’en temps normal, les calculs et vérifications peuvent être effectués efficacement et à faible coût, tandis que seule une divergence nécessite d’utiliser l’immuabilité et la transparence de la blockchain pour un arbitrage final.
Le mécanisme de défi-réponse dans BitVM implique un système où des participants (par exemple Vicky et Paul) valident l’exécution d’un programme sur la blockchain. En cas de litige, Vicky met Paul au défi de prouver la justesse de son exécution.
Vicky choisit une porte logique dans le circuit binaire, et Paul ouvre cette porte en révélant ses entrées et sorties. Ce processus se répète jusqu’à ce qu’une contradiction soit confirmée ou que Vicky n’ait plus la possibilité de lancer des défis. Une contradiction signifie que Paul affirme qu’une entrée X vaut 0 dans une porte, mais 1 dans une autre.
Paul doit garantir ses affirmations en déposant des fonds via des transactions pré-signées vers une adresse de réponse. Ces transactions forment une chaîne permettant aux fonds de basculer entre adresses de défi et de réponse selon l’interaction en cours.
Les fonds dans l’adresse de réponse peuvent suivre plusieurs chemins selon le résultat du défi :
-
Si Vicky cesse de lancer des défis, indiquant qu’elle accepte la preuve de Paul, Paul récupère finalement ses fonds après un délai.
-
Si Vicky prouve que Paul a commis une incohérence (contradiction), elle peut s’approprier les fonds.
-
Si Vicky soupçonne une erreur dans une autre partie de l’exécution, elle peut lancer un nouveau défi, transférant les fonds vers la prochaine adresse de réponse. Pour cela, elle doit révéler un antécédent d’un tapleaf spécifique, que Paul devra ensuite utiliser pour débloquer les fonds et prouver sa bonne foi dans un délai limité.
Ce système fournit une architecture robuste et transparente pour résoudre les litiges et valider l’exécution de programmes sur la blockchain. En combinant des incitations financières, il favorise l’intégrité et la précision des résultats enregistrés. Initialement, cette conception supportait un mécanisme de défi-réponse à deux parties. Toutefois, comme nous le verrons plus tard, les contributeurs de BitVM ont trouvé des moyens d’autoriser de nombreux participants à agir en tant que vérificateurs.
Bisection (Bipartition) : Améliorer l’efficacité du règlement des litiges
Pour améliorer l’efficacité de la vérification sur chaîne, le vérificateur peut utiliser la bisection, une méthode de recherche efficace sur les portes logiques préalablement soumises afin d’identifier rapidement celle à contester. Cette approche constitue une amélioration significative par rapport à un défi aléatoire. En divisant l’espace du problème en deux, la bisection permet au vérificateur de réduire rapidement la zone d’erreur potentielle, diminuant ainsi le nombre d’étapes et le temps nécessaires pour résoudre un litige. Cette méthode offre un chemin plus efficace et direct, particulièrement utile dans des processus de vérification complexes où la localisation précise d’une erreur est cruciale.
Voici un exemple simplifié illustrant le fonctionnement de la bisection :
Paul et Vicky travaillent sur un calcul : ((1+2)+(3+4))+((5+6)+(7+8)).
Le calcul correct donne : ((1+2)+(3+4))+((5+6)+(7+8)) = (3+7)+(11+15) = 10+26 = 36.
Mais Paul répond 35, car il calcule : ((1+2)+(3+4))+((5+6)+(7+8)) = (2+7)+(11+15) = 9+26 = 35.
Quand Vicky lance un défi, elle n’a besoin de contester que la première partie du calcul (c’est-à-dire d’ouvrir la porte logique concernée), car ils conviennent tous deux que la deuxième partie est correcte : ((5+6)+(7+8)) = 26.
3. Construire un pont à confiance minimale (Trust-Minimized Bridge) avec BitVM
La première application pratique de BitVM sera probablement un programme représentant un pont à confiance minimale. En analysant les détails de mise en œuvre d’un tel pont, nous pouvons mieux comprendre les complexités supplémentaires liées à l’exécution de programmes BitVM. Ci-dessous, nous résumons la proposition du cofondateur de BoB, Alexei Zamyatin.
Tout d’abord, il faut créer une méthode permettant à un nœud complet Bitcoin d’opérer un programme de pont vers une sidechain, y compris un client léger de sidechain, en utilisant uniquement le script Bitcoin.
Ensuite, il faut établir un réseau de conseil / multisignature (federation/multi-sig) pour faciliter le transfert de BTC et exécuter le jeu de défi-réponse. Ce conseil doit s’engager à exécuter le programme de pont dans le cadre du dispositif BitVM.
La complexité initiale du conseil augmente quadratiquement avec le nombre de membres, car chaque membre doit interagir avec tous les autres. Il existe donc une limite supérieure à la taille du conseil, que les chercheurs estiment viable autour de N=100.
À la différence des OP Rollups, qui n’ont aucune limite sur N, cette solution offre une garantie de sécurité plus faible. Toutefois, une solution opérationnelle pourrait inclure une rotation des membres du conseil, de sorte qu’à long terme, N soit bien supérieur à 100. À tout moment, tant qu’un seul des 100 membres est honnête, les dépôts restent sécurisés. En cas de comportement malveillant, un membre peut être mis au défi sur chaîne à tout moment et exclu du conseil s’il est prouvé qu’il triche.
À tout moment, un opérateur (Operator) du conseil est désigné pour gérer les dépôts, les retraits et valider l’état de la sidechain. L’opérateur et les tours de surveillance (Watchtowers) doivent tous deux déposer une garantie pour inciter au bon comportement et dissuader les faux défis.
Un autre motif pour lequel cette solution ne correspond pas strictement à la définition d’un rollup est que l’utilisateur ne peut pas sortir de la sidechain de manière unilatérale, mais doit demander un retrait auprès du conseil fonctionnant sous l’hypothèse de sécurité 1/N.
4. BitVM v2 : BitVM permet-il une vérification sans permission (Permissionless Verification) ?
Le 25 mars, Robin Linus a présenté BitVM v2. Le changement clé de cette proposition est que le prouveur doit soumettre d’un coup l’état de sortie et tous les résultats intermédiaires, contrairement à la version v1 où les portes logiques étaient ouvertes une par une durant le processus de défi-vérification. Avec cette modification, BitVM exige que tout défi contre ces engagements soit soutenu par une preuve cryptographique. Ce mécanisme filtre les défis abusifs sans fondement, car le challenger doit fournir une preuve cryptographique spécifique pour contester le prouveur.
En autorisant une participation illimitée au processus de vérification et de défi, BitVM v2 étend ses garanties de sécurité au-delà de la limite du conseil multisignature, se rapprochant ainsi des hypothèses de sécurité des Optimistic Rollups.
Cependant, la construction du pont nécessite toujours un conseil multisignature, ce qui signifie que les membres du conseil peuvent poser des problèmes d’activité (liveness). Dans le pire des cas, ils pourraient tenter d’extorquer des rançons aux utilisateurs pour débloquer leurs fonds. Il s’agit d’une hypothèse de sécurité supplémentaire absente dans les Optimistic Rollups, où les utilisateurs peuvent toujours sortir vers la couche L1 sans approbation d’aucun intermédiaire.
Hypothèses de sécurité supplémentaires sur la chaîne de base
5. Les limites de BitVM
Comme discuté ci-dessus, la meilleure solution d’évolutivité offerte par BitVM se rapproche des hypothèses de sécurité des Optimistic Rollups. Outre la complexité liée à la gestion d’un conseil chargé de garantir les dépôts et ses problèmes d’activité, BitVM présente des complexités supplémentaires spécifiques :
Bien que BitVM puisse théoriquement exécuter des programmes hors chaîne complexes, en pratique, à mesure que la complexité de ces programmes augmente, les frais associés à l’exécution d’une preuve de fraude sur Bitcoin augmentent rapidement. Des programmes trop volumineux pourraient nécessiter plusieurs blocs pour être traités, compliquant davantage le processus.
Un pool de minage détenant la majorité de la puissance de calcul pourrait voler dans BitVM (problème similaire au réseau Lightning), en complotant pour censurer les preuves du challenger, ou en étant corrompu par un acteur malveillant pour ignorer les défis.
En raison de la nature interactive des preuves BitVM, un prouveur malveillant pourrait manipuler le système et voler des vérificateurs. Un tel scénario d’attaque pourrait se dérouler ainsi :
-
Le prouveur démarre la séquence de vérification via une transaction
-
Un vérificateur suspectant une mauvaise foi lance un défi, incluant des frais de réponse payés au prouveur
-
Le prouveur choisit de percevoir les frais tout en ignorant le défi, sans remplir sa part de responsabilité dans le processus de vérification
Enfin, BitVM reste aujourd’hui un cadre conceptuel et l’idée d’un ordinateur virtuel presque incapable d’exécuter quoi que ce soit. Les « rollups » BitVM sont encore très loin d’un usage applicatif ; au mieux, nous pourrions voir quelques programmes BitVM en production vers 2025. Les risques techniques liés à l’implémentation de BitVM ne doivent pas non plus être sous-estimés.
6. Conclusion
En considérant la valorisation actuelle des solutions d’évolutivité d’Ethereum, estimée à environ 15-20 % de la capitalisation d’Ethereum, le potentiel de marché des solutions L2 Bitcoin pourrait être colossal.
Bien que BitVM en soit encore à ses débuts — essentiellement un concept d’ordinateur virtuel non concrétisé — il a déjà suscité un grand intérêt et de nombreuses annonces de projets cherchant à tirer parti de son potentiel. De nombreux projets non affiliés à l’équipe BitVM rivalisent pour faire de grandes déclarations, espérant occuper une place dans ce qu’ils perçoivent comme un nouveau domaine prometteur pour Bitcoin. Pourtant, un examen plus attentif révèle une réalité plus sobre : le compte GitHub de BitVM compte peu de contributeurs, et seulement quelques projets Bitcoin « L2 » sont réellement actifs dans le groupe Telegram BitVM Builders.
Un principe clé que toute solution d’évolutivité Bitcoin doit respecter est que l’architecture fondamentale de Bitcoin doit rester inchangée (selon le principe de prévisibilité). BitVM respecte ce principe et devient ainsi la première solution pionnière à proposer une couche programmable au-dessus de Bitcoin sans modifier son noyau.
Cet article est rédigé à un stade très précoce du développement de BitVM, et étant donné son rythme rapide d’évolution, ces informations pourraient rapidement devenir obsolètes. Par exemple, jusqu’à récemment, l’idée de mettre en œuvre des ZK-Rollups sur Bitcoin semblait totalement irréaliste, car les capacités de base requises — comme la capacité de Bitcoin à valider des preuves ZK — n’existaient pas. Pourtant, récemment, des chercheurs de BitVM ont partagé des avancées dans le script Bitcoin qui pourraient permettre de mettre en œuvre un vérificateur STARK sur Bitcoin.
La mise en œuvre de solutions d’évolutivité Bitcoin dépasse les simples défis techniques ; elle englobe également le soutien communautaire, l’expérience utilisateur et le timing. Bien que le moment actuel offre une fenêtre d’opportunité unique pour ces innovations, l’inflation rapide du nombre de projets et les risques importants liés aux déclarations trompeuses et au marketing pourraient compromettre les perspectives des projets les plus légitimes.
Alors que l’écosystème se trouve à ce carrefour, la question de savoir si les solutions d’évolutivité Bitcoin peuvent reproduire le succès d’Ethereum n’est pas seulement technique, mais profondément ancrée dans la dynamique plus large de la communauté blockchain. Après tout, la communauté Ethereum a choisi les L2 comme pilier central de sa feuille de route d’évolutivité, ce qui n’est pas encore le cas de la communauté Bitcoin.
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
IOSG Ventures
