¿Qué es Cosmos SDK y cómo funciona para construir blockchains?

¿Qué es Cosmos SDK?

El SDK de Cosmos es un software de desarrollo de código abierto con el que los desarrolladores pueden construir una blockchain propia, específica para una aplicación, o un libro mayor digital. Por tanto, no es una blockchain, ni una red, ni un token por sí misma.

Una blockchain construida con Cosmos SDK puede funcionar como una blockchain Layer 1 independiente. Eso significa que la cadena no se ejecuta como una aplicación encima de otra blockchain, sino que define por sí misma las reglas de las transacciones, el estado y otros componentes del protocolo. En combinación con software como CometBFT, una blockchain de este tipo también puede tener su propia red de validadores y su propio proceso de consenso.

Con Cosmos SDK, un proyecto determina por sí mismo las reglas de su cadena. Piense en quién puede realizar determinadas acciones, cómo funcionan las transacciones, qué datos se almacenan, cómo se organiza la gobernanza y qué lógica de aplicación se aplica.

Puede verse como un kit de construcción para una blockchain. En lugar de programar todos los componentes desde cero, un desarrollador elige componentes existentes y los combina con código propio. De ese modo, una cadena puede incorporar reglas para tokens, gestión de validadores, gobernanza on-chain o permisos específicos.

Técnicamente, una aplicación de Cosmos SDK es una máquina de estados determinista. Suena complejo, pero la idea es sencilla: la misma entrada válida debe conducir siempre al mismo nuevo estado en cada nodo. Si un usuario, por ejemplo, envía tokens, todos los nodos deben acabar viendo el mismo saldo.

En la configuración habitual, esa aplicación se ejecuta como un binario de Go. Go es el lenguaje de programación en el que se construye la lógica de la cadena. La aplicación se ejecuta junto con el software que permite que los nodos se comuniquen entre sí y produzcan bloques.

Cosmos SDK se encarga sobre todo de la capa de aplicación: qué transacciones son válidas y qué modifican. CometBFT suele encargarse del consenso, la red peer-to-peer y la producción de bloques. ABCI actúa como vínculo entre esas dos capas. A través de esta interfaz, el software de consenso puede pedir a la aplicación que verifique y ejecute transacciones y bloques.

Puntos clave

• Cosmos SDK es un software de desarrollo con el que, entre otras cosas, pueden construirse blockchains Layer 1 independientes y específicas para una aplicación.
• Una cadena puede establecer sus propias reglas para transacciones, gobernanza, permisos y datos almacenados.
• El SDK es modular: los desarrolladores combinan módulos existentes con lógica propia.
• CometBFT suele encargarse del consenso, la comunicación de red y la producción de bloques.
• Cosmos SDK no es una blockchain independiente y no tiene token propio.

¿Cómo funciona Cosmos SDK?

Cosmos SDK funciona porque CometBFT procesa bloques y, a través de ABCI, llama a la aplicación de la cadena. El SDK determina qué puede hacer una transacción, mientras que CometBFT se asegura de que los nodos lleguen a un acuerdo sobre los bloques.

La capa central dentro de una aplicación SDK se llama BaseApp. BaseApp traduce las llamadas de ABCI en tareas prácticas: ejecutar transacciones, enviar mensajes al módulo correcto y actualizar el estado.

Primero, un usuario envía una transacción firmada. En esa transacción hay uno o más mensajes. Un mensaje es la instrucción concreta, como enviar tokens o delegar tokens a un validador.

Además, la transacción contiene, entre otros elementos, una firma digital, comisiones y un límite de gas. La firma muestra qué cuenta ha aprobado la instrucción. Las comisiones son los costes de procesamiento. El límite de gas indica cuánto trabajo de cálculo está dispuesto a pagar como máximo el usuario.

Antes de que se ejecute la transacción, el AnteHandler comprueba una serie de reglas básicas. Por ejemplo, verifica si la firma es correcta, si la secuencia de la cuenta es adecuada, si hay suficientes comisiones y si no se supera el límite de gas. La secuencia de la cuenta es un número ascendente que ayuda a evitar que la misma transacción se reutilice.

