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/0x5fe5ed7ad3888351d1b141c9c48a298f4ecd1e73436cabc4c8209beb5c65d022

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é.