Cos’è l’Inter-Blockchain Communication Protocol (IBC) e come funziona

L’Inter-Blockchain Communication Protocol, o IBC, è un protocollo che gestisce l’autenticazione e il transito dei dati tra due blockchain differenti.

L’IBC richiede un insieme minimo di funzionalità, delineate negli Standard Interchain (ICS) ed è compatibile con una vasta gamma di blockchain e macchine a stati, poiché i suddetti standard non pongono alcuna restrizione alla topologia della rete o al processo di consenso.

A differenza della maggior parte delle tecnologie di bridging affidabili, il protocollo IBC offre un metodo permissionless per la trasmissione di pacchetti di dati da una blockchain all’altra. La sicurezza di IBC si riduce alla sicurezza delle blockchain partecipanti.

Cos’è l’Inter-Blockchain Communication Protocol (IBC) e a cosa serve

IBC offre una soluzione a un problema molto diffuso, ovvero la comunicazione tra blockchain. Quando le blockchain pubbliche sono utilizzate per gli scambi, questa difficoltà sorge perché non è possibile effettuare scambi.

Quando una blockchain è progettata per un’applicazione specifica, c’è una maggiore probabilità che ogni asset emerga da una propria blockchain costruita ad hoc. Questo crea un primo caso di dilemma. La comunicazione tra blockchain è un problema anche nel dominio delle blockchain private, in circostanze in cui è auspicabile la comunicazione con una blockchain pubblica o con altre blockchain private. Esistono già implementazioni IBC per blockchain private, come Hyperledger Fabric e Corda (si apre in una nuova finestra).

La possibilità di un’elevata scalabilità orizzontale e della finalizzazione delle transazioni si crea quando le blockchain specifiche dell’applicazione nell’Interchain comunicano tra loro attraverso la comunicazione cross-chain. Questi elementi progettuali forniscono soluzioni plausibili a difficoltà ben note che affliggono altre piattaforme, come i costi associati alle transazioni, la capacità della rete e la definitività della conferma delle transazioni.

L’IBC è necessaria per le blockchain che sono adattate ad applicazioni specifiche, come quelle presenti nella rete Interchain. Fornisce un percorso di comunicazione standardizzato per le applicazioni in esecuzione su due blockchain separate che hanno l’esigenza di comunicare tra loro.

La grande innovazione portata da IBC

Almeno prima del lancio di Interchain Security, la maggior parte delle applicazioni Interchain era progettata per funzionare su una blockchain costruita specificamente per quell’applicazione e che utilizzava il proprio set di validatori. Le applicazioni su una blockchain possono avere bisogno di comunicare con applicazioni su un’altra blockchain, ad esempio, un’applicazione potrebbe prendere token da un’altra blockchain come forma di pagamento. Queste sono le blockchain specifiche per le applicazioni che sono state costruite con il Cosmos SDK. Per raggiungere questo livello di interoperabilità, è necessario trovare un modo per trasferire i dati sullo stato delle transazioni in corso su un’altra blockchain.

Questi tipi di bridge tra blockchain non solo sono possibili da costruire, ma esistono anche; tuttavia, la loro costruzione è tipicamente ad hoc. L’IBC fornisce alle blockchain una struttura e un protocollo di comunicazione standard che possono essere utilizzati per costruire forme di comunicazione standardizzate tra le blockchain. Si tratta di una caratteristica immediata per le blockchain costruite con il kit di sviluppo software (SDK) Cosmos, ma il protocollo IBC non è esclusivo delle blockchain costruite con Interchain Stack.

La sezione seguente fornirà ulteriori informazioni sulle specifiche, ma prima di andare avanti è importante notare che l’IBC non è esclusivo delle blockchain Cosmos. Anche nelle situazioni in cui alcuni requisiti non sono inizialmente soddisfatti, è possibile trovare una soluzione al problema. Ad esempio, IBC forniva già la connettività tra Interchain e la blockchain Ethereum prima del Merge, che ha visto Ethereum passare da un’architettura Proof-of-Work (PoW) a Proof-of-Stake (PoS).

