Tutto ciò che devi sapere sui canali IBC(Parte 2)

blog originale: https://medium.com/the-interchain-foundation/everything-you-need-to-know-about-ibc-channels-faqs-part-2-44249a7b7e0b

Le channels sono un componente cruciale del protocollo di Inter Blockchain Communication (IBC) poiché consentono la comunicazione tra applicazioni. Per gli sviluppatori che implementano l'IBC per le proprie app, è utile avere una solida comprensione dei channels, poiché è il livello di astrazione con cui avranno il maggior contatto.

Nella parte 1 di questa serie di due articoli del blog, abbiamo discusso i fondamenti dei channels IBC e la loro importanza per gli sviluppatori di applicazioni. In questa seconda parte, affrontiamo domande comuni e fraintendimenti riguardo ai channels.

FAQs (Domande frequenti) Quali sono le ragioni per cui un channel potrebbe chiudersi?

Un channel può chiudersi per una delle seguenti 3 ragioni:

1. A causa di un timeout del pacchetto su un channel ordinato.

2. A causa di una presa di controllo del 66% da parte di validatori malintenzionati su una chain.

3. A causa di un attacco ai light client in cui la chain compromessa può ingannare la controparte facendole credere che ha chiuso la sua estremità del channel.

Come avviene la chiusura dei channels?

Un channel si chiude quando un modulo chiama chanCloseInit per chiudere la propria estremità del channel. Successivamente, il modulo controparte chiama chanCloseConfirm per chiudere la sua estremità del channel.

Se un pacchetto viene ricevuto fuori sequenza su un channel ordinato, il channel si chiude automaticamente?

No, non si chiude automaticamente. Il pacchetto viene semplicemente respinto da core IBC fino a quando un relayer invia il pacchetto atteso con la sequenza corretta (vedi la sezione "Tipi di channel" nella parte 1 per ulteriori informazioni).

Ogni modulo (trasferimento, conti interchain, interrogazioni interchain, ecc.) ha il proprio channel?

Sì, lo ha. Ogni modulo, come trasferimento/conti interchain/interrogazioni interchain, si collega a una porta e quindi apre un channel utilizzando quella porta.

I channels sono ordinati nel caso dei conti interchain?

Sì, attualmente tutti i channels che utilizzano i conti interchain sono channels ordinati. Quindi, se scade un timeout del pacchetto, il channel si chiude e deve essere negoziato un nuovo channel. Farlo evita errori inutili. Ad esempio, un utente invia 2 transazioni ICA, il pacchetto n. 3 per trasferire token e il pacchetto n. 4 per congelare quei token. Se i channels non fossero ordinati, potrebbe verificarsi una situazione in cui il pacchetto n. 4 viene consegnato prima del n. 3, causando un errore.

Può una chain avere più canali per lo stesso modulo di trasferimento?

Anche se non c'è motivo per cui una chain dovrebbe avere più canali per il modulo di trasferimento, è possibile farlo. Tuttavia, creare due o più canali per il trasferimento è ridondante e non fornisce alcun beneficio (a meno che non siano due versioni diverse). Inoltre, causa la non fungibilità dello stesso token inviato su due canali diversi. Consultare la sezione sulla 'fungibilità dei token' nella parte 1 per capire il motivo.

Un channel può essere collegato a più canali?

Fino ad oggi, tutti i canali sono mappature 1 a 1. Ciò significa che il channel-141 sul Cosmos Hub sarà collegato solo al channel-0 su Osmosis e a nessun altro.

Una chain può avere due o più canali con lo stesso ID di canale?

No, questo non è possibile. In una determinata chain, tutti i canali hanno un ID di canale unico. L'ID viene incrementato ogni volta che viene aperto un nuovo canale su una chain.

È necessaria una handshake del canale ogni volta che viene inviato un pacchetto IBC?

No, una handshake del canale è necessaria solo per aprire o chiudere un canale. Una volta che un canale è stato aperto, i pacchetti possono fluire liberamente attraverso di esso.

È possibile aggiornare un modulo dalla versione 1 alla versione 2 mantenendo lo stesso canale?

