¿Qué es CometBFT y cómo funciona?

¿Qué es CometBFT?

CometBFT es un software de código abierto que permite que varios ordenadores se pongan de acuerdo sobre los mismos datos de blockchain. En términos sencillos: ayuda a los nodos a ordenar las transacciones en la misma secuencia y a mantener todos el mismo estado actualizado de una blockchain.

Ese proceso se denomina Byzantine Fault Tolerant, o BFT. En él, el sistema parte de la base de que algunos participantes pueden cometer errores, desconectarse o incluso actuar de forma incorrecta a propósito. Mientras menos de un tercio del poder de voto total se comporte así, CometBFT evita que dos bloques diferentes se finalicen en el mismo lugar de la blockchain.

CometBFT es el sucesor de Tendermint Core y utiliza el algoritmo de consenso Tendermint. No es una blockchain lista para usar ni un proyecto completo de cripto con sus propias reglas fijas. El software se encarga principalmente del consenso, la comunicación entre nodos y la producción de bloques. Las reglas de la propia blockchain, como qué transacciones son válidas, residen en una aplicación aparte.

La conexión entre CometBFT y esa aplicación se llama ABCI, siglas de Application Blockchain Interface. Puede entenderse ABCI como una capa fija de comunicación: CometBFT pregunta, por ejemplo, si una transacción es válida, y la aplicación responde. Así, los desarrolladores pueden construir su propia lógica de blockchain sin tener que crear también desde cero un motor de consenso.

Puntos clave

• CometBFT es un software de código abierto para el consenso y la sincronización de datos de blockchain entre nodos.
• Utiliza consenso BFT, lo que permite tolerar errores o comportamiento malicioso de una parte de los validadores.
• CometBFT es un fork y sucesor de Tendermint Core.
• El software no determina por sí mismo qué transacciones son válidas en cuanto al contenido; eso lo hace la aplicación conectada.
• ABCI constituye la conexión entre CometBFT y la aplicación de blockchain.

¿Cómo funciona el consenso de CometBFT?

CometBFT permite que los validadores colaboren en cada bloque mediante tres pasos fijos: propose, prevote y precommit. En este contexto, un validador es un participante que puede firmar bloques y votos. Por tanto, no todos los nodos son automáticamente validadores.

Cada nueva posición en la blockchain se denomina block height. En cada height, la red intenta decidir un nuevo bloque. Primero, el protocolo asigna un proposer. Ese es el validador que, en esa ronda, puede difundir una propuesta de nuevo bloque.

Después, los demás validadores revisan la propuesta. ¿El bloque es válido y se recibió a tiempo? Entonces emiten un prevote: un primer voto a favor de ese bloque. Si hay suficiente acuerdo, sigue un precommit: el segundo voto y el decisivo.

Un bloque se confirma en cuanto más de dos tercios de todo el poder de voto han emitido un precommit para exactamente el mismo bloque. El poder de voto no depende necesariamente del número de validadores. Un validador puede tener más poder de voto que otro, por ejemplo, según las reglas de la aplicación de blockchain.

Ejemplo: Supongamos que el poder de voto total es 100. Entonces se necesitan más de 66 votos para confirmar un bloque. No importa si ese poder de voto procede de muchos validadores pequeños o de un número menor de validadores más grandes.

¿No llega una propuesta válida, el proposer está desconectado o los votos llegan demasiado tarde? Entonces la misma block height vuelve a empezar en una ronda siguiente. Los tiempos de espera pueden aumentar en cada ronda, de modo que los nodos lentos aún puedan ponerse al día. Eso no evita los retrasos, pero sí ofrece a la red una forma de seguir adelante cuando una ronda falla.

¿Qué papel desempeñan los validadores en CometBFT?

Los validadores toman las decisiones en CometBFT. Firman propuestas de bloques y votos, revisan propuestas y ayudan así a determinar qué bloque se añade. Un nodo normal puede transmitir información a otros nodos, pero sin una private validator key ese nodo no puede participar por sí mismo en el voto del consenso.

El proposer se elige de forma automática y predecible mediante un esquema round-robin. Los validadores con más poder de voto tienen, proporcionalmente, más turnos para presentar una propuesta.

En la práctica, un validador hace lo siguiente:

• el validador recibe una propuesta de bloque;
• el validador comprueba si la propuesta es válida según las reglas de la aplicación;
• si la propuesta es válida y llega a tiempo, sigue un prevote;
• si hay suficientes prevotes, puede seguir un precommit;
• tras suficientes precommits, el bloque se confirma.

