O que é o CometBFT e como funciona?

O que é o CometBFT?

CometBFT é software de código aberto que garante que vários computadores possam chegar a acordo sobre os mesmos dados de blockchain. Em termos simples: ajuda nodes a colocar transacções pela mesma ordem e a manterem todos o mesmo estado actualizado de uma blockchain.

Esse processo chama-se Byzantine Fault Tolerant, ou BFT. Aqui, o sistema parte do princípio de que alguns participantes podem cometer erros, ficar offline ou até agir de forma deliberadamente incorrecta. Enquanto menos de um terço do poder de voto total se comportar assim, o CometBFT impede que dois blocks diferentes sejam finalizados no mesmo ponto da blockchain.

O CometBFT é o sucessor do Tendermint Core e utiliza o algoritmo de consenso Tendermint. Não é uma blockchain pronta a usar nem um projecto completo de criptomoeda com regras fixas próprias. O software trata sobretudo do consenso, da comunicação entre nodes e da produção de blocks. As regras da própria blockchain, como quais as transacções válidas, ficam numa aplicação separada.

A ligação entre o CometBFT e essa aplicação chama-se ABCI, abreviatura de Application Blockchain Interface. Pode ver o ABCI como uma camada fixa de comunicação: o CometBFT pergunta, por exemplo, se uma transacção é válida, e a aplicação responde. Assim, os programadores podem construir a sua própria lógica de blockchain sem terem também de criar, do zero, um motor de consenso.

Pontos principais

• O CometBFT é software de código aberto para consenso e sincronização de dados de blockchain entre nodes.
• Utiliza consenso BFT, o que permite lidar com erros ou comportamento malicioso de parte dos validadores.
• O CometBFT é um fork e sucessor do Tendermint Core.
• O software não determina por si só quais as transacções que são válidas em termos de conteúdo; isso é feito pela aplicação ligada.
• O ABCI constitui a ligação entre o CometBFT e a aplicação de blockchain.

Como funciona o consenso do CometBFT?

O CometBFT permite que os validadores colaborem por block através de três passos fixos: propose, prevote e precommit. Neste contexto, um validador é um participante que pode assinar blocks e votos. Portanto, nem todos os nodes são automaticamente validadores.

Cada nova posição na blockchain chama-se block height. Em cada height, a rede tenta decidir um novo block. Primeiro, o protocolo designa um proposer. Trata-se do validador que, nessa ronda, pode divulgar uma proposta para um novo block.

Depois, os outros validadores analisam a proposta. O block é válido e foi recebido a tempo? Então emitem um prevote: um primeiro voto para esse block. Se houver acordo suficiente, segue-se um precommit: o segundo e decisivo voto.

Um block é commitado assim que mais de dois terços de todo o poder de voto tiverem emitido um precommit para exactamente o mesmo block. O poder de voto não depende necessariamente do número de validadores. Um validador pode, por exemplo, ter mais poder de voto do que outro, consoante as regras da aplicação de blockchain.

Exemplo: Suponha que o poder de voto total é 100. Nesse caso, são necessários mais de 66 votos para commitar um block. Não importa se esse poder de voto vem de muitos validadores pequenos ou de um número menor de validadores maiores.

Se não houver uma proposta válida, se o proposer estiver offline ou se os votos chegarem tarde demais, a mesma block height recomeça numa ronda seguinte. Os tempos de espera podem aumentar de ronda para ronda, para que nodes mais lentos ainda possam recuperar. Isto não evita atrasos, mas dá à rede uma forma de continuar quando uma ronda falha.

Que papel desempenham os validadores no CometBFT?

Os validadores tomam as decisões no CometBFT. Assinam propostas de blocks e votos, verificam propostas e ajudam assim a determinar qual o block que é adicionado. Um node normal pode transmitir informação a outros nodes, mas sem uma private validator key esse node não pode votar directamente no consenso.

O proposer é escolhido automaticamente e de forma previsível através de um esquema round-robin. Os validadores com mais poder de voto têm, proporcionalmente, mais oportunidades de apresentar uma proposta.

Na prática, um validador faz o seguinte:

• o validador recebe uma proposta de block;
• o validador verifica se a proposta é válida de acordo com as regras da aplicação;
• perante uma proposta válida e atempada, segue-se um prevote;
• com prevotes suficientes, pode seguir-se um precommit;
• após precommits suficientes, o block é commitado.