Después, BaseApp envía cada mensaje al módulo correcto. Una transferencia de tokens, por ejemplo, va al módulo que gestiona los saldos. Ese módulo comprueba sus propias reglas y, si todo es correcto, modifica el estado.

El estado es todos los datos actuales de la cadena, como cuentas, saldos y configuraciones. Estos datos se almacenan como información clave-valor en un multistore. Se trata de una colección de almacenes separados, normalmente uno por módulo.

Una transacción se ejecuta con almacenamiento temporal del estado. Los cambios que se realizan durante la ejecución de un mensaje solo se conservan si esa ejecución tiene éxito. Si un mensaje falla, esos cambios se revierten. Sin embargo, algunos cambios de la fase anterior del AnteHandler, como el cobro de comisiones de transacción y el aumento de la secuencia de la cuenta, sí pueden conservarse.

En el flujo habitual de CometBFT, BaseApp procesa un bloque determinado mediante FinalizeBlock. En ese proceso, primero se ejecuta cualquier lógica previa al bloque, después se procesan las transacciones y, por último, la lógica al final del bloque. A continuación, el nuevo estado se guarda con Commit y se genera un nuevo AppHash: una huella criptográfica del estado de la aplicación.

Ejemplo: Suponga que envía 10 tokens a otra persona. Primero, la cadena comprueba su firma, la secuencia, la comisión y el límite de gas. Después, el módulo de tokens verifica si tiene al menos 10 tokens. Solo si todas las comprobaciones tienen éxito, se restan 10 de su saldo y se añaden 10 al saldo del destinatario.

¿De qué componentes consta Cosmos SDK?

Una aplicación típica de Cosmos SDK consta de BaseApp, módulos y una capa en la que todo se ensambla y configura. Juntos, estos componentes forman una sola máquina de estados que ejecutan los operadores de nodos.

BaseApp es el vínculo entre CometBFT y la aplicación. Se encarga de la conexión ABCI, enruta mensajes y consultas, ejecuta transacciones y gestiona el multistore.

Los módulos contienen la lógica empresarial real. Cada módulo puede tener su propio estado, mensajes, funciones de consulta y reglas. Una cadena decide por sí misma qué módulos incorpora. Después, estos se combinan con los módulos propios que sean necesarios.

Esa combinación suele hacerse en app.go. Allí el desarrollador crea BaseApp, configura los almacenes, inicializa componentes y determina cómo cooperan los módulos entre sí. El binario del nodo inicia entonces tanto el nodo de consenso como la aplicación SDK.

Los módulos suelen utilizar un keeper para acceder a su estado. Un keeper puede verse como una puerta de acceso controlada a los datos almacenados. No todos los módulos pueden modificarlo todo libremente. Un módulo solo recibe los permisos y las interfaces que la aplicación le entrega de forma deliberada.

El ModuleManager lleva el control de qué módulos están activos y gestiona, entre otras cosas, el inicio en genesis, las actualizaciones y el orden de los hooks en los límites de bloque. Genesis es el punto de inicio de una blockchain: el primer estado con el que arranca la red.

Protocol Buffers también desempeñan un papel importante. Es una forma de describir de manera clara los datos y los servicios. Los mensajes, los servicios de consulta, los tipos de estado y los tipos de genesis se definen con ello, tras lo cual se genera código Go y stubs gRPC para la aplicación.

¿Qué módulos ofrece Cosmos SDK?

Cosmos SDK ofrece muchos módulos que una cadena puede elegir y combinar. Ninguna cadena necesita usar todos los módulos. Precisamente esa elección determina lo que la blockchain específica puede y no puede hacer.

Algunos módulos de uso frecuente son:

• x/auth: gestiona los tipos básicos de cuentas y transacciones. Este módulo ayuda, entre otras cosas, a comprobar firmas y nonces de cuenta.
• x/bank: gestiona saldos de múltiples tokens, transferencias de tokens y la oferta total de tokens.
• x/staking: gestiona validadores y delegaciones dentro de una configuración proof-of-stake.
• x/gov: permite propuestas y votaciones on-chain.
• x/distribution: distribuye las recompensas de staking.
• x/slashing: puede aplicar sanciones cuando los validadores no cumplen las reglas.
• x/mint: apoya la emisión de tokens según las reglas de la cadena.
• x/evidence: procesa pruebas de mala conducta de validadores.
• x/upgrade: ayuda a una cadena a ejecutar actualizaciones de software de forma coordinada.

Además, existen módulos para tareas específicas. Por ejemplo, x/authz puede gestionar autorizaciones delegadas para mensajes y x/feegrant puede permitir que otra cuenta pague las comisiones de un usuario. x/consensus permite gestionar en la cadena determinados parámetros de consenso de CometBFT. x/circuit puede funcionar como un interruptor de circuito para pausar temporalmente determinados mensajes.

La funcionalidad IBC suele añadirse mediante ibc-go. Esta es la implementación IBC habitual para cadenas de Cosmos SDK, aunque se mantiene como un proyecto independiente.

Un desarrollador puede adaptar módulos estándar, sustituir componentes o crear módulos propios. Una cadena con solo funciones básicas se ve, por tanto, muy diferente de una cadena con gestión de validadores, gobernanza y reglas de permisos amplias.

¿Cómo funcionan las aplicaciones de Cosmos SDK?

Una aplicación de Cosmos SDK funciona porque un desarrollador compone, registra y dota de los permisos adecuados a los módulos de forma deliberada. Por tanto, no basta con importar un paquete de Go para que un módulo se ejecute en una cadena.

En app.go se construye la aplicación. Allí se registran las claves de almacenamiento, se crean los keepers, se añaden módulos al ModuleManager y se conectan servicios. También determina el desarrollador en qué orden se ejecutan los hooks en los límites de bloque. Ese orden puede ser importante, porque un módulo puede depender de las acciones de otro módulo.

Un módulo suele contener cuatro componentes prácticos:

• Un keeper: para acceder de forma controlada al propio estado.
• Un servicio Msg: para acciones que modifican el estado, como una transferencia o una delegación.
• Un servicio de consulta: para preguntas de solo lectura, como consultar un saldo.
• Una implementación AppModule: para que el módulo coopere correctamente con el ModuleManager.

Cuando llega una transacción, BaseApp enruta cada mensaje, según su tipo, al MsgServer del módulo correspondiente. A continuación, el módulo comprueba si el remitente está autorizado y si la acción cumple las reglas de negocio. Después, el módulo utiliza el keeper para modificar el estado.

Las consultas siguen otra ruta. A través del gRPCQueryRouter llegan al servicio de consulta del módulo correspondiente. Una consulta lee el estado almacenado y confirmado, y no modifica nada. Piense en la diferencia entre consultar el saldo de su banco y realizar un pago.

Los módulos también pueden tener lógica para genesis, actualizaciones y límites de bloque. En una actualización pueden ser necesarias migraciones de estado, para que los datos antiguos encajen correctamente con el nuevo código. Esto requiere una planificación cuidadosa y pruebas por parte del desarrollador de la cadena.

¿Qué es Cosmos EVM?

Una blockchain de Cosmos SDK también puede hacerse compatible con la Ethereum Virtual Machine (EVM). Para ello existe Cosmos EVM, con el que la funcionalidad EVM puede integrarse como parte de una aplicación de Cosmos SDK. Así, un proyecto puede construir una blockchain Layer 1 propia que, al mismo tiempo, ejecute contratos inteligentes de Ethereum.

El núcleo de esto es el módulo x/vm. Este añade un entorno de ejecución EVM a la blockchain, de modo que los desarrolladores pueden usar contratos inteligentes en Solidity y trabajar con herramientas conocidas de Ethereum como MetaMask, Hardhat y Foundry. Mientras tanto, la blockchain sigue siendo una cadena independiente de Cosmos SDK, con sus propias reglas y configuración.