Poiché un algoritmo di consenso PoW non assicura la finalità, uno dei prerequisiti principali per l’adozione dell’IBC non è soddisfatto. Pertanto, l’interoperabilità con Ethereum è stata facilitata definendo una peg-zone in cui la finalità probabilistica è considerata deterministica (irreversibile) dopo una determinata soglia di conferme dei blocchi. Questa soluzione può servire a qualsiasi connessione IBC a una blockchain PoW.

Sebbene le blockchain specifiche per le applicazioni offrano una maggiore scalabilità (orizzontale) rispetto alle piattaforme blockchain generiche, la creazione di smart contract per le blockchain generiche e le macchine virtuali generiche (VM), come quelle presenti in Ethereum, offrono una serie di vantaggi unici. L’IBC offre un mezzo per integrare i vantaggi che si possono ottenere da blockchain sia generiche che specifiche per le applicazioni in progetti complessivi unificati. Ad esempio, consente a una blockchain Cosmos progettata per le prestazioni e la scalabilità di utilizzare fondi che iniziano su Ethereum e magari registrano eventi in un libro mastro distribuito Corda. Oppure, al contrario, un libro mastro Corda che avvia il trasferimento di attività sottostanti definite nella Interchain o in Ethereum.

Con la comunicazione tra blockchain tramite IBC, è possibile creare una rete decentralizzata di blockchain indipendenti e compatibili che scambiano informazioni e beni. Questa “internet delle blockchain” promette una scalabilità migliorata e senza soluzione di continuità. L’obiettivo che si sta perseguendo nell’Interchain è quello di avere un universo di blockchain indipendenti, tutte collegate tra loro tramite hub e peg-zone che fungono da ponte tra la rete Interchain e le blockchain che esistono al di fuori di essa. Tutti questi elementi si uniscono per formare la blockchain internet.

Una panoramica dell’IBC

Il livello di trasporto (TAO) è responsabile della fornitura dell’infrastruttura necessaria per verificare i pacchetti di dati tra le blockchain e per stabilire connessioni sicure tra le blockchain. Al di sopra del livello di trasporto si trova il livello applicativo, che è responsabile di definire esattamente come i pacchetti di dati devono essere raggruppati e come le blockchain di invio e ricezione devono interpretarli.

L’IBC ha un grande potenziale perché è in grado di fornire un livello di base affidabile, permissionless e generico (che consentirà il trasferimento sicuro dei pacchetti di dati), nonché di consentire la componibilità e la modularità con la separazione delle operazioni, spostando i progetti delle applicazioni (che interpreteranno e agiranno sui dati dei pacchetti) a un livello superiore. Questo sarà il più grande risultato dell’IBC.

Questa divisione è rappresentata nelle categorie dell’ICS, che possono essere viste nella definizione generale dell’ICS:

• IBC e TAO sono le abbreviazioni rispettivamente del protocollo Internet Broadcasting and Control e dello standard Internet Behavioural Control and Authentication Ordering. Core, Client e Relayer sono le tre categorie distinte che compongono questo aspetto dell’ICS.
• IBC/APP sono lo standard che descrivono i gestori delle applicazioni per i pacchetti di dati trasmessi attraverso il livello di trasporto. Si trovano nella categoria App dell’ICS e comprendono, ma non solo, i trasferimenti di token fungibili (ICS-20), i trasferimenti NFT (ICS-721) e i conti interchain (ICS-27).

L’importanza dei Relè nelle comunicazioni inter-blockchain

I relè sono necessari per la comunicazione tra le blockchain. Il livello di connessione “fisico” di IBC è costituito dagli algoritmi dei relatori, noti anche come ICS-18 (che si apre in una nuova finestra). Si tratta di processi esterni alla blockchain, responsabili della trasmissione dei dati tra due blockchain che eseguono entrambe il protocollo IBC. Ciò avviene scansionando lo stato di ciascuna blockchain, costruendo i datagrammi appropriati ed eseguendoli sulla blockchain opposta, come consentito dal protocollo.

• Un gran numero di relè può servire uno o più canali, consentendo la trasmissione di messaggi tra blockchain.
• Ciascuna tratta del relè si avvale del client luminoso della blockchain avversaria per effettuare una rapida verifica dei messaggi in arrivo.

In poche parole, il livello di trasporto comprende:

