La controverse des "Ordinals"

Des NFT dans les entrailles du Bitcoin… Affront, amenuisement de la décentralisation, non évènement ? Le débat fait rage.

Ordinals

Commençons par la fin. Les « Ordinals » sont des NFT qui squattent dans les blocs Bitcoin.

Créé par Casey Rodarmor, « Ordinals » est un système permettant en essence de numéroter les 2.1 quatrillons de satoshis en fonction de l’ordre dans lequel ils sont minés.

Le protocole Ord consiste en un wallet et un explorateur permettant de suivre l’emplacement de satoshis spécifiques via leurs numéros ordinaux ainsi que de créer et de transférer des « inscriptions ».

Ces inscriptions associent des satoshis à un jpeg (ou video, pdf, etc) et sont stockées dans le Witness (nous y reviendrons) d’une transaction BTC. C’est la grande différence avec la plupart des NFT dont les fichiers sont hébergés sur un serveur comme Opensea.

Cette nuance est considérée comme un attribut positif puisque « l’œuvre d’art » est vraiment stockée de manière décentralisée. Il ne s’agit plus d’un simple hash qui se contente de pointer vers un serveur centralisé qui pourrait disparaitre.

En résumé, les inscriptions (des NFT Bitcoin on-chain) sont enregistrées dans les blocs via une transaction BTC. Et le fait est que ces transactions sont beaucoup plus volumineuses que les transactions normales :

BREAKING: 🚨 NFTs ON #BITCOIN

Ordinals are taking up most of the BLOCKSPACE 😯 pic.twitter.com/Gxwq4vV8MI

— Bitcoin News ⚡ (@BitcoinNewsCom) January 29, 2023

D’où la controverse

Les sourcils se lèvent face à ces blocs très lourds, mais contenant très peu de transactions. Certains y voient une attaque Dos. La raison étant que ces transactions volumineuses remplissent les blocs à peu de frais.

C’est un problème dans le sens où les nœuds qui font respecter le protocole Bitcoin devront allouer plus d’espace disque pour stocker l’historique des transactions du réseau BTC. C’est un coût qui nuit in fine à la décentralisation du réseau.

En effet, après 14 longues années, un nœud n’a besoin que de 471 Go d’espace disque. Nous en serions à plus de 735 Go si chaque bloc avait été rempli à ras bord. On comprend donc le risque en cas de popularisation de ces NFT sur Bitcoin.

[Nous pourrions même en être à 1600 Go si les nœuds SegWit téléchargeaient toutes les données du Witness. Nous y reviendrons.]

Tout cela étant dit, toutes les transactions sont en compétition. Celui qui paie le plus de frais est prioritaire. Point barre. Les transactions contenant un NFT voulant être validées en priorité devront payer des frais de transaction proportionnels à l’espace qu’ils occupent.

Dit autrement, on ne peut pas parler stricto sensu d’attaque Dos. Et puis, à charge pour les mineurs (ou plutôt les pools de mining, puisque ce sont eux qui choisissent les transactions) de faire le tri si ces NFT les dérangent.

Mais comment est-il possible d’ajouter du « contenu arbitraire » volumineux dans les transactions d’un protocole aussi carré que le Bitcoin ? Bonne question.

Big Block

Il faut pour répondre à cette question se pencher sur une modification majeure du protocole Bitcoin : SegWit. Mais avant ça, un peu d’Histoire.

Pour rappel, l’une des règles de consensus du protocole Bitcoin est que chaque bloc ne doit pas contenir plus d’un million d’octets (1 Mo). Ce million d’octets se constitue de données telles que le hash du précédent bloc, le nombre de transactions, les transactions elles-mêmes, etc.

Un bloc dépassant 1 Mo sera rejeté par les nœuds. Cette limite vise à garantir un certain niveau de décentralisation. Une taille de bloc illimitée verrait l’espace disque nécessaire s’envoler. Adieu la décentralisation.

Cette décentralisation a pour conséquence un faible débit de transactions (une grosse poignée de transactions par seconde). Si bien que les frais de transaction peuvent exploser s’il y a embouteillage dans le mempool. Ces frais ont déjà atteint 50 dollars par transaction à deux occasions :