Además, Cosmos EVM puede dar acceso a otras partes de Cosmos SDK mediante precompiles. Así, un contrato inteligente puede, por ejemplo, comunicarse con funcionalidades de staking, gobernanza o IBC. Qué precompiles están disponibles lo configuran los desarrolladores de la blockchain.

Cosmos EVM no es una parte obligatoria de Cosmos SDK. Un desarrollador puede construir una cadena Cosmos SDK sin EVM o añadir funcionalidad EVM de forma deliberada cuando se desea compatibilidad con aplicaciones y herramientas de Ethereum.

¿Para qué se utiliza Cosmos SDK?

Cosmos SDK se utiliza para construir blockchains y libros mayores digitales específicos para una aplicación, cuando un proyecto quiere definir por sí mismo las reglas de la cadena. Así, un proyecto puede diseñar una blockchain Layer 1 independiente en lugar de construir solo una aplicación o contratos inteligentes sobre una blockchain existente. Esto resulta especialmente útil cuando las reglas estándar de una blockchain general existente no ofrecen suficiente margen.

Por ejemplo, un proyecto puede establecer a nivel de protocolo reglas para la tokenización, las transferencias de tokens, la gestión de validadores de proof-of-stake, la gobernanza, las autorizaciones y las fee allowances. La lógica de cumplimiento normativo o de permisos también puede formar parte de las reglas de la cadena.

El SDK puede utilizarse para redes públicas, redes privadas permissioned y redes de consorcio. En una red pública, en principio cualquiera puede participar según las reglas abiertas. En una red permissioned, en cambio, pueden recibir permisos de antemano determinados participantes o validadores.

Eso hace que el SDK sea útil en situaciones en las que una organización o grupo no solo quiere construir una dApp o contratos inteligentes sobre una blockchain existente, sino que necesita un entorno Layer 1 propio con sus propias transiciones de estado y reglas de cadena.

Algunos ejemplos de posibles aplicaciones son las redes interbancarias, la tokenización de activos y la automatización empresarial. No obstante, si una cadena propia es adecuada depende de los requisitos concretos. Una cadena propia requiere, además de código, gestión, supervisión, actualizaciones, gobernanza y un modelo de seguridad adecuado.

¿Cuál es la relación entre Cosmos SDK, Cosmos Hub e IBC?

Cosmos SDK es el framework de construcción, IBC es el protocolo de comunicación entre blockchains y Cosmos Hub es una blockchain proof-of-stake pública concreta. Por tanto, estos tres elementos están relacionados, pero no son lo mismo.

Cosmos Hub ejecuta la aplicación Gaia. Gaia está construida como una aplicación de Cosmos SDK y utiliza ibc-go para IBC. ATOM es el token nativo de staking de Cosmos Hub.

IBC significa Inter-Blockchain Communication. Es un protocolo abierto que permite a las blockchains enviarse datos verificados entre sí. Esos datos pueden consistir en tokens, mensajes o lógica de aplicación.

Entonces, ¿cómo sabe una cadena que la información de otra cadena es correcta? IBC utiliza, entre otras cosas, clientes, a menudo llamados light clients, para verificar el estado de la contraparte. Después, IBC puede enviar, confirmar o dejar expirar paquetes de forma demostrable. Un paquete es aquí un bloque de datos que pasa de una cadena a otra.

Cosmos SDK tiene una estrecha conexión con IBC a través de ibc-go, pero IBC debe integrarse realmente en la cadena. Un desarrollador debe, entre otras cosas, añadir keepers y almacenamiento de IBC, configurar un router IBC con rutas y registrar los módulos relevantes.

Después, para que exista una comunicación real, también se necesita una contraparte adecuada, además de un canal IBC y relaying. Los relayers son procesos que transmiten mensajes IBC entre cadenas. No determinan por sí mismos qué datos son válidos, porque las cadenas verifican esos datos según las reglas de IBC.

