NFT Month - Chapitre V - La

technologie derrière les NFT

Quentin Chabert

Adossé à la technologie blockchain, le NFT est en passe

de révolutionner la numérisation de la propriété. Pour
mieux appréhender sa transformation numérique et faire
un choix pleinement éclairé, il peut être judicieux d'en
connaître les mécanismes, et comprendre ce qui s'opère
sous le capot.

Que se cache-t-il techniquement derrière toutes ces

capacités ? Comment ces nouvelles normes ont réussi à
s'imposer dans un domaine en construction et pourquoi ?

I - Propriétés techniques
Indivisible : Un NFT ne peut être séparé en morceaux,
comme les bitcoins peuvent être divisés jusqu'à leur plus
petite unité, le satoshi (=10^-8 btc).

Un NFT est une entité définie de manière unique (sur

Ethereum : adresse du smart-contract, identifiant du
token). Même si sa propriété peut être partagée par
consensus, le NFT restera bien intact du point de vue du
smart-contract. On peut cependant imaginer que cette
"propriété partagée" puisse à son tour être échangée,
étant donné qu'elle reprend à son tour les caractéristiques
d'un NFT.

Non intéropérable: Chaque Nft est lié à un smart-

contract spécifique, qui contient les propriétés liées aux
token, ainsi que les fonctions que l'on peut exécuter
dessus. En effet, un personnage Aavegotchi n'est pas
autorisé nativement dans le protocole CryptoKitties par
exemple, malgré le fait que ces logiques se trouvent sur
Ethereum.

Les smart-contracts se développent rapidement, et on

voit émerger davantage de collaborations entre équipes et
projets, permettant notamment de plus riches interactions
entre les différents environnements dans le futur.

Indestructible : La structure du NFT et ses informations

étant stockées dans le smart-contract, ces données sont
publiques et ne peuvent être effacées irrémédiablement.

Même s'il est possible de "brûler" (burn) un NFT en

l'envoyant vers une adresse aléatoire comme 0x000...,
cela va simplement désactiver la possibilité que
quiconque puisse le transférer ou le modifier. En effet, le
token et ses données sont toujours accessibles sur le
smart-contract gérant son identité.

Vérifiable: Il est possible pour quiconque de tracer tout

mouvement d'un NFT depuis son origine, facilitant la
vérification de la nature du NFT que vous voudriez
acheter, vous prévenant des possibilités d'en acquérir un
frauduleux. Toute tentative de réplication ou de
falsification lèvera alors des soupçons auprès de
l'acheteur. Par exemple : si le célèbre NFT que vous
voulez acquérir a été généré il y a seulement 4 jours.

Voilà donc les propriétés principales qu'un NFT doit

posséder.

Le propriétaire d'un NFT est donc le seul capable de le

déplacer, il est, par exemple, le seul à posséder les droits
de cette œuvre d'art bien qu'il n'en soit pas le créateur.
Même la société l'ayant émise peut à terme perdre tout
droit de modification dessus.

II - Vers les premiers NFT

1- Bitcoin et l'émergence de nouveaux
tokens

Avec l'émergence du réseau Bitcoin et son incroyable

solidité, de véritables cas d'usage décentralisés voient le
jour et rapidement le bitcoin ne suffit plus.

Il n'a pas fallu longtemps avant que l'envie d'ajouter

d'autres tokens n'arrive aux idées des bitcoiners. Il fallait
pouvoir décrire d'autres actifs, d'autres tokens
représentant des quantités ou même des éléments
uniques.

La première tentative s'appelle les "colored coins".

En ajoutant des métadonnées à des transactions bitcoin -

généralement d'un faible montant - il est possible de
"colorer" cette somme de BTC. En effet, 100 satoshis
envoyés depuis une adresse Ownest, avec le code
"OWNEST" représentant des parts d'Ownest, seraient
interprétés dans un portefeuille blockchain compatible
avec les colored coins comme étant 100 parts de la
société Ownest. Cela permet, dès lors, de créer de
nouvelles classes de tokens et en adaptant un protocole
standardisé, permet la mise en place d'échanges
spécifiques d'assets, et non plus uniquement de BTC.