Si no se ha recibido una propuesta válida, un validador puede votar nil. Eso significa simplemente: ningún voto a favor de un bloque específico en esta ronda. Así, la red puede pasar a una ronda siguiente sin aceptar sin más una propuesta incorrecta.

El conjunto de validadores y la distribución del poder de voto llegan como entrada desde la aplicación de blockchain. Por tanto, esa aplicación también puede tener reglas para ajustar el conjunto de validadores. Staking, la delegación y el slashing no son funciones autónomas fijas de CometBFT en sí. La aplicación determina si existen esas reglas y cómo funcionan.

Otro aspecto importante: las validator signing keys deben estar bien protegidas. Si el mismo validador firma mensajes contradictorios, eso puede ser prueba de comportamiento bizantino. CometBFT puede procesar este tipo de pruebas, pero una eventual sanción financiera la determina la aplicación.

¿Cómo se desarrolla la comunicación entre validadores?

Los validadores se comunican a través de una red peer-to-peer, a menudo abreviada como P2P. Los nodos transmiten información a otros nodos mediante gossip. Suena informal, pero simplemente significa que los mensajes se propagan de nodo en nodo por la red.

A través de ese gossip se difunden, entre otras cosas, transacciones, partes de bloques, propuestas, prevotes y precommits. Los nodos también comparten su estado actual: en qué block height se encuentran, en qué ronda están y qué paso del consenso están ejecutando. Gracias a ello, un nodo que va retrasado puede ver qué está ocurriendo y volver a conectarse.

Los nodos que no validan también pueden ser útiles en este proceso. Pueden retransmitir propuestas, bloques y votos, aunque ellos mismos no emitan un voto de consenso. Eso ayuda a distribuir la información ampliamente por la red.

Las transacciones que la aplicación considere suficientemente válidas mediante CheckTx pueden entrar en la mempool. La mempool es, en esencia, una sala de espera para transacciones que podrían incluirse en un bloque posterior. A través del gossip, esas transacciones pueden seguir difundiéndose. Sin embargo, eso no garantiza que una transacción vaya a incluirse realmente: el proposer, los límites del bloque y las reglas de la aplicación intervienen en ello.

No debe confundirse la comunicación entre nodos con ABCI. P2P y gossip se refieren a los mensajes entre nodos de la red. ABCI, en cambio, se refiere a la comunicación local entre CometBFT y la aplicación de blockchain, por ejemplo dentro del mismo proceso, mediante un socket o a través de gRPC.

¿Cómo está estructurado CometBFT?

CometBFT se compone, a grandes rasgos, de una parte de consenso y una parte de aplicación, con ABCI como conexión entre ambas. Esa separación es útil: un lado regula cómo llegan los nodos a un acuerdo, y el otro determina qué hace realmente la blockchain.

El motor de CometBFT incluye, entre otros, componentes para el consenso, la comunicación P2P, la mempool, la difusión de bloques, el almacenamiento del estado y un servidor RPC. A través de ese servidor RPC, las aplicaciones cliente pueden solicitar datos sobre el consenso y la blockchain.

La aplicación, por su parte, gestiona sus propias reglas y datos. Piense en si una transacción es válida, cómo cambian los saldos o qué otras acciones admite la blockchain. En muchos nodos de Cosmos SDK, CometBFT y la aplicación se ejecutan juntos en un solo daemon, pero también pueden colaborar como procesos separados mediante ABCI.

Es importante saber lo siguiente: CometBFT llama a la aplicación a través de ABCI. Por tanto, la aplicación no controla CometBFT, sino que responde cuando CometBFT le solicita información durante el ciclo de vida de una transacción o un bloque.

¿Qué hace la capa de consenso?

La capa de consenso de CometBFT regula cuándo y cómo se deciden los nuevos bloques. Esta capa proporciona consenso BFT, red P2P, producción de bloques y la difusión de bloques a los nodos.

Con cada nuevo bloque, el protocolo elige un proposer y guía las rondas de propose, prevote y precommit. En cuanto más de dos tercios del poder de voto han hecho precommit para el mismo bloque, ese bloque queda confirmado.

La capa de consenso también gestiona la mempool. Cuando un nodo recibe una transacción, CometBFT pregunta a la aplicación, a través de ABCI, si esa transacción es adecuada para la mempool. Esa comprobación se llama CheckTx. Que CheckTx se complete con éxito no significa todavía que la transacción se haya ejecutado de forma definitiva. Solo significa que la transacción puede optar a una propuesta de bloque posterior.

Después del consenso sobre un bloque, CometBFT se encarga de que la aplicación ejecute el bloque y almacene el nuevo estado. Por tanto, la capa de consenso no determina por sí misma si una transacción es correcta en cuanto al contenido. Esa sigue siendo tarea de la aplicación.

