NEAR Live Révision des contrats | Partie 4 : Berry Farm

17 min read
To Share and +4 nLEARNs

Introduction

C’est Eugene , et aujourd’hui nous allons parler du contrat Berry Farm qui est le supplément de Berry Club qui vous permet de convertir vos bananes en concombres, et de cultiver NEAR. Faisons d’abord un examen rapide de la Berry Farm. Le référentiel peut être trouvé sur mon Github. Voici la vidéo originale sur laquelle ce guide est basé :

UI

 

Berry farm est une application très bien conçue avec du texte volumineux et de nombreux emojis. La façon dont cela fonctionne est qu’il affiche vos soldes une fois que vous êtes connecté. Il les extrait de deux contrats différents ainsi que de votre compte. Il les combine à partir de plusieurs sources. L’avocat et les bananes proviennent du contrat Berry Club, les concombres sont locaux pour ce contrat et NEAR provient du solde de votre compte. Si vous avez formé quelque chose, vous obtenez des récompenses lorsque les récompenses sont distribuées. Il semble que quelqu’un ait récemment acheté beaucoup d’avocats et que les récompenses aient en fait augmenté. Il a également des statistiques mondiales, ce qui signifie que 2 500 NEAR ont été transférés de Berry Club à Berry Farm. J’ai gagné 116,9 NEAR et ma récompense sera de 0,014332 NEAR en fonction de la quantité de concombres que j’ai par rapport au nombre total de concombres.

Le nombre total de concombres est de 54116.4. Je reçois une part de 3% de cette récompense à chaque fois qu’il y a une récompense. Ainsi, lorsque je clique sur Actualiser, j’actualise essentiellement les statistiques de plusieurs comptes et je peux réclamer NEAR qu’elles soient transférées du contrat vers mon compte. Je peux aussi troquer des bananes contre des concombres et je fais appel au contrat Berry Club.

Je vais transfer_with_vault qui utilise la nouvelle norme, et cela nécessite une petite quantité de NEAR, et je pense que c’est comme 1 yocto NEAR pour confirmer que je ne fais pas cela via une clé d’accès. Je ne peux pas effectuer de virement via une clé d’accès afin d’éviter un retrait automatique, et ce n’est qu’un dispositif de sécurité. Si, par exemple, vous autorisez Berry Club à partir d’une autre application qui essaie de vider toutes vos bananes, cela échouera, car il ne pourra pas appeler transfer_raw ou transfer_with_vault. Pour clarifier, transfer_raw est le nouveau nom pour transférer sans contrat afin que vous puissiez simplement déposer avec le compte de quelqu’un qui existe, et dans transfer_with_vault le coffre-fort appelle le destinataire pour retirer des jetons.

J’ai dépensé 10 bananes pour obtenir plus de concombres, et je peux à nouveau rafraîchir la balance pour voir si quelqu’un a retiré quelque chose. C’est ainsi que fonctionne l’interface utilisateur, mais il y a plus de fonctionnalités que cela. Le contrat prend en charge les concombres en tant que jeton fongible, ainsi que les bananes. Vous pouvez potentiellement créer une autre application qui transfère des concombres et il y en a une autre qui est Banana Swap que Vlad Garchina a construite.

Il s’agit d’un uniswap simplifié avec un seul pool où vous pouvez acheter et vendre des bananes. En fait, je ne l’ai pas essayé avant. Je veux obtenir 1 NEAR valeur de bananes que je dois vendre pour 6 bananes. Voyons si cela fonctionne.

Il appelle les transferts du Berry Club qui est à nouveau en cause, mais vers un contrat différent. Nous n’affichons actuellement pas d’arguments, mais nous finirons par le faire.

Cela dit que j’ai transféré, et j’en ai eu 1 NEAR sur lequel j’ai dépensé 6 bananes. Plutôt cool.

Vous ne pouvez pas augmenter la liquidité et il faut une réduction de 10 %. Voici donc l’interface utilisateur.

Vérification de contrat

Berry Club

Permettez-moi de présenter le contrat. Nous allons donc commencer par le contrat Banana Farm, mais vous devrez probablement jeter un œil au contrat de jeton de pixelboard, au contrat de Berry Club, ainsi qu’à celui qui envoie des jetons.

Berry club a un contrat codé en dur appelé farm contract id.

Lorsque vous dessinez, il vérifie que vous ne dessinez pas de pixels vides, sinon vous pouvez simplement déclencher une récompense sans dépenser d’avocat.

