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. Italian
  3. Traduzioni del blog di ICF

Presentazione del Middleware per le Chiamate di Ritorno: Componi Contratti Intelligenti e Moduli con

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

Siamo entusiasti di annunciare il rilascio del middleware per le chiamate di ritorno. Ora, i contratti intelligenti e i moduli possono integrarsi senza soluzione di continuità con applicazioni IBC come i trasferimenti di token ICS-20 o gli account interchain ICS-27 (ICA). Per la prima volta, gli sviluppatori di applicazioni possono comporre i loro contratti intelligenti/moduli su una delle oltre 100 catene abilitate IBC che utilizzano un ambiente di esecuzione come Wasm o EVM, per sfruttare casi d'uso del tipo "invia X, fai Y in modo programmatico".

In questo post del blog, approfondiremo il concetto del middleware per le chiamate di ritorno, discutendo della sua importanza e della vasta gamma di casi d'uso a cui si rivolge.

TL;DR Il middleware per le chiamate di ritorno sarà supportato in ibc-go dalla versione 7.3.0 in poi e avrà il suo go.mod. Il team di Confio mira ad aggiungere il supporto per questa funzionalità entro il quarto trimestre di quest'anno in x/wasm. Un'implementazione dell'ADR-008, il middleware per le chiamate di ritorno consente alle app IBC come il trasferimento e l'ICA di passare chiamate di ritorno IBC a contratti intelligenti/moduli in ogni fase del ciclo di vita del pacchetto: SendPacket, onRecvPacket, onAcknowledgementPacket e onTimeoutPacket. I contratti intelligenti implementati su ambienti di esecuzione come Wasm, EVM, ecc., possono recuperare queste chiamate di ritorno per eseguire ulteriori azioni dell'utente. Ad esempio: inviare token, se il trasferimento è stato completato con successo, quindi inviare automaticamente un messaggio ICA per mettere in staking quei token. Consulta la nostra documentazione per imparare come integrare il middleware per le chiamate di ritorno sulla tua catena. Qual è il problema risolto dal middleware per le chiamate di ritorno? Nel suo design iniziale, IBC era limitato alle chiamate di ritorno tra i moduli IBC core e le applicazioni. IBC core eseguiva una chiamata di ritorno all'applicazione ogni volta che veniva inviato o ricevuto un pacchetto.

Figura 1: Architettura delle chiamate di ritorno tra IBC core e i moduli dell'applicazione Come mostrato nella Figura 1, quando viene inviato un pacchetto, IBC core esegue la chiamata di ritorno al modulo mittente onAcknowledgementPacket o onTimeoutPacket. Al contrario, al ricevimento di un pacchetto, viene chiamata la chiamata di ritorno onRecvPacket.

Col passare del tempo, gli sviluppatori di contratti intelligenti hanno manifestato interesse nell'integrazione dei contratti intelligenti con le applicazioni IBC come i trasferimenti di token ICS-20 o gli account interchain ICS-27 (ICA). La sfida principale era che i contratti intelligenti non avevano modo di ottenere informazioni sull'esito del ciclo di vita di un pacchetto. Ciò significava che se un contratto inviava un pacchetto utilizzando il trasferimento, non c'era alcuna funzionalità all'interno di ibc-go che consentisse le chiamate di ritorno al contratto per confermare se un pacchetto fosse stato completato con successo. L'assenza delle chiamate di ritorno ostacolava l'esecuzione di azioni successive, come l'invio di un pacchetto ICA per scambiare i token che erano stati trasferiti nel passaggio precedente.

Per affrontare questa sfida, abbiamo introdotto il middleware per le chiamate di ritorno che si posiziona tra IBC core e l'ambiente di esecuzione, facilitando le chiamate di ritorno tra queste due parti dello stack.