• Client leggeri
  I client IBC sono client leggeri identificabili da un ID cliente univoco. I client IBC tengono traccia dello stato di consenso delle altre blockchain e degli standard di prova delle altre blockchain necessari per verificare correttamente le prove rispetto allo stato di consenso del client. Non c’è limite al numero di collegamenti che possono essere stabiliti tra un client e la blockchain della controparte.
• Connessioni
  Una volta stabilite, le connessioni sono responsabili della facilitazione di tutte le verifiche interchain di uno stato IBC. Non c’è limite al numero di canali che possono essere collegati a una connessione. Su due blockchain distinte, ogni connessione contiene due oggetti ConnectionEnd incapsulati al suo interno. Ogni ConnectionEnd è collegato a un light client dell’altra blockchain, che nel nostro scenario può essere la blockchain della controparte. L’handshake della connessione ha il compito di garantire che i light client di ciascuna blockchain siano quelli appropriati per le rispettive controparti. Questa verifica avviene prima dell’inizio dell’handshake.
  Un modulo su una blockchain può connettersi con altri moduli su altre blockchain inviando, ricevendo e riconoscendo pacchetti attraverso canali identificati in modo univoco dalla tupla (channelID, portID).
• Canali – ICS-4
  I canali incapsulano due ChannelEnd associati a una connessione. I canali consentono di trasmettere diversi tipi di informazioni tra le blockchain, ma non aumentano la capacità totale del sistema. Come le connessioni, i canali vengono stabiliti tramite un handshake.
  Un canale può essere ORDINATO, in cui i pacchetti di un modulo mittente devono essere gestiti dal modulo ricevente nell’ordine in cui sono stati inviati, o NON ORDINATO, in cui i pacchetti di un modulo mittente vengono elaborati nell’ordine in cui arrivano (che potrebbe essere diverso dall’ordine in cui sono stati inviati).
• Porte – ICS-5
  Un modulo IBC può legarsi a un numero qualsiasi di porte. Ogni porta deve essere identificabile con un portID univoco. Il portID identifica il tipo di applicazione, ad esempio nei trasferimenti di token fungibili il portID è transfer.
  Sebbene queste informazioni di base siano utili, IBC è stato strutturato in modo tale che l’esposizione al livello di trasporto sia ridotta al minimo per gli sviluppatori di applicazioni IBC.
• Trasferimento di token fungibili – ICS-20
  La prima e più evidente applicazione dell’IBC è il trasferimento di token fungibili tra le blockchain. Con le specifiche fornite da ICS-20, un utente può inviare token tra blockchain abilitate all’IBC. Ciò avviene depositando i token sulla blockchain di origine: la prova, insieme ai metadati del token, viene trasmessa alla blockchain di destinazione, dopo di che la prova viene convalidata dal client leggero della blockchain di origine, memorizzato sulla blockchain di destinazione. Se la verifica ha esito positivo, vengono generati nuovi voucher per i token della blockchain di destinazione e la blockchain di origine riceve una conferma della transazione.
  È possibile dare un’occhiata ai passaggi osservando l’avanzamento del trasferimento di token IBC su Mintscan (che si apre in una nuova finestra), ma la discussione più approfondita del flusso di pacchetti è riservata a una parte successiva. 
• Conti interchain – ICS-27
  Conti interchain specifica un protocollo di gestione dei conti interchain basato su IBC. Le blockchain che hanno abilitato ICS-27 possono creare programmaticamente conti su altre blockchain dotate di ICS-27 e controllare questi conti utilizzando transazioni IBC, senza dover firmare con una chiave privata. I conti interchain possiedono tutte le funzioni di un normale conto (ad es. staking, inviare, votare), ma sono amministrati da una seconda blockchain tramite IBC, in modo tale che il conto proprietario della blockchain controllante abbia piena autorità su tutti i conti interchain che registra sulle blockchain ospitanti.

Questo elenco può essere e sarà ampliato nel tempo. Nuovi concetti come i conti interchain continueranno ad aumentare la popolarità e a fornire una diversità di applicazioni nell’ecosistema Interchain.

Un elenco degli sforzi dell’ecosistema sulle applicazioni IBC e sui client leggeri si trova nel readme della repo ibc-go o nella repo ibc-apps.

