Développeurs Bitcoin contre les inscriptions : un conflit de longue date
TechFlow SélectionTechFlow Sélection
Développeurs Bitcoin contre les inscriptions : un conflit de longue date
Les développeurs de Bitcoin Core s'opposent depuis longtemps aux inscriptions et ont clairement indiqué leur intention d'agir. Toutefois, étant donné que le marché des inscriptions implique désormais des intérêts croisés entre mineurs, exchanges et utilisateurs, la situation se transformera inévitablement en un conflit multipartite, ce qui rendra la progression loin d'être fluide.
Dédié à des analyses Web3 approfondiesRédaction : Trustless Labs
Aujourd'hui, Luke, développeur de Bitcoin Core, a affirmé sur la plateforme X son opposition aux protocoles d'inscription comme Ordinals, allant jusqu'à les considérer comme une attaque contre Bitcoin. Il estime que ces inscriptions exploitent une faille de Bitcoin pour diffuser des informations inutiles sur le réseau.
Cette déclaration s'est rapidement répandue dans la communauté Bitcoin et a suscité un grand nombre de réactions et de discussions.
Origine du débat
En réalité, les développeurs de Bitcoin Core critiquent les inscriptions depuis longtemps. Après la mise en œuvre de SegWit, la limite de taille de bloc a été étendue à 4 Mo. En février dernier, un bloc de 3,96 Mo a été extrait, dont 3,94 Mo étaient occupés par des transactions liées à Ordinals, soit pas moins de 99,5 %. Lorsque les inscriptions ont explosé au mois de mai, la liste de discussion Bitcoin-dev avait déjà exprimé des préoccupations concernant l'utilisation excessive de l'espace bloc par des transactions Taproot non standard. Un courrier électronique publié sur la liste soulignait que des projets similaires à BRC-20 généraient un volume transactionnel énorme, provoquant une congestion sévère du réseau BTC au point que les « véritables transactions Bitcoin » ne pouvaient plus être intégrées normalement dans la chaîne.
Luke qualifie directement les protocoles tels qu'Ordinals de « sans valeur », affirmant qu'ils nuisent gravement à l'utilisation normale du BTC en tant que monnaie cryptographique peer-to-peer. Dans ce courrier, il mentionne également la méthode proposée dans son tweet pour restreindre les inscriptions : introduire un mécanisme de contrôle dans le client afin que les nœuds suppriment automatiquement les transactions Taproot non standard, cessant ainsi de relayer ce type de transaction afin d'interdire l'inscription.
Propositions de mise à jour et conséquences
Selon les explications de Luke dans son tweet, les restrictions proposées concernent principalement les paramètres de politique de contrôle dans le client Knots :
-datacarriersize :
-
Ce paramètre limite la quantité de données pouvant être incluses dans les scripts de sortie OP_RETURN. Ces données sont insérées dans la sortie des UTXO. Parmi les protocoles existants, Omni et Colored utilisent tous deux OP_RETURN pour stocker des données ; dans l'écosystème des inscriptions, Runes repose également sur OP_RETURN pour fournir un index de données.
-
Actuellement fixé par défaut à 83 octets, Luke propose de le définir immédiatement à 0 dans les clients actuels afin d'empêcher les nœuds de relayer toute transaction contenant des données OP_RETURN, et prévoit de modifier cette valeur par défaut à 42 dans la prochaine version Knots 25.1.
-maxscriptsize :
-
Ce paramètre limite la taille du script des transactions que les nœuds peuvent relayer. Le protocole Ordinals inscrit des données de protocole dans les scripts Taproot pour permettre l'indexation des données.
-
Une fois activé, les nœuds cesseront de relayer via P2P les transactions dont le script Taproot dépasse le seuil défini, affectant ainsi le minting et le transfert des inscriptions Ordinals.
-
Luke a introduit ce paramètre dans la version V25.1 et défini sa valeur par défaut à 1650.
On constate que la voie de mise à jour évoquée par Luke suit exactement la même logique que celle mentionnée précédemment dans ses courriels Bitcoin-dev : ajouter un filtre dans le client pour rejeter les transactions Taproot anormales. Si les mineurs adoptent eux aussi cette modification présente dans le code actuel, les nœuds refuseront de relayer les transactions Taproot dont la taille du script dépasse le seuil fixé (par défaut 1650 octets), rendant impossible la diffusion de certaines transactions Ordinals.
Toutefois, cette mise à jour se contente de limiter, au niveau du client Knots, la taille des données transportées par OP_RETURN et les scripts Taproot. Elle donne simplement aux opérateurs de nœuds le choix de rejeter certaines transactions liées aux inscriptions, mais ne peut pas empêcher fondamentalement les nœuds de les relayer ou les mineurs de les inclure dans les blocs. De plus, la mise à jour Taproot de Bitcoin Core n'inclut aucune vérification relative à la taille des données witness de Taproot.
D'après l'analyse du code, la valeur maximale actuelle par défaut de 1650 octets dans Knots suffit à supporter les besoins en transfert de jetons. Ainsi, le mode de limitation actuel ne peut pas totalement bloquer les opérations liées à BRC-20. Pour des restrictions plus strictes, il faudra surveiller les éventuelles modifications futures apportées par Luke à la politique de validation.
Évolution future de l'écosystème BTC
Bien que le débat autour des inscriptions dure depuis longtemps, la prise de position de Luke intervient aujourd'hui alors que l'écosystème BTC connaît un essor exceptionnel, provoquant une forte réaction au sein de la communauté, qui entame désormais un débat animé sur l'avenir de l'écosystème BTC.
À propos de cet événement, Shenyu, représentant des mineurs, a exprimé son opinion : Bitcoin n'est pas dirigé par les développeurs ; les mineurs doivent soutenir les mises à jour correspondantes, sinon, les développeurs devront procéder à un fork eux-mêmes.
Par ailleurs, les propositions de Luke visant à filtrer et contrôler les « transactions inutiles » des inscriptions restent pour l'instant limitées au niveau du client. Pour interdire complètement ces transactions au niveau du protocole, il faudrait intégrer ces changements dans Bitcoin Core, voire les formaliser sous forme de BIP. Luke lui-même reconnaît qu'il sera impossible d'éviter cette « faille » avant la mise à jour V27.
De nombreux influenceurs de la communauté ont également réagi à cette affaire, certains affirmant clairement qu’ils « n’accepteront jamais cela » :
Manwu Yuxian a déclaré quant à lui que « la correction n’est pas nécessaire » :
Ces réactions montrent indirectement que la communauté reste favorable à l’écosystème des inscriptions, reconnaissant pleinement le formidable élan qu’il a donné au développement de l’écosystème BTC et à l’activité minière. L'idée, avancée par des utilisateurs, de créer une « chaîne d'inscriptions » similaire à une couche 2 a d'ailleurs reçu une réponse positive de la part de Luke.
En résumé, bien que cette controverse ait eu un large retentissement, et que les développeurs de Bitcoin Core s'opposent depuis longtemps aux inscriptions en annonçant clairement leur intention d'agir, la progression de ces mesures ne sera pas aisée. En effet, le marché des inscriptions implique désormais des intérêts complexes entre mineurs, exchanges et utilisateurs, créant un équilibre instable fait de compromis et de tensions. Par ailleurs, Taproot Assets, souvent perçu comme la solution « orthodoxe » et utilisant peu d'espace sur la chaîne, ne sera pas impacté par ces mises à jour et pourrait donc connaître un développement accru à l'avenir.
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
@TrustlessLabs