Cos'è il Middleware per le Chiamate di Ritorno? Un'implementazione dell'ADR-008, il middleware per le chiamate di ritorno, è un modulo IBC che consente a IBC core di eseguire chiamate di ritorno verso qualsiasi ambiente di esecuzione. Consente a un'applicazione sottostante, come il trasferimento o l'ICA, di eseguire chiamate di ritorno verso applicazioni secondarie, come i framework di esecuzione Wasm o EVM.

Il middleware per le chiamate di ritorno funziona come un'estensione del codice IBC core per i contratti intelligenti che operano su diversi ambienti di esecuzione come x/wasm o ethermint, consentendo ai contratti intelligenti di ricevere chiamate di ritorno che si verificano durante l'elaborazione di un ciclo di vita di pacchetto regolare.

Il middleware per le chiamate di ritorno avrà il proprio file go.mod ed è supportato da ibc-go dalla versione 7.3.0 in poi. Il supporto per questa funzionalità in x/wasm è previsto per il quarto trimestre di quest'anno. Evmos supporterà anche il middleware per le chiamate di ritorno per i loro casi d'uso EVM.

Casi d'Uso e Benefici Il middleware per le chiamate di ritorno soddisfa tutti i casi d'uso della forma: 'invia X, fai Y in modo programmato'. Il principale vantaggio per gli sviluppatori di contratti intelligenti è la possibilità di sfruttare le app IBC esistenti per creare nuove e uniche app per casi d'uso della forma 'trasferimento + azione', o 'ICA + azione'. Questo semplifica l'esperienza dell'utente finale e può migliorare il coinvolgimento degli utenti nelle catene.

Di seguito sono riportati alcuni esempi di casi d'uso. Si noti che tutti questi vengono eseguiti in un unico flusso utente.

Invia token dalla catena A alla B. Se il trasferimento è stato completato con successo, invia quindi un pacchetto ICA per mettere in staking/i token swap. Esegui logica arbitraria di contratto intelligente al ricevimento di un pacchetto ICS-20. Come rappresentato nella Figura 2, prima dell'introduzione di questa funzionalità, un utente doveva confermare manualmente l'esito dell'azione 1 per decidere se procedere con l'azione 2, poiché quest'ultima dipendeva dal risultato della prima (successo/fallimento del pacchetto). Questo introduce complessità e attrito superflui per gli utenti finali di un prodotto.

Abilitando i contratti intelligenti a comporre tra loro su IBC, il middleware per le chiamate di ritorno automatizza questo flusso consentendo ai moduli dell'applicazione di trasmettere il risultato di un ciclo di vita del pacchetto ed eseguire azioni in modo programmato in base al risultato.

Come Funziona il Middleware per le Chiamate di Ritorno Ecco una breve panoramica del funzionamento del middleware. Nei nostri esempi, un attore IBC si riferisce a un contratto intelligente/modulo/off-chain utente che avvia un pacchetto utilizzando un'applicazione sottostante come il trasferimento o l'ICA. Un attore di chiamata di ritorno è un contratto intelligente/modulo on-chain registrato per ricevere chiamate di ritorno dalla seconda app (ambiente di esecuzione).

Un attore IBC invia un pacchetto di trasferimento. Se il pacchetto ha successo o fallisce, l'attore di chiamata di ritorno riceve la chiamata di ritorno onAcknowledgementPacket. Un attore IBC invia un pacchetto di trasferimento. Se il pacchetto va in timeout, l'attore di chiamata di ritorno riceve la chiamata di ritorno onTimeoutPacket. Nota: In certi casi, l'attore IBC e l'attore di chiamata di ritorno possono essere la stessa entità, il che significa che il mittente del pacchetto è anche l'entità che riceve la chiamata di ritorno e compie un'azione successiva.

Le chiamate di ritorno definite dal middleware possono essere suddivise in due categorie:

Chiamate di ritorno della catena di origine: SendPacket onAcknowledgementPacket onTimeoutPacket

  1. Chiamate di ritorno della catena di destinazione:

