🚀 Apprenez à automatiser les flux Start/Stop Superfluid dans Super Apps.

L'une des choses les plus extraordinaires à propos du web3 est que nous en sommes encore à un stade précoce et au moment où nous parlons, l'écosystème web3 se développe avec de nouveaux protocoles, outils, etc., et quel que soit notre niveau d'expertise, nous pouvons contribuer à aider les autres comme nous apprenons. Ce blog vise à aider les développeurs à utiliser le réseau gelato avec des contrats intelligents et plus particulièrement à utiliser l'automatisation Gelato avec Superfluid Super Apps.

Le protocole Superfluid, entre autres fonctionnalités, permet aux utilisateurs de transférer de l'argent/des jetons aux utilisateurs/contrats avec une seule transaction et un blocage de capital minimal. La mise en garde est que vous devez vous rappeler d'arrêter le flux, sinon le flux continuera indéfiniment. Veuillez visiter le site Web de Superfluid pour plus d'informations https://www.superfluid.finance/home

Gelato Network vous permet d'exécuter des tâches à un moment futur (pour ex-web2 serait similaire à une sorte de planificateur). Le cas d'utilisation principal concerne les tâches répétées. Pour les flux Superfluid, nous n'aurons besoin que d'une seule exécution (démarrer ou arrêter) donc nous devrons déployer la tâche et en même temps la "tâche d'annulation". Veuillez visiter le site Web de Gelato pour plus d'informations https://www.gelato.network/

Ce projet présente des exemples à usage général d'automatisation de contrats intelligents avec gelato ainsi que l'application pour les flux superfluides présentant un guide très simple en 3+3 étapes pour créer des flux de trésorerie programmables

Pour ce faire, nous avons déployé une application vitrine sur https://gelato-superapp.web.app . nous allons interagir avec deux principaux contrats vérifiés et déployés sur mumbai :

• Contrat d'application de fête ( voir sur le scan )
• Gelato Super App Contract ( voir sur le scan )

Le code peut être trouvé dans ce référentiel

Guide en 3+3 étapes pour gelatofy un contrat intelligent

Vous trouverez ici 3 + 3 étapes les plus simples pour ajouter l'infrastructure gelato et automatiser très facilement vos tâches de contrat intelligent :

1. Infrastructure filaire Gelato

2. Stratégie de financement de Gelato

3. Logique commerciale Gelato

   3.1) Création de tâche

   3.2) État du vérificateur

   3.3) Fonction exécutable

Étape 1 : Câblage de l'infrastructure Gelato

Afin d'interagir avec le réseau gelato, nous devrons interagir avec les contrats Gelato (les adresses peuvent être trouvées ici ). Nous allons interagir avec trois contrats :

Contrat Ops : Le contrat principal pour créer, annuler, obtenir des frais de transaction, des frais de transfert, etc. Nous hériterons du contrat OpsReady.sol , nous transmettrons au constructeur les adresses gelato ops et gelato treasury et nous sommes prêts à partir !.

 import {OpsReady} from "./gelato/OpsReady.sol"; import {IOps} from "./gelato/IOps.sol"; import {ITaskTreasury} from "./gelato/ITaskTreasury.sol"; contract PartyApp is OpsReady, Ownable { constructor(address payable _ops, address payable _treasury) OpsReady(_ops, payable(_treasury)){ }

Contrat de trésorerie Gelato : Nous aurons besoin d'interagir avec le contrat de trésorerie Gelato pour le financement/retrait en fonction de notre stratégie de financement (voir étape 2)

Gelato Network : Nous allons interagir avec ce contrat dans nos tests… plus sur Bonus Track #2

Le contrat OpsReady.sol, ainsi que les interfaces, se trouvent dans les fichiers gelato du référentiel. Vous pouvez simplement les copier et ça marche!

Étape 2 : Stratégie de financement de Gelato

Gelato exécute des transactions à un moment futur, nous devons donc choisir un moyen de financer les transactions que Gelato va exécuter en notre nom. Il existe deux alternatives pour le faire :

1) Financer le contrat de trésorerie Gelato : tant que vous avez un solde positif dans le contrat de trésorerie, les transactions futures seront exécutées. Si nous choisissons cette alternative, nous devons interagir avec le contrat de trésorerie Gelato qui la finance.

 function fundGelato(uint256 amount) public payable { require(msg.value == amount, "NO_FUNDING"); ITaskTreasury(treasury).depositFunds{value: amount}(address(this),ETH,amount); } function withdrawGelato() public onlyOwner { uint256 maxAmount = ITaskTreasury(treasury).userTokenBalance(address(this),ETH); ITaskTreasury(treasury).withdrawFunds(payable(msg.sender), ETH, maxAmount); }

