onflow/flow-nft : la norme de jeton non fongible sur la chaîne de blocs de flux

Ceci est une description de la norme de travail en cours pour les contrats de jetons non fongibles sur la Flow Blockchain. Il est censé contenir les fonctionnalités minimales pour mettre en œuvre un contrat de jeton non fongible sûr, sécurisé, facile à comprendre et à utiliser dans Cadence.

Qu’est-ce que le flux ?

Flow est une nouvelle blockchain pour les mondes ouverts. Lire la suite ici.

Qu’est-ce que Cadence ?

Cadence est un nouveau langage de programmation orienté ressources pour développer des contrats intelligents pour la Flow Blockchain. Lire la suite ici

Nous recommandons à toute personne qui lit ceci d’avoir déjà terminé le Tutoriels de cadence
afin qu’ils puissent développer une compréhension de base du langage de programmation.

La programmation orientée ressources, et par extension Cadence, est l’environnement de programmation parfait pour les jetons non fongibles (NFT), car les utilisateurs peuvent stocker leurs objets NFT directement dans leurs comptes et effectuer des transactions d’égal à égal. S’il vous plaît voir le article de blog sur les ressources
pour comprendre pourquoi ils sont parfaits pour les actifs numériques.

Retour

Flow et Cadence sont tous deux encore en développement, donc cette norme subira encore de nombreux changements à mesure que le protocole et le langage évoluent et que nous recevons des commentaires de la communauté sur la norme.

Nous serions ravis d’avoir des commentaires. Les principaux commentaires que nous recherchons sont :

Y a-t-il des fonctionnalités qui manquent à la norme ?
Les fonctionnalités que nous avons incluses sont-elles définies de la meilleure façon possible ?
Y a-t-il des conditions pré et post qui manquent ?
Les conditions pré et post sont-elles suffisamment bien définies ? Messages d’erreur?
Y a-t-il d’autres actions qui nécessitent un événement défini pour elles ?
Les définitions des événements actuels sont-elles suffisamment claires et fournissent-elles suffisamment d’informations ?
Les noms de variables, de fonctions et de paramètres sont-ils suffisamment descriptifs ?
Y a-t-il des ouvertures pour des bogues ou des vulnérabilités que nous ne remarquons pas ?

Veuillez créer un problème dans ce référentiel s’il existe une fonctionnalité qui, selon vous, doit être discutée ou modifiée.

Fonctionnalités principales (interface principale NonFungibleToken)

Ces fonctionnalités sont celles qui sont spécifiées dans l’interface pour les NFT. Veuillez noter qu’un contrat NFT qui implémente l’interface peut inclure d’autres fonctionnalités en plus de celles-ci s’il le souhaite. Sachez également qu’avec la façon dont les contrats intelligents Cadence définissent les objets et avec la façon dont les objets peuvent être facilement intégrés dans d’autres contrats, de nombreuses autres actions et fonctionnalités sont possibles même avec un contrat qui ne définit que la fonctionnalité minimale.

L’interface principale nécessite que les types d’implémentation définissent un NFT ressource et un Collection ressource qui contient et gère ces NFT.

1 – Obtenir des métadonnées pour le token smart contract via les champs du contrat :

Obtenez le nombre total de jetons qui ont été créés par le contrat
- pub var totalSupply: UInt64
Evénement émis lors de l’initialisation du contrat
- event ContractInitialized()

2 – Récupérer les champs tokens d’un NFT dans la collection d’un utilisateur

unique identifier
fonction pour emprunter une référence à un NFT spécifique dans la collection
- pub fun borrowNFT(id: UInt64): &NonFungibleToken.NFT
  - l’appelant peut lire des champs et appeler des fonctions sur le NFT avec la référence

3 – Retrait d’un identifiant de token unique à l’aide du `withdraw` fonction de la collection du propriétaire

retirer l’événement
- event Withdraw(id: UInt64, from: Address?)
Interface fournisseur
- pub fun withdraw(withdrawID: UInt64): @NonFungibleToken.NFT

5 – Dépôt d’un identifiant de jeton unique à l’aide de celui du destinataire fonction de dépôt

événement de dépôt
- event Deposit(id: UInt64, to: Address?)
Interface récepteur
- pub fun deposit(token: @NonFungibleToken.NFT)
- IMPORTANT: Afin de se conformer à la fonction de dépôt dans l’interface, une implémentation DOIT prendre une @NonFungibleToken.NFT ressource comme argument. Cela signifie que n’importe qui peut envoyer un objet ressource conforme à @NonFungibleToken.NFT à une fonction de dépôt. Dans une implémentation, vous DEVEZ convertir le token comme type de jeton spécifique avant de le déposer ou vous déposerez un autre type de jeton dans votre collection :
  let token <- token as! @ExampleNFT.NFT

7 – Récupération d’une liste des token ID de la collection

getIDs(): [UInt64] renvoie un tableau de tous les jetons de la collection

8 – Création d’une ressource de collection vide