Ce problème (qui n’est pas un bug, mais un attribut essentiel à la décentralisation) déboucha sur la guerre du « Big Block ».

Ceux qui voulaient augmenter la taille des blocs, quitte à sacrifier sa décentralisation, finirent par « hard forker » en créant Bitcoin Cash (BCH).

Les autres misèrent sur le Lightning Network (second layer). Ce dernier n’étant pas encore opérationnel à l’époque du schisme, on para au plus pressé en quadruplant la taille des blocs via le soft fork SegWit (Segregated Witness).

Le Soft Fork SegWit

SegWit est une évolution du protocole Bitcoin Core. Les « blocs SegWit » font 4 Mo. Mais puisqu’il s’agit d’un soft fork, ces blocs sont tout de même validés par les nœuds n’ayant pas voulu se mettre à jour (appelons les « nœuds Legacy »).

Dit autrement : Soft fork = nouvelles règles de consensus compatibles avec les anciennes.

L’idée derrière SegWit est qu’une partie des données d’une transaction (signature, pubkey, etc.) est ségréguée dans une section spéciale de la transaction appelée « Witness ».

Les données du Witness n’étant pas comptabilisées par les nœuds Legacy, il est possible de faire des blocs allant jusqu’à 4 Mo sans dépasser la limite de 1 Mo.

Sans entrer dans les détails, cette ségrégation des données fait que la taille du bloc envoyé aux nœuds legacy ne dépasse pas 1 Mo tout en contenant quatre fois plus de transactions.

Le Witness

Maintenant que nous avons expliqué qu’il y a pas mal d’espace disponible dans un bloc BTC, reste à savoir comment est-il possible de rentrer des « inscriptions » de NFT dans un bloc.

Le stockage de données arbitraires on-chain est en vérité possible depuis toujours. Satoshi a utilisé le coinbase pour intégrer un titre de journal dans le bloc genesis : « The Times 03/Jan/2009 Chancellor on brink of second bailout for banks ».

Mais le coinbase ne permet pas de stocker beaucoup de données (80 octets). Cet espace est par ailleurs réservé aux mineurs.

Il est également possible d’utiliser la fonction Op_RETURN pour insérer des données arbitraires. Mais là encore, seulement 80 octets. Ce n’est pas assez.

Néanmoins, la récente mise à jour Taproot a levé certaines limites de taille assignées à la section du Witness, ce qui permet d’insérer un NFT pouvant théoriquement peser jusqu’à 4 Mo à partir d’une seule transaction… Des données « arbitraires » signifient qu’elles ne participent pas au mécanisme venant modifier l’historique des transactions.

A contrario, certaines données sont absolument nécessaires pour créer un bloc. Notamment le hash du bloc précédent, le hash de la racine de l’arbre de Merkle (l’historique des transactions), les adresses BTC, les montants de BTC échangés, les signatures des clés privés, etc.

Un bloc doit également contenir un hash indiquant l’heure et la date de création du bloc (time stamp). Ou encore le nonce (diminutif en anglais de « number only used once ») que les mineurs font varier dans le cadre du « consensus Nakamoto » du Proof-of-Work.

Les données arbitraires sont à contrario des données ne participant pas au protocole Bitcoin. C’est le cas de ces fameuses « inscriptions » dont Casey Rodarmor se sert pour créer des NFT au cœur du Bitcoin.

Terminons en rappelant cette déclaration faite par Jeff Garzik (un des principaux Bitcoin Dev Core de l’époque) sur le forum Bitcointalk, en 2014, lorsque le débat que nous avons aujourd’hui faisait déjà des étincelles :

« Jusqu’à présent, je n’ai pas vu de schéma d’intégration de données sur la blockchain qui ne puisse être remplacé en toute sécurité par un simple hash. Il est inutile de stocker des données dans la blockchain. C’est de la pure paresse intellectuelle. Faire de l’horodatage en insérant un hash est tout aussi sûr et plus efficace. En outre, une side chain peut être adossée au bitcoin. »