Ensuite, il appelle may_send_reward qui obtient l’heure actuelle de la blockchain et vérifie que next_reward_timestamp est inférieur à l’heure actuelle.

La récompense suivante est soit le début du temps d’agriculture qui était un horodatage global qui activait à l’origine un compte à rebours de 26 heures ou last_reward_timestamp lorsque nous l’avons déclenché pour la dernière fois plus 60 secondes.

Donc, s’il est temps d’envoyer la prochaine récompense, il se souvient de l’heure actuelle et calcule la récompense en fonction de cette logique. Il prend donc le solde actuel de Berry Club, prend le stockage actuel, calcule le stockage en fonction du coût de stockage plus une barre de sécurité marge de sécurité, qui est de 50 NEAR.

Il garde toujours 15 NEAR pour les soldes futurs. Ensuite, cela dit si le solde est disponible, si notre solde est supérieur au montant dont nous avons besoin pour le stockage plus la sécurité, alors nous calculons le solde liquide et nous le divisons par la portion de récompense que nous donnerons à chaque fois, soit 24 fois 68. Si vous l’appeliez toutes les minutes, vous videriez la majorité du compte, mais il diminue toujours en quelque sorte sur lui-même, car le solde diminue sur lui-même, mais il donne principalement tout le solde en une journée si vous l’appeliez toutes les minutes. . Tout d’abord, vous ne pouvez pas produire un bloc horodaté plus tôt, puis vous ne pouvez pas produire un bloc au-delà de votre slot, vous avez un slot dédié lorsque vous devez produire un morceau. Donc, tout ce que vous pouvez faire est de produire une partie du bloc final à la dernière milliseconde de votre emplacement, ce qui est une seconde d’avance. Vous ne pouvez pas vraiment le faire avancer, sinon tous les autres nœuds casseront également le protocole, ils sont donc limités par leur compréhension du temps et de la barre qu’ils utilisent pour décider d’accepter ou non un bloc, donc vous ne pouvez pas accélérer vraiment le temps, à moins que tous les validateurs ne veuillent le faire. Cela signifierait que nous aurons les validateurs qui cesseront essentiellement de suivre le protocole. Ils doivent coordonner leur temps.

Donc, à la fin, il a obtenu la récompense, il dit que je vais distribuer cette récompense, et ce qu’il fait, c’est qu’il appelle le contrat de ferme et appelle take_my_near et il ne passe tout simplement aucun argument et passe sa récompense et son gaz. Juste une quantité minimale de gaz nécessaire pour ajouter les soldes. C’est ainsi que Berry Club a été mis à jour pour commencer à distribuer des récompenses après chaque tirage potentiellement. Il en faut un peu plus. Il utilise du gaz qui a été dépensé pour le tirage pour réellement distribuer la récompense de temps en temps, ce qui nécessite environ 10 téra de gaz pour cela.

Berry Farm

Allons à Berry Farm et commençons par ce contrat. La façon dont fonctionne la ferme de baies doit, en temps constant, pouvoir distribuer des récompenses en fonction du nombre total de concombres, ce qui n’est pas une tâche triviale, c’est un peu similaire au pool de jalonnement et à la façon dont le pool de jalonnement distribue les récompenses. Le pool de jalonnement crée un tas d’actions pour chaque dépôt que vous effectuez et l’action a un prix mondial actuel qui dit : « Hé, j’ai acheté ou émis plus d’actions, et maintenant mes actions peuvent être échangées contre un nombre donné de jetons NEAR ». Le cours de l’action commence à partir de 1 yocto NEAR par action, puis plus vous accumulez de récompenses, plus le prix des actions augmente. Lorsque vous utilisez un jalonnage, vous vendez des actions au prix actuel, et vous récupérez NEAR, et ce n’est pas jalonné, et il arrondit à la baisse. Le défi, c’est que lorsque vous misez des concombres, le prix d’un concombre est de zéro, et lorsque vous les misez pour la première fois, vous ne pouvez pas vraiment acheter d’actions et d’actions de menthe, car leur prix est de zéro. La logique des actions ne fonctionne pas très bien pour cela, donc pour cette chose, j’avais besoin de créer quelque chose de différent pour faire la comptabilité. Entrons dans les exemples. Disons que Mike est la première personne à avoir déposé 10 concombres sur le contrat, puis disons que 100 NEAR ont été distribués. Mike prendra toutes les récompenses car il est le seul, il contrôle désormais 100% des parts de la Berry Farm. Mike était hors ligne par exemple, et ne les a pas réclamés, nous ne pouvons donc pas vraiment mettre à jour son compte, car cela doit être fait en temps constant. Nous ne pouvons pas parcourir tous les comptes, mais nous devons d’une manière ou d’une autre nous rappeler que Mike a tout NEAR pour ses concombres. Supposons maintenant que Josh entre et mise 10 concombres supplémentaires, maintenant que la part de Mike est de 50 % et la part de Josh de 50 %, mais Josh a misé les concombres après que ces 100 NEAR initiaux aient déjà été distribués. Il n’a droit à rien de tout cela maintenant 100 autres NEAR drops. Mike doit maintenant en obtenir 50 de plus, car il détient 50% du capital et Josh en obtient 50 NEAR. Lorsque Mike revient en ligne, nous devons pouvoir afficher son solde à 150 NEAR qu’il a gagné en temps constant. C’est donc le défi que nous devions relever avec ce contrat, et la façon dont il a été résolu est d’avoir un ratio global appelé near par concombre qui indique combien NEAR est reçu par un solde de concombre donné lorsqu’un compte est créé, ou touché de quelque manière que ce soit. On se souvient de la dernière valeur de cette fraction.

