Cos'è CometBFT e come funziona?

Cos'è CometBFT?

CometBFT è un software open-source che fa sì che più computer possano mettersi d'accordo sugli stessi dati della blockchain. In parole semplici: aiuta i nodi a mettere le transazioni nello stesso ordine e a mantenere tutti lo stesso stato aggiornato di una blockchain.

Questo processo si chiama Byzantine Fault Tolerant, o BFT. In questo modello, il sistema parte dal presupposto che alcuni partecipanti possano sbagliare, andare offline o persino comportarsi in modo scorretto di proposito. Finché meno di un terzo del potere di voto totale si comporta così, CometBFT impedisce che due block diversi vengano finalizzati nello stesso punto della blockchain.

CometBFT è il successore di Tendermint Core e usa l'algoritmo di consenso Tendermint. Non è una blockchain pronta all'uso e nemmeno un progetto crypto completo con regole fisse proprie. Il software gestisce soprattutto il consenso, la comunicazione tra nodi e la produzione dei block. Le regole della blockchain stessa, come quali transazioni sono valide, stanno in un'applicazione separata.

Il collegamento tra CometBFT e quell'applicazione si chiama ABCI, abbreviazione di Application Blockchain Interface. Puoi vedere ABCI come uno strato di comunicazione fisso: CometBFT, per esempio, chiede se una transazione è valida e l'applicazione risponde. Così gli sviluppatori possono costruire la propria logica blockchain senza dover creare da zero anche un motore di consenso.

In breve

• CometBFT è un software open-source per il consenso e la sincronizzazione dei dati blockchain tra nodi.
• Usa il consenso BFT, che permette di gestire errori o comportamenti malevoli di una parte dei validator.
• CometBFT è un fork e successore di Tendermint Core.
• Il software non decide da solo quali transazioni siano valide nel merito; lo fa l'applicazione collegata.
• ABCI è il collegamento tra CometBFT e l'applicazione blockchain.

Come funziona il consenso di CometBFT?

CometBFT fa collaborare i validator per ogni block attraverso tre passaggi fissi: propose, prevote e precommit. Un validator, in questo caso, è un partecipante che può firmare block e voti. Quindi non ogni nodo è automaticamente un validator.

Ogni nuova posizione nella blockchain si chiama block height. A ogni height, la rete cerca di decidere un nuovo block. Prima il protocollo assegna un proposer. È il validator che, per quel round, può diffondere una proposta di nuovo block.

Poi gli altri validator esaminano la proposta. Il block è valido ed è arrivato in tempo? Allora esprimono un prevote: un primo voto per quel block. Se c'è abbastanza accordo, segue un precommit: il secondo voto, quello decisivo.

Un block viene committato quando più di due terzi di tutto il potere di voto hanno dato un precommit per esattamente lo stesso block. Il potere di voto non dipende per forza dal numero di validator. Un validator, per esempio, può avere più potere di voto di un altro, a seconda delle regole dell'applicazione blockchain.

Esempio: Immagina che il potere di voto totale sia 100. Allora servono più di 66 voti per committare un block. Non importa se quel potere di voto arriva da tanti validator piccoli o da un numero minore di validator più grandi.

Se non arriva una proposta valida, il proposer è offline o i voti arrivano troppo tardi, la stessa block height ricomincia in un round successivo. I tempi di attesa possono aumentare a ogni round, così i nodi lenti possono comunque recuperare. Questo non evita i ritardi, ma dà alla rete un modo per andare avanti quando un round fallisce.

Quale ruolo hanno i validator in CometBFT?

I validator prendono le decisioni in CometBFT. Firmano le proposte di block e i voti, controllano le proposte e aiutano a stabilire quale block viene aggiunto. Un nodo normale può inoltrare informazioni ad altri nodi, ma senza una private validator key non può votare direttamente nel consenso.

Il proposer viene scelto in modo automatico e prevedibile tramite uno schema round-robin. I validator con più potere di voto hanno quindi, in proporzione, più occasioni di fare una proposta.

In pratica, un validator fa questo:

• il validator riceve una proposta di block;
• il validator controlla se la proposta è valida secondo le regole dell'applicazione;
• se la proposta è valida e arriva in tempo, segue un prevote;
• con abbastanza prevote può seguire un precommit;
• dopo abbastanza precommit, il block viene committato.