2) Financer chaque transaction : notre contrat intelligent transférera dans chaque transaction future le montant demandé pour payer les frais. Dans ce cas, nous n'aurons pas besoin d'interagir avec le contrat de trésorerie Gelato mais nous devons maintenir un solde positif dans notre contrat .

Étape 3 : Logique commerciale de Gelato

Il y a trois parties/étapes principales que nous devons définir dans la logique métier :

3.1) Créer la tâche : Nous devrons définir une tâche pour dire à Gelato ce que nous voulons être exécuté.

 function createTask() public { require(taskIdByUser[msg.sender] == bytes32(0), "TASK_STILL_ACTIVE"); bytes32 taskId = IOps(ops).createTask( address(this), /// Contract executing the task this.startParty.selector, /// Executable function's selector address(this), /// Resolver contract, in our case will be the same abi.encodeWithSelector(this.checkerStartParty.selector) /// Checker Condition ); taskIdByUser[msg.sender] = taskId; }

3.2) Condition de vérification : afin d'exécuter une future transaction, nous devrons fournir à Gelato la condition de vérifier si Gelato peut s'exécuter ou non.

 function checkerStartParty() external view returns (bool canExec, bytes memory execPayload) { canExec = headachePresent == false; execPayload = abi.encodeWithSelector(this.startParty.selector); }

3.3) Fonction exécutable : Fonction qui sera exécutée lorsque les conditions et/ou le temps seront remplis.

 function startParty() external onlyOps { require(headachePresent == false, "NOT_READY"); lastPartyStart = block.timestamp; headachePresent = true; }

https://gist.github.com/donoso-eth/0678b0613db36c6c332063c9f39cddfd

Démo de l'application Party !

Notre première application Gelato va être très simple. Il vérifie si notre soirée gelato a commencé ou non. La fête commencera toujours si nous n'avons pas un « mal de tête » de la fête précédente.

Nous pouvons définir manuellement la fin de notre « mal de tête », puis le réseau Gelato pourra exécuter la fête de démarrage, en définissant un nouvel horodatage de la fête de démarrage et en définissant notre « mal de tête sur vrai ».

Notre écran est divisé en deux parties en fonction de notre stratégie de financement.

Ce contrat permet trois cas d'utilisation :

1. Créer une tâche simple financée par la trésorerie : les détails peuvent être vus ci-dessus

Une fois la tâche créée, nous pouvons aller sur le site Web de gelato ops et nous verrons notre tâche en attente d'exécution

Et après une exécution réussie, le tableau de bord des opérations nous montrera quelque chose comme ça.

2. Créez une tâche simple financée par la trésorerie et annulez après la première exécution (nous allons utiliser ce modèle plus tard avec nos flux Superfluid).

   https://gist.github.com/donoso-eth/517e2dca691980de506229cbe27eee62

3. Créer une tâche simple payant chaque transaction (pas de financement du Trésor)

   https://gist.github.com/donoso-eth/340ca96b53005dd457defab0991a735c

   
   

Démo de l'application Super Gelato

Notre Super App Gelato nous aidera à rendre les flux superfluides programmables en automatisant l'arrêt ou le démarrage d'un flux.

Nous mettrons en œuvre l'infrastructure gelato (étape 1) comme dans l'application de fête et nous choisirons le financement du Trésor comme stratégie de financement (étape 2)

Nous ferons une démonstration de l'arrêt d'un flux après quelques minutes prédéfinies. Notre logique métier ressemblera à ceci :

https://gist.github.com/donoso-eth/e4fc0145ed75ed84309da1a467175931

Maintenant, si vous avez financé la trésorerie, avez lancé un flux et que la glace a déjà été exécutée en arrêtant le flux, vous avez débloqué votre bonus !!

Piste bonus n° 1 : Mettez-vous en veille et le flux commencera.

Jusqu'à présent, nous avons réussi à arrêter un flux automatiquement, mais en suivant la même logique, je peux vouloir commencer à diffuser un flux vers un nouvel employé exactement à 00h00 le premier jour de travail et je ne veux pas rester éveillé tous les jours car avec un peu de chance, nous allons embaucher beaucoup d'employés !

.. puis CFA ACL (CFA Access Control List) à la rescousse, avec un simple appel à l'accord constant CFA soit depuis le SDK, soit directement vers le contrat, vous pouvez autoriser notre Super App à démarrer un flux en votre nom lorsqu'un un certain temps s'est écoulé et une "Tâche Gelato" est exécutée.

