Introduction

Bonjour à tous. Aujourd’hui, nous allons passer en revue 2 contrats au lieu d’un. Nous allons inclure des contrats impliquant des appels croisés et parler des promesses et de leur fonctionnement chez NEAR. Si vous voulez en savoir plus sur le fonctionnement de la composabilité, c’est une bonne session à lire. Le premier contrat que nous allons examiner s’appelle un contrat de liste blanche, et il est utilisé sur le réseau principal pour mettre en liste blanche les pools de staking. Ceci est important car la distribution des jetons se fait via des contrats intelligents. Nous utilisons des contrats de verrouillage que nous examinerons éventuellement dans cette série, mais la façon dont cela fonctionne est que le verrouillage est un contrat autonome qui contient des jetons censés être libérés sur une période de temps. Disons que les jetons sont libérés sur 2 ans et sont alloués de manière linéaire à chaque bloc. Ce que nous voulions faire, c’est donner la possibilité de jalonner ces jetons, y compris les jetons qui ne sont pas encore sortis. Cela signifie que vous devriez pouvoir déléguer tous les jetons que vous avez verrouillés pendant 2 ans par exemple, et commencer à gagner des récompenses dessus. Cela se fait sur un contrat intelligent, et un contrat de verrouillage appelle essentiellement le contrat de pool de staking que nous avons examiné auparavant et transfère des jetons d’un contrat à un autre. Les jetons du contrat de blocage quittent le compte et vont sur le compte du pool de staking. Si un pool de staking ne fournit pas les garanties requises, telles que la possibilité de retourner ces jetons, cela signifie qu’il y aura des problèmes. Disons que je construis un pool de staking personnalisé qui me permet non seulement de miser des jetons, mais aussi de les retirer sur n’importe quel compte. Ce type d’opération vous permettra d’obtenir des liquidités avant la fin de la période de libération. Vous pourrez donc vous retirer, et ce n’est pas le comportement souhaité.

C’est pourquoi nous avons introduit la liste blanche où les implémentations personnalisées des pools de staking approuvés par la Fondation NEAR peuvent être utilisées par les contrats de verrouillage. En même temps, nous voulions donner la possibilité de créer de nouveaux pools de staking déjà approuvés par quiconque sans passer par l’approbation de la Fondation NEAR. Cela permet à quiconque de créer un nouveau pool de staking via une factory de pool de staking. factory de staking est le deuxième contrat que nous examinerons aujourd’hui. La façon dont cela fonctionne est lorsqu’un contrat de blocage veut déléguer, avant de pouvoir transférer des fonds vers ce contrat, il doit d’abord sélectionner un pool de staking. Lorsque vous sélectionnez le pool de staking, le verrouillage émet une transaction pour vérifier si un identifiant de compte donné est sur liste blanche dans un contrat de liste blanche, et s’il renvoie vrai, ce qui signifie que le compte est sur liste blanche, le contrat de verrouillage peut continuer avec la délégation. Il permet au lock-up de se transférer effectivement sur ce contrat. Cela signifie que le contrat de pool de staking a certaines garanties et API que le contrat local attend, et il ne va pas verrouiller les jetons du propriétaire, ni voler les jetons du contrat de verrouillage. Cela était également important pour les horaires d’investissement des employés de NEAR. C’était sur un calendrier d’investissement de quatre ans, et cela permet à la fondation d’émettre une transaction spécifique au lock-up de cette personne afin de tout retirer du pool de staking et de restituer le montant investi à la fondation NEAR en cas de départ d’un employé. l’emploi ou a été licencié. C’est le contexte des blocages et du contrat de liste blanche.

Le référentiel d’origine de ces contrats se trouve sur le NEAR Github. Voici la vidéo originale sur laquelle ce guide est basé :

Contrat de liste blanche

Structure Main

Regardons le contrat de liste blanche. C’est en fait un contrat assez simple, et il n’a pas vraiment beaucoup de logique, on connaît déjà la majorité des choses.

