Les + populaires

BTC ETH SOL XRP BNB USDC USDT

Suivez-nous

Contrats de référentiel de fractions NFT | par Szabolcs Szentes | Coinmoines | octobre 2021

IAavec
Szabolcs Szentes

Les référentiels de fractions NFT sont basés sur la norme ERC1155 qui est la deuxième norme de facto pour les NFT en plus de l’ERC721. Les contrats ERC1155 sont une combinaison de jetons fongibles et non fongibles. Dans ERC721, chaque jeton est unique et possède ses propres paramètres, métadonnées, historique, etc. En plus de cela, dans ERC1155, chaque jeton est également associé à un montant. Ce montant peut être traité comme des copies du jeton d’origine, des actions, des éléments identiques ou toute autre abstraction significative que vous pouvez proposer. ERC1155 a été développé par Enjin pour représenter des éléments de jeux. Ces objets peuvent être des épées (beaucoup du même type), des bagues (7 dans certains contextes) ou tout autre élément qui pourrait être unique (le montant est un – alias non fongible) ou associé à un montant supérieur à un (fongible). Ces différents éléments peuvent s’intégrer dans un même contrat ERC1155. Le même effet pourrait être obtenu avec l’ERC721 en déployant des contrats séparés pour chaque article : un contrat pour les épées, un pour les anneaux, etc. L’inconvénient est évident. Vous pouvez en savoir plus dans la proposition originale.

Dans notre cas, ERC1155 est un choix simple pour frapper des fractions d’un NFT à l’origine unique. Chaque jeton du référentiel de fractions NFT représente un NFT unique créé à l’origine dans un autre contrat. Le montant associé à chaque jeton ERC1155 correspond aux fractions frappées pour ce NFT.

Pour simplifier, la fonction de dépôt NFT n’est disponible que sur Polygon et non sur BSC. L’application est donc en quelque sorte asymétrique dans la mesure où les fractions NFT proviennent de Polygon et peuvent ensuite être négociées sur BSC après les avoir transférées. Du point de vue de l’expérience utilisateur, lorsque l’utilisateur dépose son NFT dans le NFT Fractions Dex, il se passe ce qui suit :
– Le NFT est transféré à l’adresse du Dex dans le contrat original où le NFT a été frappé. C’est le mécanisme de verrouillage pour empêcher l’utilisateur de vendre son NFT à moins qu’il ne le retire du Dex. Pour garder les choses simples, le Dex n’utilise aucun système de coffre-fort, il transfère simplement le NFT dans le contrat d’origine.
– Un nouveau jeton ERC1155 est émis avec un montant donné qui représente les actions/fractions.
– La norme ERC1155 implémente un système d’approbation pour permettre le transfert de token comme dans ERC721. Ainsi, avant le dépôt, il est demandé à l’utilisateur d’approuver le contrat Dex pour transférer son NFT.
– Seuls les NFT peuvent être retirés du Dex dont toutes les actions appartiennent au même utilisateur. En d’autres termes, l’utilisateur doit acquérir la propriété entière (toutes les actions) d’un NFT avant de le retirer.

Regardons de plus près les contrats de référentiel de fractions NFT :

L’interface définit des fonctions de niveau supérieur qui sont appelées à partir d’autres contrats intelligents, par exemple : à partir de contrats de pont :
– Burn and mint sont directement liés aux contrats-relais. Lorsque quelqu’un transfère ses jetons d’une chaîne à l’autre, le contrat de pont appelle la fonction burn sur la chaîne d’origine et la fonction mint sur l’autre chaîne. Plus d’informations sur celui-ci dans un article détaillé ultérieur sur le pont lui-même.
– TransferFrom est identique à safeTransferFrom dans ERC1155 avec une restriction, le contrat n’est pas suspendu et il introduit également une fonction de crochet (_afterTransferFrom).
– GetTotalFractionsAmount et getErc721ContractAddress ne sont que des fonctions de lecture

Le contrat de base (NftFractionsRepositoryBase) implémente les fonctions de l’interface et introduit les fonctions de crochet qui peuvent être implémentées par les contrats enfants. Ces fonctions de hook offrent la possibilité de hooker une logique (émission d’événements ou mise à jour de structures de données internes) comme détaillé à la fin du post précédent.

Les contrats spécifiques à la chaîne reflètent la différence entre l’utilisation du graphique pour la lecture de données et la lecture directe à partir de contrats intelligents. Dans le cas des contrats Polygon, ces hooks contiennent l’émission d’événement et dans le cas des contrats BSC, ces fonctions hook mettent à jour les structures de données internes.

Commençons par le contrat Polygon (MaticFractionsRepositoryBase). Il implémente les fonctions depositNft et withrawNft car elles ne sont disponibles que sur Polygon. De plus, il émet les événements depositNft et removeNft correspondants qui sont indexés par le Graph.

En revanche, le contrat BSC (BscNftFractionsRepository) gère trois structures de données internes différentes :
– identifiants de jetons par les actionnaires
– propriétaires par token ID
– tous les identifiants de jeton
Tous ont une fonction getter correspondante :
– getTokenIdsByShareOwner
– getOwnersBYtokenId
– getTokenIds
Ils servent les cas d’utilisation de l’affichage des données pour l’interface utilisateur :
– Liste des NFT pour un utilisateur donné
– Liste des propriétaires d’un NFT donné
– Tous les NFT

Dans la section suivante, nous détaillerons les contrats DEX.

Si vous souhaitez accéder à d’autres articles de la série, vous pouvez trouver des liens dans l’article principal.

Ou si vous souhaitez voir mes autres projets et contributions :

https://www.szabolcsszentes.com/

Rejoignez Coinmonks Telegram Channel et Youtube Channel pour en savoir plus sur le trading et l’investissement crypto

Source medium.com

Pilotez vos investissements
TradingView
15$ offerts sur l’abonnement

Donnez votre avis

Soyez le 1er à noter cet article


Partagez cet article maintenant !

Envoyez simplement nos contenus crypto et finance à vos proches.