Rédigé par : Brandon Black
Traduit par : AididiaoJP, Foresight News
Dans le petit cercle du crypto-Twitter, la proposition de "soft fork temporaire de réduction des données" (BIP110) avancée par @dathon_ohm fait l'objet de vifs débats depuis un an.
La logique centrale de cette proposition est la suivante : certaines transactions Bitcoin incluent dans leurs scripts de verrouillage ou de déverrouillage des données qui, au-delà de leur signification pour le script Bitcoin lui-même, peuvent être interprétées comme des informations supplémentaires par d'autres logiciels. Les partisans y voient une violation des principes du réseau.
Ils estiment que réduire ce type de transactions suffit à justifier ce qui serait à ce jour le soft fork Bitcoin le plus "confiscatoire" – son déploiement serait beaucoup plus rapide que les deux derniers soft forks, avec un seuil d'activation plus bas.
Bitcoin est par essence un registre distribué à accès ouvert et résistant à la censure. N'importe qui peut écrire dans ce registre en payant des frais suffisants pour convaincre les constructeurs de modèles de blocs et les mineurs d'inclure sa transaction. La valeur fondamentale de Bitcoin, ce qui le distingue de tous les autres systèmes de registre, réside précisément dans cette ouverture. Sans elle, le registre Bitcoin ne différerait guère d'un tableau de score de bowling. Grâce à cet accès ouvert, nous savons tous que Bitcoin sera utilisé par des personnes que nous n'aimons pas.
C'est comme le principe de la liberté d'expression : s'il ne protègeait que les discours que nous apprécions, il n'aurait aucun sens. L'accès ouvert de Bitcoin fonctionne de la même manière – s'il n'autorisait que les entrées de registre que vous et moi approuvons, il perdrait son sens. Par conséquent, nous n'avons pas besoin de censurer la manière dont les autres construisent leurs entrées de registre, pas plus que nous ne voulons qu'ils censurent les nôtres.
Les partisans du BIP110 pourraient rétorquer : "Bien sûr, mais cela ne concerne que les entrées non monétaires ! Et les transactions purement monétaires ?" En réalité, une telle distinction claire n'existe pas. Sur Bitcoin, toute transaction consiste à créer une entrée dans le registre en satisfaisant les conditions d'un script de verrouillage – en consommant des UTXO en entrée pour en générer de nouveaux en sortie.
Le fait qu'un script de transaction soit plus ou moins volumineux n'a absolument aucune importance pour un opérateur de nœud ou un utilisateur ordinaire. Premièrement, je me moque éperdument des détails des transactions des autres, c'est comme la commande d'un inconnu dans un café. Deuxièmement, les nœuds Bitcoin ne font pas cette distinction. Une transaction est simplement valide ou invalide, avec des coûts de vérification variables (une transaction multisig importante coûte plus cher à vérifier, certains Ordinals ou OP_RETURN sont relativement peu coûteux).
Certains argumentent que Bitcoin serait un meilleur actif monétaire s'il ne pouvait pas être utilisé "d'autres façons", à l'instar de l'or. Imaginez si l'or ne pouvait servir ni en joaillerie ni dans l'industrie, il serait peut-être plus pur en tant que monnaie. Mais ce sont précisément les propriétés physiques qui font de l'or une bonne monnaie qui le rendent également populaire pour les bijoux et l'industrie.
Il en va de même pour Bitcoin : parce qu'il permet à quiconque de payer pour écrire des données, nous ne pouvons contrôler la manière dont d'autres interpréteront ces données. Peu importe comment nous restreignons la structure des scripts, des personnes trouveront toujours des moyens d'interpréter ces entrées différemment à l'aide de logiciels extérieurs à Bitcoin. Ainsi, comme pour l'or, nous devons accepter que les "autres usages" sont inévitables. Sur le marché de l'or, cela peut entraîner des distorsions de prix dues aux fluctuations de la demande non monétaire ; sur Bitcoin, cela peut provoquer une hausse des frais lors de pics de demande d'espace bloc.
Cependant, Bitcoin possède deux avantages sur l'or. Premièrement, créer des transactions Bitcoin interprétables de manière alternative n'affecte pas directement le marché de Bitcoin en tant qu'actif – contrairement à l'or, la quantité de Bitcoin utilisée pour ces "usages supplémentaires" est très faible. Deuxièmement, le protocole Bitcoin a été conçu dès le départ avec des mécanismes pour minimiser le fardeau que ces "interprétations supplémentaires" font peser sur le réseau de vérification. Il limite la taille des blocs et le nombre de signatures (sigops) dans les transactions, éléments qui représentent justement la plus grande part du coût de vérification pour les nœuds.
Ces limites, établies très tôt, visaient précisément à prévenir les abus à haute fréquence et volume sur le registre. Ce sont ces limites qui ont stimulé l'innovation au niveau 2, avec le Lightning Network, Ark, Spark, Cashu, etc. Même une demande accrue d'espace bloc due à des données "non monétaires" encourage l'utilisation de ces solutions d'échelle plus efficaces – qui enregistrent moins de choses sur la chaîne principale.
Maintenant que les prétendues justifications du BIP110 sont exposées (et clairement infondées), examinons ce qu'il propose réellement de changer.
Le BIP110 limiterait la taille des scripts de verrouillage, limiterait le nombre de scripts alternatifs disponibles dans Taproot, rendrait l'annexe (annex) de Taproot invalide, supprimerait toutes les versions de témoin et de Tapscript pouvant être mises à niveau, supprimerait tous les opcodes pouvant être mis à niveau dans Tapscript, et désactiverait OP_IF et OP_NOTIF dans Tapscript. Ces restrictions s'appliqueraient uniquement aux UTXO créés dans les environ 52414 blocs (environ un an) suivant l'activation.
De plus, le BIP110 abaisserait le seuil de signalement de préparation des mineurs à 55% (les soft forks précédents nécessitaient généralement plus de 90%) et mettrait en place un mécanisme d'activation forcée par les nœuds : si le signalement est insuffisant avant le bloc 961632, les nœuds appliquant cette règle considéreraient les blocs non signalés comme invalides, forçant ainsi le verrouillage des changements au bloc 963648 et leur activation au bloc 965664.
Ce serait la restriction la plus radicale apportée au script Bitcoin depuis que Satoshi a désactivé plusieurs opcodes en 2010 en raison d'une grave vulnérabilité (CVE-2010-5137). Il tente de pousser ce changement avec un seuil historiquement bas, un délai d'activation extrêmement court (moins de 9 mois entre la numérotation du BIP et l'activation), et un examen de code minimal – tout cela au nom du simple fait que certaines personnes interprètent les entrées du registre d'une manière que les partisans n'approuvent pas.
L'ironie suprême est que ceux qui utilisent les données "contestées" ont déjà mis à jour leurs logiciels et sont prêts : même si le BIP110 s'active, ils pourront continuer à intégrer des données similaires. Beaucoup d'entre nous l'avaient prédit, car il est impossible de restreindre la manière dont les utilisateurs d'un registre public ouvert interprètent ses entrées avec des logiciels externes.
En résumé, le BIP110 tente de faire l'impossible – restreindre la manière dont les utilisateurs d'un registre à accès ouvert l'utilisent – alors que le problème qu'il prétend résoudre est déjà bien géré par les limites existantes du protocole Bitcoin. Il tente en outre de forcer son adoption avec un calendrier irresponsablement court, un examen de code précipité et un mépris du consensus de l'écosystème. Heureusement, Bitcoin n'est pas un système aussi fragile, et cette tentative de modification imprudente n'aboutira pas.
Les mineurs ont déjà clairement rejeté le BIP110, et les développeurs, investisseurs, influenceurs et entreprises ont exprimé leur opposition. D'ici août de cette année, cette "attaque" contre les règles de consensus de Bitcoin se soldera par un échec, et Bitcoin en sortira renforcé, continuant à produire des blocs à un rythme régulier – bloc après bloc.