Come viene gestita la sicurezza nel protocollo IBC

Oltre all’estensione del protocollo, all’affidabilità e alla sicurezza senza la necessità di terze parti fidate, la natura permissionless di IBC come standard di interoperabilità è una delle qualità più preziose di IBC rispetto ai tipici protocolli bridge. La creazione di client, connessioni e canali IBC, così come la trasmissione di pacchetti tra blockchain, non richiede alcuna autorizzazione. Alla luce di ciò, sorg euna domanda: Quali sono le implicazioni per la sicurezza dei dati?

• La costruzione del sistema di sicurezza IBC si basa su due principi fondamentali:
• La fiducia nelle (opinioni delle) blockchain con cui ci si connette è una buona idea.
• La creazione di metodi di isolamento dei guasti, al fine di limitare i danni nel caso in cui queste blockchain siano vulnerabili a comportamenti malevoli.

IBC, a differenza della maggior parte delle altre soluzioni trusted bridge, non si affida a una terza parte per convalidare la legalità delle transazioni cross-chain. Come appena discusso, la verifica delle prove di impegno dei pacchetti è un compito che spetta al cliente light. 

Per esaminare le prove per l’invio e la ricezione dei pacchetti sulla blockchain di origine e sulla blockchain di destinazione, il client lite è in grado di tracciare e verificare efficacemente lo stato appropriato della blockchain della controparte.

Nella IBC, le blockchain non comunicano direttamente tra loro inviando messaggi attraverso la rete. Ai fini della comunicazione, le blockchain impegnano lo stato corrente su un percorso accuratamente definito, riservato a un certo tipo di messaggio e a una particolare controparte. I relayer verificano la presenza di aggiornamenti su questi percorsi e trasmettono i messaggi inviando i dati memorizzati nel percorso insieme alle prove di tali dati alla blockchain della controparte.

I percorsi che tutte le implementazioni IBC devono abilitare per il commit dei messaggi IBC sono delineati nei requisiti della macchina di stato dell’host ICS-24.

Questo è fondamentale perché garantisce che il protocollo IBC rimanga sicuro anche in situazioni bizantine in cui i relayers potrebbero operare in modo ostile o imperfetto. Non è necessario fidarsi dei relayers, ma della verifica della prova fornita dal client leggero. Nel peggiore dei casi, se tutti i relayers funzionano in modo bizantino, i pacchetti inviati verrebbero rifiutati perché non includono la prova richiesta. Questo comprometterebbe solo la vivacità, non la sicurezza, del particolare segmento della rete Interchain in cui i relayers sono malintenzionati.

Si noti che questo effetto danneggerebbe la rete solo se tutti i relayers fossero bizantini. Poiché il relaying non richiede un’autorizzazione, una soluzione semplice sarebbe quella di creare un relayer non malintenzionato che trasmetta i pacchetti che includono la prova appropriata. Ciò si adatta al paradigma della sicurezza sulla vivacità adottato da IBC e dal più ampio ecosistema Interchain.

Rippore più fiducia nelle blockchain che nei bridge.

I client e le transazioni IBC presuppongono il modello di fiducia delle blockchain a cui sono collegati. Per esprimere con precisione questo concetto negli asset che sono stati spostati attraverso l’Interchain, l’informazione sul percorso che un asset ha fatto (la garanzia di sicurezza dell’asset) è registrata nella denominazione dell’asset stesso.

Nel caso in cui l’utente finale o un’applicazione non si fidino di una specifica blockchain di origine, saranno in grado di verificare che il loro asset non provenga da una blockchain non affidabile semplicemente guardando la denominazione dell’asset, piuttosto che fare riferimento al set di validatori di un bridge o di un altro verificatore di terze parti fidato.

A tutti i token trasferiti su un determinato canale verrà assegnata la stessa denominazione degli altri token che transitano sul canale, ma una diversa da quella che gli stessi asset tra le stesse blockchain avrebbero se fossero trasmessi attraverso un canale diverso. I denomi IBC sono rappresentati dal formato ibc/[hash del channel-id e del port-id].

L’impatto del BTF