Cosmos Hub puede comunicarse mediante IBC con otras cadenas compatibles, pero no es una capa intermedia central obligatoria. Dos cadenas IBC bien configuradas pueden comunicarse directamente entre sí mediante sus propios clientes, conexiones y canales.

IBC tampoco es exclusivo de las cadenas de Cosmos SDK. El SDK hace que la integración sea especialmente práctica para las cadenas construidas con él.

¿Cuáles son las ventajas y limitaciones de Cosmos SDK?

La mayor fortaleza de Cosmos SDK es la personalización. Los desarrolladores pueden usar solo los módulos que necesitan, adaptar el comportamiento estándar y añadir lógica propia. De ese modo, las reglas de una cadena pueden diseñarse directamente a nivel de protocolo.

La separación entre lógica de aplicación, ABCI y consenso también resulta útil. Quien utiliza CometBFT no tiene que construir por completo por sí mismo la capa habitual de consenso y peer-to-peer. Así, el desarrollador puede centrarse más en lo que la cadena debe hacer.

Otras ventajas son:

• Bloques de construcción reutilizables: los módulos ofrecen funciones para cuentas, tokens, staking, gobernanza, actualizaciones y autorización.
• Acceso controlado: los keepers limitan qué estado puede leer o modificar un módulo de otros módulos.
• Interoperabilidad mediante IBC: las cadenas IBC correctamente integradas pueden intercambiar datos verificados sin una parte central de puente.
• Modelos de red flexibles: el SDK puede utilizarse para redes públicas, privadas y de consorcio.

Esa libertad también conlleva responsabilidad. Un desarrollador debe diseñar correctamente los módulos, keepers, permisos, parámetros y el orden de los hooks. También requieren atención las migraciones de estado en las actualizaciones y la gestión de dependencias. El SDK está en gran medida estabilizado, pero todavía puede contener breaking changes. Por ello, una actualización debe planificarse y probarse bien.

En la práctica, es importante conocer Go, porque las aplicaciones SDK son binarios de Go y Go es necesario para construir y ejecutar un nodo. Esto puede ser una barrera para equipos que trabajan principalmente con otros lenguajes de programación.

IBC hace posible la interoperabilidad, pero no de forma automática. Una cadena debe integrar y configurar IBC correctamente. Además, se necesita una contraparte compatible, un canal operativo y relayers en funcionamiento.

Por último, el SDK no elimina toda la responsabilidad operativa y de seguridad. Una cadena independiente debe ejecutar por sí misma un modelo adecuado para validadores y stake, o para reglas de validadores permissioned. La seguridad también depende del código propio de los módulos, la configuración, la gestión de claves, las actualizaciones, la infraestructura y la forma en que se administra la red.

Conclusión

Cosmos SDK es un framework flexible para equipos que quieren construir su propia blockchain con sus propias reglas. En lugar de colocar solo lógica dentro de una cadena existente, un proyecto puede decidir por sí mismo cómo funcionan las transacciones, el estado, la gobernanza, los permisos y otros procesos.

La estructura modular permite combinar componentes existentes para, por ejemplo, tokens, staking y gobernanza con código propio. Además, un proyecto puede integrar Cosmos EVM, por ejemplo, cuando quiere combinar su propia blockchain con compatibilidad para contratos inteligentes y herramientas de Ethereum. CometBFT suele encargarse del consenso y la capa de red, mientras que BaseApp y los módulos ejecutan la lógica de aplicación.

IBC puede conectar una cadena de Cosmos SDK con otras cadenas correctamente integradas, pero esa conexión requiere una configuración técnica deliberada. Lo mismo ocurre con la propia cadena: la flexibilidad también significa que los desarrolladores siguen siendo responsables del diseño, las actualizaciones, la operación y la seguridad.

En resumen, Cosmos SDK resulta especialmente interesante cuando un proyecto no solo quiere construir una aplicación, sino dar forma a las reglas de la propia blockchain subyacente.