Cosmos Spaces
  • About us
    • 💜Mission and Values
  • Twitter Spaces
    • 🎙️Twitter Spaces
  • Validation Service
  • ⛓️Chains
    • ➡️CosmosHub
    • ➡️Neutron
    • ➡️Stride
    • ➡️Evmos
    • ➡️Osmosis
    • ➡️Migaloo
    • ➡️Comdex
    • ➡️Stargaze
    • ➡️Juno
    • ➡️Composable
    • ➡️Axelar
    • ➡️Crescent
    • ➡️Canto
    • ➡️Omniflix
    • ➡️Quicksilver
    • ➡️Passage
    • ➡️Band Protocol
    • ➡️Kyve
    • ➡️Mars
    • ➡️Quasar
  • RELAYING SERVICE
    • 📡IBC RELAYER
  • Guides and Translations
    • 🇪🇸Spanish
      • Traducciones del blog de ICF
        • Actualización de Ingeniería del Cosmos Hub — Septiembre de 2023
        • Presentación del Roadmap del Cosmos Hub de Informal & Hypha
        • Actualización de Ingeniería del Cosmos Hub — Agosto de 2023
        • Presentando el Middleware de Devoluciones de Llamada: Combinar Contratos Inteligentes y Módulos con
        • Actualización de Ingeniería del Cosmos Hub — Julio 2023
        • Actualización de Ingeniería del Cosmos Hub — Junio de 2023
        • Capacidad de Actualización de Canales y Middleware de Tarifas: Un Vistazo Más Detallado a los Costo
        • Actualización de Ingeniería del Cosmos Hub — Mayo de 2023
        • Comparación de Seguridad Replicada, Opt-In y de Malla
        • Actualización de Ingeniería del Hub y Lanzamiento de la Primera Cadena de Consumidores
        • Prioridades de CometBFT para el segundo trimestre de 2023
        • Actualización de Ingeniería del Cosmos Hub — Marzo de 2023
        • Presentación de Twilight (v0.47)
        • Actualización de Ingeniería del Cosmos Hub — Febrero de 2023
        • Informe de Ingeniería del Cosmos Hub — Enero de 2023
        • Todo lo que necesitas saber sobre los canales IBC: FAQs (Parte 2)
        • Impulsando el crecimiento del Interchain a través del software de código abierto
        • Todo lo que necesitas saber sobre los canales IBC (Parte 1)
        • Cosmos, conoce a CometBFT
        • Interchain NFT: un protocolo para enlazar activos entre cadenas
        • Una revisión de los principales desarrollos de 2022
    • 🇮🇹Italian
      • 📝Traduzioni del blog di ICF
        • Aggiornamento sull'Ingegneria del Cosmos Hub — Settembre 2023
        • Presentazione della Roadmap del Cosmos Hub di Informal & Hypha
        • Aggiornamento sull'Ingegneria del Cosmos Hub — Agosto 2023
        • Presentazione del Middleware per le Chiamate di Ritorno: Componi Contratti Intelligenti e Moduli con
        • Aggiornamento di ingegneria del Cosmos Hub - Luglio 2023
        • Aggiornamento sull'Ingegneria del Cosmos Hub — Giugno 2023
        • Canale di Upgradabilità e Middleware delle Commissioni: Uno Sguardo Approfondito ai Costi del Relaye
        • Aggiornamento dell'Ingegneria del Cosmos Hub — Maggio 2023
        • Confronto tra Replicated, Opt-in e Mesh Security
        • Aggiornamento dell'Ingegneria del Hub & Lancio della Prima Consumer Chain
        • Priorità CometBFT per il secondo trimestre del 2023
        • Aggiornamento dell'Ingegneria di Cosmos Hub — Marzo 2023
        • Cosmos SDK: Presentazione di Twilight (v0.47)
        • Aggiornamento sull'Ingegneria di Cosmos Hub — Febbraio 2023
        • Aggiornamento sull'Ingegneria di Cosmos Hub — Gennaio 2023
        • Tutto ciò che devi sapere sui canali IBC(Parte 2)
        • Promuovere la crescita dell'Interchain attraverso il software open source.
        • Tutto ciò che devi sapere sui canali IBC (Parte 1)
        • Cosmos, incontra CometBFT
        • Interchain NFT: un protocollo per collegare asset tra catene
        • Protocollo IBC: Una Revisione dei Principali Sviluppi del 2022
  • NFT COLLECTIONS
    • 🐙Adora Squids
  • Collaborating
    • 🤝Contacts