Il utilise une API NEAR appelée LookupSet. C’est similaire à un ensemble non ordonné. C’est une collection persistante, mais elle n’a pas d’itérateurs, vous ne pouvez donc pas itérer sur les clés des éléments de l’ensemble. Vous pouvez seulement vérifier si un élément donné est présent, ou non, et vous pouvez l’ajouter à l’ensemble. Vous ne pouvez pas vérifier quels éléments sont présents dans cet ensemble. Ce faisant, il améliore l’efficacité du stockage et l’accès de plusieurs lectures à quelques lectures. Le contrat contient quelques champs. Le premier est le foundation_account_id. Il s’agit de l’identifiant du compte qui contrôle la liste blanche. Cela signifie que ce compte peut mettre en liste blanche les pools de staking par 1, et il peut également mettre en liste blanche les factory de pools de staking. factory est un contrat qui peut créer une nouvelle instance de pool de staking. La façon dont cela fonctionne est que lorsque vous effectuez une transaction vers factory de staking qui est sur liste blanche par ce contrat, cela crée un nouveau compte en tant que sous-compte de factory. Dans notre cas, sur le réseau principal, cela s’appelle poolv1.near, qui est factory de pool de staking que nous utilisons. Il crée un contrat, par exemple bisontrails.poolv1.near, sur lequel il déploie le code de pool de staking en liste blanche que cette factory peut produire. Nous entrerons dans factory de pool de staking plus tard, mais en même temps, il peut également mettre en liste blanche ce pool de staking donné. Voilà comment cela fonctionne. L’initialisation du contrat ne prend qu’un argument foundation_account_id. Un compte de fondation a des autorisations plus élevées sur ce contrat.

Getters

Il y a un groupe de getters.

Vous pouvez vérifier si une entrée d’enjeu donnée est sur liste blanche. C’est ainsi qu’un contrat de verrouillage vérifie si le pool est sur liste blanche. Il vérifie simplement si un élément est présent dans un ensemble. La deuxième façon qu’il peut également vérifier est si factory est sur la liste blanche, donc ce n’est pas vraiment nécessaire, et personne ne l’appelle.

Ajouter une méthode staking de pool

C’est une méthode qui peut être appelée à la fois par une factory et par la fondation. Ce que nous faisons ici, c’est vérifier que cette méthode de staking ajoute un nouveau staking_pool_account_id à une liste blanche. Il vérifie si l’identifiant du compte est valide, puis s’il réussit, nous vérifions s’il s’agit d’une factory. On vérifie dans un ensemble que l’appelant de cette méthode est présent dans la liste blanche des factory. S’il est appelé par factory de pool de staking, alors ce n’est pas grave. Sinon, il doit s’agir d’un identifiant de compte de fondation, sinon le contrat échouera et cette méthode paniquera. Si nous réussissons la vérification des autorisations, nous ajoutons simplement ce pool de staking à la liste blanche. À l’heure actuelle, nous n’avons qu’une seule implémentation pour le pool de staking, mais en théorie, nous pouvons modifier cette implémentation lorsque nous introduisons le slashing par exemple, et un pool de staking doit avoir l’autorisation nécessaire. Il doit maintenir un certain équilibre minimum. Il y a un autre changement où nous devons modifier un contrat validé sur la période d’investissement de tout le monde de 4 ans. Beaucoup de choses peuvent se produire autour du réseau et nous devons avoir la possibilité de modifier potentiellement les pools de staking. Si la logique du staking pool change par exemple. Il permet la création d’une nouvelle factory qui est une meilleure version ou prend en charge quelque chose qui n’était pas pris en charge auparavant. Il ne permet pas de modifier instantanément les frais de récompense, mais ne permet de le modifier qu’après une période d’attente de 7 jours, ou une autre idée de modification qui sera un facteur différent.

