sam. Jan 1st, 2022
    TrueNFT, RSquad, TON Surf

    Le lundi 16 août, l’équipe combinée de développement de Surf et RSquad a présenté son concept True NFT à la sous-gouvernance, et le 23 août participera à la session AMA Free TON. Tnft.surf a déjà été préparé pour les utilisateurs, et nous publions la première partie de la description technologique d’une solution fondamentalement nouvelle de création de jetons NFT.

    Comment devenir réalité

    Dans cet article, nous analyserons ce qu’est TrueNFT, comment la technologie a été créée, son architecture, les principaux scénarios, parlerons des options de personnalisation et répondrons à la question principale : quelles exigences un système fini doit remplir pour s’appeler True NFT.

    True NFT, c’est quoi

    True NFT est une technologie créée conjointement par les équipes Surf et RSquad pour implémenter des tokens NFT basés sur le réseau Free TON.

    La technologie autorise:

    • le fait d’être sûr que toutes les données NFT sont stockées sur la blockchain sans dépendre de protocoles tiers ;
    • le fait de simplifier et standardiser les requêtes de recherche de collections et de jetons NFT de l’utilisateur ;
    • aux utilisateurs d’interagir avec leurs jetons dans des navigateurs et dApp décentralisés en connaissant uniquement leur propre adresse, et de les transférer en connaissant uniquement l’adresse du destinataire.

    Une Tâche

    Au début du développement, des implémentations NFT existaient déjà dans la blockchain Free TON, par exemple, TIP-3 NFT. De plus, TIP-31 vient d’être publié, développant les idées de TIP-3 et offrant de nouvelles opportunités pour développer des contrats, et personne n’a annulé l’option avec la mise en œuvre de l’analogue ERC-721.

    Les équipes Surf et RSquad ont été chargées d’étudier les solutions existantes et de développer la technologie NFT pour Free TON répondant aux exigences suivantes :

    • se concentrer sur une convivialité maximale : un utilisateur qui ne connaît que son adresse Surf doit disposer d’un ensemble complet d’outils pour travailler avec ses tokens NFT ;
    • permettre à l’utilisateur de transférer des jetons à d’autres utilisateurs ou systèmes, en connaissant uniquement l’adresse du destinataire ;
    • afficher les jetons dans le portefeuille sans spécifier d’adresses supplémentaires ;
    • créer un système universel et hautement personnalisable ;
    • enregistrer le contenu du jeton exclusivement sur la chaîne.

    L’étude des solutions existantes a montré qu’elles ne répondent pas aux exigences ci-dessus et ont beaucoup de problèmes concernant la tâche. Par exemple, l’ERC-721 classique actuel est irréalisable sous condition dans Free TON en raison de mappages volumineux, et TIP-3 oblige les utilisateurs à déployer des portefeuilles supplémentaires pour chaque collection NFT.

    De plus, vous ne pouvez envoyer des jetons qu’entre ces mêmes portefeuilles, dont vous devez connaître les adresses. En multipliant ces problèmes car il faut trouver un mécanisme pour récupérer tous les jetons de l’utilisateur, ne connaissant que son adresse, on arrive à la conclusion : il faut trouver quelque chose de nouveau.

    Comment L’idée Est Née Et A Eté Développée

    À la suite d’un brainstorming, il est devenu évident pour l’équipe que chaque portefeuille NFT doit générer une adresse afin qu’il puisse être trouvé sur tout le réseau, par exemple, en stockant l’adresse du propriétaire dans les données initiales.

    La solution permettrait de retrouver tous les wallets de l’utilisateur qui contiennent ses tokens. Cette approche a supprimé un certain nombre d’abstractions de TIP-3 et a apporté des éléments de TIP-31, mais a encore laissé beaucoup de questions :

    • comment transférer des jetons à un utilisateur qui n’a pas encore de portefeuille dans la collection.
    • qui devrait payer pour déployer des portefeuilles.
    • comment garantir une personnalisation maximale dans le cadre de la mise en œuvre d’un système particulier.

    Toutes ces questions ont incité l’équipe à conclure qu’il est nécessaire de se débarrasser des portefeuilles dans le cadre du système.

    En conséquence, l’équipe a décidé, inspirée par TIP-31, de créer une nouvelle fonctionnalité — pour stocker le propriétaire d’un jeton spécifique dans les données initiales, le rendant ainsi consultable, en gardant l’adresse unique et en supprimant l’ancien contrat, et déployer un nouveau lors du transfert du jeton. De plus, placer les données dans un contrat distinct non amovible et créer une sorte d’index de recherche pouvant être recréé lorsque le propriétaire du jeton change. Ainsi, un moyen a été trouvé qui a conduit l’équipe à la solution de la tâche.

    La solution elle-même est devenue possible grâce à la représentation de la blockchain Free TON comme un stockage clé:valeur, où la clé est une certaine combinaison du code du contrat et des données initiales, et la valeur est l’adresse ou le contrat lui-même.

    Dans Free TON, il existe de nombreuses façons de trouver le bon contrat en plus de l’habituel “ Je connais l’adresse — je peux tirer ”. Il existe un grand nombre de contrats similaires au sein du réseau en termes de fonctionnalités (tels que des concours ou des collections NFT), et Free TON vous permet de tous les obtenir. Il suffit de comprendre qu’un contrat a un code, vous pouvez en tirer un hachage, utiliser GraphQL et obtenir toutes les adresses où se trouvent les contrats correspondant au code spécifié.

    L’adresse dans Free TON est une combinaison du code du contrat et de ses données initiales. Ainsi, connaissant ces deux paramètres utilisés dans le déploiement du contrat, il est possible de calculer son adresse. Il est important de comprendre que le code peut être modifié ultérieurement, mais pas l’adresse. Par conséquent, la recherche par hachage de code et la collecte d’une adresse sont des choses fondamentalement différentes.

    Avant la publication du TIP-31, la possibilité de saler le code du contrat a été ajoutée, c’est-à-dire d’ajouter un ensemble de données ( sel ) au code compilé avec la possibilité ultérieure de le lire. Cela n’affecte pas les mécanismes décrits ci-dessus, mais cela vous permet de stocker des données non seulement dans les données initiales mais également dans le code du contrat lui-même, ajoutant une certaine flexibilité au processus d’initialisation.

    Ainsi, nous avons un concept simple : créer un ensemble de contrats système immuables qui serviront d’index de recherche, et leur ajouter un ensemble de contrats qui contiendront une logique et des données personnalisées.

    Solution

    Figure 1. Architecture conceptuelle du système

    La figure 1 montre un diagramme de contrat du système conceptuel résultant. Le noyau du système développé et des exemples peuvent être trouvés dans le référentiel.

    IndexBasis

    IndexBasis, ou simplement base, est un contrat utilisé pour trouver toutes les collections NFT sur le réseau. Sur le schéma, vous pouvez voir que son code n’est pas “ salé ”, et l’unicité de l’adresse est obtenue en ajoutant une adresse de contrat NftRoot et le code de hachage du contrat Data. Ainsi, pour être considéré comme TrueNFT, chaque système doit émettre une base pour chaque collection NFT.

    IndexOwner and IndexOwnerRoot

    Ces contrats sont regroupés en un seul groupe car ils sont essentiellement identiques et héritent du contrat Index. En d’autres termes, ils ont le même code, mais ils sont nécessaires à des fins différentes et sont “ alés ” de différentes manières.Dans les deux index, l’adresse du contrat Data est stockée dans les données initiales, qui sont un lien entre l’index et Data. IndexOwner est “ salé ” avec uniquement l’adresse du propriétaire, ce qui nous permet de rechercher tous les jetons d’un utilisateur spécifique, et IndexOwnerRoot est “ salé ” avec à la fois l’adresse du propriétaire et l’adresse NftRoot, ce qui nous permet de trouver tous les jetons d’utilisateur dans un collection spécifique en une seule requête. Conclusion : pour être considéré comme TrueNFT, chaque système doit émettre un IndexOwner et un IndexOwnerRoot pour chaque NFT.

    NftRoot

    Un contrat de collecte NFT contient généralement une logique de frappe de jetons et des informations sur une collection. Il convient de noter que parce que le contrat a une base, la mise en œuvre du contrat peut être complètement différente au sein de différents systèmes. Le référentiel du projet et le diagramme ne contiennent qu’un exemple de l’implémentation de base de NftRoot pour une compréhension générale du concept du système.

    Data

    Le contrat de données (Data) de jeton NFT, ou simplement NFT, contient les données de jeton, un lien vers le média, généralement la logique de transfert, et un ensemble de logiques supplémentaires. Le contrat, comme NftRoot, est entièrement personnalisable car le jeton a un ensemble de champs différent au sein de différentes collections.

    Dans l’exemple de l’implémentation de base, le transfert est également implémenté dans Data, afin de sauvegarder les transactions, mais dans les systèmes réels, il peut être déplacé vers un contrat séparé ou être totalement absent. Pour être considéré comme TrueNFT, chaque système doit stocker toutes les données NFT dans un contrat de données ou avoir des liens vers d’autres contrats au sein du réseau, toutes les données provenant d’autres sources ne sont pas considérées comme faisant partie du système.

    Les données incluent un script pour télécharger des médias et créer un lien vers celui-ci. Nous considérerons cet aspect du système dans de futures publications.

    Nous avons un ensemble de trois index de recherche qui doivent être immuables dans tous les systèmes TrueNFT, les contrats NftRoot et Data, qui contiennent la logique d’un seul système et sont entièrement personnalisables.

    Transfert de jeton

    La partie la plus importante de la technologie est le scénario de transfert de propriété. La logique autour du transfert peut être absolument quelconque, mais pour s’appeler TrueNFT, le système doit préserver la logique de transition NFT d’un propriétaire à un autre, quelle que soit la logique qui l’entoure.

    Considérons un scénario de transfert de propriété de base dans un système où le propriétaire d’un token peut transférer son token à n’importe qui. L’utilisateur connaît l’adresse de l’autre utilisateur auquel il souhaite envoyer son NFT.

    Figure 2. Séquence de transfert de propriété

    L’utilisateur saisit l’adresse du destinataire dans l’interface et le jeton est transféré sans action supplémentaire. Le destinataire peut voir le jeton reçu dans son interface sans effectuer aucune action. Cela semble simple. Sous le capot, l’utilisateur appelle la méthode de transfert depuis son contrat Data. Ensuite, Data supprime ses index de recherche, change de propriétaire et déploie de nouveaux index avec un nouveau propriétaire dans les données initiales.

    L’intégrité des données est préservée. A tout moment, le NFT (tant en termes d’indices qu’en termes de contrat Data) appartient à un seul propriétaire ou n’appartient à personne.

    Une logique supplémentaire, par exemple des redevances à l’auteur, peut être mise en œuvre dans le cadre de la méthode de transfert de propriété elle-même, ou il peut n’y avoir aucune méthode du tout, et le transfert ne peut être effectué que lors de l’achat — cela n’a pas d’importance. L’important est que pour que le système s’appelle TrueNFT, il doit préserver la logique du transfert de propriété avec la recréation des index de recherche et le changement de propriété dans le contrat Data.

    Frappe de jetons (Minting)

    La frappe de jetons fonctionne presque de la même manière qu’un transfert.

    Figure 3. Séquence de frappe

    L’utilisateur qui peut émettre des jetons appelle NftRoot lors du transfert de données NFT. NftRoot déploie le contrat Data, qui à son tour déploie ses index. Les droits de frappe, leur présence/absence en tant que tels, ou la frappe à l’achat, par exemple, est une partie personnalisable du système. Dans le même temps, pour que le système s’appelle TrueNFT, il doit conserver la logique de création de jetons avec des index de déploiement et de recherche de date.

    Rechercher et afficher

    Dans le processus, des exigences spécifiques pour les capacités de recherche ont été formalisées. Le système doit vous permettre de tout trouver :

    • collections;
    • jetons d’utilisateur;
    • jetons d’utilisateur au sein de la collection ;
    • jetons au sein de la collection.

    Comme nous le savons déjà, Free TON nous fournit l’API GraphQL comme interface pour obtenir des données de la blockchain (en fait, bien sûr, pas directement de la blockchain, mais de la base de données de mise en cache, ce qui nous donne des outils supplémentaires pour rechercher et filtrer ), à partir de laquelle nous pouvons obtenir des adresses.

    Total:

    • pour obtenir des données sur tous les jetons utilisateur, nous devons prendre le code du contrat IndexOwner, saler l’adresse de l’utilisateur, la hacher et interroger l’API GraphQL sur les comptes avec le code_hash reçu ;
    • la même action pour toutes les collections — nous prenons le code du contrat IndexBasis, le hachons, l’interrogeons et obtenons toutes les collections du réseau ;
    • pour les jetons d’utilisateur au sein d’une collection, nous prenons IndexOwnerRoot, le salons avec l’adresse de l’utilisateur et l’adresse de la collection d’intérêt, le hachons, l’interrogeons ;
    • pour trouver tous les tokens d’une collection, il suffit de prendre la base de cette collection, et elle a déjà un code date hash, grâce auquel on peut retrouver tous les tokens de la collection, car les données sont salées par l’adresse NftRoot.

    Toutes les opérations sont en fait effectuées par une seule requête, mais, bien sûr, pour obtenir les données directement, il faudra parcourir chaque contrat séparément, mais la liste est assez facile à obtenir.

    La réponse à la question de savoir pourquoi nous avons besoin de ces index si nous pouvons personnaliser l’interface au sein de chaque projet individuel est simple. Au fur et à mesure que l’écosystème se développe, des catalogues montrant toutes les collections et des portefeuilles montrant tous les jetons d’utilisateur seront créés. La standardisation en la matière permettra à tous les systèmes répondant à la norme d’être automatiquement répertoriés dans ces catalogues, par simple déploiement sur le réseau.

    Conclusion

    Nous avons déduit plusieurs exigences pour qu’un système soit considéré comme TrueNFT, il doit:

    • émettre IndexBasis pour chaque NftRoot ;
    • émettre IndexOwner et IndexOwnerRoot pour chaque donnée ;
    • stocker toutes les données dans le contrat de données ou avoir des liens vers d’autres contrats au sein du réseau ;
    • Les contrats IndexBasis, IndexOwner et IndexOwnerRoot sont unifiés et ne sont soumis à aucune modification au sein des systèmes TrueNFT ;
    • préserver la logique de transfert de propriété avec une recréation d’index de recherche et de changement de propriété dans le contrat Data.

     ________________________

    Dans les prochains articles, nous parlerons du téléchargement de médias, écrirons notre système TrueNFT simple, examinerons des exemples de réception et d’affichage de jetons et discuterons de la façon de développer des applications qui fonctionnent avec des registres décentralisés dans les blockchains modernes.

      Surf & RSquad

    26
    0