Cette année, on a assisté à une augmentation massive de la demande pour l'espace limité disponible dans les blocs de bitcoins, ce qui a entraîné une augmentation des frais pour les transactions sur la chaîne. Une grande partie de la demande concerne des transactions révélant des inscriptions. Le contenu de ces inscriptions est révélé dans le cadre des données témoins1 d'une transaction en bitcoins. Ces données témoins1 sont ramenées à un quart du coût des autres données de transaction. Pourquoi accorder une réduction à ces inscriptions ? Devrions-nous supprimer la réduction pour les témoins ?

Pourquoi certains octets sont-ils moins chers que d'autres ?

L'argent en général et le bitcoin en particulier fonctionnent sur la base d'incitations humaines. Bitcoin aligne les incitations des mineurs et des transacteurs en utilisant le jeton bitcoin natif pour payer les mineurs pour l'inclusion de transactions particulières dans les blocs qu'ils construisent. On ne peut pas en dire autant de l'alignement des incitations des coureurs de nœuds sur celles des mineurs et des transacteurs, ni de l'alignement des incitations entre les expéditeurs et les destinataires.

À ce jour, trois améliorations majeures ont été apportées à l'alignement des incitations du bitcoin :

1. Limitation de la taille des blocs

2. Transfert du coût des scripts complexes de l'expéditeur au destinataire (P2SH)

3. Alignement des coûts des données entre les gestionnaires de nœuds et les transacteurs (SegWit)

LA LIMITATION DE LA TAILLE DES BLOCS

Les opérateurs veulent effectuer un grand nombre de transactions et les mineurs veulent percevoir un grand nombre de frais de transaction ; mais les gestionnaires de nœuds doivent relayer, vérifier et stocker toutes ces données de transaction et ils ne sont pas rémunérés comme les mineurs pour le faire. Au début de l'histoire du bitcoin, Satoshi s'est efforcé de résoudre ce problème en ajoutant une limite fixe à la taille des blocs (appliquée par les nœuds). La limite était de 1 million d'octets par bloc, ce qui fixait une limite supérieure à la quantité de données que les nœuds devaient télécharger et vérifier. À l'époque, Satoshi avait écrit: "Nous pourrons introduire progressivement un changement plus tard si nous nous rapprochons du moment où nous en aurons besoin". Plus tard, faisant référence à un correctif permettant d'augmenter la limite, il a indiqué "n'utilisez pas ce correctif, il vous rendra incompatible avec le réseau", ce qui signifie que l'augmentation de la limite de la taille des blocs est une modification hard fork et qu'elle nécessite davantage de coordination qu'une soft fork. Dans les années qui ont suivi, le bitcoin a délibérément évité de tels changements incompatibles avec le hard fork, ce qui a également signifié le maintien de la limite de 1 million d'octets pour la taille des blocs.

TRANSFERT DES COÛTS DES SCRIPTS COMPLEXES DE L'EXPÉDITEUR AU DESTINATAIRE

Le bitcoin étant sécurisé par des scripts de verrouillage, il a toujours été possible de le verrouiller à l'aide de scripts avancés, notamment multisig. Selon la conception initiale, l'expéditeur d'une transaction en bitcoins plaçait le script de verrouillage complet du destinataire dans sa transaction et payait les frais éventuels pour que ce script de verrouillage soit inclus dans un bloc. Les développeurs se sont rendu compte qu'avec l'augmentation des frais, les expéditeurs pourraient hésiter à payer les utilisateurs de scripts de verrouillage plus importants en raison du coût plus élevé de la rémunération de ces utilisateurs. Ces scripts de verrouillage complexes posent également un problème d'encodage dans des adresses et de partage via des mécanismes à faible bande passante tels que le code QR.

Pour résoudre ce problème, P2SH a été ajouté au bitcoin en tant que "soft fork". Selon les règles de cette fourche, au lieu d'inclure l'intégralité du script de verrouillage du destinataire dans la sortie de la transaction, l'expéditeur se contente d'en inclure un hachage. Lorsque le destinataire dépense inévitablement ce résultat, il inclut le script complet dans la transaction de dépense, qui est vérifiée par rapport au hachage du script sur lequel la pièce est verrouillée avant d'être validée. Grâce à cette modification, un script de rachat de n'importe quelle taille peut être représenté par un script de verrouillage de longueur fixe et les expéditeurs n'ont plus besoin (ou ne peuvent plus) faire de distinction entre les destinataires en fonction de leurs conditions de dépenses.

ALIGNER LES COÛTS DES DONNÉES ENTRE LES EXÉCUTANTS DE NŒUDS ET LES TRANSACTEURS