Attualmente ciò non è possibile in ibc-go. L'aggiornamento di un modulo o l'aggiunta di una nuova funzionalità/middleware su entrambi i lati di un canale richiede o un aggiornamento a livello di rete o la negoziazione di un nuovo canale. Ma con il lancio della funzionalità di aggiornamento dei canali previsto per quest'anno, i canali potranno sfruttare nuove funzionalità e i moduli potranno essere aggiornati mantenendo il canale esistente.

È possibile limitare la quantità di token che fluiscono dentro/fuori da un canale?

Sì, con l'uso di un middleware di limitazione del tasso. Consultare qui per le specifiche e le implementazioni del limitatore del tasso in Go e per i contratti CosmWasm in un wrapper Go.

È possibile limitare determinati token denom dal fluire in una chain?

Sì, vedere questo PR accettato su come aggiungere un middleware IBC che funziona essenzialmente come un firewall per determinate denom dal trasferimento in una blockchain connessa all'IBC.

Come vengono riaperti i canali?

Una volta che un canale è chiuso, lo stesso canale con lo stesso ID di canale non può essere riaperto.

Il riutilizzo degli ID dei canali è impedito al fine di evitare la ripetizione dei pacchetti. Ogni pacchetto è identificato in modo univoco dal suo ID porta, ID canale e sequenza. Quando si apre un nuovo canale, la sequenza del pacchetto viene azzerata. Pertanto, utilizzare lo stesso ID porta e ID canale può causare il ripetersi dei pacchetti che sono stati elaborati in precedenza.

Se un light client scade o viene bloccato, è possibile mantenere i canali esistenti mentre si riattiva il client?

Sì, un light client bloccato o scaduto può essere riattivato con una proposta di governance riuscita. Se la proposta viene approvata, il client viene riattivato e tutti i canali esistenti costruiti su quel client vengono riaperti. Puoi fare riferimento alla nostra documentazione per ulteriori informazioni su come riattivare un client.

Cos'è una porta?

Una porta è una costruzione logica che applica le capacità degli oggetti. Le porte assicurano che il modulo unico che può aprire un canale su una porta particolare sia il modulo vincolato a quella porta. Quando un modulo si lega a una porta, gli viene emessa una capacità che il modulo deve poi richiedere.

Le porte designano uno spazio dei nomi per i moduli, come ad esempio 'transfer' per i trasferimenti di token ICS-20 o 'icacontroller' per il sottomodulo controller ICA.

Avere più canali aumenta la capacità di throughput della chain?

No, non lo fa per ibc-go perché Tendermint elabora le transazioni in modo sequenziale. Avere un solo canale o più canali tra due chain produrrà lo stesso throughput.

Chi imposta i parametri di timeout?

Il modulo che invia il pacchetto.

È possibile impostare i timeout su zero?

È possibile impostare a zero sia il timestamp di timeout che l'altezza di timeout, ma non entrambi contemporaneamente.

I relayer devono pagare commissioni per l'invio di un pacchetto che ha subito un timeout?

Sì, devono farlo. Un relayer deve eseguire calcoli che comportano la spesa di gas, anche se il pacchetto subisce un timeout sulla chain di ricezione.

Le conferme hanno timeout?

No, non ce l'hanno. Deve esserci almeno un messaggio che può essere inviato in modo asincrono. In caso contrario, si crea un problema circolare in cui se ci fossero timeout per le conferme, allora il messaggio che prova che la conferma è scaduta potrebbe scadere a sua volta, e così via, causando un loop infinito.

Dove posso vedere tutti i canali IBC esistenti e i loro rispettivi ID?

Puoi vederli qui su mintscan o sul registro della chain.

Conclusione Se hai domande rimanenti dopo aver letto le FAQ, sentiti libero di contattarci nei canali per sviluppatori o di supporto su Discord. E se sei uno sviluppatore di chain, uno sviluppatore di applicazioni o uno sviluppatore di light client interessato a utilizzare IBC, troverai tutte le informazioni di cui hai bisogno nel nostro portale per sviluppatori o nella nostra documentazione ibc-go.