Dans ce cas d'utilisation, nous concaténons deux tâches, lorsque la première est exécutée, le flux sera démarré, la tâche annulée et une autre tâche pour arrêter le flux sera créée.

https://gist.github.com/donoso-eth/5491f5f94409f9648fa196c3ed24ca3d

Bonus Track # 2: Master Hardhat Fork et Sky Rocket votre vitesse de développement

L'une des expériences agréables dans le développement de la blockchain est la possibilité de créer en un clic… ..

Au fur et à mesure que nos dapps gagneront en complexité, nous devrons interagir avec les contrats en chaîne existants et si nous voulons rester locaux , nous devrons simuler/déployer des protocoles. Dans certains cas, cela peut être fastidieux et nous passerons un temps de développement précieux . La meilleure alternative pour surmonter ce problème est de travailler avec un fork, avec une configuration très simple dans notre hardhat.config.ts (merci Sam Flamini et Hilmar X pour avoir indiqué la bonne direction).

https://gist.github.com/donoso-eth/1dbfc57d3d40679e324048e1d7c01ab4

puis avec le npx hardhat node --network "hardhat" nous pourrons créer une copie "virtuelle" de la blockchain que nous ciblons. Les blocs que nous créons désormais seront stockés localement et pour les plus anciens nous interrogerons la "vraie" blockchain avec notre fournisseur RPC (ci-dessus nous utilisons l'alchimie)

Dans notre exemple, nous travaillons avec mumbai, les contrats Superfluid (Host, ConstanFlowAgreeent, Supertoken…), ainsi que les contrats Gelato (Network, OPS, et Treasury), existent avec l'état qu'ils avaient au numéro de bloc du fork nous permettant d'interagir avec eux comme nous interagirions avec la "vraie" blockchain.

Maintenant, vous avez votre "mumbai" local avec les méthodes d'assistance supplémentaires pour vraiment maîtriser la chaîne :

https://gist.github.com/donoso-eth/148d031bbc57e6a3b6708367a52b0069

Dans notre Dapp, nous travaillons avec des contrats Gelato. Les « Exécuteurs » se chargeront d'automatiser nos tâches, mais dans notre chaîne « virtuelle » locale il n'y a pas d'exécuteurs… qui exécutera nos tâches ?. Et la réponse à cela est très simple, nous allons exécuter la tâche nous -mêmes . Nous pouvons le faire parce que nous maîtrisons notre blockchain locale, nous pouvons être qui nous voulons et nous choisissons d'être l'exécuteur. Hardhat nous fournit la méthode fantastique hardhat_impersonateAcount et nous l'utiliserons pour devenir localement "l'exécuteur".

Ici, nous pouvons voir les détails de l'implémentation pour l'exécution des tâches gelato imitant le contrat Gelato NetWork

https://gist.github.com/donoso-eth/88b3e43f5957cf1e6cdbcd326067fee0

Nous aurons besoin de construire les paramètres pour pouvoir exécuter la tâche, si nous regardons dans l'interface Ops, nous voyons que nous avons besoin des paramètres suivants

 /// @notice Execution API called by Gelato /// @param _txFee Fee paid to Gelato for execution, deducted on the TaskTreasury /// @param _feeToken Token used to pay for the execution. ETH = 0xeeeeee... /// @param _taskCreator On which contract should Gelato check when to execute the tx /// @param _useTaskTreasuryFunds If msg.sender's balance on TaskTreasury should pay for the tx /// @param _revertOnFailure To revert or not if call to execAddress fails /// @param _execAddress On which contract should Gelato execute the tx /// @param _execData Data used to execute the tx, queried from the Resolver by Gelato function exec( uint256 _txFee, address _feeToken, address _taskCreator, bool _useTaskTreasuryFunds, bool _revertOnFailure, bytes32 _resolverHash, address _execAddress, bytes calldata _execData ) external;

En utilisant l'un de nos exemples dans l'application de fête, nous aurons :

https://gist.github.com/donoso-eth/bacd13ccb9718d70f618eca6c82587f7

L'implémentation dans nos tests dapp peut être vue dans le code . Nous utilisons cette technique dans nos tests contractuels.

Conclusion

Comme nous l'avons vu, il est relativement simple de connecter le réseau gelato à nos contrats intelligents et de libérer tout le potentiel de l'automatisation. Spécifiquement pour les flux Superfluid, gelato peut permettre aux Super Apps de planifier les flux.

J'espère que cet article pourra aider d'autres développeurs à se familiariser rapidement avec gelato et à l'appliquer aux flux Superfluid.

Vous pouvez vous connecter avec moi sur Twitter @donoso_eth

Également publié ici .