La première implémentation du protocole de colored coins

par ChromaWay fonctionnait en ajoutant directement des
données aux métadonnées des transactions bitcoin.
Techniquement, cela passait par un attribut nSequence qui
est un entier de 32 bits dont les 6 derniers représentent le
"tag" du colored coin permettant de l'associer à sa
famille.

La seconde implémentation - davantage standardisée par

OpenAssets - utilise plutôt les opcode, des instructions
permettant à bitcoin de posséder un langage script non
Turing-complet. En effet, mises bout à bout, ces
instructions forment une chaîne logique d'instructions
permettant de vérifier diverses conditions, comme la
possibilité d'empêcher le mouvement des bitcoins
associés à cette transaction avant une date spécifiée, par
ce script :<expiry time> OP_CHECKLOCKTIMEVERIFY
OP_DROP OP_DUP OP_HASH160 <pubKeyHash>
OP_EQUALVERIFY OP_CHECKSIG.

En utilisant ces mécanismes OpenAssets a en effet

standardisé une implémentation se basant sur le
"OP_RETURN" opcode, qui peut soit marquer une
transaction comme invalide soit être utilisé pour apporter
des metadonnées à partir de la version 0.9 du protocole
btc.

Mais revenons à nos moutons, les NFT, et observons

comme Bergson en faisait déjà la description :

"Sans doute on comptera les moutons d’un troupeau et

l’on dira qu’il y en a cinquante, bien qu’ils se distinguent
les uns des autres et que le berger les reconnaisse sans
peine". (Bergson)

Maintenant que nous pouvons créer des familles de

tokens il manque toujours les caractéristiques pour
obtenir un token ayant les caractéristiques d'un NFT.

Counterparty fût la première implémentation de NFT sur

une blockchain. C'est une couche logicielle qui se base
sur les données du réseau Bitcoin pour en représenter
certains aspects comme la possession de NFT et leur
caractérisation. À travers une standardisation poussée et
l'utilisation des métadonnées dans les transactions ils ont
ainsi créé les premiers NFT.

Mais l'innovation avance vite dans le secteur et Ethereum

va amener une modernité et une flexibilité supplémentaire
à la gestion de ces NFT.

2 - Les standards sur Ethereum

Indéniablement, la standardisation de ces protocoles est

essentielle pour achever un environnement uniforme et
interconnecté, et également afin de pouvoir créer des
explorateurs et autres interfaces de visualisation qui ont
besoin de normes pour fonctionner.

Avant d'aller plus loin sur les normes de tokens Ethereum

il est nécessaire de rappeler que chaque token sur
Ethereum autre que l'ether, sa crypto-monnaie native, est
géré par un smart-contract.

Un smart-contract peut être vu comme la combinaison de

classes objets et de stockage mis à disposition des
utilisateurs de la blockchain.
Le stockage contient les données long termes que le
smart-contract doit garder accessible afin de fonctionner.
Celui-ci est en réalité géré par les méthodes du contrat,
qui pilotent ces modifications.
Toute méthode publique du contrat peut être appelée par
n'importe quelle adresse du réseau, le contrat évaluera
ensuite si les droits de l'appelant sont bien en accord avec
sa demande, si les arguments fournis avec cette appel
sont bien conformes, etc, jusqu'à aboutir au résultat.

Un smart-contract peut donc être vu comme une classe

décentralisée sur laquelle chacun peut interagir selon les
règles du contrat, c'est-à-dire les méthodes exposées.
Contrairement à Bitcoin, le réseau Ethereum possède bien
un langage Turing complet.

Ces smart-contracts développables en Solidity par