Ensuite, nous avons un solde NEAR, donc si la dernière fraction était inférieure à la fraction actuelle, cela signifie que nous pouvons multiplier les concombres du compte donné par la différence entre 2 fractions, et calculer à combien NEAR j’ai droit. Lorsque le compte de Mike a été créé, la fraction était de 0 divisée par un et lorsque 100 NEAR ont été déposés là où le nombre total de concombres était de 10, cette fraction est devenue égale à 10. Puis, une fois que Josh a rejoint et a laissé tomber 10 autres concombres au total, et encore 100 NEAR ont été distribués, cette fraction a été augmentée de 5, car il y avait un total de 20 concombres et 100 NEAR. Donc 100 NEAR divisé par 20, cela signifie 5 NEAR par concombre donc cela est devenu 15. Maintenant, quand Mike revient, il regarde son solde de concombre qui est de 10 near par concombre sur un contrat global est de 15 sa dernière valeur mémorisée est zéro donc il prend juste la différence qui est 15 multipliée par 10 et réclame ce solde dans NEAR, et ce 1 est ramené à 15. Lorsque Josh revient, il obtient cette valeur qui était à 10, et il a 10 concombres et la valeur actuelle est 15. La différence est de 5 multiplié par le solde du concombre de 10 donc il obtient 50 NEAR. C’est ainsi que nous gérons le solde NEAR et que nous nous approprions les récompenses reçues des personnes en utilisant un temps constant pour le recalculer. Donc au lieu de garder une fraction entière en mémoire donc on utilise un dénominateur global qui est fixe et je l’ai utilisé à 10 puissance 18 qui est la même que la précision des concombres, bananes et avocats. C’est l’arrière-plan de la façon dont tout est calculé.

Regardons la structure main du contrat, un contrat appelé ferme. Il dispose d’une carte de recherche de comptes et utilise des hachages courts similaires aux jetons fongibles avec des coffres. Il a l’identifiant du compte du jeton banane qui peut également être codé en dur, mais il a été utilisé à partir du contrat car nous pouvons le transmettre, car ce compte a été déployé après et je ne voulais pas mettre à niveau l’état du contrat Banane Berry Club. Je ne voulais plus modifier l’état par évolutivité, j’ai donc codé en dur la valeur dans le contrat précédent. Près du concombre, la fraction que j’ai expliquée plus tôt, est le numérateur et le solde total du concombre est nécessaire comme dénominateur. Les coffres et le vote suivant sont utilisés pour les transferts ; en fait, ils n’ont probablement jamais fini par s’habituer à transférer des concombres, sauf peut-être une fois pour un test.

C’est ce que nous avons vu auparavant, c’est encore une fois un hachage de l’identifiant du compte.

La structure du compte est la dernière valeur avant que le compte ne soit touché avec cette fraction. Le near_balance est le solde non réclamé. Chaque fois que vous touchez un compte soit en déposant plus de concombres, soit en réclamant NEAR, il met à jour la dernière valeur et déplace tous les NEAR non réclamés vers votre solde local de la différence, et le solde de concombre est votre solde en concombres. Le near_claimed correspond aux statistiques, qui indiquent simplement le montant de la récompense que vous avez déjà réclamée. Ce n’est pas nécessaire pour la logique du contrat.