Se non viene ricevuta una proposta valida, un validator può votare nil. Vuol dire semplicemente: nessun voto per un block specifico in questo round. Così la rete può passare a un round successivo senza accettare a caso una proposta sbagliata.

Il validator set e la distribuzione del potere di voto arrivano come input dall'applicazione blockchain. Quell'applicazione può quindi avere anche regole per modificare il validator set. Staking, delega e slashing non sono funzioni autonome fisse di CometBFT stesso. È l'applicazione a stabilire se queste regole esistono e come funzionano.

Un'altra cosa importante: le validator signing key devono essere protette bene. Se lo stesso validator firma messaggi in conflitto, questo può essere una prova di comportamento bizantino. CometBFT può elaborare questo tipo di prova, ma un'eventuale sanzione economica la decide l'applicazione.

Come avviene la comunicazione tra validator?

I validator comunicano tramite una rete peer-to-peer, spesso abbreviata in P2P. I nodi inoltrano informazioni ad altri nodi tramite gossip. Sembra un termine informale, ma significa semplicemente che i messaggi si diffondono da nodo a nodo attraverso la rete.

Attraverso questo gossip vengono diffusi, tra le altre cose, transazioni, parti di block, proposte, prevote e precommit. I nodi condividono anche il loro stato attuale: a quale block height si trovano, in quale round sono e quale fase del consenso stanno eseguendo. Così un nodo in ritardo può vedere cosa sta succedendo e rientrare nel processo.

Anche i nodi non validanti possono essere utili in questo. Possono inoltrare proposte, block e voti, anche se non esprimono loro stessi un voto di consenso. Questo aiuta a diffondere le informazioni in modo ampio nella rete.

Le transazioni che l'applicazione considera abbastanza valide tramite CheckTx possono finire nella mempool. La mempool è in pratica una sala d'attesa per le transazioni che potrebbero entrare in un block successivo. Tramite gossip, queste transazioni possono essere diffuse ulteriormente. Però questo non garantisce che una transazione venga davvero inclusa: il proposer, i limiti del block e le regole dell'applicazione contano tutti.

La comunicazione tra nodi non va confusa con ABCI. P2P e gossip riguardano i messaggi tra nodi nella rete. ABCI riguarda invece la comunicazione locale tra CometBFT e l'applicazione blockchain, per esempio nello stesso processo, tramite socket o tramite gRPC.

Com'è strutturato CometBFT?

CometBFT è composto in grandi linee da una parte di consenso e da una parte applicativa, con ABCI come collegamento tra le due. Questa separazione è utile: un lato gestisce come i nodi si mettono d'accordo, l'altro decide cosa fa davvero la blockchain.

Il motore CometBFT include tra le altre cose componenti per il consenso, la comunicazione P2P, la mempool, la diffusione dei block, la conservazione dello stato e un server RPC. Attraverso questo server RPC, le applicazioni client possono richiedere dati sul consenso e sulla blockchain.

L'applicazione, invece, gestisce le proprie regole e i propri dati. Pensa alla domanda se una transazione è valida, a come cambiano i saldi o a quali altre operazioni supporta la blockchain. In molti nodi Cosmos SDK, CometBFT e l'applicazione girano insieme in un unico daemon, ma possono anche collaborare come processi separati tramite ABCI.

È importante sapere questo: CometBFT chiama l'applicazione tramite ABCI. Quindi non è l'applicazione a controllare CometBFT, ma è CometBFT a fare richieste quando, durante il ciclo di vita di una transazione o di un block, ha bisogno di una risposta.

Cosa fa il livello di consenso?

Il livello di consenso di CometBFT decide quando e come vengono finalizzati i nuovi block. Questo livello gestisce il consenso BFT, il networking P2P, la produzione dei block e la loro diffusione ai nodi.

Per ogni nuovo block, il protocollo sceglie un proposer e guida i round di propose, prevote e precommit. Appena più di due terzi del potere di voto hanno fatto precommit per lo stesso block, quel block viene committato.

Il livello di consenso gestisce anche la mempool. Quando un nodo riceve una transazione, CometBFT chiede tramite ABCI all'applicazione se quella transazione è adatta alla mempool. Questo controllo si chiama CheckTx. Un CheckTx riuscito non significa ancora che la transazione sia stata eseguita in modo definitivo. Significa solo che la transazione può essere presa in considerazione per una proposta di block successiva.