onRecvPacket Panoramica delle Interfacce del Middleware per le Chiamate di Ritorno Il middleware per le chiamate di ritorno espone tutte le parti del ciclo di vita del pacchetto alla seconda app/ambiente di esecuzione. Spetta ai diversi ambienti di esecuzione definire le proprie API con i contratti intelligenti implementati sulla loro piattaforma.

Per raggiungere questo obiettivo, abbiamo aggiunto tre nuove interfacce a IBC core:

PacketDataUnmarshaller: Per deserializzare i byte dei dati del pacchetto nel tipo di dati del pacchetto appropriato. PacketDataProvider: Per recuperare i dati personalizzati dal pacchetto. Nel caso di trasferimenti e ICA, i dati personalizzati del pacchetto sono codificati nel campo memo. PacketData: Per recuperare l'indirizzo del mittente del pacchetto dai dati del pacchetto. Puoi vedere i diversi tipi di callback esposti dal middleware qui nel file keys.go, ovvero send_packet, receive_packet, acknowledgement_packet e timeout_packet.

src_callback e dest_callback sono le chiavi del campo memo che vengono utilizzate per le callback di origine e destinazione, rispettivamente. address indica l'indirizzo del contratto intelligente al quale desideri fare la callback. E gas_limit indica il limite di gas definito dall'utente per eseguire una callback. Il gas_limit sarà uguale o inferiore al maxCallbackGas.

Un altro file all'interno del middleware per le chiamate di ritorno è ibc_middleware.go. Lì puoi vedere le callback della catena di origine e di destinazione per tutte le fasi del ciclo di vita del pacchetto. Per quanto riguarda questo post, passeremo attraverso OnAcknowledgementPacket, ma nota che la logica per tutte le callback (SendPacket, onTimeoutPacket, onRecvPacket) è esattamente la stessa.

Il metodo OnAcknowledgementPacket chiama l'applicazione sottostante per ottenere il risultato del pacchetto. Se l'applicazione sottostante restituisce un errore, allora la callback non viene eseguita. In caso contrario, i dati della callback vengono recuperati utilizzando la funzione GetSourceCallbackData. L'esecuzione della callback del contratto è eseguita da processCallback.

Il middleware per le chiamate di ritorno richiede che l'applicazione secondaria (ambiente di esecuzione come x/wasm) implementi l'interfaccia contractKeeper. Questa interfaccia definisce i punti di ingresso esposti all'applicazione secondaria che chiama un contratto intelligente. Come mostrato nella Figura 3, il middleware per le chiamate di ritorno comunica con il contractKeeper implementato dall'applicazione secondaria e quest'ultima avrà la sua propria API personalizzata con l'attore di chiamata di ritorno, ovvero i contratti intelligenti/moduli.

L'interfaccia contractKeeper delinea i metodi richiesti per un conservatore di contratti per gestire varie callback della catena di origine e di destinazione. Questi includono IBCSendCallback, IBCOnAcknowledgementPacketCallback, IBCOnTimeoutCallback e IBCReceivePacketCallback. I primi tre metodi sono callback della catena di origine, mentre l'ultimo è una callback di destinazione.

Consulta la nostra documentazione per imparare come integrare il middleware per le chiamate di ritorno nella tua app.

La Figura 4 qui sotto mostra un flusso completo di transazioni per il trasferimento ICS-20 + ICA utilizzando il middleware per le chiamate di ritorno per le callback OnAcknowledgementPacket.

Conclusioni Il rilascio del middleware per le chiamate di ritorno stabilisce le basi per consentire ai contratti intelligenti e ai moduli di sfruttare le app IBC esistenti per una vasta gamma di casi d'uso. Gli sviluppatori di applicazioni e contratti intelligenti possono ora condensare molteplici azioni diverse degli utenti finali in un'unica azione, migliorando notevolmente l'esperienza dell'utente finale on-chain.

PreviousAggiornamento sull'Ingegneria del Cosmos Hub — Agosto 2023NextAggiornamento di ingegneria del Cosmos Hub - Luglio 2023

Last updated 1 year ago

🇮🇹
📝