Ensuite, remove_staking_pool ne peut être appelé que par la fondation, de sorte qu’un pool de staking ne peut être tué que par la fondation.

De plus, add_factory ne peut être appelé que par la fondation. C’est basique, ça s’ajoute juste à une liste blanche des comptes de factory.

Enfin, remove_factory ne peut également être appelé que par la fondation et supprime le factory_account_id. Disons que la première factory expire, alors la fondation peut essentiellement supprimer factory de la liste blanche ainsi que supprimer tous les pools précédents de la liste blanche. Maintenant, vous ne pourrez pas sélectionner l’un des sondages de staking précédents à partir d’un contrat de verrouillage, et enfin, il y a une vérification que cela est appelé par la fondation qui est une comparaison. C’est un contrat très simple, et il ne fonctionne que sur des ensembles internes et la seule vraie méthode visible de l’extérieur est is_whitelisted. C’est assez simple, c’est juste un tas de setters et getters.

Immuabilité des contrats intelligents

La façon dont les contrats intelligents se comportent généralement, ce qui est vrai sur Ethereum, et sur d’autres plateformes, est qu’ils sont immuables sur eux-mêmes. Sur Ethereum, chaque intérieur de contrat est immuable, mais ils utilisent un contrat proxy qui leur permet de mettre à niveau le point de terminaison pour certains contrats très critiques pour les jetons. Dans ce cas, nos contrats de base sont essentiellement complètement immuables, et nous pensons à eux comme si nous allions les déployer une fois, et probablement ne pas être en mesure de les modifier, car sinon vous devrez faire un hard fork et convaincre tous les validateurs de faire un certain type de migration de code. C’est important, car leur contrôle doit se faire au niveau du contrat plutôt que sur certaines entités centralisées. Par exemple, bien que la fondation conserve un contrôle important sur les pools de staking en ayant la possibilité de supprimer des pools de staking ici, elle n’a pas le contrôle de mettre sur liste noire une entité particulière dans le monde réel du déploiement d’un pool de staking. Ils peuvent toujours créer un pool de staking avec autant d’anonymat que possible et créer un pool de staking sans demander la permission de devenir un validateur sur le réseau principal. Certaines choses viennent de la décentralisation, l’autre vient de la limitation du contrôle. Bien que la fondation soit censée soutenir le réseau, il est possible que dans certains scénarios, la fondation soit obligée de faire quelque chose de mal pour le réseau. Disons que le gouvernement arrive et essaie de les forcer. S’ils ont moins de capacité à le faire, alors il y a une plus grande sécurité sur le réseau. Lorsque nous concevons un contrat, nous pensons : « Quelle est la valeur de ce contrat ? » ou « Quelle est la capacité de ce contrat à influencer le réseau en général ? ». Si c’est une petite valeur, alors c’est bien de garder la crédibilité tant que la communauté fait confiance, si c’est une grande valeur, alors ce n’est pas bien. Lorsque nous allons en fait arriver au contrat de blocage, et à la façon dont il est conçu, vous pouvez voir comment, par exemple, l’acquisition a été conçue pour permettre à la fondation de retirer les fonds restants, mais en même temps empêcher la fondation de retirer les fonds acquis. C’est une façon légale de faire les choses, sauf que c’est écrit dans le code. La liste blanche est un contrat très critique, car avant que les fonds ne soient verrouillés, la majorité des fonds contrôlent en quelque sorte le réseau via des contrats locaux dans des pools de staking via cette liste blanche particulière, il était donc important de la concevoir de manière à maintenir la décentralisation. , et la sécurité du réseau sans laisser le contrôle à la fondation. Disons que quelque chose s’est passé et que la fondation a commencé à agir avec malveillance. Disons que vous avez pu créer un nouveau pool de staking via une factory et déléguer au pool de staking, maintenant la fondation ne peut pas vraiment vous empêcher de déléguer à ce pool de staking.

Staking Contrat pool factory

Include Bytes Macro