Se não tiver sido recebida uma proposta válida, um validador pode votar em nil. Isto significa simplesmente: nenhum voto para um block específico nesta ronda. Assim, a rede pode passar para uma ronda seguinte sem aceitar de forma arbitrária uma proposta incorrecta.

O conjunto de validadores e a distribuição do poder de voto entram como input a partir da aplicação de blockchain. Essa aplicação também pode ter regras para ajustar o conjunto de validadores. Staking, delegação e slashing não são funções autónomas fixas do próprio CometBFT. A aplicação determina se essas regras existem e como funcionam.

Há ainda outro ponto importante: as validator signing keys devem estar bem protegidas. Se o mesmo validador assinar mensagens conflituantes, isso pode ser prova de comportamento bizantino. O CometBFT pode processar este tipo de prova, mas uma eventual penalização financeira é determinada pela aplicação.

Como decorre a comunicação entre validadores?

Os validadores comunicam através de uma rede peer-to-peer, frequentemente abreviada para P2P. Os nodes transmitem informação a outros nodes através de gossip. Isto pode soar informal, mas significa apenas que as mensagens se propagam de node para node pela rede.

Através desse gossip são difundidos, entre outros, transacções, partes de blocks, propostas, prevotes e precommits. Os nodes também partilham o seu estado actual: em que block height se encontram, em que ronda estão e que passo do consenso estão a executar. Assim, um node que esteja atrasado pode ver o que se passa e voltar a ligar-se.

Também os nodes que não validam podem ser úteis neste processo. Estes podem transmitir propostas, blocks e votos, mesmo que não emitam por si próprios um voto de consenso. Isso ajuda a espalhar informação amplamente pela rede.

As transacções que a aplicação considere suficientemente válidas através de CheckTx podem entrar na mempool. A mempool é, na prática, uma sala de espera para transacções que podem entrar num block seguinte. Através de gossip, essas transacções podem ser ainda mais difundidas. No entanto, isso não garante que uma transacção seja realmente incluída: o proposer, os limites do block e as regras da aplicação também contam.

Não deve confundir a comunicação entre nodes com o ABCI. P2P e gossip dizem respeito a mensagens entre nodes na rede. O ABCI diz respeito, pelo contrário, à comunicação local entre o CometBFT e a aplicação de blockchain, por exemplo dentro do mesmo processo, através de um socket ou via gRPC.

Como é estruturado o CometBFT?

De forma geral, o CometBFT é composto por uma parte de consenso e uma parte de aplicação, com o ABCI como ligação entre ambas. Essa separação é útil: um lado trata de como os nodes chegam a acordo, o outro determina o que a blockchain faz realmente.

O motor CometBFT inclui, entre outros, componentes para consenso, comunicação P2P, a mempool, a difusão de blocks, o armazenamento de estado e um servidor RPC. Através desse servidor RPC, as aplicações cliente podem pedir dados sobre o consenso e a blockchain.

A aplicação, por sua vez, gere as suas próprias regras e dados. Pense na questão de saber se uma transacção é válida, como os saldos mudam ou que outras operações a blockchain suporta. Em muitos nodes do Cosmos SDK, o CometBFT e a aplicação correm em conjunto num único daemon, mas também podem trabalhar como processos separados através do ABCI.

Importa saber o seguinte: o CometBFT chama a aplicação através do ABCI. Portanto, a aplicação não controla o CometBFT, mas responde quando o CometBFT lhe pede algo durante o ciclo de vida de uma transacção ou de um block.

O que faz a camada de consenso?

A camada de consenso do CometBFT regula quando e como novos blocks são decididos. Esta camada assegura o consenso BFT, a rede P2P, a produção de blocks e a difusão de blocks para os nodes.

Em cada novo block, o protocolo escolhe um proposer e orienta as rondas de propose, prevote e precommit. Assim que mais de dois terços do poder de voto tiverem feito precommit para o mesmo block, esse block é commitado.

A camada de consenso também gere a mempool. Quando um node recebe uma transacção, o CometBFT pergunta à aplicação, através do ABCI, se essa transacção é adequada para a mempool. Essa verificação chama-se CheckTx. Um CheckTx bem-sucedido ainda não significa que a transacção foi executada de forma definitiva. Significa apenas que a transacção pode ser considerada para uma proposta de block posterior.

Depois do consenso sobre um block, o CometBFT garante que a aplicação executa o block e guarda o novo estado. A camada de consenso, portanto, não determina por si só se uma transacção está correcta em termos de conteúdo. Essa continua a ser tarefa da aplicação.