¿Qué hace la capa de aplicación?

La capa de aplicación determina las reglas de la blockchain. Ahí se define, por ejemplo, qué datos se registran, qué transacciones son válidas y cómo una transacción válida modifica el estado.

Esta capa es la máquina de estado determinista de la blockchain. Es un término técnico para algo sencillo: si dos nodos reciben la misma entrada, también deben calcular exactamente el mismo resultado. De lo contrario, los nodos podrían obtener versiones distintas de la blockchain, y eso, por supuesto, no funciona.

En una aplicación de Cosmos SDK, esta capa consta, entre otras cosas, de módulos, procesamiento de transacciones y state stores. El estado actual también recibe un resumen criptográfico, el AppHash. Si los nodos calculan valores de AppHash diferentes después del mismo bloque, eso indica un problema en la ejecución.

A través de ABCI, la aplicación gestiona distintos momentos del proceso:

• CheckTx: comprueba si una transacción recibida puede entrar en la mempool.
• PrepareProposal: permite que la aplicación del proposer elija, ordene, omita o añada transacciones para una propuesta de bloque dentro de los límites aplicables.
• ProcessProposal: permite que otros validadores evalúen si aceptan la propuesta.
• FinalizeBlock: ejecuta un bloque después de alcanzarse el consenso.
• Commit: guarda de forma permanente el nuevo estado.

No todas las llamadas ABCI tienen exactamente los mismos requisitos. Por ejemplo, PrepareProposal puede variar, porque solo la ejecuta el proposer. ProcessProposal y la ejecución de bloques, en cambio, deben ser deterministas, para que todos los validadores lleguen al mismo resultado.

¿Para qué se utiliza CometBFT?

CometBFT se utiliza como motor general de consenso y replicación para blockchains con reglas propias. Así, los desarrolladores pueden situar detrás una aplicación determinista, en lugar de construir desde cero un sistema en el que los nodos deban ponerse de acuerdo sobre los bloques.

Las posibles aplicaciones son variadas. Una aplicación de blockchain puede centrarse, por ejemplo, en monedas, e-voting u orquestación de infraestructura. CometBFT no fija cuál debe ser el caso de uso. Proporciona la base técnica para copiar de forma fiable las mismas transacciones y el mismo estado entre varios nodos.

Dentro de la Cosmos Stack, CometBFT tiene una función clara: gestiona el consenso, la comunicación de red y la producción de bloques. La Cosmos SDK, por su parte, proporciona los componentes para la lógica de la aplicación. Así, los desarrolladores no tienen que crear por sí mismos ambas partes desde cero.

CometBFT también dispone de su propio servidor RPC. Una wallet, una dApp u otro cliente puede utilizarlo para solicitar datos sobre bloques y consenso, además de las API de una aplicación de Cosmos SDK.

¿Cómo funciona CometBFT junto con Cosmos SDK?

CometBFT y Cosmos SDK se complementan: CometBFT gestiona el consenso y Cosmos SDK gestiona la aplicación de blockchain. Son, por tanto, dos componentes distintos que juntos pueden formar un único nodo de blockchain funcional.

Cosmos SDK ofrece módulos, procesamiento de transacciones, gestión del estado y otras reglas de aplicación. CometBFT, mientras tanto, gestiona la comunicación P2P, la mempool, la elección de un proposer y la consecución del consenso sobre nuevos bloques.

El puente entre ambos es ABCI. En una aplicación de Cosmos SDK, BaseApp implementa esta interfaz. CometBFT realiza entonces solicitudes como CheckTx, PrepareProposal, ProcessProposal, FinalizeBlock y Commit. BaseApp procesa esas solicitudes y devuelve una respuesta.

Ante una nueva propuesta, CometBFT elige primero un proposer en función del poder de voto de los validadores. Después, la aplicación de ese proposer puede usar PrepareProposal para decidir qué transacciones entran en la propuesta y en qué orden, dentro de los límites del bloque. Los demás validadores evalúan la propuesta mediante ProcessProposal antes de votar.

Esa distribución es práctica. Los desarrolladores pueden trabajar en su propia aplicación de blockchain, mientras el motor de consenso probado permanece separado. De este modo, el mismo motor CometBFT también puede utilizarse con distintas aplicaciones SDK.

¿Cuáles son las ventajas de CometBFT?

Una ventaja importante de CometBFT es su clara seguridad BFT. Mientras menos de un tercio del poder de voto relevante de los validadores tenga comportamiento bizantino, no se confirmarán bloques conflictivos en la misma block height.