Le contrat staking_pool_factory est un contrat qui a en interne le code d’un staking de contrat de pool. Dans Rust, vous pouvez le faire en utilisant la macro include_bytes. Il prend essentiellement un fichier local et l’intègre dans le binaire en tant que vecteur. Ce qui se passe là-bas, c’est que dans ce binaire WebAssembly, nous pouvons avoir une partie de la mémoire allouée qui représente un binaire de ce pool de staking particulier. Revenons au sommet.

Structure

C’est encore une fois la structure.

Il y avait quelques informations sur le gas, nous y reviendrons plus tard.

Il y a un reward_fee_fraction qui vient juste d’être copié du contrat de pool de staking que nous avons examiné auparavant.

Contrats externes

Il y a les arguments du pool de staking qu’il faut, et il y a les traits, et les contrats externes, c’est donc l’interface de haut niveau que nous utilisons pour appeler certains contrats.

Nous en avons deux, le premier peut être n’importe quel nom. Nous l’appelons ExtSelf, car il représente notre propre contrat et contient un rappel vers une méthode on_staking_pool_create. Le deuxième trait concerne le contrat de liste blanche que nous venons de voir appelé add_staking_pool. C’est ici.

C’est exactement la même interface, sauf que les caractéristiques de Rust sont comme les interfaces de Java, par exemple. On vient de définir l’interface d’un contrat distant.

Initialisation

Commençons par le scénario. Lorsqu’une factory est créée, nous vérifions qu’elle n’a pas été initialisée et nous vérifions le staking_pool_whitelist_account_id, l’identifiant du compte du contrat de liste blanche, lors de l’initialisation de la StakingPoolFactory. Nous devons connaître le staking_pool_whitelist_account_id. C’est là que le contrat de liste blanche est déployé afin de mettre en liste blanche nos instances de pool de staking nouvellement créées. Nous nous en souvenons et créons également un ensemble de comptes déjà créés à la fin de cet extrait.

Méthode Main

Maintenant que Staking de pool factory est créée, elle s’appelle poolv1.near par exemple, et la fondation a ajouté factory à la liste blanche sur un contrat de liste blanche en émettant une autre transaction. Maintenant que cette factory de pools de staking est sur liste blanche, cela signifie qu’elle a la permission de mettre en liste blanche les nouveaux pools de stakings qu’elle crée. Alors maintenant, un validateur arrive, et ils veulent créer un pool de staking pour eux-mêmes. La façon dont cela fonctionne est qu’ils appellent create_staking_pool, et cela prend un tas d’arguments. Le premier argument est un préfixe. Disons qu’il s’agit de bisontrails sans le suffixe de cet identifiant de compte actuel, et cela provient des noms de compte NEAR. Un compte ne peut créer qu’un sous-compte, ou un compte très long, donc la fabrique de pool de staking crée un sous-compte sous elle-même qui sera bisontrails.poolv1.near. Le owner_id est l’identifiant du compte du propriétaire du pool de staking comme nous l’avons vu précédemment. Ces trois éléments sont essentiellement des arguments que vous transmettez à un pool de staking lorsque vous le créez pour la première fois. C’est un argument que vous pouvez proxy vers le pool de staking. Par exemple, staking_pool_id peut être bisontrails.near. Le stake_public_key peut être la clé de staking de l’exécution d’un nœud de validation, et reward_fee_fraction peut être de 10 % par exemple. Notez que cette méthode est également payable, cela signifie qu’elle accepte un dépôt joint entrant, et la première chose qu’elle demande est : « Avez-vous joint suffisamment de dépôt ? » Le dépôt que vous devez joindre est 30 NEAR, et cela a beaucoup de zéros, mais c’est parce que c’est dans yocto NEAR. Vous devez joindre 30 NEAR principalement parce que vous devez couvrir l’état du contrat lui-même sur un pool de staking nouvellement créé. Le contrat est assez important, il fait 250 kilo-octets et il faut au moins 25 NEAR pour cela, mais il faut aussi un peu d’argent supplémentaire pour couvrir le fonds de garantie des prix. C’est l’un de ces cas où vous devez avoir un dépôt attaché, car vous ne pouvez pas attacher autant de gas à cette transaction. De plus, nous ne pouvons pas convertir le gas en NEAR dans le cadre d’un contrat, donc idéalement, la séparation du gas reste la même, elle n’est utilisée que pour le calcul, certaines opérations de lecture/écriture et les appels de contrats croisés. Le solde est utilisé pour le stockage d’état et les transferts. Donc, dans notre cas, cela créera un nouveau compte, et la création d’un nouveau compte sur NEAR vous obligera à payer pour le stockage de ce compte. Dans notre cas, le stockage ne sera pas seulement le compte lui-même, mais également le contrat de ce compte. Dans notre cas, il s’agit du code de staking du contrat de pool .