La vérification la plus fondamentale que les nœuds effectuent sur les transactions en bitcoins est que les bitcoins qu'ils tentent de dépenser existent bel et bien. Pour ce faire, chaque nœud maintient un index de chaque unité de bitcoin dépensable (UTXO). Plus cet indice est élevé, plus le coût de fonctionnement d'un nœud et de vérification des transactions futures est important2. Par conséquent, une transaction qui augmente la taille de cet index (ayant plus de sorties que d'entrées) coûte plus cher au fil du temps qu'une transaction avec le même nombre d'octets qui réduit la taille de l'index.

La partie la plus importante de la plupart des scripts de déverrouillage de bitcoins est constituée par les signatures cryptographiques. Ces signatures sont environ deux fois plus grandes que les clés publiques correspondantes, ce qui fait que les scripts de déverrouillage (même sans P2SH) sont plus grands que les scripts de verrouillage.

Le coût nettement plus élevé de la consommation par rapport à la création d'UTXO crée un conflit d'incitation entre les coureurs de nœuds et les transacteurs. Les opérateurs sont dissuadés de dépenser leurs petites UTXO (en particulier lorsque les frais sont élevés), préférant dépenser des UTXO plus importantes et créer davantage d'UTXO de petite monnaie. Pendant ce temps, les coureurs de nœuds paient le coût de cette accumulation de petites UTXO sous la forme de coûts de validation plus élevés pour toutes les transactions.

Aussi étrange que cela puisse paraître, la vérification que chaque UTXO dépensé par une transaction dans la blockchain historique a son script de verrouillage satisfait par un script de déverrouillage correspondant est beaucoup moins fondamentale. Ainsi, un nœud bitcoin fonctionnant avec le bitcoin core 26.x par défaut ne validera pas l'exécution complète du script de verrouillage pour les transactions antérieures au bloc 804000 (19 août 2023).

Tout ce qui précède signifie que les coûts imposés aux nœuds de bitcoins varient en fonction des différentes parties de la blockchain. Les données nécessaires pour déterminer les effets de chaque transaction doivent être validées par chaque nœud se synchronisant à partir du bloc de genèse3, les résultats des transactions ont tendance à être plus coûteux que les entrées des transactions à long terme (surtout si elles ont une longue durée de vie), et une grande partie des données témoins n'est même pas vérifiée, sauf pour les transactions les plus récentes.

ENTRER DANS LE TÉMOIN ISOLÉ

La fourchette logicielle SegWit (segregated witness) est la modification la plus ambitieuse apportée au bitcoin à ce jour. La principale motivation de ce changement était de résoudre le problème de longue date de la malléabilité5du TXID4 dans le bitcoin. Pour remédier à cette malléabilité, le script de déverrouillage est remplacé par un "témoin" nouvellement créé. En supprimant les données d'autorisation (qui peuvent souvent être modifiées par des tiers sans changer les effets de la transaction) du TXID, les protocoles (tels que Lightning) qui dépendent de TXID immuables deviennent possibles.

Les données d'autorisation ayant été retirées de la structure de transaction originale, elles ne sont plus prises en compte dans la limite du bloc de 1 million d'octets. Une nouvelle limite est nécessaire. De nombreuses approches visant à limiter les données séparées des témoins ont été discutées à l'époque : Une limite d'octets par témoin séparé6, une limite combinée de < 1 million d'octets7, ou une limite combinée pondérée. Finalement, c'est la limite combinée pondérée qui a été choisie, avec les données des témoins isolés pondérées à 1 unité, les données des transactions pondérées à 4 unités, et une limite de bloc de 4 millions de poids. Chaque unité de poids est traitée comme 1/4 d'un octet virtuel (vByte) pour les besoins du calcul des redevances.

Pourquoi ces poids ? Examinons le coût des intrants et des extrants des transactions avec et sans témoin séparé :

La première chose à noter dans ce tableau est que les types de scripts témoins (P2WPKH, P2WSH) ont pratiquement le même nombre d'octets d'entrée et de sortie (qui sont facturés à raison d'un vByte entier chacun). Le dépensier d'un script témoin est alors facturé 1/4 vByte pour les données autorisant la dépense, dont une grande partie n'est pas vérifiée, sauf pour les transactions les plus récentes, et dont aucune n'a de coût permanent dans l'indice UTXO. Il convient également de noter que le coût de l'utilisation d'une signature multiple 2 sur 3, plus sûre, par rapport à une signature simple, est ramené de 147 vBytes à 36,25 vBytes.

LA RACINE PIVOTANTE ET LES INSCRIPTIONS CHANGENT TOUT (OU RIEN)

Comme je l'ai dit au début, le bitcoin repose sur des incitations humaines, et nous pouvons voir ici comment des changements ont été apportés au bitcoin au fil des ans pour améliorer l'alignement des incitations entre les parties utilisant le réseau.

Taproot lui-même n'est "qu'un" moyen alternatif de verrouiller les bitcoins en utilisant des témoins séparés. Elle ne modifie pas ces incitations de manière significative. L'un des changements apportés par Taproot a été de supprimer certaines limites à la taille des scripts. Cela a été fait pour réduire la complexité de la conception d'outils d'analyse pour les scripts bitcoins et pour tenir compte du coût relatif des différents types de données. La suppression de ces limites a rendu les inscriptions plus simples qu'elles ne l'étaient avant Taproot, mais n'a pas fondamentalement modifié la structure d'incitation du réseau.

Venons-en maintenant au cœur du problème. Les inscriptions étant révélées par le témoin, elles ne sont facturées qu'à raison de 1/4 de vByte par octet de données d'inscription. S'agit-il d'un abus de la remise de témoin ? En réalité, les données d'inscription sont parmi les moins chères à valider pour les nœuds du réseau. La structure de script utilisée par les inscriptions ignore explicitement l'exécution des données d'inscription, de sorte que la seule vérification effectuée est un simple contrôle de hachage (garantissant que l'inscription révélée est bien celle que l'auteur de l'inscription avait l'intention de révéler). Ces données sont hachées une fois et ne sont plus jamais consultées par les nœuds. Son coût de calcul est très faible (un ordre de grandeur inférieur à celui d'un script multisig de taille équivalente).

Mais les inscriptions font grimper les tarifs et évincent les autres utilisateurs.

Oui ! Avec les logiciels actuellement disponibles pour interagir avec le réseau bitcoin, les personnes qui s'inscrivent ont plus d'intérêt économique à le faire que beaucoup d'autres personnes à effectuer d'autres transactions.

Cela met en évidence la valeur de l'augmentation de la densité économique des transactions en bitcoins. Le réseau Lightning fait un grand pas en avant en permettant de regrouper des centaines, des milliers ou des millions de transactions économiques en une seule transaction bitcoin. Plus la densité économique de chaque octet d'une transaction est élevée, plus la redevance payée pour cette activité économique est faible. À mesure que la densité économique des transactions en bitcoins augmente, d'autres utilisations de l'espace des blocs ont été et continueront d'être exclues9.

Il convient de noter que si les protocoles multi-signes hors chaîne tels que MuSig2 ou FROST, ou les signatures d'adaptateurs se répandent, il peut être judicieux de réduire ou d'éliminer la réduction de la valeur du témoin. Ces protocoles peuvent permettre à des conditions de dépenses autrement importantes d'être représentées par une seule signature. Ceci, combiné à l'efficacité du parcours des clés de Taproot, pourrait ramener le coût d'une entrée avec des conditions presque arbitrairement complexes à seulement 105 octets.

CONCLUSION

La réponse aux frais élevés causés par les inscriptions est la même que pour tout autre scénario supposé de chute du ciel dans l'histoire du bitcoin : construire patiemment, construire patiemment. Nous pouvons faire beaucoup pour augmenter la densité économique des transactions en bitcoins, depuis la construction de meilleurs portefeuilles Lightning jusqu'aux contrats Ark to discrete log et au-delà. La suppression (prématurée) de la décote des témoins, le retour en arrière de taproot ou d'autres actions contre-productives similaires ne feront que réduire la densité économique des transactions actuelles en bitcoins et exacerber la situation.

Restez humble, empilez les statistiques et construisez.

NOTES DE BAS DE PAGE

1. Le terme "témoin" a été adopté dans le bitcoin à partir du jargon de la cryptographie, où il fait référence aux données nécessaires pour vérifier efficacement une affirmation cryptographique. Le BIP141 la définit comme toute "donnée nécessaire pour vérifier la validité de la transaction mais non nécessaire pour déterminer les effets de la transaction". Les cryptographes ont peut-être repris le terme des marques témoins de fabrication utilisées pour vérifier efficacement l'alignement des composants.
2. Le projet Utreexo vise à changer cette situation pour un sous-ensemble de nœuds bitcoins en leur permettant d'accumuler efficacement des racines d'inclusion d'UTXO et de recevoir ensuite les chemins d'inclusion avec les dépenses de ces UTXO. Si ce mode d'utilisation du bitcoin devient courant, le coût de l'augmentation du nombre d'UTXO passera des nœuds aux détenteurs de ces UTXO.
3. Le projet ZeroSync vise à changer cette situation pour certains nœuds dans certains contextes.
4. Transaction ID : Double SHA256, dans l'ordre inverse des octets, de la transaction au format réseau pré-Segwit.
5. Plusieurs transactions valides avec les mêmes entrées et sorties ont des txids différents si elles sont signées de différentes manières ou si leur signature est modifiée par un tiers.
6. Elle peut être de n'importe quelle valeur sans hard fork car les anciens nœuds n'ont pas connaissance des données des témoins séparés.
7. 1 million ou moins pour maintenir la compatibilité et éviter un "hard fork".
8. En supposant l'utilisation de clés publiques compactes et de signatures DER à faible R/S de 71 octets.
9. Quelqu'un se souvient-il de Satoshi Dice?

Ce billet a été rédigé par Brandon Black. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.

Clause de non-responsabilité：

1. Cet article est repris de[bitcoinmagazine]. Tous les droits d'auteur appartiennent à l'auteur original[BRANDON BLACK]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.