Powered by GitBook
On this page
  1. Guides and Translations
  2. Spanish
  3. Traducciones del blog de ICF

Presentando el Middleware de Devoluciones de Llamada: Combinar Contratos Inteligentes y Módulos con

https://medium.com/the-interchain-foundation/introducing-the-callbacks-middleware-compose-smart-contracts-and-modules-with-ibc-6f3fb527e44a

Nos complace anunciar el lanzamiento del middleware de devoluciones de llamada. Ahora, los contratos inteligentes y los módulos pueden integrarse sin problemas con aplicaciones de IBC como las transferencias de tokens ICS-20 o las cuentas intercadenas ICS-27 (ICA). Por primera vez, los desarrolladores de aplicaciones pueden componer sus contratos inteligentes/módulos en cualquiera de las 100+ cadenas habilitadas para IBC que utilizan un entorno de ejecución como Wasm o EVM, para aprovechar casos de uso del tipo "enviar X, hacer Y de manera programática".

En esta publicación de blog, profundizaremos en el concepto del middleware de devoluciones de llamada, discutiendo su importancia y la amplia gama de casos de uso a los que se adapta.

TL;DR El middleware de devoluciones de llamada se admitirá a partir de ibc-go v7.3.0 y tendrá su propio go.mod. El equipo de Confio tiene como objetivo agregar soporte para esta función durante el cuarto trimestre de este año en x/wasm. Una implementación de ADR-008, el middleware de devoluciones de llamada permite que las aplicaciones de IBC como transferencia y ICA pasen devoluciones de llamada de IBC a contratos inteligentes/módulos en cada etapa del ciclo de vida del paquete: SendPacket, onRecvPacket, onAcknowledgementPacket y onTimeoutPacket. Los contratos inteligentes implementados en entornos de ejecución como Wasm, EVM, etc., pueden recuperar estas devoluciones de llamada para ejecutar acciones adicionales del usuario. Por ejemplo: enviar tokens, si la transferencia fue exitosa, automáticamente enviar un mensaje ICA para apostar esos tokens. Consulte nuestra documentación para aprender cómo integrar el middleware de devoluciones de llamada en su cadena. ¿Qué problema resuelve el middleware de devoluciones de llamada? En su diseño inicial, IBC estaba limitado a devoluciones de llamada entre IBC central y módulos de aplicación. IBC central ejecutaba una devolución de llamada a la aplicación cada vez que se enviaba o recibía un paquete.

Figura 1: Arquitectura de devolución de llamada entre IBC central y módulos de aplicación Como se muestra en la Figura 1, cuando se envía un paquete, IBC central ejecuta la devolución de llamada al módulo de envío en onAcknowledgementPacket u onTimeoutPacket. Por otro lado, al recibir un paquete, se llama a la devolución de llamada onRecvPacket.

Con el tiempo, los desarrolladores de contratos inteligentes expresaron su interés en integrar contratos inteligentes con aplicaciones de IBC como las transferencias de tokens ICS-20 o las cuentas intercadenas ICS-27 (ICA). El principal desafío al hacerlo era que los contratos inteligentes no tenían medios para obtener información sobre el resultado del ciclo de vida de un paquete. Esto significaba que si un contrato enviaba un paquete usando transferencia, no había funcionalidad dentro de ibc-go que permitiera devoluciones de llamada al contrato para confirmar si un paquete había tenido éxito. La ausencia de devoluciones de llamada obstaculizaba la ejecución de acciones de seguimiento, como el envío de un paquete ICA para intercambiar tokens que se transfirieron en el paso anterior.

Para abordar este desafío, hemos introducido el middleware de devoluciones de llamada que se encuentra entre IBC central y el entorno de ejecución, facilitando devoluciones de llamada entre estas dos partes de la pila.

¿Qué es el middleware de devoluciones de llamada? Una implementación de ADR-008, el middleware de devoluciones de llamada, es un módulo de IBC que permite que el IBC central ejecute devoluciones de llamada en cualquier entorno de ejecución. Permite que una aplicación subyacente, como transferencia o ICA, ejecute devoluciones de llamada a aplicaciones secundarias, como los marcos de ejecución Wasm o EVM.

El middleware de devoluciones de llamada funciona como una extensión del código central de IBC hacia los contratos inteligentes que residen en diferentes entornos de ejecución como x/wasm o ethermint, permitiendo que los contratos inteligentes reciban devoluciones de llamada que ocurren durante el procesamiento de un ciclo de vida de paquete regular.

