Cos’è il Cosmos SDK e come funziona per costruire blockchain?

Cos’è il Cosmos SDK?

Il Cosmos SDK è un software di sviluppo open-source che permette agli sviluppatori di costruire una propria blockchain o un registro digitale specifico per un’applicazione. Quindi non è una blockchain, non è una rete e non è nemmeno un token in sé.

Una blockchain costruita con il Cosmos SDK può funzionare come una blockchain Layer 1 autonoma. Questo significa che la chain non gira come applicazione sopra un’altra blockchain, ma definisce da sola le regole per transazioni, state e altre parti del protocollo. In combinazione con software come CometBFT, una blockchain così può avere anche una propria rete di validator e un proprio processo di consenso.

Con il Cosmos SDK, un progetto decide da solo le regole della propria chain. Pensa a chi può fare certe azioni, a come funzionano le transazioni, quali dati vengono salvati, come è impostata la governance e quale logica applicativa vale.

Puoi vederlo come un kit di costruzione per una blockchain. Invece di programmare tutto da zero, uno sviluppatore sceglie componenti già esistenti e li unisce con codice proprio. Così una chain può, per esempio, avere regole per i token, la gestione dei validator, la governance on-chain o permessi specifici.

Un’applicazione Cosmos SDK, dal punto di vista tecnico, è una deterministic state machine. Sembra complicato, ma l’idea è semplice: lo stesso input valido deve portare sempre esattamente al nuovo stato su ogni nodo. Se per esempio un utente invia token, tutti i nodi devono alla fine vedere lo stesso saldo.

Nell’impostazione più comune, questa applicazione gira come un Go binary. Go è il linguaggio di programmazione con cui viene costruita la logica della chain. L’applicazione gira insieme al software che fa comunicare i nodi tra loro e crea i blocchi.

Il Cosmos SDK gestisce soprattutto il livello applicativo: quali transazioni sono valide e cosa modificano. CometBFT di solito gestisce il consenso, il networking peer-to-peer e la produzione dei blocchi. ABCI fa da collegamento tra questi due livelli. Tramite questa interfaccia, il software di consenso può chiedere all’applicazione di controllare ed eseguire transazioni e blocchi.

In breve

• Il Cosmos SDK è un software di sviluppo con cui si possono costruire, tra le altre cose, blockchain Layer 1 autonome e specifiche per un’applicazione.
• Una chain può impostare da sola le regole per transazioni, governance, permessi e dati salvati.
• L’SDK è modulare: gli sviluppatori combinano moduli esistenti con logica propria.
• CometBFT di solito si occupa di consenso, comunicazione di rete e produzione dei blocchi.
• Il Cosmos SDK non è una blockchain separata e non ha un token proprio.

Come funziona il Cosmos SDK?

Il Cosmos SDK funziona perché CometBFT fa elaborare i blocchi e, tramite ABCI, richiama l’applicazione della chain. L’SDK decide cosa può fare una transazione, mentre CometBFT fa in modo che i nodi siano d’accordo sui blocchi.

Il livello centrale dentro un’applicazione SDK si chiama BaseApp. BaseApp traduce le chiamate di ABCI in compiti pratici: eseguire transazioni, inviare i message al modulo giusto e aggiornare lo state.

Un utente invia prima una transazione firmata. In una transazione del genere ci sono uno o più message. Un message è l’istruzione concreta, come inviare token o delegare token a un validator.

La transazione contiene inoltre, tra le altre cose, una firma digitale, le fee e un gas limit. La firma mostra quale account ha approvato l’operazione. Le fee sono i costi di elaborazione. Il gas limit indica quanta potenza di calcolo l’utente è disposto a pagare al massimo.

Prima che la transazione venga eseguita, l’AnteHandler controlla alcune regole di base. Per esempio verifica se la firma è corretta, se la sequence dell’account è giusta, se ci sono fee sufficienti e se il gas limit non viene superato. La sequence dell’account è un numero progressivo che aiuta a evitare che la stessa transazione venga riutilizzata.

Poi BaseApp invia ogni message al modulo corretto. Un trasferimento di token, per esempio, va al modulo che gestisce i saldi. Quel modulo controlla le proprie regole e, se tutto è corretto, aggiorna lo state.

Lo state è tutti i dati attuali della chain, come account, saldi e impostazioni. Questi dati sono salvati come dati key-value in un multistore. Si tratta di una raccolta di archivi separati, di solito uno per modulo.

Una transazione viene eseguita con uno storage temporaneo dello state. Le modifiche fatte durante l’esecuzione di un message vengono mantenute solo se quell’esecuzione riesce. Se un message fallisce, quelle modifiche vengono annullate. Alcune modifiche della fase precedente dell’AnteHandler, come l’incasso delle fee di transazione e l’aumento della sequence dell’account, possono però restare.