Il y a deux structures d’assistance juste pour le front-end. Le HumanAccount renvoie les valeurs d’une manière plus lisible et HumanStats est des statistiques globales pour la consommation. Allons dans la fonction take_my_near pour voir comment cela fonctionne.

La première chose que nous faisons est de vérifier qu’il y a suffisamment de concombres là-bas, car nous l’utilisons comme dénominateur. Nous voulons juste qu’un concombre déclenche cela, et ce n’est qu’une précaution. Vous n’aimez pas déclencher ce genre de choses. Explorons cette valeur. Ce qui se passe, c’est que vous obtenez le montant de NEAR, et yocto NEAR, et vous le multipliez par le dénominateur global. Vous résolvez donc une fraction qui est NEAR par concombre divisé par le dénominateur plus le solde attaché divisé par le solde total de concombre. Voici la formule : near_per_cucumber / denom + attachment_deposit / total_cucumber_balance. Ainsi, new_near_per_cucumber est en fait le numérateur avec attach_deposit et le dénominateur ensuite divisé par le dénominateur. Voici la formule : new_near_per_cucumber = (near_per-concumber_numer +denom + dépôt attaché) / denom. C’est la formule que nous utilisons pour calculer le new_near_per_concombre. Chaque fois que vous touchez un compte, votre solde actuel non réclamé devient toujours un nombre fixe, puis vous pouvez modifier n’importe laquelle des valeurs sans rompre la logique. Cette méthode tactile est appelée par chaque getter et chaque méthode de changement. Avant de modifier le compte, il appelle toujours toucher sur le compte

Par exemple, dans get_near_balance, nous obtenons le compte interne. Si le compte existe alors nous le touchons localement. Ensuite, nous devrions obtenir le near_balance

Si vous obtenez le compte que nous touchons avant, obtenez votre quasi_balance, votre cucumber_balance et votre solde de réclamation. Ce sont des fonctions d’affichage qui changent les choses, mais elles ne les enregistrent pas, elles modifient donc temporairement la valeur du compte et ne la sauvegardent pas. Il fait juste une touche qui est une sorte de recalcul avec la dernière valeur

Il l’enregistre lorsque vous effectuez un appel de modification, par exemple, appelez à claim_near. Nous obtenons votre compte et get_mut_account touche réellement le compte. Vous obtenez le compte qui est déjà mis à jour et near_balance est le solde réel. Cela met le Near_balance à zéro, cela veut dire que vous avez réclamé tout cela, et cela sauve votre compte. Ensuite, si vous réclamez une valeur positive, nous vous la transférerons à partir de votre compte. Il renvoie combien NEAR vous avez réclamé. La beauté de cette méthode tactile est qu’elle peut être appelée à tout moment. Il n’a pas besoin d’être appelé à un moment donné, il vous donnera donc toujours le même résultat, que vous l’ayez appelé deux fois au milieu ou une fois. C’est juste pour rendre à l’utilisateur combien il a. Il vous indique simplement combien NEAR vous avez gagné en calculant à partir de l’état actuel. Au Berry Club, nous faisons les mêmes choses que nous avons également touchées, et cela est nécessaire, car disons que vous voulez savoir combien de bananes vous avez cultivées. Puisque nous savons la dernière fois que vous avez touché votre compte, quand vous avez dessiné quelque chose pour la dernière fois, nous savons combien de pixels vous avez. Nous pouvons calculer à partir d’un instant donné jusqu’à l’instant précédent multiplié par le nombre de pixels que vous aviez combien de bananes vous devriez avoir en ce moment, et le frontal fait exactement la même chose. Le frontal le simule, il obtient les mêmes informations à l’exception des dernières, puis il crée simplement une minuterie qui la calcule. En théorie, la méthode get_near_balance n’a pas à renvoyer votre valeur NEAR qui est à jour, vous pouvez simplement dire que voici le total NEAR par concombre et votre dernier total NEAR par concombre et également votre dernier NEAR solde, mais à la place, cela se fait sur le niveau du contrat. Disons que nous n’avions pas de méthodes d’affichage pour lesquelles vous ne payez pas et ne renvoyez et récupérez qu’un état, alors vous devriez faire cette logique sur le front-end au lieu de le faire ici en mémoire.