O que faz a camada de aplicação?

A camada de aplicação define as regras da blockchain. Aí fica registado, por exemplo, que dados são mantidos, quais as transacções válidas e como uma transacção válida altera o estado.

Esta camada é a máquina de estados determinística da blockchain. É um termo técnico para algo simples: se dois nodes recebem a mesma entrada, também têm de calcular exactamente o mesmo resultado. Caso contrário, os nodes podem acabar com versões diferentes da blockchain, e isso obviamente não funciona.

Numa aplicação do Cosmos SDK, esta camada inclui, entre outros, módulos, processamento de transacções e state stores. O estado actual recebe também um resumo criptográfico, o AppHash. Se os nodes calcularem valores de AppHash diferentes após o mesmo block, isso indica um problema na execução.

Através do ABCI, a aplicação trata de diferentes momentos no processo:

• CheckTx: verifica se uma transacção recebida pode entrar na mempool.
• PrepareProposal: permite que a aplicação do proposer escolha, ordene, omita ou adicione transacções para uma proposta de block, dentro dos limites aplicáveis.
• ProcessProposal: permite que outros validadores avaliem se aceitam a proposta.
• FinalizeBlock: executa um block depois de alcançado o consenso.
• Commit: guarda o novo estado de forma permanente.

Nem todas as chamadas ABCI têm exactamente os mesmos requisitos. Por exemplo, o PrepareProposal pode variar, porque só o proposer o executa. Já o ProcessProposal e a execução de blocks têm de ser determinísticos, para que todos os validadores cheguem ao mesmo resultado.

Para que é utilizado o CometBFT?

O CometBFT é utilizado como motor geral de consenso e replicação para blockchains com regras próprias. Os programadores podem, assim, colocar atrás dele uma aplicação determinística, em vez de construírem de raiz um sistema em que os nodes têm de chegar a acordo sobre blocks.

As possíveis utilizações são variadas. Uma aplicação de blockchain pode, por exemplo, centrar-se em currencies, e-voting ou orquestração de infraestrutura. O CometBFT não define qual deve ser a aplicação. Fornece a base técnica para copiar de forma fiável as mesmas transacções e o mesmo estado por vários nodes.

Dentro da Cosmos Stack, o CometBFT tem um papel claro: gere o consenso, a comunicação de rede e a produção de blocks. A Cosmos SDK fornece depois os blocos de construção para a lógica da aplicação. Assim, os programadores não precisam de desenvolver ambos os componentes por completo.

O CometBFT também tem o seu próprio servidor RPC. Uma wallet, dApp ou outro cliente pode utilizá-lo para pedir dados sobre blocks e consenso, para além das APIs de uma aplicação Cosmos SDK.

Como funciona o CometBFT em conjunto com o Cosmos SDK?

O CometBFT e o Cosmos SDK complementam-se: o CometBFT trata do consenso e o Cosmos SDK trata da aplicação de blockchain. São, portanto, dois componentes diferentes que, em conjunto, podem formar um único node de blockchain funcional.

O Cosmos SDK oferece módulos, processamento de transacções, gestão de estado e outras regras da aplicação. Entretanto, o CometBFT trata da comunicação P2P, da mempool, da escolha de um proposer e da obtenção de consenso sobre novos blocks.

A ponte entre ambos é o ABCI. Numa aplicação Cosmos SDK, o BaseApp implementa esta interface. O CometBFT faz então pedidos como CheckTx, PrepareProposal, ProcessProposal, FinalizeBlock e Commit. O BaseApp processa esses pedidos e devolve uma resposta.

Perante uma nova proposta, o CometBFT escolhe primeiro um proposer com base no poder de voto dos validadores. Depois, a aplicação desse proposer pode, através do PrepareProposal, determinar quais as transacções que entram na proposta e em que ordem, dentro dos limites do block. Os outros validadores avaliam a proposta através do ProcessProposal antes de votarem.

Essa divisão é prática. Os programadores podem trabalhar numa aplicação de blockchain própria, enquanto o motor de consenso testado permanece separado. Assim, o mesmo motor CometBFT também pode ser utilizado em diferentes aplicações SDK.

Quais são as vantagens do CometBFT?

Uma vantagem importante do CometBFT é a clara segurança BFT. Enquanto menos de um terço do poder de voto relevante dos validadores tiver comportamento bizantino, não são commitados blocks conflituantes no mesmo block height.