Nel normale flusso CometBFT, BaseApp elabora un blocco stabilito tramite FinalizeBlock. Prima viene eseguita l’eventuale logica prima del blocco, poi vengono elaborate le transazioni e infine la logica alla fine del blocco. Dopo di questo, il nuovo state viene salvato con Commit e nasce un nuovo AppHash: un’impronta crittografica dello state dell’applicazione.

Esempio: Immagina di inviare 10 token a qualcuno. Prima la chain controlla la tua firma, la sequence, la fee e il gas limit. Poi il modulo dei token verifica se hai almeno 10 token. Solo se tutti i controlli vanno a buon fine, 10 vengono tolti dal tuo saldo e 10 vengono aggiunti al saldo del destinatario.

Da quali componenti è composto il Cosmos SDK?

Una tipica applicazione Cosmos SDK è composta da BaseApp, moduli e un livello in cui tutto viene assemblato e configurato. Insieme, questi componenti formano una sola state machine che gli operatori dei nodi eseguono.

BaseApp è il collegamento tra CometBFT e l’applicazione. Gestisce il collegamento ABCI, instrada message e query, esegue le transazioni e gestisce il multistore.

I moduli contengono la vera business logic. Ogni modulo può avere state, message, funzioni di query e regole proprie. Una chain sceglie da sola quali moduli includere. Poi li combina con eventuali moduli personalizzati.

Questo assemblaggio avviene di solito in app.go. Lì lo sviluppatore crea BaseApp, imposta gli archivi, inizializza i componenti e decide come i moduli collaborano tra loro. Il node binary avvia poi sia il nodo di consenso sia l’applicazione SDK.

Di solito i moduli usano un keeper per accedere al proprio state. Un keeper si può vedere come un punto di accesso controllato ai dati salvati. Non ogni modulo può modificare tutto liberamente. Un modulo riceve solo i diritti e le interfacce che l’applicazione gli passa in modo intenzionale.

Il ModuleManager tiene traccia di quali moduli sono attivi e gestisce, tra le altre cose, l’avvio al genesis, gli upgrade e l’ordine degli hook ai confini dei blocchi. Genesis è il punto di partenza di una blockchain: il primo state con cui la rete inizia.

Anche i Protocol Buffers hanno un ruolo importante. È un modo per descrivere in modo chiaro dati e servizi. Message, servizi di query, tipi di state e tipi di genesis vengono definiti così, dopo di che per l’applicazione vengono generati codice Go e stub gRPC.

Quali moduli offre il Cosmos SDK?

Il Cosmos SDK offre molti moduli che una chain può scegliere e combinare. Nessuna chain deve per forza usare tutti i moduli. Proprio questa scelta determina cosa la blockchain specifica può fare e cosa no.

Alcuni moduli usati spesso sono:

• x/auth: gestisce i tipi base di account e transazione. Questo modulo aiuta, tra le altre cose, nei controlli su firme e nonce dell’account.
• x/bank: gestisce i saldi di più token, i trasferimenti di token e la fornitura totale di token.
• x/staking: gestisce validator e deleghe in un sistema proof-of-stake.
• x/gov: permette proposte e votazioni on-chain.
• x/distribution: distribuisce le ricompense dello staking.
• x/slashing: può applicare sanzioni quando i validator non rispettano le regole.
• x/mint: supporta l’emissione di token secondo le regole della chain.
• x/evidence: gestisce le prove di comportamento scorretto dei validator.
• x/upgrade: aiuta una chain a eseguire gli upgrade software in modo coordinato.

Ci sono anche moduli per compiti specifici. Per esempio x/authz può gestire autorizzazioni delegate per i message e x/feegrant può permettere che un altro account paghi le fee di un utente. x/consensus rende possibile gestire on-chain alcuni parametri di consenso di CometBFT. x/circuit può funzionare come circuit breaker per mettere temporaneamente in pausa certi message.

La funzionalità IBC viene di solito aggiunta tramite ibc-go. Questa è l’implementazione IBC usata normalmente per le chain Cosmos SDK, ma viene mantenuta come progetto separato.

Uno sviluppatore può adattare i moduli standard, sostituire componenti o costruire moduli propri. Una chain con sole funzioni base appare quindi molto diversa da una chain con gestione dei validator, governance e regole di permesso estese.

Come funzionano le applicazioni Cosmos SDK?

Un’applicazione Cosmos SDK funziona perché uno sviluppatore assembla, registra e dota di diritti adeguati i moduli in modo intenzionale. Quindi non basta importare un Go package per far girare un modulo su una chain.

In app.go viene costruita l’applicazione. Lì vengono registrate le store key, creati i keeper, aggiunti i moduli al ModuleManager e collegate le service. Inoltre lo sviluppatore decide in quale ordine gli hook vengono eseguiti ai confini dei blocchi. Questo ordine può essere importante, perché un modulo può dipendere dalle azioni di un altro modulo.