La prochaine chose que nous faisons est de vérifier que le préfixe n’a pas de point, ce qui signifie qu’il ne s’agit pas d’un sous-compte lui-même. Ensuite, nous créons un nouveau staking_pool_account_id en concaténant notre point d’identifiant de compte (.) ce nouveau préfixe. Nous vérifions que le nouvel identifiant de compte de pool de staking est valide. Fondamentalement, si l’une de ces assertions échoue, le protocole NEAR remboursera les jetons. Si une transaction échoue avec un dépôt joint, le dépôt joint reviendra à l’expéditeur ou au prédécesseur, car seul le prédécesseur peut joindre un solde. C’est sûr de faire comme un tas d’affirmations ici. Ensuite, nous vérifions que le owner_id du pool de staking est valide. Il s’agit essentiellement d’un groupe d’aides supplémentaires qui sont également vérifiées sur le pool de staking. Cela permet de s’assurer que si vous ne passez pas les bons arguments, ou des arguments légèrement incorrects, vous feriez mieux d’échouer tôt avant que tout ne s’exécute afin d’éviter de brûler du gas et de verrouiller les jetons que vous avez dépensés. Enfin, nous vérifions à l’aide d’insert que le pool de staking n’existe pas. Fondamentalement, insert renverra true s’il s’agit d’un nouvel élément unique et renverra false si l’élément existe déjà dans un ensemble. C’est ainsi que fonctionne le hashset Rust de la même manière qu’un ensemble ordonné fonctionne. Donc, si le nom du pool existe déjà, nous n’ajouterons pas ce pool de staking et n’essaierons pas de recréer ce compte. Insert fait deux choses, il ajoute cet élément au stockage, et renvoie true si l’élément est unique et n’existait pas auparavant ou renvoie false si l’élément est déjà présent. Si l’ensemble n’avait pas cette valeur présente, true est renvoyé, si cet ensemble avait cette valeur présente faux, il est renvoyé.