El middleware de devoluciones de llamada tendrá su propio archivo go.mod y es compatible desde ibc-go v7.3.0 en adelante. El soporte para esta función dentro de x/wasm está planeado para el cuarto trimestre de este año. Evmos también admitirá el middleware de devoluciones de llamada para sus casos de uso de EVM.

Casos de Uso y Beneficios El middleware de devoluciones de llamada satisface todos los casos de uso del tipo: 'enviar X, hacer Y de forma programática'. El principal beneficio para los desarrolladores de contratos inteligentes es la capacidad de aprovechar aplicaciones de IBC existentes para construir aplicaciones nuevas y únicas para casos de uso del tipo 'transferencia + acción' o 'ICA + acción'. Esto simplifica la experiencia del usuario final y puede mejorar la retención de usuarios en las cadenas.

A continuación, se presentan algunos ejemplos de casos de uso. Tenga en cuenta que todos estos se ejecutan en un flujo de usuario único.

Enviar tokens de la cadena A a la B. Si la transferencia fue exitosa, entonces enviar un paquete ICA para apostar/participar/cambiar tokens. Ejecutar lógica de contrato inteligente arbitrario al recibir un paquete ICS-20. Como se muestra en la Figura 2, antes de que se introdujera esta función, un usuario debía confirmar manualmente el resultado de la acción 1 para decidir si continuar con la acción 2, ya que esta última dependía del resultado de la primera (éxito/fallo del paquete). Esto introduce una complejidad innecesaria y fricción para los usuarios finales de un producto.

Al permitir que los contratos inteligentes se compongan entre sí a través de IBC, el middleware de devoluciones de llamada automatiza este flujo al permitir que los módulos de aplicación transmitan el resultado de un ciclo de vida de paquete y ejecuten acciones de manera programática basadas en el resultado.

Cómo Funciona el Middleware de Devoluciones de Llamada Aquí hay una descripción rápida de cómo funciona el middleware. En nuestros ejemplos, un actor de IBC se refiere a un contrato inteligente/módulo/usuario fuera de línea que inicia un paquete utilizando una aplicación subyacente como transferencia o ICA. Un actor de devolución de llamada es un contrato inteligente/módulo en cadena registrado para recibir devoluciones de llamada de la aplicación secundaria (entorno de ejecución).

Un actor de IBC envía un paquete de transferencia. Si el paquete tiene éxito o falla, el actor de devolución de llamada recibe la devolución de llamada onAcknowledgementPacket. Un actor de IBC envía un paquete de transferencia. Si el paquete expira, el actor de devolución de llamada recibe la devolución de llamada onTimeoutPacket. Nota: En ciertos casos, el actor de IBC y el actor de devolución de llamada pueden ser la misma entidad, lo que significa que el remitente del paquete es también la entidad que recibe la devolución de llamada y realiza una acción posterior.

Las devoluciones de llamada definidas por el middleware se pueden dividir en dos categorías:

Devoluciones de llamada de la cadena de origen:

  1. SendPacket (EnviarPaquete)

  2. onAcknowledgementPacket (en el paquete de Reconocimiento)

  3. onTimeoutPacket (en el paquete de Tiempo de espera)

Devoluciones de llamada de la cadena de destino:

  1. onRecvPacket (en el paquete de Recepción)

Descripción de las Interfaces del Middleware de Devoluciones de Llamada El middleware de devoluciones de llamada expone todas las partes del ciclo de vida del paquete a la aplicación secundaria/entorno de ejecución. Dependerá de los diferentes entornos de ejecución definir sus propias API con los contratos inteligentes desplegados en su plataforma.

Para lograr esto, hemos agregado tres nuevas interfaces al IBC central:

  1. PacketDataUnmarshaller (Deserializador de Datos del Paquete): Para deserializar los bytes de datos del paquete en el tipo de datos de paquete adecuado.

  2. PacketDataProvider (Proveedor de Datos del Paquete): Para recuperar los datos personalizados del paquete. En el caso de la transferencia y el ICA, los datos personalizados del paquete están codificados dentro del campo de memo.

  3. PacketData (Datos del Paquete): Para recuperar la dirección del remitente del paquete a partir de los datos del paquete.

