Dans le fil de discussion du PR visant à « filtrer » les inscriptions Bitcoin, quels sont les points de vue pour et contre exprimés par les développeurs ?
TechFlow SélectionTechFlow Sélection
Dans le fil de discussion du PR visant à « filtrer » les inscriptions Bitcoin, quels sont les points de vue pour et contre exprimés par les développeurs ?
Concernant la question de savoir s'il faut interdire les inscriptions, cet article fait un point sur les opinions des développeurs, tant favorables qu'opposées.
Dédié à des analyses Web3 approfondiesPréparation : gloria
Traduction : GaryMa, Wu Shuo Blockchain
Contexte
En septembre 2023, le développeur Bitcoin Luke Dashjr a soumis une demande de fusion (PR) au dépôt GitHub de Bitcoin Core, visant à mettre à jour l'option « datacarriersize » afin de filtrer les transactions portant des données via de nouveaux types de scripts, comme celles utilisées par les « Inscriptions ». Cette proposition s'appuie sur la conviction que ces transactions constituent une exploitation de faille qu'il convient de corriger et d'interdire.
Par défaut, Bitcoin Core limite le nombre de sorties OP_RETURN dans les transactions non confirmées ainsi que la quantité de données insérées, avec une valeur par défaut fixée à 80 octets. L'option de configuration -datacarriersize permet aux utilisateurs de modifier cette limite de volume. Toutefois, cette option ne s'applique actuellement qu'aux sorties OP_RETURN.
La modification proposée permettrait aux utilisateurs ayant configuré l’option -datacarriersize de limiter non seulement les données présentes dans les sorties OP_RETURN, mais aussi celles intégrées dans les données de témoin (witness data).
Il est important de noter que cette PR n'implémente pas un moyen complet d'identifier toutes les données arbitrairement insérées dans les témoins (car aucune méthode fiable n'existe actuellement pour cela). Elle vérifie principalement la structure OP_FALSE OP_IF ... OP_ENDIF, couramment utilisée pour gérer les données d'Inscriptions.
Bien que cette PR ait suscité de nombreux débats parmi les développeurs, le mainteneur de Bitcoin Core achow101 l’a officiellement fermée le 5 janvier 2024. Dans son dernier commentaire, achow101 a indiqué que cette proposition était clairement controversée et qu’à l’état actuel, il n’y avait aucun espoir d’aboutir à une conclusion acceptable pour tous. Il a ajouté qu’il ne voyait aucune raison de la laisser ouverte plus longtemps ni de continuer à alimenter des discussions stériles qui ne mènent nulle part.
Un autre mainteneur de Bitcoin Core, gloria, a compilé les arguments pour et contre ce sujet. Voici la traduction de Wu Shuo.
Arguments en faveur de l'interdiction des « Inscriptions »
1. « Interdire les Inscriptions, ce sont des transactions polluantes »
Ces types de transactions sont utilisés pour les ordinaux, les NFT, le transport de données ou d'autres cas d'utilisation non financiers. Ce trafic constitue une « pollution transactionnelle » qui nuit à l’utilisation du Bitcoin comme moyen de paiement, en raison du volume élevé des transactions et des frais associés.
● Ces transactions polluantes rendent l'utilisation véritable du Bitcoin de plus en plus difficile.
● Insérer des données représente une tromperie et un abus du script taproot.
● La capacité d'insérer des octets aléatoires constitue une « vulnérabilité ».
● Si Bitcoin est une monnaie (et c’est le cas !), alors les transactions non monétaires devraient être réduites au minimum.
● Les partisans enthousiastes des ordinaux sont des extrémistes pro-ethereum et anti-Bitcoin ; ceux qui disent « nous devons changer la culture du Bitcoin » sont des trolls qui perdent leur temps.
● C'est une mauvaise utilisation du réseau, conçu pour les transactions financières (le livre blanc, le nom et le code le confirment), le stockage de données n'étant pas un cas d'utilisation prévu.
● Cela provoque une « congestion du réseau » et entraîne des « frais plus élevés ou des délais de traitement plus longs », ce qui équivaut à une attaque « DDoS ».
● Le problème ne vient pas des Inscriptions elles-mêmes, mais des frais de transaction excessivement élevés.
● Le réseau Bitcoin doit être protégé immédiatement contre les attaques par transactions polluantes.
2. « Les Inscriptions et les données insérées nuisent au réseau »
Ces types de transactions augmentent les coûts supportés par les opérateurs de nœuds et nuisent donc au réseau d'une manière ou d'une autre.
● Les transactions visées par cette PR sont l'une des principales sources de coûts importants subis par les opérateurs de nœuds ordinaires.
● Ces transactions affectent la décentralisation du réseau en augmentant le coût d'exploitation des nœuds.
● Elles conduisent à un stockage disproportionné et excessif de grandes quantités de données directement sur la blockchain.
3. « Interdire répond à une demande des utilisateurs »
Il est évident qu'il existe une demande spécifique de la part des utilisateurs et certains cas d'utilisation justifient que Bitcoin Core propose cette option. Sinon, les utilisateurs seront amenés à appliquer eux-mêmes des correctifs, ce qui peut s'avérer dangereux.
● Les opérateurs de nœuds ont besoin d'une option intégrée pour ignorer toutes les formes modernes de transport de données, afin de ne pas avoir à modifier manuellement leurs nœuds.
● Si les développeurs n'aident pas les opérateurs de nœuds à se protéger contre ces attaques, ils pourraient recourir à des moyens inappropriés pour renforcer leur défense.
● Je souhaite contrôler ma propre politique de mempool ; je veux décider moi-même ce qui est une transaction polluante ou non.
● Si les mineurs considèrent que Bitcoin est une monnaie et non simplement une blockchain permissive et immuable, ils filtreront effectivement les transactions polluantes pour rendre le réseau monétaire fonctionnel, et souhaiteront donc disposer de cette fonctionnalité.
4. « Il s'agit simplement de corriger datacarriersize pour qu'il fonctionne comme prévu »
Nous limitons déjà les données transportées dans OP_RETURN. Cette limitation devrait s'appliquer à toutes les méthodes permettant d'insérer des données arbitraires dans une transaction. Tel a toujours été l'objectif de l'option -datacarriersize ; il s'agit donc d'une « correction de bogue ».
● Selon luke-jr, le fait que -datacarriersize n'ait pas été mis à jour avec segwit et taproot pour couvrir d'autres formes de transport de données constitue une erreur, qu'il qualifie donc de bogue / vulnérabilité.
● Bitcoin Core a déjà normalisé le fait que l'insertion de plus de 83 octets de données arbitraires ou d'Inscriptions constitue un contournement de cette limite ; il s'agit donc d'une correction de bogue.
● Les transactions polluantes sont déjà filtrées à plusieurs niveaux du code, et cela depuis plus de dix ans. Tout ce que fait cette PR, c'est d'appliquer une limite existante (-datacarriersize) à une autre forme de transport de données, qui constitue manifestement une faille imprévue.
● À quoi sert la limite de transport de données, si ce n'est à restreindre les données arbitraires stockées dans les transactions ?
● L'objectif de cette règle normalisée n'est pas uniquement de limiter les données contenues dans le scriptPubKey d'origine, mais bien toutes les formes de données arbitraires.
Arguments contre l'interdiction des « Inscriptions »
1. « Cela n'empêchera pas les Inscriptions »
Cela n'arrêtera pas les Inscriptions. Étant donné qu'elle n'est pas compatible avec les incitations, il est peu probable que les mineurs (ni bien sûr les utilisateurs d'Inscriptions) adoptent cette politique, ce qui signifie qu'elle aura peu d'effet pour bloquer ces transactions.
● Si seul le pool Ocean utilise cette règle et reste relativement petit, elle sera sans effet. Même si elle était largement déployée, il serait facile de la contourner.
● À long terme, cela va à l’encontre des incitations économiques des mineurs.
● Les mineurs sont peu susceptibles d'abandonner cette source de revenus. La censure de ces transactions encouragera uniquement le développement de mempools privés.
● Les transactions ordinaux finiront par entrer dans la blockchain en contournant la mempool, rendant cette PR inefficace pour résoudre ou atténuer le problème.
● En quelque sorte, cette tentative vise non seulement à ne pas relayer ces transactions, mais aussi à en empêcher l'utilisation, ce qui risque tout au plus de faire contourner les nœuds implémentant cette règle, ou dans le pire des cas d'encourager la pratique consistant à envoyer directement les transactions aux mineurs, ce qui présente un grave risque de centralisation du minage.
● Les adeptes des Inscriptions peuvent assurer leur diffusion sur le réseau en s'assurant que quelques nœuds seulement filtrent ces transactions.
● Il est évident que tout bloc construit à partir d'une mempool filtrée offrira un gain total inférieur à celui d'un bloc construit à partir de toutes les transactions non confirmées. Cela signifie que tout mineur filtrant les Inscriptions réduit volontairement ses revenus, au profit des mineurs qui ne filtrent pas.
2. « Nous ne pouvons pas écrire de code capable de détecter toutes les données insérées »
Globalement, il est impossible d'empêcher les transactions contenant des données arbitraires. Les Inscriptions exploitent de nombreuses façons d'insérer des données (que nous ne pourrons jamais couvrir entièrement). Il vaut mieux préserver les méthodes les plus efficaces, c’est-à-dire celles qui ont le moindre impact sur les ressources du réseau.
● Il n’existe aucune méthode universelle pour filtrer tous les modes actuels et futurs de transport de données. Cela déclencherait un jeu sans fin du chat et de la souris dans des parties critiques du code.
● Tenter d'empêcher tous les types d'insertion de données rendrait ce code de plus en plus complexe. Chaque fois que cela se produit, une forte pression est exercée sur les mainteneurs pour qu'ils agissent rapidement afin d’« arrêter les transactions polluantes ».
● À ma connaissance, il n'existe aucune méthode raisonnable d'empêcher le stockage de données arbitraires dans les témoins (witnesses) sans encourager des comportements encore pires et/ou nuire à des cas d'utilisation légitimes.
3. « Cette modification pourrait être nuisible »
Cette PR modifie la politique par défaut de la mempool et pourrait nuire aux opérateurs de nœuds indépendants ainsi qu’au réseau.
● Exclure des transactions qui seront tout de même extraites est préjudiciable pour les nœuds. L’intérêt de participer à la relais des transactions et de posséder une mempool est de pouvoir anticiper l’apparence du prochain bloc. Exclure intentionnellement des transactions soutenues par une demande économique claire (même si elle semble absurde) compromet cette capacité.
● En fin de compte, les utilisateurs exécutant ce correctif traitent quand même les blocs contenant des Inscriptions. Ils nuisent uniquement à leurs propres estimations de frais, ralentissent la validation des blocs et deviennent moins utiles pour les autres nœuds.
● Modifier généralement une politique par défaut est dangereux. Rendre non standardes des transactions auparavant standardes signifie que certaines personnes pourraient désormais rencontrer des difficultés pour accéder à leurs fonds. Changer la valeur par défaut, plutôt que de l’offrir en option facultative, représente une évolution potentiellement perturbatrice et indésirable pour les mineurs qui s'appuient sur Bitcoin Core pour construire leurs gabarits de blocs... C
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
@glozow