Di solito un modulo contiene quattro componenti pratiche:

• Un keeper: per l’accesso controllato al proprio state.
• Una Msg-service: per azioni che modificano lo state, come un trasferimento o una delega.
• Una queryservice: per richieste in sola lettura, come controllare un saldo.
• Un’implementazione AppModule: così il modulo collabora bene con il ModuleManager.

Quando arriva una transazione, BaseApp instrada ogni message in base al tipo verso il MsgServer del modulo corretto. Il modulo controlla poi se il mittente è autorizzato e se l’azione rispetta le regole di business. Dopo di che il modulo usa il keeper per modificare lo state.

Le query seguono un altro percorso. Tramite il gRPCQueryRouter arrivano alla queryservice del modulo giusto. Una query legge lo state salvato e confermato e non modifica nulla. Pensa alla differenza tra guardare il saldo del conto e fare un pagamento.

I moduli possono avere anche logica per genesis, upgrade e confini dei blocchi. Durante un upgrade possono servire migrazioni dello state, così i dati vecchi si allineano bene al nuovo codice. Questo richiede una pianificazione attenta e test da parte dello sviluppatore della chain.

Cos’è Cosmos EVM?

Una blockchain Cosmos SDK può anche essere resa compatibile con la Ethereum Virtual Machine (EVM). Per questo esiste Cosmos EVM, che permette di integrare la funzionalità EVM come parte di un’applicazione Cosmos SDK. Così un progetto può costruire una propria blockchain Layer 1 che allo stesso tempo può eseguire smart contract Ethereum.

Il cuore di tutto questo è il modulo x/vm. Questo aggiunge un ambiente di esecuzione EVM alla blockchain, così gli sviluppatori possono usare smart contract Solidity e lavorare con strumenti Ethereum noti come MetaMask, Hardhat e Foundry. Nel frattempo la blockchain resta una chain Cosmos SDK autonoma, con regole e configurazione proprie.

Cosmos EVM può inoltre dare accesso ad altre parti del Cosmos SDK tramite precompile. Uno smart contract può quindi, per esempio, comunicare con funzionalità di staking, governance o IBC. Quali precompile siano disponibili viene configurato dagli sviluppatori della blockchain.

Cosmos EVM non è una parte obbligatoria del Cosmos SDK. Uno sviluppatore può costruire una chain Cosmos SDK senza EVM oppure aggiungere volutamente la funzionalità EVM quando vuole compatibilità con applicazioni e strumenti Ethereum.

Per cosa viene usato il Cosmos SDK?

Il Cosmos SDK viene usato per costruire blockchain e registri digitali specifici per un’applicazione, quando un progetto vuole decidere da solo le regole della chain. Così un progetto può progettare una blockchain Layer 1 autonoma invece di costruire solo un’applicazione o uno smart contract su una blockchain esistente. Questo è particolarmente utile quando le regole standard di una blockchain generale già esistente non lasciano abbastanza spazio.

Per esempio, un progetto può definire a livello di protocollo regole per la tokenizzazione, i trasferimenti di token, la gestione dei validator in proof-of-stake, la governance, le autorizzazioni e le fee allowance. Anche logiche di compliance o permissioning possono far parte delle regole della chain.

L’SDK può essere usato per reti pubbliche, reti private permissioned e reti consortili. In una rete pubblica, in linea di principio, chiunque può partecipare secondo le regole aperte. In una rete permissioned, invece, possono avere diritti solo partecipanti o validator stabiliti in anticipo.

Questo rende l’SDK utile in situazioni in cui un’organizzazione o un gruppo non vuole solo costruire una dApp o smart contract su una blockchain esistente, ma ha bisogno di un proprio ambiente Layer 1 con proprie transizioni di state e proprie regole di chain.

Esempi di possibili applicazioni sono reti interbancarie, tokenizzazione di asset e automazione aziendale. Se una chain propria sia adatta dipende però dai requisiti concreti. Una chain propria richiede, oltre al codice, anche gestione, monitoraggio, upgrade, governance e un modello di sicurezza adeguato.

Qual è il rapporto tra Cosmos SDK, Cosmos Hub e IBC?

Il Cosmos SDK è il framework di costruzione, IBC è il protocollo di comunicazione tra blockchain e Cosmos Hub è una specifica blockchain pubblica proof-of-stake. Questi tre elementi quindi sono collegati, ma non sono la stessa cosa.

Cosmos Hub esegue l’applicazione Gaia. Gaia è costruita come applicazione Cosmos SDK e usa ibc-go per IBC. ATOM è il token nativo di staking di Cosmos Hub.

IBC sta per Inter-Blockchain Communication. È un protocollo aperto che permette alle blockchain di inviarsi dati verificati a vicenda. Questi dati possono essere token, message o logica applicativa.

