La réduction pour les témoins  : pourquoi certains octets sont moins chers que d’autres

Ces données témoins1 sont réduites d’un quart du coût des autres données de transaction. Pourquoi accordons-nous une réduction à ces inscriptions ? Devrions-nous accorder une réduction à 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 grâce à des incitations humaines. Bitcoin aligne les incitations des mineurs et des opérateurs grâce à l’utilisation du 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 gestionnaires de nœuds sur celles des mineurs et des opérateurs, ni de l’alignement des incitations entre les expéditeurs et les destinataires.
Il y a eu 3 améliorations majeures à l’alignement des incitations de Bitcoin à ce jour :
1. Limiter la taille des blocs
2.

Déplacement du coût des scripts complexes de l’expéditeur au destinataire (P2SH)
3. Aligner les coûts des données entre les exécuteurs de nœuds et les transacteurs (SegWit)

Limiter la taille du bloc

Les opérateurs veulent effectuer de nombreuses transactions et les mineurs veulent percevoir de nombreux frais de transaction ; mais les exécuteurs 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 ce faire. Au début de l’histoire de Bitcoin, Satoshi s’est efforcé de résoudre ce problème en ajoutant une limite fixe de taille de bloc (appliquée par les nœuds).

La limite était de 1 million d’octets par bloc et imposait une limite supérieure à la quantité de données que les nœuds auraient besoin de télécharger et de vérifier. À l’époque, Satoshi écrivait : «[w]Nous pouvons introduire progressivement un changement plus tard si nous nous rapprochons du besoin. » Plus tard, faisant référence à un correctif visant à augmenter la limite, il a noté : «[d] »Si vous n’utilisez pas ce correctif, cela vous rendra incompatible avec le réseau », ce qui signifie que l’augmentation de la limite de taille de bloc est un changement difficile et nécessite plus de coordination, même qu’un soft fork.

Dans les années qui ont suivi, Bitcoin a délibérément évité de tels changements de hard fork incompatibles, ce qui implique également de maintenir la limite de taille de bloc de 1 million d’octets.

Transférer les 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 avec des scripts avancés, notamment multisig. Selon la conception originale, l’expéditeur d’une transaction Bitcoin placerait le script de verrouillage complet du destinataire dans sa transaction et paierait tous les frais pour que ce script de verrouillage soit inclus dans un bloc.

Les développeurs ont réalisé qu’à mesure que les frais augmentaient, les expéditeurs pourraient hésiter à payer les utilisateurs de scripts de verrouillage plus volumineux en raison du coût plus élevé du paiement de ces utilisateurs. Ces scripts de verrouillage complexes posaient également un problème d’encodage en adresses et de partage via des mécanismes à faible bande passante tels que le QR Code.
Pour résoudre ce problème, P2SH a été ajouté au Bitcoin en tant que soft fork.

Selon les règles de ce fork, au lieu de mettre l’intégralité du script de verrouillage du destinataire dans la sortie de la transaction, l’expéditeur en inclut simplement 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é par rapport au hachage du script sur lequel la pièce est verrouillée avant d’être validée. Avec ce changement, un script d’échange de n’importe quelle taille pouvait être représenté par un script de verrouillage d’une longueur fixe et les expéditeurs n’avaient plus besoin (ou capacité) de faire la distinction entre les destinataires en fonction de leurs conditions de dépenses.

Aligner les coûts des données entre les exécuteurs de nœuds et les transacteurs

La vérification la plus fondamentale que les nœuds effectuent sur les transactions Bitcoin est que le Bitcoin qu’ils tentent de dépenser existe bel et bien. Pour ce faire, chaque nœud conserve un index de chaque unité de bitcoin dépensable (sortie de transaction non dépensée, UTXO). Plus cet indice est grand, plus le coût de fonctionnement d’un nœud et de vérification des transactions futures est élevé2.

En conséquence, 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 plus grande partie de la plupart des scripts de déverrouillage Bitcoin est constituée de signatures cryptographiques. Ces signatures sont environ deux fois plus grandes que leurs clés publiques correspondantes, ce qui rend les scripts de déverrouillage (même sans P2SH) plus grands que les scripts de verrouillage.

Le coût nettement plus élevé de consommation par rapport à la création d’UTXO crée un conflit d’incitations entre les exécuteurs de nœuds et les opérateurs. Les opérateurs ne sont pas incités à dépenser leurs petits UTXO (surtout lorsque les frais sont élevés), préférant plutôt dépenser de gros UTXO et créer davantage d’UTXO de petite monnaie. Pendant ce temps, les exécuteurs de nœuds paient le coût de cette accumulation de petits 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 nettement moins fondamentale. D’ailleurs, un nœud Bitcoin exécutant 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 différents coûts sont imposés aux nœuds Bitcoin par différentes parties de la blockchain. Les données requises pour déterminer les effets de chaque transaction doivent être validées par la synchronisation de chaque nœud à partir du bloc Genesis3, les sorties de transaction ont tendance à être plus coûteuses que les entrées de transaction à long terme (surtout si elles durent longtemps), et une grande partie des données témoins n’est même pas vérifié, sauf pour les transactions les plus récentes.