Token.rs

La dernière logique que nous devons faire est en fait de savoir comment vous recevez vos concombres de Berry Club, et cela se fait en utilisant transfer_with_vault de Berry Club. Nous avons discuté précédemment du fonctionnement de la carte 122.

Vous transmettez le receiver_id, le montant et la charge utile. Il a un chèque assert_paid qui vérifie simplement que le dépôt est positif. Cela dit, vous avez besoin d’au moins 1 yocto NEAR pour empêcher les appels de touches d’accès aux fonctions afin d’éviter qu’une interface utilisateur Berry Club malveillante ne draine toutes vos bananes. Il récupère le gaz, puis lance un appel qui met des bananes dans un coffre-fort. Il initie également un appel vers le récepteur. Dans ce cas, nous l’appelons un contrat à la ferme et il transmet à l’identifiant de l’expéditeur une quantité de bananes, un identifiant de coffre qui est juste un u64 sans JSON et une charge utile qui est une chaîne. Dans l’exemple précédent, lorsque nous parlions de la carte 122, la charge utile était un binaire de vec q8 en base64, car il s’agissait d’une charge utile sérialisée borsh. Au cours de la discussion, j’ai noté que si vous examiniez cet argument dans un portefeuille, vous ne pourrez pas voir la charge utile que vous souhaitez faire. Par conséquent, dans cette implémentation de contrat, nous utilisons en fait JSON pour la charge utile afin d’insérer le JSON du charge utile de chaîne. C’est une énumération avec une seule option appelée deposit_and_stake.

Maintenant, lorsque vous effectuez un appel de fonction à partir de l’interface utilisateur de la ferme qui ira au portefeuille dans les arguments, la charge utile sera comme une chaîne adjacente dans une chaîne indiquant le dépôt et la mise au lieu d’être un zéro encodé comme base, au lieu d’être un borsh version sérialisée, c’est une version lisible par l’homme. Ce contrat a des types de charge utile différents de ceux d’Uniswap, par exemple, il aura une charge utile indiquant combien NEAR vous souhaitez recevoir au maximum ou recevoir au moins. L’interface utilisateur malveillante d’Uniswap peut simplement remplacer cette valeur, et si vous ne l’avez pas vérifiée du côté du portefeuille, vous pouvez en fait tomber sous la tendance avant. Nous avons obtenu le compte en utilisant get_mut_account qui obtient soit un compte existant, soit crée un nouveau compte où il définit tous les soldes sur 0, mais le dernier numérateur proche par concombre est le numérateur global actuel. Cela signifie que vous n’avez rien cultivé et que votre solde de concombre est nul. Il touche de toute façon même s’il n’en a pas besoin, nous aurions pu l’éviter si nous avions mappé, puis il renvoie le hachage et le compte. Le compte est déjà à jour. Ce que nous faisons, c’est d’abord augmenter le solde total du concombre, puis le sauvegarder dans l’état du compte et nous augmentons également le solde global du concombre du nombre de concombres déposés. Ensuite, nous ne vérifions pas vraiment que le coffre-fort contenait des concombres, nous pensons donc que l’appelant précédent, qui est un contrat de banane, a effectivement mis les bananes dans le coffre-fort, et nous retournons la promesse en dehors de cette méthode. C’est une correspondance étrange avec une seule entrée car la charge utile ne peut être qu’un seul type pour le moment. Nous appelons remove_from_vault, nous indiquons le montant que nous voulons retirer, qui est le montant total, puis nous le rappelons à l’identifiant du compte du jeton banane qui est un contrat Berry Club. Même ainsi, ce contrat n’a pas encore reçu de bananes, il s’en moque car il n’utilise de toute façon pas de bananes. Il n’a pas besoin de bananes avant de pouvoir continuer, donc peu importe combien de temps il va y planter des concombres, et le coffre-fort est déjà verrouillé. Il augmente le solde total du concombre en diluant les parts. Désormais, lorsque take_my_near arrivera, il utilisera le nouveau solde total de concombre. Maintenant, je vais répartir le nombre d’actions entre tous les participants.

Conclusion

C’est l’aperçu des contrats Berry Club, Berry Farm et token.rs. Merci d’avoir lu et bonne chance dans vos futurs projets avec NEAR.

20
Retour haut de page