exemple, sont ensuite compilés en bytecode (code
binaire) exécutable par l'Ethereum Virtual Machine (EVM).
L'EVM est en effet responsable de l'interprétation des
appels aux méthodes des smart-contracts, et chaque
noeud du réseau Ethereum compile de manière identique
grâce à l'EVM.
De l'espace de liberté qui découle de ces smart-contracts
plusieurs normes ont rapidement émergé : les tokens
fongibles ERC20, token non fongibles ERC721 et,
récemment, un standard proposant des tokens semi-
fongibles, l'ERC1155. Bien d'autres seraient à citer mais la
liste est longue : https://eips.ethereum.org/erc.

Nous nous concentrerons uniquement sur ces deux

standards encadrant les NFT : l'ERC721 et l'ERC1155.

Principes et structuration du standard NFT

ERC721

Les normes ERC sont décrites sous Ethereum comme un

ensemble de méthodes, d'attributs ou d'événements
qu'un smart-contract doit posséder. La norme ERC721
constitue l'interface minimale qu'un smart-contract doit
implémenter pour permettre la gestion de tokens unique,
leur possession et leur échange. Il ne constitue pas un
standard pour la gestion des métadonnées associées aux
tokens et n'empêchent pas l'ajout de fonctions
supplémentaires.

Sur ce contrat il faut notamment pouvoir accéder à une

structure de données appelée mapping en Solidity qui lie
un tokenId aux propriétés du token inscrites sur le
contrat, comme son propriétaire actuel ("owner").

Pour être compatible ERC721 voici également les

méthodes minimales à posséder :
balanceOf(address _owner) pour obtenir le solde d'une
adresse, c'est-à-dire le nombre de tokens qu'elle possède
sur ce contrat
ownerOf(uint256 _tokenId) permet d'obtenir l'adresse
du propriétaire actuel du token
safeTransferFrom et transferFrom qui permettent de
transférer un token du contrat identifié par son tokenId de
_from vers _to
approve and setApprovalForAll permet d'autoriser ou de
révoquer le droit d'une adresse d'envoyer les tokens du
portefeuille vers une autre adresse. Les adresses
autorisées peuvent être d'autres utilisateurs ou
d'opérateurs (comme un smart-contract ou un échange
décentralisé)
getApproved et isApprovedForAll permet d'obtenir si une
adresse est autorisée à transférer les tokens du porte-
feuille

Chacune de ces méthodes génère des événements

lorsqu'il s'agit d'un transfert ou d'une autorisation, des
traces visibles par tous et inscrites sur le registre
décentralisé d'Ethereum. Ces traces permettent
notamment de faciliter la compréhension de la nature des
interactions avec un contrat, dans le cas des explorateurs
de blockchain.

En plus de ces traces d'autres données, comme le nom

de l'ERC721 et son nom court, sont également
renseignées sur le smart-contract. Par exemple : par la
déclaration ERC721Full("Ownest", "OWN") qui crée un
contrat ERC721 du nom d'Ownest et dont les tokens
seront qualifiés par "OWN".

Voici la visibilité obtenue sur un explorateur de blockchain

type Ethereum pour une transaction avec un contrat
gérant des ERC721. Vous pouvez voir dans le 3ème
section "Tokens transferred" qu'il y a eu 2 transferts de ce
jeton ERC721 pour cette transaction :

En réalité, cette transaction représente l'achat d'un nom

de domaine Ethereum appelé ENS : Ethereum Name
Service. Ce nom de domaine est représenté par un token
ERC721, ici appelé "ownest.eth", obtenu par l'ENS.
Comme ce nom n'existait pas, la première transaction de
création provient de l'adresse 0x000... vers l'adresse
d'ENS, puis de l'ENS vers mon adresse. Cela permet de
facilement trouver l'adresse d'Ownest en cherchant
ownest.eth dans le contrat ENS ou un explorateur. Voici
une vraie transaction de ce service si vous souhaitez
davantage inspecter la blockchain :
https://etherscan.io/tx/0x5fe5ed7ad3888351d1b141c9c4
8a298f4ecd1e73436cabc4c8209beb5c65d022