Dopo il consenso su un block, CometBFT fa in modo che l'applicazione esegua il block e salvi il nuovo stato. Il livello di consenso quindi non decide da solo se una transazione sia corretta nel merito. Quello resta compito dell'applicazione.

Cosa fa il livello applicativo?

Il livello applicativo definisce le regole della blockchain. Qui si stabilisce, per esempio, quali dati vengono conservati, quali transazioni sono valide e come una transazione valida modifica lo stato.

Questo livello è la deterministic state machine della blockchain. È un termine tecnico per qualcosa di semplice: se due nodi ricevono lo stesso input, devono calcolare esattamente lo stesso risultato. Altrimenti i nodi possono ottenere versioni diverse della blockchain, e ovviamente non funziona.

In un'applicazione Cosmos SDK, questo livello è composto tra le altre cose da moduli, gestione delle transazioni e state store. Lo stato attuale riceve anche un riepilogo crittografico, l'AppHash. Se i nodi calcolano valori AppHash diversi dopo lo stesso block, questo indica un problema nell'esecuzione.

Tramite ABCI, l'applicazione gestisce diversi momenti del processo:

• CheckTx: controlla se una transazione ricevuta può entrare nella mempool.
• PrepareProposal: permette all'applicazione del proposer di scegliere, ordinare, escludere o aggiungere transazioni per una proposta di block entro i limiti validi.
• ProcessProposal: permette agli altri validator di valutare se accettare la proposta.
• FinalizeBlock: esegue un block dopo che il consenso è stato raggiunto.
• Commit: salva in modo permanente il nuovo stato.

Non tutte le chiamate ABCI hanno esattamente gli stessi requisiti. PrepareProposal, per esempio, può differire perché la esegue solo il proposer. ProcessProposal e l'esecuzione dei block devono invece essere deterministiche, così tutti i validator arrivano allo stesso risultato.

A cosa serve CometBFT?

CometBFT viene usato come motore generale di consenso e replica per blockchain con regole proprie. Gli sviluppatori possono quindi mettere dietro una applicazione deterministica, invece di costruire da zero un sistema in cui i nodi devono mettersi d'accordo sui block.

Le possibili applicazioni sono varie. Una blockchain application può, per esempio, riguardare valute, e-voting o orchestrazione dell'infrastruttura. CometBFT non stabilisce quale debba essere l'uso. Fornisce la base tecnica per copiare in modo affidabile le stesse transazioni e lo stesso stato su più nodi.

All'interno della Cosmos Stack, CometBFT ha un ruolo chiaro: gestisce consenso, comunicazione di rete e produzione dei block. La Cosmos SDK fornisce poi i mattoni per la logica applicativa. Così gli sviluppatori non devono creare da soli entrambi i pezzi.

CometBFT ha anche un proprio server RPC. Un wallet, una dApp o un altro client può usarlo per richiedere dati su block e consenso, oltre alle API di un'applicazione Cosmos SDK.

Come funziona CometBFT insieme a Cosmos SDK?

CometBFT e Cosmos SDK si completano a vicenda: CometBFT gestisce il consenso e Cosmos SDK gestisce l'applicazione blockchain. Sono quindi due componenti diversi che insieme possono formare un'unica blockchain node funzionante.

La Cosmos SDK offre moduli, gestione delle transazioni, state management e altre regole applicative. CometBFT, nel frattempo, gestisce la comunicazione P2P, la mempool, la scelta del proposer e il raggiungimento del consenso sui nuovi block.

Il ponte tra i due è ABCI. In un'applicazione Cosmos SDK, BaseApp implementa questa interfaccia. CometBFT fa quindi richieste come CheckTx, PrepareProposal, ProcessProposal, FinalizeBlock e Commit. BaseApp elabora queste richieste e restituisce una risposta.

Con una nuova proposta, CometBFT sceglie prima un proposer in base al potere di voto dei validator. Poi l'applicazione di quel proposer può usare PrepareProposal per decidere quali transazioni entrano nella proposta e in quale ordine, entro i limiti del block. Gli altri validator valutano la proposta tramite ProcessProposal prima di votare.

Questa divisione è pratica. Gli sviluppatori possono lavorare su una propria applicazione blockchain, mentre il motore di consenso collaudato resta separato. Così lo stesso motore CometBFT può essere usato anche con applicazioni SDK diverse.

Quali sono i vantaggi di CometBFT?

Un vantaggio importante di CometBFT è la chiara safety BFT. Finché meno di un terzo del potere di voto dei validator rilevanti si comporta in modo bizantino, non vengono committati block in conflitto sulla stessa block height.

