🚀 Aprenda a automatizar transmisiones de Superfluid Start/Stop en Super Apps.

Una de las cosas más extraordinarias de web3 es que todavía estamos en una etapa inicial y, mientras hablamos, el ecosistema web3 está creciendo con nuevos protocolos, herramientas, etc., e independientemente de nuestro nivel de experiencia, podemos contribuir a ayudar a otros. como estamos aprendiendo. Este blog tiene como objetivo ayudar a los desarrolladores a usar la red de gelato con contratos inteligentes y específicamente para usar la automatización de Gelato con Superfluid Super Apps.

El protocolo superfluido, entre otras características, permite a los usuarios transmitir dinero/fichas a usuarios/contratos con una sola transacción y un bloqueo de capital mínimo. La advertencia es que debe recordar detener la transmisión, de lo contrario, la transmisión continuará sin cesar. Visite el sitio web de Superfluid para obtener más información https://www.superfluid.finance/home

Gelato Network le permite ejecutar tareas en un momento futuro (por ejemplo, web2 sería similar a una especie de programador). El caso de uso principal es para tareas repetidas. Para flujos de Superfluid solo necesitaremos una ejecución (start o stop) por lo tanto tendremos que desplegar la tarea y al mismo tiempo la “cancelar Tarea”. Visite el sitio web de Gelato para obtener más información https://www.gelato.network/

Este proyecto muestra ejemplos de uso general de la automatización de contratos inteligentes con gelato, así como la aplicación para flujos superfluidos que presentan una guía muy simple de 3+3 pasos para crear flujos de efectivo programables.

Para hacer eso, hemos implementado un dapp de exhibición en https://gelato-superapp.web.app . interactuaremos con dos principales contratos verificados y desplegados en mumbai:

• Contrato de aplicación de fiesta ( ver en escaneo )
• Gelato Super App Contract ( ver en escaneo )

El código se puede encontrar en este repositorio .

Guía de 3+3 pasos para Gelatofy un contrato inteligente

Aquí encontrará 3 + 3 pasos más fáciles para agregar la infraestructura de gelato y automatizar muy fácilmente sus tareas de contrato inteligente:

1. Infraestructura de Wire Gelato

2. Estrategia de financiación de helados

3. Lógica de negocio del helado

   3.1) Creación de tareas

   3.2) Condición del verificador

   3.3) Función ejecutable

Paso 1: Infraestructura de Wire Gelato

Para interactuar con la red de gelato, necesitaremos interactuar con los contratos de Gelato (las direcciones se pueden encontrar aquí ). Interactuamos con tres contratos:

Contrato de operaciones: el contrato principal para crear, cancelar, obtener tarifas de transacción, tarifas de transferencia, etc. Heredaremos el contrato OpsReady.sol , pasaremos al constructor las direcciones de heladería y heladería y estamos listos para comenzar.

 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 tesorería de helado: Necesitaremos interactuar con el contrato de tesorería de helado para fondos/retiros dependiendo de nuestra estrategia de financiación (consulte el paso 2)

Gelato Network : interactuaremos con este contrato en nuestras pruebas... más en Bonus Track #2

El contrato OpsReady.sol, así como las interfaces, se pueden encontrar en archivos gelato dentro del repositorio. ¡Puedes simplemente copiarlos y funciona!

Paso 2: Estrategia de financiación de Gelato

Gelato ejecuta transacciones en un momento futuro, por lo tanto, debemos elegir una forma de financiar las transacciones que Gelato ejecutará en nuestro nombre. Hay dos alternativas para hacerlo:

1) Financiar el contrato de tesorería de Gelato: siempre que tenga un saldo positivo en el contrato de tesorería, las transacciones futuras se ejecutarán. Si elegimos esta alternativa, necesitamos interactuar con el Contrato de Tesorería de Gelato que lo financia.

 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 cada transacción: Nuestro contrato inteligente transferirá en cada transacción futura el monto solicitado para pagar las tarifas. En este caso, no necesitaremos interactuar con el Contrato de Tesorería de Gelato pero sí debemos mantener un saldo positivo en nuestro contrato .

Paso 3: Lógica de negocios de Gelato

Hay tres partes/pasos principales que tenemos que definir dentro de la lógica empresarial:

3.1) Crear la Tarea: Tendremos que definir una tarea para decirle a Gelato lo que queremos que se ejecute.

 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) Condición del verificador: para ejecutar una transacción futura, tendremos que proporcionarle a Gelato la condición para verificar si Gelato puede ejecutar o no

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

3.3) Función Ejecutable: Función que será ejecutada cuando se cumplan las condiciones y/o tiempo.

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

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

¡Demostración de la aplicación Party!

Nuestra primera aplicación Gelato va a ser muy simple. Comprueba si nuestra fiesta de helado ha comenzado o no. La fiesta siempre empezará si no tenemos un “dolor de cabeza” de la fiesta anterior.

Podemos establecer manualmente cuándo termina nuestro "dolor de cabeza" y luego la red Gelato podrá ejecutar la fiesta de inicio, establecer una nueva marca de tiempo de la fiesta de inicio y establecer nuestro "dolor de cabeza en verdadero"

Nuestra pantalla se divide en dos partes dependiendo de nuestra estrategia de financiación.

Este contrato permite tres casos de uso:

1. Cree una tarea simple financiada con tesorería: los detalles se pueden ver arriba

Una vez creada la tarea podemos ir a la web de gelato ops y veremos nuestra tarea esperando ejecución

Y después de una ejecución exitosa, el tablero de operaciones nos mostrará algo como esto.

2. Cree una tarea simple financiada con tesorería y cancele después de la primera ejecución (vamos a usar este patrón más adelante con nuestras transmisiones Superfluid).

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

3. Crear una tarea simple pagando cada transacción (no financiación de tesorería)

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

   
   

Demostración de la aplicación Gelato Super

Nuestra súper aplicación Gelato nos ayudará a hacer que las transmisiones superfluidas sean programables al automatizar la parada o el inicio de una transmisión.

Implementaremos la Infraestructura del helado (Paso 1) como en la aplicación del partido y elegiremos la financiación del Tesoro como Estrategia de Financiamiento (Paso 2)

Haremos una demostración de detener una transmisión después de algunos minutos predefinidos. Nuestra lógica de negocios se verá así:

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

Ahora, si ha financiado la tesorería, ha iniciado una transmisión y el helado ya se ha ejecutado deteniendo la transmisión, ¡ha desbloqueado su Bono!

Bonus Track #1: Ve a dormir y la transmisión comenzará.

Hasta ahora hemos logrado detener una transmisión automáticamente, pero siguiendo la misma lógica, es posible que desee comenzar a transmitir a un nuevo empleado exactamente a las 00:00 a. m. del primer día de trabajo y no quiero estar despierto todos los días. ¡Porque con suerte, vamos a contratar a muchos empleados!

.. luego CFA ACL (Lista de control de acceso de CFA) al rescate, con una simple llamada al acuerdo constante de CFA, ya sea desde el SDK o directamente al contrato , es posible que desee permitir que nuestra Super aplicación inicie una transmisión en su nombre cuando un transcurre cierto tiempo y se ejecuta una “Tarea Gelato”.

En este caso de uso, estamos concatenando dos tareas, cuando se ejecuta la primera, se iniciará la transmisión, se cancelará la tarea y se creará otra tarea para detener la transmisión.

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

Bonus Track n.° 2: Master Hardhat Fork y Sky Rocket tu velocidad de desarrollo

Una de las experiencias agradables en el desarrollo de blockchain es la capacidad de crear con un solo clic…

A medida que nuestras dapps crezcan en complejidad, necesitaremos interactuar con los contratos en cadena existentes y , si queremos permanecer locales , tendremos que simular/implementar protocolos. En algunos casos, eso puede ser engorroso y gastaremos un tiempo precioso de desarrollo . La mejor alternativa para superar este problema es trabajar con una bifurcación, con una configuración muy simple dentro de nuestro hardhat.config.ts (gracias a Sam Flamini y Hilmar X por señalar la dirección correcta).

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

y luego con el npx hardhat node --network "hardhat" podremos crear una copia "virtual" de la cadena de bloques a la que nos dirigimos. Los bloques que creamos a partir de ahora se almacenarán localmente y para los más antiguos consultaremos la cadena de bloques "real" con nuestro proveedor de RPC (arriba estamos usando alquimia)

En nuestro ejemplo, estamos trabajando con mumbai, los contratos Superfluid (Host, ConstanFlowAgreeent, Supertoken…), así como los contratos Gelato (Network, OPS y Treasury), existen con el estado que tenían en el número de bloque del fork permitiéndonos interactuar con ellos como lo haríamos con la cadena de bloques "real".

Ahora, tiene su "mumbai" local con los métodos auxiliares adicionales para dominar realmente la cadena:

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

En nuestra Dapp estamos trabajando con contratos de Gelato. Los “Ejecutores” se encargarán de automatizar nuestras tareas, pero en nuestra cadena local “virtual” no hay ejecutores… ¿quién ejecutará nuestras tareas?. Y la respuesta a eso es muy sencilla, vamos a ejecutar la tarea nosotros mismos . Podemos hacer eso porque dominamos nuestra cadena de bloques local, podemos ser quienes queramos ser y elegimos ser el ejecutor. Hardhat nos proporciona el fantástico método hardhat_impersonateAcount y lo utilizaremos para convertirnos localmente en “el ejecutor”.

Aquí podemos ver los detalles de la implementación para ejecutar tareas de gelato suplantando el contrato de Gelato NetWork

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

Necesitaremos construir los parámetros para poder ejecutar la tarea, si miramos en la interfaz de Ops vemos que necesitamos los siguientes 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;

Usando uno de nuestros ejemplos en la aplicación de fiesta tendremos:

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

La implementación en nuestras pruebas dapp se puede ver en el código . Usamos esta técnica en nuestras pruebas de contrato.

Conclusión

Como hemos visto, es relativamente sencillo conectar la red de heladería a nuestros contratos inteligentes y desbloquear todo el potencial de la automatización. Específicamente para las transmisiones Superfluid, el gelato puede permitir que Super Apps realice la programación de transmisiones.

Espero que este artículo pueda ayudar a otros desarrolladores a ponerse en marcha rápidamente con gelato y aplicarlo a las transmisiones de Superfluid.

Puedes conectarte conmigo en Twitter @donoso_eth

También publicado aquí .