Une implémentation complète de ces normes est fournies

par OpenZeppelin si vous souhaitez tenter d'en
développer je vous conseille un coup d'œil sur leur repo
github : https://github.com/OpenZeppelin/openzeppelin-
contracts

Un standard multi-token : l'ERC1155

Mais chaque famille d'ERC721 nécessite donc un contrat

propre, et cela peut rapidement devenir compliqué de
rajouter un contrat pour chaque classe de tokens que
vous possédez. Chez Ownest, par exemple, nous avons
des centaines de types de NFT, du colis au produit de
luxe, qui sont tous stockés dans le même contrat.

Ce standard multi-token s'appelle l'ERC1155. Il rend donc

possible la gestion de différents types de NFT au sein du
même contrat. Il est même possible de gérer des tokens
fongibles au sein de cette norme.

Un gros avantage en découle rapidement : au lieu de

devoir appeler 10 smart-contracts différents pour
transférer vos actifs, ces transferts peuvent désormais
être faits en une seule transaction. Cela a plusieurs effets
bénéfiques :

une meilleure UX pour l'utilisateur qui n'a plus à valider

individuellement chacun des transferts
une réduction des coûts des transactions puisqu'elles
sont groupées en une, ainsi qu'une réduction de
l'utilisation du réseau
de l'espace de stockage sur le registre distribué est
également économisé parce qu'il n'y a qu'un contrat
plutôt que des centaines

Maintenant que nous avons un réseau qui s'est mis

d'accord sur ces différentes structures des tokens il est
désormais possible d'en créer de tous types. Sur
Ethereum il en existe des milliers, de types variés, d'utilité
et de légitimité diverses.

Mais comment motiver ensuite l'utilisation de ces tokens ?

Comment amener cette transformation digitale au plus
grand nombre et garantir la vie des ambitieux projets
sous-jacents à ces tokens ?

III - Tokenomie
"Tokenomics" ? Il s'agit de la fusion des termes anglais
"token" et "economics".

L'économie représente étymologiquement «

l'administration de la maison » (de οἰκία / oikía, « maison
», et νόµος / nómos, « loi ») (wikipedia). Ce sont donc un
ensemble de lois régissant la vie au sein du foyer, ces
règles économiques ont ensuite été rendues plus globales
et régissent désormais de gigantesques systèmes
financiers.

Il en est de même pour la "tokenomie" : ce sont un

ensemble de règles du smart-contract qui vont permettre
de convaincre ou tout du moins d'inciter des utilisateurs
ou des investisseurs à s'engager avec le token. Beaucoup
de procédés peuvent être utilisés, de la rétribution
financière à d'autres récompenses. Il faut parfois
convaincre les joueurs, les créateurs, les vendeurs ou les
acheteurs et chaque paramètre de la tokenomie d'un
projet rentre en compte.

Cela utilise notamment la théorie des jeux qui vont

permettre d'orienter le comportement d'un joueur dans un
environnement dynamique s'il souhaite maximiser sa
réussite.

Voyons rapidement comment quelques projets ont créé

ces "incentives", ces mécanismes d'implication :

Aavegotchi

Aavegotchi permet de collectionner un certain nombre

de fantômes virtuels, les gotchis. Chaque gotchi est un
NFT, on peut y associer vêtements et accessoires en tout
genre. Afin d'engager davantage les utilisateurs au
perfectionnement du style de chaque fantôme, ils ont
développé un mécanisme de "récompense de rareté"
("rarity farming") : les 100 gotchis les plus rares
obtiennent des récompenses en $GHST, la monnaie de
l'écosystème Aavegotchi. Ainsi, chaque joueur est incité à
aller plus loin dans la construction de son univers et il
devient alors comme un objectif commun à atteindre pour
les joueurs. En plus de garantir l'implication des joueurs
cela favorise également la diversité de ces petites
créatures les gotchis afin d'avoir un univers toujours en
évolution.