Enfin nous utilisons une API de niveau moyen, nous n’utilisons pas nos méthodes de coût brut, mais en même temps nous n’utilisons pas d’interface de haut niveau. La façon dont cela fonctionne est que nous créons une nouvelle promesse, qui crée une structure temporaire dans notre NEAR SDK, et il se souvient du destinataire de cette promesse. Vous pouvez penser à cela comme si le contrat émettrait la transaction vers cet identifiant de compte donné. Nous appellerons un identifiant de compte de pool de staking inexistant. Bien sûr ce n’est pas une transaction mais un reçu, mais c’est un détail technique. La prochaine chose est la première action en plus de cette promesse. Nous commençons à regrouper des actions dans cette promesse. La première action est le create_account. Cette action créera un nouveau compte ou échouera si le compte existe déjà. Ensuite, nous déposons le solde ci-joint. Nous déposons la totalité du dépôt qui nous a été transmis, afin que nous ne le gardions pas dans cette factory, et il ira avec le même reçu sur le compte distant. Ensuite, nous déployons un contrat. Comme expliqué précédemment, include_bytes est une macro qui crée une tranche statique que nous convertissons en un vecteur qui passera à une action de déploiement. Cela déploiera le code sur le compte distant. Vous ne pouvez déployer du code que sur le compte que vous contrôlez, mais create_account vous donne la permission d’agir comme si vous étiez le propriétaire de ce compte uniquement pour cette transaction particulière. Vous pouvez utiliser la méthode deploy_contract, vous pouvez miser et faire d’autres choses au nom de ce contrat lors de la première transaction que vous effectuez. Enfin, nous initialisons le contrat de pool de staking à l’aide de l’API serda. Nous prenons cette structure et nous la sérialisons en JSON, la méthode est appelée new. Le premier argument est le dépôt attaché à cet appel de fonction. Nous n’en avons pas besoin, car il ne s’y attend pas. Le suivant est la quantité de gas que vous prenez de votre quantité actuelle de gas et que vous retirez immédiatement, après quoi elle correspond à la promesse. Disons que notre méthode s’appelait 100 téra de gas, le téra de gas est une sorte d’unité qui est à peu près compréhensible par l’homme.

Vous avez 100 téra de gas lorsque vous entrez et nous disons que nous allons passer la base (25 téra de gas) multipliée par 2. Nous passerons immédiatement 50 téra de gas à l’appel de fonction de cette méthode, donc ces 50 téra de gas signifient que nous sommes n’est reparti qu’avec moins de 50 téra de gas, car nous en avons déjà brûlé dans la logique avant. De plus, chaque action que vous incluez dans cette promesse vous coûtera également de l’essence. Par exemple, une action de déploiement vous coûtera pour transférer les octets d’un compte à un autre. Enfin, nous utilisons alors. Ensuite, c’est similaire au fonctionnement de Javascript, il attache la dépendance à la promesse précédente. C’est la première promesse, et nous disons qu’une fois qu’elle est terminée, faites la deuxième promesse. La façon dont cela fonctionne est que vous appelez disons bisontrails.near appelé ce contrat (poolv1.near) pour créer bisontrails.poolv1.near. Nous créons d’abord une promesse à bisontrails.poolv1.near, puis nous attachons un rappel à cette api, ce qui n’est pas génial en termes d’utilisation d’arguments de position pour deux choses différentes. Dans tous les cas, il rappelle l’identifiant du compte actuel. Il appellera donc poolv1.near après l’exécution de la première promesse. Voici la structure : bisontrails.near appelle poolv1.near créant une promesse de pool de staking. Maintenant, cela crée une promesse à bisontrails.poolv1.near, et cela crée également une promesse à lui-même sur la méthode on_staking_pool.

Il a besoin du résultat de cette méthode avant que cette méthode ne démarre et il passe ici trois arguments. Il transmet le staking_pool_account_id, le attachment_deposit et le prédécesseur_account_id. C’est donc qui nous a appelés, quel compte a essayé d’être créé et combien de jetons ont été attachés au cas où nous devions effectuer un remboursement. Maintenant, si bisontrails.poolv1.near est exécuté avec succès, on_staking_pool_create recevra le résultat de l’exécution. Disons qu’il y a eu une mauvaise configuration selon laquelle cette méthode sera également appelée, mais recevra un rappel indiquant qu’elle a échoué. Nous avons renvoyé la promesse principale après, cela signifie que nous avons d’abord renvoyé on_staing_pool_create. C’est important, car le résultat de la méthode create_staking_pool dépend du résultat de la promesse on_staking_pool_create. La transaction ne démarre pas complètement en parallèle, mais dépend maintenant de l’exécution de cette méthode particulière.

Callback

Regardons le Callback .

La première chose que nous faisons est de dire qu’elle ne peut être appelée que par le contrat actuel en utilisant assert_self, ce qui signifie que personne d’autre ne peut appeler cette promesse.