Além disso, a separação entre consenso e lógica da aplicação é muito útil. Através do ABCI, um programador pode criar regras próprias de blockchain sem ter de construir sozinho um motor completo de consenso BFT. Isso torna as tarefas técnicas mais organizadas: o CometBFT trata do acordo, a aplicação trata do conteúdo.

Outras vantagens são:

• Processo de voto claro: um block só é decidido após mais de dois terços de precommits para esse mesmo block.
• Tecnologia reutilizável: o mesmo motor pode suportar diferentes aplicações de blockchain.
• Ligação flexível: o ABCI pode funcionar in-process em Go, mas também via socket ou gRPC.
• Separação de responsabilidades: o código de consenso e o código da aplicação podem ser desenvolvidos de forma independente.

Ainda assim, é importante notar que estas vantagens não significam automaticamente que qualquer blockchain com CometBFT seja rápida, segura ou fortemente descentralizada. Isso também depende do conjunto de validadores, das ligações de rede, do hardware, da configuração e do código da aplicação.

Que limitações e riscos tem o CometBFT?

O CometBFT tem condições de segurança e riscos operacionais claros. A condição principal é que menos de um terço do poder de voto dos validadores possa ter comportamento bizantino. Bizantino significa aqui que os validadores se comportam de forma incorrecta ou maliciosa, por exemplo ao enviar informação contraditória, ao não seguir as regras ou ao colaborar para manipular a rede. Se esse limite for ultrapassado, a garantia de segurança contra commits conflituantes deixa de se aplicar.

Também é necessário poder de voto activo suficiente para haver progresso. Se validadores com poder de voto suficiente ficarem offline, ou se não puderem comunicar entre si devido a uma partição da rede, a rede pode não conseguir atingir quórum. Nesses casos, seguem-se novas rondas e a produção de blocks pode atrasar-se ou parar temporariamente.

O atraso de rede tem aqui um papel importante. Se propostas, partes de blocks ou votos não chegarem a tempo, a ronda termina e o protocolo tenta novamente. Os time-outs podem então aumentar. Isso ajuda participantes lentos, mas também significa que as confirmações podem demorar mais.

A aplicação por trás do ABCI é outro ponto importante. Onde é exigido determinismo, cada node tem de produzir o mesmo resultado a partir da mesma entrada. Um erro que faça com que os nodes calculem resultados diferentes pode causar incompatibilidades de AppHash e problemas de consenso. A separação entre o CometBFT e a aplicação, portanto, não evita todos os efeitos de código de aplicação deficiente.

As validator keys e a infraestrutura dos nodes também são sensíveis. Chaves de assinatura mal protegidas podem ser exploradas e os validadores podem tornar-se alvo de ataques de negação de serviço. Uma arquitectura de sentry nodes pode ajudar a expor menos directamente os validator nodes a esses ataques.

Além disso, uma transacção na mempool ainda não está seguramente incluída num block. Os nodes podem falhar antes de uma transacção entrar numa proposta, o que pode fazer com que a transacção se perca da mempool. Quem envia uma transacção deve, portanto, esperar até que esta esteja realmente num block commitado.

Por fim, actualizações de versão podem causar problemas de compatibilidade. Alterações incompatíveis numa versão minor podem exigir uma nova chain ou uma migração de dados própria. Actualizar exige, por isso, uma boa preparação, tanto na aplicação como nos nodes que executam a blockchain.

Conclusão

O CometBFT é o motor técnico que ajuda os nodes de blockchain a chegar a acordo sobre novos blocks e a manter o mesmo estado. Funciona com um processo de consenso BFT em que os validadores fazem propostas, votam e só cometem um block quando mais de dois terços do poder de voto aprovam o mesmo block.

A força está sobretudo na divisão do trabalho. O CometBFT trata do consenso, da comunicação P2P e da produção de blocks, enquanto a aplicação por trás do ABCI determina as regras da blockchain. Em combinação com o Cosmos SDK, os programadores podem assim construir a sua própria aplicação de blockchain sem terem de criar sozinhos toda a camada de consenso.

Ao mesmo tempo, a prática continua a ser importante. A segurança depende do poder de voto dos validadores, de redes fiáveis, de chaves bem protegidas e de uma aplicação que calcule sempre o mesmo resultado. O CometBFT oferece, portanto, uma base técnica sólida, mas o funcionamento final de uma chain depende sempre também da forma como essa base é utilizada.