pub fun createEmptyCollection(): @NonFungibleToken.NFTCollection
pas d’évènement
défini dans le contrat
la collection retournée ne doit contenir aucun NFT

8 – Destructeur de ressources NFTCollection

Comparaison avec d’autres normes sur Ethereum

Cela couvre une grande partie du même terrain qu’une spécification comme ERC-721 ou ERC-1155, mais sans la plupart des inconvénients.

Les jetons ne peuvent pas être envoyés à des contrats qui ne comprennent pas comment les utiliser, car un compte doit avoir un Receiver ou alors Collection dans son stockage pour recevoir des jetons.
Si le destinataire est un contrat qui a un Collection, les jetons peuvent simplement être déposés dans cette collection sans avoir à faire un maladroit approve, transferFrom
Les événements sont définis dans le contrat de retrait et de dépôt, de sorte qu’un destinataire sera toujours informé que quelqu’un lui a envoyé des jetons avec son propre événement de dépôt.
Cette version peut prendre en charge les transferts par lots de NFT. Même s’il n’est pas explicitement défini dans le contrat, un transfert par lots peut être effectué au sein d’une transaction en retirant simplement tous les jetons à transférer, puis en les déposant là où ils doivent être, le tout de manière atomique.
Les transferts peuvent déclencher des actions car les utilisateurs peuvent définir des Receivers pour exécuter un certain code lorsqu’un jeton est envoyé.
Indexation facile de la propriété : au lieu d’avoir à parcourir tous les jetons pour trouver ceux que vous possédez, vous les avez tous stockés dans la collection de votre compte et pouvez obtenir la liste de ceux que vous possédez instantanément

Métadonnées

Nous essayons toujours de réfléchir à la manière de créer des métadonnées de jeton, ce qui est très important. Nous voulons être en mesure d’avoir toutes les métadonnées en chaîne, mais nous n’avons pas fait beaucoup de progrès en termes de discussion ou de conception.

Comment tester la norme

Si vous souhaitez tester ces contrats, nous vous recommandons soit de les tester avec le Aire de jeux Flow
ou avec l’extension de code Visual Studio.

Les étapes à suivre sont :

Déployer NonFungibleToken.cdc
Déployer ExampleNFT.cdc, importation NonFungibleToken à partir de l’adresse vers laquelle vous l’avez déployé.

Ensuite, vous pouvez expérimenter avec d’autres transactions et scripts dans transactions/
ou même écrire le vôtre. Vous devrez remplacer certains des espaces réservés d’adresses d’importation par des adresses vers lesquelles vous déployez, ainsi que certains des arguments de transaction.

Vous pouvez trouver des tests automatisés dans le lib/go/test/nft_test.go déposer. Il utilise les modèles de transaction contenus dans le lib/go/templates/templates.go déposer. Actuellement, ceux-ci dépendent d’une dépendance d’un référentiel privé dapper labs pour s’exécuter, de sorte que les utilisateurs externes ne pourront pas les exécuter. Nous travaillons à rendre tout cela public afin que tout le monde puisse effectuer des tests, mais nous n’avons pas encore terminé ce travail.

Fonctionnalités bonus

(Ceux-ci pourraient chacun être définis comme une interface et une norme distinctes et ne font probablement pas partie de la norme principale) Ils ne sont pas encore implémentés dans ce référentiel

10- Retirer des jetons de la Collection de quelqu’un d’autre en utilisant son Provider référence.

événement de retrait approuvé
Fournir une ressource qui approuve uniquement un compte pour retirer un montant spécifique par transaction ou par jour/mois/etc.
Retour de la liste des tokens qu’un compte peut retirer pour un autre compte.
Lecture du solde du compte pour lequel vous êtes autorisé à envoyer des tokens
Le propriétaire peut augmenter et diminuer l’approbation à volonté, ou la révoquer complètement
- C’est beaucoup plus dur que prévu

11 – Norme de composabilité/extensibilité

12 – Frapper une quantité spécifique de jetons à l’aide d’une ressource de minter spécifique qu’un propriétaire peut contrôler

jetons frappés événement
Fixer un plafond sur le nombre total de jetons pouvant être frappés à la fois ou globalement
Définir un délai où cela est autorisé

13 – Brûler une quantité spécifique de jetons à l’aide d’une ressource de brûleur spécifique qu’un propriétaire contrôle

événement de jetons brûlés
Fixer un plafond sur le nombre de jetons pouvant être brûlés à la fois ou globalement
Définir un délai où cela est autorisé

14 – Suspendre les transferts de Token (peut-être un moyen d’empêcher l’importation du contrat ? probablement pas une bonne idée)

15 – Clonage du token pour créer un nouveau token avec la même distribution

Licence

Les travaux dans ces dossiers /onflow/flow-NFT/blob/master/contracts/ExampleNFT.cdc /onflow/flow-NFT/blob/master/contracts/NonFungibleToken.cdc

sont sous le Unlicense https://github.com/onflow/flow-NFT/blob/master/LICENSE