La prochaine chose que nous faisons est d’utiliser une autre méthode d’assistance utilitaire qui indique si la dépendance, la création du pool de staking, a réussi ou échoué.

Nous procédons de la manière suivante : nous utilisons d’abord deux méthodes de fin pour vérifier que le nombre de résultats est de 1. C’est un invariant car nous savons déjà que personne ne peut l’appeler deux fois, et la seconde est si le résultat est un succès. Si la méthode s’est exécutée avec succès, alors nous retournons true si la promesse a échoué, alors ce sera false. Alors maintenant, nous savons si le pool de staking a été créé ou non. Encore une fois, nous avons également attaché 50 téra de gas au rappel, nous sommes donc maintenant dans le rappel, ce qui signifie que nous n’avons que 50 téra de gas.

Si nous réussissons, nous enregistrerons que le pool a été créé avec succès, puis nous le mettrons en liste blanche. Ensuite, nous appelons une autre promesse à partir d’un rappel et attachons 25 téra de gas. Alors maintenant, nous appelons staking_pool_whitelist_account_id, le contrat de liste blanche. Maintenant, nous pouvons ajouter à la liste blanche le pool de staking que nous venons de créer, car nous avons transmis cet argument au rappel. Nous retournons cette promesse afin de ne pas arrêter l’exécution pour le moment, car nous ne voulons terminer l’intégralité de la transaction qu’une fois la liste blanche terminée. Rust n’a pas de retour, car si la dernière valeur sans point-virgule est donnée, c’est une valeur de retour. Si la création échoue, elle peut échouer pour une seule raison : si vous mettez une clé ristretto invalide comme nous en avons discuté brièvement précédemment. S’il y a une courbe étrange dans laquelle vous avez créé votre clé de staking, cela échouera. La raison pour laquelle cela échoue est que cela signifie que le dépôt que vous avez transféré au pool de staking pour la création nous sera remboursé, et non au prédécesseur. Nous avons 30 NEAR sur ce contrat, et nous devons les rendre à l’expéditeur afin de ne pas les enfermer. La première chose que nous faisons est de le supprimer de la liste des pools de staking qui ont été créés, car cela n’a pas réussi. Nous disons donc que la création a échoué et nous allons vous rembourser l’acompte joint. Maintenant, ce n’est pas un véritable dépôt joint, car le rappel ne reçoit pas le dépôt joint. Il parcourt un reçu de remboursement séparé qui arrive généralement avant le rappel, et il prend également le prédécesseur_account_id. Dans notre cas, si nous appelons le prédécesseur_account_id, ce sera nous car il s’agit d’un rappel. Nous devons savoir à qui nous devons retourner les jetons, et la façon dont nous le faisons est de créer une promesse en utilisant le nouveau prédécesseur_account_id, et nous renvoyons les jetons qui étaient attachés auparavant. Comme vous pouvez le voir, nous ne retournons pas cette promesse, nous disons simplement que c’est tout, peu importe si cela réussit ou échoue, le retour de base de la valeur false indique que le pool n’a pas pu être créé. Que se passe-t-il maintenant, la transaction continue d’être exécutée mais la valeur sera renvoyée au frontal. L’extrémité avant est le NEAR CLI. Vous saurez immédiatement que la transaction a échoué. Vous n’avez peut-être pas encore récupéré votre argent, vous attendez donc toujours que ce remboursement particulier s’exécute dans le prochain bloc, mais vous savez déjà que le pool n’a pas été créé pour que vous puissiez continuer. Ceci est un exemple de la façon dont vous pouvez faire une promesse parallèle. C’est ainsi que fonctionne un facteur de pool de staking. Voici un getter qui vérifie combien de pools de staking ont été créés et peuvent être appelés sur le NEAR CLI.

Conclusion

Тhis conclut le NEAR Live Révision des Contracts | Partie 3 : Liste blanche et de staking de pool factory. Merci d’avoir pris le temps d’apprendre NEAR, d’autres contenus seront bientôt disponibles dans cette série.