La monnaie $GHST peut servir de plusieurs manières :

être échangée en jeu contre des objets, gotchis

être échangée contre d'autres crypto-monnaies sur les
échanges décentralisés comme Quickswap par exemple
être utilisée dans les votes pour l'évolution du projet.

En effet, la gouvernance des projets décentralisés tend à

être démocratique : les possesseurs de $GHST sont donc
invités à voter pour ou contre les différentes propositions
des développeurs ou de la communauté.

Pour parfaire la tokenomie du projet, Aavegotchi permet

également d'inclure des jetons de leur autre projet, une
banque décentralisée avec intérêt inclus sur chaque
crypto-monnaie déposée. En effet, si vous déposez
10ETH sur Aave, vous obtiendrez 10aETH et chaque aETH
rapporte un certain pourcentage par an. Ces aETH
peuvent désormais être insérés en propriétés sur un
gotchi afin d'en renforcer la puissance et son unicité, voire
la rentabilité de ces dépôts.

Rarible

Rarible est une plateforme de vente d'art numérique.

Chaque créateur peut définir le pourcentage qu'il recevra
lors des ventes ultérieures de ces œuvres. Cela permet
d'inciter les créateurs à choisir cette plateforme afin de
posséder le choix sur leur stratégie financière et leur
permettre de gagner un revenu durable.

Une photo sur internet peut être revendue/produite sans

que l'auteur en soit informé, cela garantit donc un
minimum de rétribution long terme pour chaque oeuvre
de l'artiste.

En garantissant la présence d'artistes cela permet de

proposer davantage d'œuvres aux différents visiteurs du
site et donc permet de maximiser la probabilité qu'un
acheteur et un vendeur fasse affaire.

Ownest

Chez Ownest nous souhaitons être capable de prouver à

tout instant le responsable d'un produit au sein de chaînes
d'approvisionnement. Pour cela nous avons donc
développé des NFT représentant les biens physiques,
ceux-ci sont détenus par le possesseur du produit
physique.
Par exemple, tant qu'un chauffeur possède 10 palettes et
40 colis dans son portefeuille NFT il est tenu responsable
des produits physiques. De plus, il ne peut pas transférer
ces tokens à une autre adresse sans son accord, cela
serait trop facile de s'en débarrasser et on ne pourrait
garantir que le nouveau propriétaire en devienne
sciemment responsable puisqu'il n'en a pas été informé.

Pour transférer ses NFT de responsabilité il est nécessaire

d'avoir l'accord du portefeuille de destination. Cela
permet d'éviter tout transfert qui viserait à se débarrasser
de la responsabilité.

De plus, comme chaque personne est responsable du

contenu de son portefeuille, cela va inciter les utilisateurs
à ne pas oublier de les transférer en parallèle du transfert
physique. Également, l'état et la qualité des produits reçus
peuvent être validés par consensus entre les deux parties
et chaque bien reçu peut être scrupuleusement inspecté
afin de reporter correctement son état.

Avec ces mécanismes nous arrivons à faire correspondre

les NFT de nos clients dans leurs réseaux logistiques à
une réalité présente, pour que le token décrive toujours
l'état actuel du produit physique et son propriétaire.
La technologie et les normes derrière les NFT sont en
perpétuelles évolutions, et il est fort probable que leur
définition et leurs capacités changent encore au cours
des prochaines années. Les cas d'usage et leurs
déclinaisons vont continuer à mettre à l'épreuve ces
standards et d'autres vont continuer d'émerger. On peut
notamment penser à l'accusé de réception, mécanisme
développé au sein d'Ownest, qui ne possède pas
d'équivalent standardisé.