Inoltre, la separazione tra consenso e logica applicativa è molto comoda. Tramite ABCI uno sviluppatore può creare regole blockchain proprie senza dover costruire da solo un motore completo di consenso BFT. Questo rende più chiari i compiti tecnici: CometBFT gestisce l'accordo, l'applicazione gestisce il contenuto.

Altri vantaggi sono:

• Processo di voto chiaro: un block viene deciso solo dopo più di due terzi di precommit per quello stesso block.
• Tecnologia riutilizzabile: lo stesso motore può supportare diverse applicazioni blockchain.
• Collegamento flessibile: ABCI può funzionare in-process in Go, ma anche tramite socket o gRPC.
• Separazione delle responsabilità: il codice di consenso e il codice applicativo possono essere sviluppati separatamente.

Però è importante: questi vantaggi non significano automaticamente che ogni blockchain con CometBFT sia veloce, sicura o fortemente decentralizzata. Dipende anche dal validator set, dalle connessioni di rete, dall'hardware, dalla configurazione e dal codice dell'applicazione.

Quali limiti e rischi ha CometBFT?

CometBFT ha condizioni di sicurezza e rischi operativi ben precisi. La condizione principale è che meno di un terzo del potere di voto dei validator possa comportarsi in modo bizantino. Bizantino, qui, significa che i validator si comportano in modo scorretto o malevolo, per esempio inviando informazioni contraddittorie, non seguendo le regole o collaborando per manipolare la rete. Se questa soglia viene superata, la garanzia di safety contro commit in conflitto non vale più.

Anche per andare avanti serve abbastanza potere di voto attivo. Se i validator con potere di voto sufficiente sono offline, o non riescono a comunicare tra loro a causa di una partizione di rete, la rete non può raggiungere il quorum. In quel caso partono nuovi round e la produzione dei block può rallentare o fermarsi temporaneamente.

La latenza di rete qui conta molto. Se proposte, parti di block o voti non arrivano in tempo, il round scade e il protocollo riprova. I timeout possono poi aumentare. Questo aiuta i partecipanti lenti, ma significa anche che le conferme possono richiedere più tempo.

L'applicazione dietro ABCI è un altro punto importante. Dove serve determinismo, ogni nodo deve dare lo stesso risultato con lo stesso input. Un errore che fa calcolare risultati diversi ai nodi può causare mismatch dell'AppHash e problemi di consenso. La separazione tra CometBFT e l'applicazione quindi non evita tutti gli effetti di un codice applicativo sbagliato.

Anche le validator key e l'infrastruttura dei nodi sono sensibili. Le signing key protette male possono essere sfruttate e i validator possono diventare bersaglio di attacchi denial-of-service. Un'architettura con sentry node può aiutare a esporre meno direttamente i validator a questi attacchi.

Inoltre, una transazione nella mempool non è ancora inserita in modo sicuro in un block. I nodi possono andare in crash prima che una transazione finisca in una proposta, e così la transazione può sparire dalla mempool. Chi invia una transazione deve quindi aspettare che sia davvero in un block committato.

Infine, gli upgrade di versione possono creare problemi di compatibilità. Breaking change in una minor release possono richiedere una nuova chain o una migrazione dei dati propria. Aggiornare richiede quindi una buona preparazione, sia per l'applicazione sia per i nodi che eseguono la blockchain.

Conclusione

CometBFT è il motore tecnico che aiuta i nodi blockchain a mettersi d'accordo sui nuovi block e a mantenere lo stesso stato. Funziona con un processo di consenso BFT in cui i validator fanno proposte, votano e committano un block solo quando più di due terzi del potere di voto approvano lo stesso block.

La forza sta soprattutto nella divisione del lavoro. CometBFT gestisce consenso, comunicazione P2P e produzione dei block, mentre l'applicazione dietro ABCI definisce le regole della blockchain. In combinazione con Cosmos SDK, gli sviluppatori possono così costruire una propria applicazione blockchain senza creare da soli l'intero livello di consenso.

Allo stesso tempo, la pratica resta fondamentale. La sicurezza dipende dal potere di voto dei validator, da reti affidabili, da key protette bene e da un'applicazione che calcoli sempre lo stesso risultato. CometBFT offre quindi una base tecnica solida, ma il funzionamento finale di una chain dipende sempre anche da come quella base viene usata.