Una forma di comportamento bizantino che può verificarsi in una blockchain abilitata all’IBC è quando i validatori firmano due volte un blocco, ovvero firmano due blocchi separati alla stessa altezza. Questo scenario è definito fork. A differenza delle blockchain Proof-of-Work (come Bitcoin o Ethereum), in cui le forchette sono periodicamente previste, in CometBFT è prevista la rapida finalizzazione delle blockchain (ed è un prerequisito per IBC), pertanto i fork non dovrebbero verificarsi.

Attraverso l’idea della fork accountability, i processi che hanno causato il fallimento del consenso possono essere identificati e penalizzati secondo le regole del protocollo. Se, invece, questo dovesse accadere su una blockchain straniera, si metterebbe in moto una corsa per il cliente leggero della blockchain compromessa per venire a conoscenza del fork sulla rete della controparte.

Il protocollo IBC include la funzionalità di invio di una prova di comportamento scorretto, che può essere fornita dai relayers. Una volta inviata questa prova, il client leggero viene congelato per prevenire eventuali effetti causati dalla biforcazione. Dopo che l’attacco è stato fermato, i fondi possono essere recuperati scongelando il client lite tramite una proposta di governance.

Questo potrebbe essere possibile in un secondo momento. La funzionalità di submit misbehavior consente quindi ai relayers di aumentare la sicurezza di IBC, anche quando i relayers stessi non sono intrinsecamente affidabili.

Le capacità di adattamento del protocollo IBC

IBC è destinato a funzionare in ambienti di esecuzione in cui i moduli non si fidano necessariamente l’uno dell’altro. Pertanto, IBC deve autenticare le operazioni dei moduli su porte e canali, in modo che solo i moduli con i relativi permessi possano utilizzarli. Per eseguire l’autenticazione di questo modulo viene utilizzata un’implementazione di un archivio di capacità dinamiche. IBC restituisce una capacità dinamica a un modulo dopo che questo si è legato a una porta o ha creato un canale per quel modulo. 

Per poter utilizzare la porta o il canale, il modulo deve rivendicare tale capacità. Altri moduli non possono utilizzare quella porta o quel canale perché non possiedono la capacità necessaria. Questo perché il modulo di capacità dinamica impedisce loro di farlo.

Vale la pena sottolineare che, oltre alle particolari preoccupazioni di sicurezza di IBC, restano valide le considerazioni sulla sicurezza dell’SDK Cosmos e dell’architettura a blockchain specifica dell’applicazione del whitepaper Cosmos. Con riferimento alle sezioni precedenti, ricordiamo che mentre l’iterazione sui moduli può essere più lenta rispetto all’iterazione sui contratti, le blockchain specifiche per le applicazioni sono vulnerabili a un numero molto inferiore di vettori di attacco rispetto alle configurazioni di smart contract distribuite sulla blockchain. Le blockchain dovrebbero adottare di proposito un modulo dannoso da parte della governance.

La Roadmap

Come indicato in precedenza, anche se IBC proviene dall’Interchain Stack, consente alle blockchain non progettate con l’SDK Cosmos di adottare IBC, o anche quelle con un consenso completamente diverso da CometBFT. Tuttavia, a seconda della blockchain per la quale si desidera implementare IBC o costruire applicazioni IBC, potrebbe essere necessario uno sviluppo preliminare per garantire che tutti i vari componenti necessari al funzionamento di IBC siano accessibili per il tipo di consenso e l’architettura blockchain scelti.

Questo aspetto varia a seconda della blockchain per la quale si sceglie di implementare l’IBC o di costruire applicazioni IBC su di essa.

In generale, sono necessari i seguenti elementi:

• Un’istanza dell’implementazione del livello di trasporto IBC.
• Un’implementazione leggera del client sulla propria blockchain, con lo scopo di tracciare la blockchain della controparte a cui ci si vuole connettere.
• Un’implementazione client leggera per il tipo di consenso che si desidera utilizzare, che può essere incorporata nella blockchain della controparte con cui si desidera interagire.

Il metodo più semplice per utilizzare l’IBC è costruire una blockchain con l’SDK di Cosmos, che include già il modulo IBC, come si può vedere esaminando il repository ibc-go.