Entrez le témoin séparé

Le soft fork du témoin séparé (SegWit) est le changement le plus ambitieux apporté au bitcoin à ce jour.

La principale motivation pour ce changement était de résoudre le problème de longue date de la malléabilité du TXID45 dans Bitcoin. Afin de corriger 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 modifier les effets de la transaction) du TXID, les protocoles (tels que Lightning) qui dépendent de TXID inchangés deviennent possibles.

Les données d’autorisation étant retirées de la structure de transaction d’origine, elles ne sont plus prises en compte dans la limite de bloc de 1 million d’octets. Une nouvelle limite est requise. De nombreuses approches pour limiter les données témoins séparées ont été discutées à l’époque : une limite d’octets témoins distincte6, une limite combinée de 7 ou une limite combinée pondérée.

En fin de compte, la limite combinée pondérée a été choisie, avec des données de témoin séparées pondérées à 1 unité, des données de transaction pondérées à 4 unités et une limite de bloc de poids de 4 millions. Chaque unité de poids est traitée comme 1/4 d’octet virtuel (vByte) aux fins du calcul des frais.
Pourquoi ces poids ? Examinons le coût des entrées et sorties de transaction avec et sans témoin séparé :
La première chose à noter dans ce tableau est la façon dont les types de scripts témoins (P2WPKH, P2WSH) ont presque le même nombre d’octets d’entrée et de sortie (qui sont facturés chacun un vByte complet).

Le dépensier d’un script témoin est ensuite facturé 1/4 de vByte pour les données autorisant la dépense, dont une grande partie n’est vérifiée que pour les transactions les plus récentes, et dont aucune n’a un coût continu dans l’index UTXO. L’autre chose à noter ici est la façon dont le coût d’utilisation d’un multisig 2 sur 3 plus sécurisé par rapport à une signature unique est réduit 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 « juste » qu’un moyen alternatif de verrouiller Bitcoin à l’aide d’un témoin séparé. Cela ne change pas ces incitations de manière significative. L’un des changements apportés à Taproot était de supprimer certaines limites sur la taille des scripts.

Cela a été fait pour réduire la complexité de la conception d’outils d’analyse pour les scripts Bitcoin et pour reconnaître le 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.
Passons maintenant au nœud du problème.

Les inscriptions sont révélées dans le témoin, elles ne sont donc facturées que 1/4 vByte par octet de données d’inscription. Est-ce un abus de la réduction pour les témoins ? La vérité est que les données d’inscription font partie des données 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 sur celle-ci est une seule vérification de hachage (garantissant que l’inscription révélée correspond à ce que l’inscrit avait prévu de révéler).

Ces données sont hachées une fois, puis ne sont plus jamais examinées par les nœuds. Il a un coût de calcul très faible (un ordre de grandeur inférieur à celui d’un script multisig de taille équivalente).
Mais les inscriptions font grimper les frais et éloignent les autres utilisateurs.

Oui ! Avec les logiciels actuellement disponibles pour interagir avec le réseau Bitcoin, les inscrits sont plus incités économiquement à effectuer leurs inscriptions que de nombreuses personnes n’en ont à effectuer d’autres transactions.
Cela met en évidence l’intérêt d’augmenter la densité économique des transactions Bitcoin. Le Lightning Network fait un grand pas en avant en permettant de regrouper des centaines, des milliers ou des millions de transactions économiques dans une seule transaction Bitcoin.

Plus la densité économique de chaque octet dans une transaction est grande, plus les frais payés pour cette activité économique sont faibles. À mesure que la densité économique des transactions Bitcoin augmente, d’autres utilisations de l’espace de bloc ont été et continueront d’être exclues9.
Il convient de noter que si les protocoles multisig hors chaîne tels que MuSig2 ou FROST, ou les signatures d’adaptateurs deviennent répandus ; il peut être judicieux de réduire ou d’éliminer la réduction accordée aux témoins.

Ces protocoles peuvent permettre de représenter des conditions de dépenses autrement importantes par une seule signature. Ceci, combiné aux dépenses efficaces en matière de chemin de clé 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 ciel tombant dans l’histoire du Bitcoin : construisez patiemment, construisez patiemment.

Nous pouvons faire beaucoup pour augmenter la densité économique des transactions Bitcoin, depuis la création de meilleurs portefeuilles Lightning vers Ark jusqu’aux contrats de journaux discrets et au-delà. La suppression de la réduction des témoins (prématurément), l’annulation de la racine pivotante ou des actions contre-productives similaires ne serviront qu’à réduire la densité économique des transactions Bitcoin actuelles et à aggraver la situation.
Restez humble, empilez les sats et construisez.

Notes de bas de page

Ceci est un article invité de 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.