Puede ver los diferentes tipos de devolución de llamada que expone el middleware aquí en el archivo keys.go, a saber, send_packet (enviar_paquete), receive_packet (recibir_paquete), acknowledgement_packet (paquete_de_reconocimiento) y timeout_packet (paquete_de_tiempo_de_espera).

src_callback (devolución de llamada de origen) y dest_callback (devolución de llamada de destino) son las claves del campo de memo que se utilizan para las devoluciones de llamada de origen y destino, respectivamente. address (dirección) denota la dirección del contrato inteligente al que desea hacer la devolución de llamada. Y gas_limit (límite de gas) denota el límite de gas definido por el usuario para ejecutar una devolución de llamada. El gas_limit será igual o menor que el maxCallbackGas (gas máximo para devolución de llamada).

Otro archivo dentro del middleware de devoluciones de llamada es ibc_middleware.go. Allí puede ver las devoluciones de llamada de la cadena de origen y destino para todas las etapas del ciclo de vida del paquete. Para los fines de esta publicación en el blog, revisaremos OnAcknowledgementPacket (en el paquete de Reconocimiento), pero tenga en cuenta que la lógica para todas las devoluciones de llamada (SendPacket, onTimeoutPacket, onRecvPacket) es exactamente la misma.

El método OnAcknowledgementPacket llama a la aplicación subyacente para obtener el resultado del paquete. Si la aplicación subyacente devuelve un error, entonces la devolución de llamada no se ejecuta. De lo contrario, se recuperan los datos de la devolución de llamada utilizando la función GetSourceCallbackData (ObtenerDatos de Devolución de llamada de Origen). La ejecución de la devolución de llamada del contrato se realiza mediante processCallback (proceso de devolución de llamada).

El middleware de devoluciones de llamada requiere que la aplicación secundaria (entorno de ejecución como x/wasm) implemente la interfaz contractKeeper. Esta interfaz define los puntos de entrada expuestos a la aplicación secundaria que invoca un contrato inteligente. Como se muestra en la Figura 3, el middleware de devoluciones de llamada se comunica con contractKeeper implementado por la aplicación secundaria, y la aplicación secundaria tendrá su propia API personalizada con el actor de devolución de llamada, es decir, contratos inteligentes/módulos.

Echa un vistazo a nuestra documentación para aprender cómo integrar el middleware de devoluciones de llamada en tu aplicación.

La Figura 4 a continuación muestra un flujo de transacción completo para la transferencia ICS-20 + ICA utilizando el middleware de devoluciones de llamada para las devoluciones de llamada OnAcknowledgementPacket.

Figura 4: Flujo de transacción para transferencia + ICA utilizando el middleware de devoluciones de llamada para las devoluciones de llamada OnAcknowledgementPacket

Conclusión El lanzamiento del middleware de devoluciones de llamada establece la base para que los contratos inteligentes y módulos accedan a las aplicaciones IBC existentes para una amplia variedad de casos de uso. Los desarrolladores de aplicaciones y contratos inteligentes ahora pueden condensar múltiples acciones de usuarios finales diferentes en una sola, mejorando en gran medida la experiencia del usuario final en la cadena.

Además de permitir que los contratos inteligentes interactúen con IBC, el middleware de devoluciones de llamada amplía la comunidad de desarrolladores de IBC para incluir a los desarrolladores de contratos inteligentes. En lugar de crear nuevos controladores para hacer que tu aplicación sea compatible con IBC, ahora puedes usar tipos de mensajes preexistentes. Este enfoque transforma los componentes de IBC en bloques de construcción, lo que permite a los desarrolladores apilar fácilmente diferentes aplicaciones una encima de la otra.

Si eres un desarrollador de aplicaciones o contratos inteligentes, te animamos encarecidamente a explorar las capacidades del middleware de devoluciones de llamada, que puedes encontrar aquí. Consulta nuestra documentación para aprender cómo integrar el middleware en tu aplicación. Si tienes alguna pregunta o comentario sobre esta función, ¡no dudes en ponerte en contacto con nosotros en nuestro discord!

Agradecimientos Muchas gracias al equipo de Confio por su apoyo, con un agradecimiento especial a Alex Peters por sus invaluables contribuciones al desarrollo de esta función. También, un saludo a Osmosis por ser pioneros en los ganchos de IBC que sirvieron como fuente de inspiración para la implementación del middleware de devoluciones de llamada.

PreviousActualización de Ingeniería del Cosmos Hub — Agosto de 2023NextActualización de Ingeniería del Cosmos Hub — Julio 2023

Last updated 1 year ago

🇪🇸