Además, la separación entre consenso y lógica de aplicación resulta muy útil. A través de ABCI, un desarrollador puede crear sus propias reglas de blockchain sin tener que construir por sí mismo un motor completo de consenso BFT. Eso hace que las tareas técnicas sean más manejables: CometBFT se encarga del acuerdo, la aplicación del contenido.

Otras ventajas son:

• Proceso de voto claro: un bloque solo se decide después de más de dos tercios de precommits para ese mismo bloque.
• Tecnología reutilizable: el mismo motor puede dar soporte a distintas aplicaciones de blockchain.
• Conexión flexible: ABCI puede funcionar en proceso en Go, pero también mediante socket o gRPC.
• Separación de responsabilidades: el código de consenso y el código de aplicación pueden desarrollarse por separado.

No obstante, es importante tener en cuenta que estas ventajas no significan automáticamente que toda blockchain con CometBFT sea rápida, segura o altamente descentralizada. Eso también depende del conjunto de validadores, las conexiones de red, el hardware, la configuración y el código de la aplicación.

¿Qué limitaciones y riesgos tiene CometBFT?

CometBFT tiene condiciones de seguridad y riesgos operativos claros. La condición principal es que menos de un tercio del poder de voto de los validadores puede tener comportamiento bizantino. Bizantino significa aquí que los validadores actúan de forma incorrecta o maliciosa, por ejemplo enviando información contradictoria, incumpliendo reglas o colaborando para manipular la red. Si se supera ese umbral, la garantía de seguridad frente a confirmaciones conflictivas deja de aplicarse.

También se necesita suficiente poder de voto activo para que haya progreso. Si los validadores con suficiente poder de voto están desconectados, o no pueden comunicarse entre sí debido a una partición de red, la red no puede alcanzar quórum. Entonces se suceden nuevas rondas y la producción de bloques puede ralentizarse o detenerse temporalmente.

La latencia de red desempeña aquí un papel importante. Si las propuestas, las partes de bloques o los votos no llegan a tiempo, la ronda expira y el protocolo lo intenta de nuevo. Después, los tiempos de espera pueden aumentar. Eso ayuda a los participantes lentos, pero también significa que las confirmaciones pueden tardar más.

La aplicación detrás de ABCI es otro aspecto importante. Cuando se requiere determinismo, cada nodo debe obtener el mismo resultado a partir de la misma entrada. Un error que haga que los nodos calculen resultados distintos puede provocar discrepancias de AppHash y problemas de consenso. Por tanto, la separación entre CometBFT y la aplicación no evita todos los efectos de un código de aplicación deficiente.

Las validator keys y la infraestructura de los nodos también son sensibles. Las signing keys mal protegidas pueden ser explotadas y los validadores pueden ser objetivo de ataques de denegación de servicio. Una arquitectura de sentry nodes puede ayudar a exponer menos directamente los nodos validadores a este tipo de ataques.

Además, una transacción en la mempool todavía no está incorporada de forma segura en un bloque. Los nodos pueden fallar antes de que una transacción llegue a una propuesta, lo que puede hacer que la transacción se pierda de la mempool. Quien envía una transacción debe, por tanto, esperar hasta que realmente esté en un bloque confirmado.

Por último, las actualizaciones de versión pueden generar problemas de compatibilidad. Los breaking changes en una versión menor pueden requerir una nueva cadena o una migración de datos propia. Por ello, actualizar exige una buena preparación, tanto en la aplicación como en los nodos que ejecutan la blockchain.

Conclusión

CometBFT es el motor técnico que ayuda a los nodos de blockchain a ponerse de acuerdo sobre nuevos bloques y a mantener el mismo estado. Funciona con un proceso de consenso BFT en el que los validadores presentan propuestas, votan y solo confirman un bloque cuando más de dos tercios del poder de voto aprueban el mismo bloque.

La fortaleza reside sobre todo en la distribución del trabajo. CometBFT gestiona el consenso, la comunicación P2P y la producción de bloques, mientras que la aplicación detrás de ABCI determina las reglas de la blockchain. En combinación con Cosmos SDK, los desarrolladores pueden así construir su propia aplicación de blockchain sin tener que crear por sí mismos toda la capa de consenso.

Al mismo tiempo, la práctica sigue siendo importante. La seguridad depende del poder de voto de los validadores, de redes fiables, de claves bien protegidas y de una aplicación que calcule siempre el mismo resultado. CometBFT ofrece, por tanto, una base técnica sólida, pero el funcionamiento final de una cadena depende siempre también de cómo se utilice esa base.