Come fa allora una chain a sapere che le informazioni di un’altra chain sono corrette? IBC usa tra le altre cose dei client, spesso chiamati light client, per verificare lo state della controparte. Dopo di questo, IBC può inviare, confermare o far scadere i packet in modo dimostrabile. Un packet, in questo caso, è un pacchetto di dati che passa da una chain all’altra.

Il Cosmos SDK ha un forte collegamento con IBC tramite ibc-go, ma IBC deve comunque essere integrato davvero nella chain. Uno sviluppatore deve, tra le altre cose, aggiungere IBC keeper e storage, impostare un IBC router con le route e registrare i moduli rilevanti.

Dopo di questo, per una comunicazione reale serve anche una controparte adatta, oltre a un canale IBC e al relaying. I relayer sono processi che inoltrano i messaggi IBC tra le chain. Non decidono da soli quali dati siano validi, perché le chain verificano quei dati secondo le regole IBC.

Cosmos Hub può comunicare via IBC con altre chain compatibili, ma non è un livello centrale obbligatorio di passaggio. Due chain IBC ben configurate possono comunicare direttamente tra loro tramite i propri client, connection e channel.

Anche IBC non è esclusivo delle chain Cosmos SDK. L’SDK rende soprattutto più pratica l’integrazione per le chain costruite con esso.

Quali sono i vantaggi e i limiti del Cosmos SDK?

Il punto di forza principale del Cosmos SDK è la personalizzazione. Gli sviluppatori possono usare solo i moduli necessari, adattare il comportamento standard e aggiungere logica propria. Così le regole di una chain possono essere progettate direttamente a livello di protocollo.

Anche la separazione tra logica applicativa, ABCI e consenso è utile. Chi usa CometBFT non deve costruire da zero l’usuale livello di consenso e peer-to-peer. Lo sviluppatore può quindi concentrarsi di più su ciò che la chain deve fare.

Altri vantaggi sono:

• Blocchi di costruzione riutilizzabili: i moduli offrono funzioni per account, token, staking, governance, upgrade e autorizzazione.
• Accesso controllato: i keeper limitano quale state un modulo può leggere o modificare dagli altri moduli.
• Interoperabilità tramite IBC: le chain IBC integrate correttamente possono scambiarsi dati verificati senza una parte centrale di bridge.
• Modelli di rete flessibili: l’SDK può essere usato per reti pubbliche, private e consortili.

Questa libertà porta però anche responsabilità. Uno sviluppatore deve progettare correttamente moduli, keeper, permessi, parametri e ordine degli hook. Anche le migrazioni dello state durante gli upgrade e la gestione delle dipendenze richiedono attenzione. L’SDK è in gran parte stabilizzato, ma può ancora contenere breaking changes. Un upgrade va quindi pianificato e testato bene.

Conoscere Go è importante nella pratica, perché le applicazioni SDK sono Go binary e Go serve per costruire ed eseguire un nodo. Questo può essere un ostacolo per team che lavorano soprattutto con altri linguaggi di programmazione.

IBC rende possibile l’interoperabilità, ma non in automatico. Una chain deve integrare e configurare bene IBC. Inoltre servono una controparte compatibile, un canale funzionante e relayer operativi.

Infine, l’SDK non elimina tutta la responsabilità operativa e di sicurezza. Una chain autonoma deve gestire da sola un modello adeguato per validator e stake, oppure per regole di validator permissioned. La sicurezza dipende inoltre dal codice dei moduli propri, dalla configurazione, dalla gestione delle chiavi, dagli upgrade, dall’infrastruttura e dal modo in cui la rete viene gestita.

Conclusione

Il Cosmos SDK è un framework flessibile per team che vogliono costruire una propria blockchain con regole proprie. Invece di inserire solo logica dentro una chain esistente, un progetto può decidere da solo come funzionano transazioni, state, governance, permessi e altri processi.

L’impostazione modulare rende possibile combinare componenti esistenti per esempio per token, staking e governance con codice proprio. Un progetto può inoltre integrare, per esempio, Cosmos EVM quando vuole combinare una propria blockchain con il supporto per smart contract e strumenti Ethereum. CometBFT di solito gestisce consenso e livello di rete, mentre BaseApp e i moduli eseguono la logica applicativa.

IBC può collegare una chain Cosmos SDK ad altre chain integrate correttamente, ma questo collegamento richiede comunque una configurazione tecnica consapevole. Lo stesso vale per la chain stessa: la flessibilità significa anche che gli sviluppatori restano responsabili di progettazione, upgrade, operatività e sicurezza.

In breve, il Cosmos SDK è soprattutto interessante quando un progetto non vuole solo costruire un’applicazione, ma vuole dare forma alle regole della blockchain sottostante stessa.