🚀 Aprenda a automatizar fluxos Start/Stop Superfluid em Super Apps.
Uma das coisas mais extraordinárias sobre o web3 é que ainda estamos em um estágio inicial e, enquanto falamos, o ecossistema web3 está crescendo com novos protocolos, ferramentas, etc., e independentemente do nosso nível de especialização, podemos contribuir para ajudar os outros como estamos aprendendo. Este blog visa ajudar os desenvolvedores a usar a rede gelato com contratos inteligentes e especificamente para usar a automação Gelato com Superfluid Super Apps.
O Superfluid Protocol, entre outros recursos, permite que os usuários transmitam dinheiro/tokens para usuários/contratos com apenas uma transação e bloqueio mínimo de capital. A ressalva é que você deve se lembrar de interromper o fluxo, caso contrário, o fluxo continuará indefinidamente. Por favor, visite o site Superfluid para mais informações https://www.superfluid.finance/home
A Gelato Network permite que você execute tarefas em um ponto futuro (para o ex-web2 seria semelhante a uma espécie de agendador). O principal caso de uso é para tarefas repetidas. Para fluxos do Superfluido precisaremos apenas de uma execução (iniciar ou parar), portanto, teremos que implantar a tarefa e ao mesmo tempo o “cancelar tarefa”. Por favor, visite o site da Gelato para mais informações https://www.gelato.network/
Este projeto apresenta exemplos de uso geral de automação de contratos inteligentes com gelato, bem como o aplicativo para fluxos superfluidos, apresentando um guia muito simples de 3+3 etapas para criar fluxos de caixa programáveis
Para fazer isso, implantamos um showcase dapp em https://gelato-superapp.web.app . vamos interagir com dois principais contratos verificados e implantados em mumbai:
O código pode ser encontrado neste repositório
Aqui você encontrará 3 + 3 etapas mais fáceis para adicionar a infraestrutura de gelato e automatizar com muita facilidade suas tarefas de contrato inteligente:
Infraestrutura Wire Gelato
Estratégia de Financiamento de Gelato
Lógica de Negócios Gelato
3.1) Criação de Tarefas
3.2) Condição do Verificador
3.3) Função executável
Para interagir com a rede gelato, precisaremos interagir com os contratos Gelato (os endereços podem ser encontrados aqui ). Vamos interagir com três contratos:
Ops Contract: O contrato principal para criar, cancelar, obter taxas de transação, taxas de transferência, etc. Herdaremos o contrato OpsReady.sol
, passaremos no construtor os endereços de gelato ops e gelato treasury e estamos prontos!
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)){ }
Contrato de Tesouraria Gelato : Exigiremos a interação com o contrato de tesouraria gelato para fundos/retiradas, dependendo de nossa estratégia de financiamento (consulte a etapa 2)
Gelato Network : Vamos interagir com este contrato em nossos testes… mais na Bonus Track #2
O contrato OpsReady.sol, bem como as interfaces, podem ser encontrados em arquivos gelato dentro do repositório. Você pode simplesmente copiá-los e funciona!
A Gelato executa transações em um momento futuro, portanto, precisamos escolher uma forma de financiar as transações que a Gelato executará em nosso nome. Existem duas alternativas para fazer isso:
1) Financiar o Contrato de Tesouraria Gelato: desde que você tenha um saldo positivo no contrato de tesouraria, as transações futuras serão executadas. Se escolhermos esta alternativa, precisamos interagir com o Contrato de Tesouraria do Gelato financiando-o.
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) Financiar todas as transações: Nosso contrato inteligente transferirá em todas as transações futuras o valor solicitado para pagar as taxas. Nesse caso, não precisaremos interagir com o Contrato de Tesouraria da Gelato, mas devemos manter um saldo positivo em nosso contrato .
Existem três partes/etapas principais que temos que definir dentro da lógica de negócio:
3.1) Criar a Tarefa: Teremos que definir uma tarefa para dizer ao Gelato o que queremos que seja executado.
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) Condição do verificador: Para executar uma transação futura, teremos que fornecer à Gelato a condição de verificar se a Gelato pode executar ou não
function checkerStartParty() external view returns (bool canExec, bytes memory execPayload) { canExec = headachePresent == false; execPayload = abi.encodeWithSelector(this.startParty.selector); }
3.3) Função Executável: Função que será executada quando condições e/ou tempo forem atendidos.
function startParty() external onlyOps { require(headachePresent == false, "NOT_READY"); lastPartyStart = block.timestamp; headachePresent = true; }
https://gist.github.com/donoso-eth/0678b0613db36c6c332063c9f39cddfd
Nosso primeiro aplicativo Gelato será muito simples. Ele verifica se nossa festa do gelato começou ou não. A festa sempre vai começar se não tivermos uma “dor de cabeça” da festa anterior.
Podemos definir manualmente quando nossa “dor de cabeça” acabou e então a rede Gelato será capaz de executar a festa de início, definindo um novo timestamp de festa de início e definindo nossa “dor de cabeça como verdadeiro”
Nossa tela é dividida em duas partes, dependendo de nossa estratégia de financiamento.
Este contrato permite três casos de uso:
Uma vez criada a tarefa, podemos acessar o site do gelato ops e veremos nossa tarefa aguardando a execução
E após a execução bem-sucedida, o painel de operações nos mostrará algo assim.
Crie uma tarefa simples financiada com tesouraria e cancele após a primeira execução (vamos usar esse padrão mais tarde com nossos fluxos de superfluido).
https://gist.github.com/donoso-eth/517e2dca691980de506229cbe27eee62
Crie uma tarefa simples pagando cada transação (não financiamento do tesouro)
https://gist.github.com/donoso-eth/340ca96b53005dd457defab0991a735c
Nosso super aplicativo Gelato nos ajudará a tornar os fluxos superfluidos programáveis, automatizando a parada ou o início de um fluxo.
Implementaremos a Infraestrutura do gelato (Etapa 1) como no app da festa e escolhemos o financiamento do Tesouro como Estratégia de Financiamento (Etapa 2)
Demonstraremos a interrupção de um fluxo após alguns minutos predefinidos. Nossa lógica de negócios ficará assim:
https://gist.github.com/donoso-eth/e4fc0145ed75ed84309da1a467175931
Agora se você financiou o tesouro, iniciou um fluxo e o gelato já foi executado parando o fluxo, você desbloqueou seu Bônus!!
Até agora conseguimos parar um stream automaticamente, mas seguindo a mesma lógica, posso querer começar a transmitir para um novo funcionário exatamente às 00:00 AM do primeiro dia de trabalho e não quero ficar acordado todos os dias porque, com sorte, vamos contratar muitos funcionários!
.. então CFA ACL (lista de controle de acesso CFA) para o resgate, com uma simples chamada para o contrato constante CFA do SDK ou diretamente para o contrato, você pode permitir que nosso Super App inicie um fluxo em seu nome quando um determinado tempo é decorrido e uma “Tarefa Gelato” é executada.
Neste caso de uso, estamos concatenando duas tarefas, quando a primeira for executada, o fluxo será iniciado, a tarefa cancelada e outra tarefa para interromper o fluxo será criada.
https://gist.github.com/donoso-eth/5491f5f94409f9648fa196c3ed24ca3d
Uma das experiências agradáveis no desenvolvimento de blockchain é a capacidade de criar um clique de…..
À medida que nossos dapps crescem em complexidade, precisaremos interagir com os contratos on-chain existentes e , se quisermos permanecer locais , teremos que simular/implantar protocolos. Em alguns casos, isso pode ser complicado e gastaremos um tempo precioso de desenvolvimento . A melhor alternativa para contornar esse problema é trabalhar com um fork, com uma configuração bem simples dentro do nosso hardhat.config.ts
(obrigado Sam Flamini e Hilmar X por apontarem a direção certa).
https://gist.github.com/donoso-eth/1dbfc57d3d40679e324048e1d7c01ab4
e, em seguida, com o npx hardhat node --network "hardhat"
, poderemos criar uma cópia "virtual" do blockchain que estamos almejando. Os blocos que criamos a partir de agora serão armazenados localmente e para os mais antigos iremos consultar o blockchain “real” com nosso provedor RPC (acima estamos usando alquimia)
Em nosso exemplo, estamos trabalhando com Mumbai, os contratos Superfluid (Host, ConstanFlowAgreeent, Supertoken…), bem como os contratos Gelato (Network, OPS e Treasury), existem com o estado que tinham no número do bloco do fork permitindo-nos interagir com eles como interagiríamos com o blockchain “real”.
Agora, você tem seu “mumbai” local com os métodos auxiliares adicionais para realmente dominar a cadeia:
https://gist.github.com/donoso-eth/148d031bbc57e6a3b6708367a52b0069
Em nosso Dapp estamos trabalhando com contratos Gelato. Os “Executores” se encarregarão de automatizar nossas tarefas, mas em nossa cadeia “virtual” local não há executores… quem executará nossas tarefas?. E a resposta para isso é muito simples, nós mesmos vamos executar a tarefa . Podemos fazer isso porque dominamos nosso blockchain local, podemos ser quem quisermos e escolhemos ser o executor. Hardhat nos fornece o fantástico método hardhat_impersonateAcount
e vamos usá-lo para nos tornarmos localmente “o executor”.
Aqui podemos ver os detalhes da implementação para executar tarefas de gelato representando o contrato Gelato NetWork
https://gist.github.com/donoso-eth/88b3e43f5957cf1e6cdbcd326067fee0
Precisamos construir os parâmetros para poder executar a tarefa, se olharmos na interface Ops, veremos que precisamos dos seguintes parâmetros
/// @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;
Utilizando um de nossos exemplos no app party teremos:
https://gist.github.com/donoso-eth/bacd13ccb9718d70f618eca6c82587f7
A implementação em nossos testes dapp pode ser vista no código . Usamos essa técnica em nossos testes de contrato.
Como vimos, é relativamente simples conectar a rede de gelato aos nossos contratos inteligentes e liberar todo o potencial da automação. Especificamente para fluxos Superfluid, o gelato pode permitir que Super Apps façam agendamento de fluxo.
Espero que este artigo possa ajudar outros desenvolvedores a começar a trabalhar rapidamente com o gelato e aplicá-lo aos fluxos do Superfluido.
Você pode se conectar comigo no Twitter @donoso_eth
Publicado também aqui .