Cosmos SDK

¿Qué es Cosmos SDK?

Cosmos SDK es un framework de software de código abierto para crear blockchains Layer 1 personalizables, libros contables distribuidos y redes cripto específicas para aplicaciones.

Proporciona a los desarrolladores componentes de blockchain reutilizables para cuentas, transferencias de tokens, comisiones de transacción, staking, gobernanza, recompensas, autorización, actualizaciones y otras funciones habituales.

Los desarrolladores pueden combinar estos componentes con módulos personalizados que definen la lógica de negocio específica de una nueva blockchain.

Cosmos SDK está escrito principalmente en el lenguaje de programación Go.

Es la capa de aplicación y transición de estado de la pila tecnológica más amplia de Cosmos, no una criptomoneda ni una blockchain por sí sola.

Una blockchain creada con el SDK puede definir su propio token nativo, sistema de validadores, reglas de transacción, modelo de comisiones, proceso de gobernanza y funciones de aplicación.

La descripción general oficial de Cosmos SDK lo define como un framework para crear blockchains específicas para aplicaciones y libros contables digitales a partir de módulos predefinidos y personalizados.

El framework puede admitir cadenas públicas sin permisos, libros contables privados con permisos, redes de consorcio y otras estructuras especializadas de blockchain.

¿Qué significa SDK?

SDK son las siglas de software development kit, o kit de desarrollo de software.

Un kit de desarrollo de software proporciona bibliotecas, interfaces, herramientas, documentación y código reutilizable para ayudar a los desarrolladores a crear software para un entorno determinado.

Cosmos SDK proporciona componentes básicos específicos para blockchain, de modo que los desarrolladores no tengan que crear desde cero todas las funciones de cuentas, transacciones, almacenamiento, gobernanza y staking.

La palabra SDK no significa que todas las blockchains creadas con él deban tener las mismas reglas o experiencia de usuario.

Cada equipo de desarrollo puede elegir sus módulos, parámetros, permisos, integración de consenso y políticas de actualización.

¿Cuál es la versión más reciente de Cosmos SDK?

A fecha de julio de 2026, Cosmos SDK v0.54.3 figura como la versión más reciente en el repositorio oficial.

La versión se publicó el 5 de mayo de 2026 como parte de la familia de versiones v0.54 y 2026.1.

Antes de iniciar el desarrollo, conviene consultar la página de versiones de Cosmos SDK, ya que pueden publicarse nuevas versiones de mantenimiento y correcciones de seguridad.

Los números de versión son importantes porque las interfaces de los módulos, los paquetes de almacenamiento, la configuración de la aplicación, las dependencias y los requisitos de migración pueden variar entre familias de versiones.

Una cadena no debería actualizar su dependencia de SDK sin revisar los cambios incompatibles y preparar una actualización coordinada de la red cuando sea necesario.

La guía de actualización de Cosmos SDK v0.54 documenta cambios relacionados con la configuración de la aplicación, la gobernanza, los hooks del ciclo de vida del módulo bank, Store v2, el registro de eventos, las dependencias de IBC y las funciones experimentales de rendimiento.

¿Qué es una blockchain específica para aplicaciones?

Una blockchain específica para aplicaciones es una red cuyas reglas a nivel de protocolo están diseñadas para una aplicación, un sector o un conjunto de casos de uso determinados.

Su funcionalidad principal se ejecuta como parte de la máquina de estados de la blockchain, en lugar de depender exclusivamente de contratos desplegados en una capa de ejecución compartida de propósito general.

Un equipo de desarrollo puede personalizar los tipos de transacción, los permisos de las cuentas, las comisiones, la selección de validadores, la emisión de tokens, las facultades de gobernanza y las estructuras de almacenamiento.

Este modelo puede reducir la dependencia de las reglas elegidas por una plataforma de aplicaciones compartida y no relacionada.

También atribuye a los desarrolladores y a la comunidad de la cadena una mayor responsabilidad en materia de seguridad del consenso, operaciones de los validadores, actualizaciones, diseño económico y mantenimiento de la infraestructura.

Una cadena específica para aplicaciones puede incorporar una máquina virtual si los desarrolladores quieren añadir contratos inteligentes programables a los módulos nativos.

¿Cómo funciona Cosmos SDK?

Una blockchain de Cosmos SDK se compone de un motor de ejecución, módulos de aplicación, almacenes de estado, gestores de transacciones e interfaces con un motor de consenso externo.

Los usuarios crean transacciones firmadas que incluyen uno o más mensajes que solicitan cambios de estado.

La red de consenso ordena las transacciones válidas en bloques y envía la información de los bloques a la aplicación.

La aplicación del SDK comprueba cada transacción, dirige sus mensajes a los módulos correspondientes, ejecuta las reglas de negocio pertinentes y actualiza el estado de la blockchain.

Todos los validadores honestos deben ejecutar las mismas transacciones ordenadas y generar el mismo hash del estado resultante de la aplicación.

La ejecución determinista es esencial, ya que los validadores no pueden ponerse de acuerdo sobre el estado de la blockchain si unas entradas idénticas producen resultados distintos.

Principales capas de una blockchain de Cosmos SDK

Consenso y red

El consenso y la red entre pares suelen estar a cargo de CometBFT, en lugar de implementarse directamente en cada módulo del SDK.

CometBFT ordena las transacciones, coordina las votaciones de los validadores, finaliza los bloques y se comunica con la aplicación a través de Application Blockchain Interface.

BaseApp

BaseApp es el motor de ejecución principal integrado en una aplicación de Cosmos SDK.

Gestiona la decodificación de transacciones, el middleware de firmas, el enrutamiento de mensajes, el cálculo del gas, las consultas, los hooks de bloque, la gestión del estado y la comunicación con el motor de consenso.

Módulos

Los módulos contienen lógica de aplicación especializada para funciones como cuentas, transferencias de tokens, staking, gobernanza y actualizaciones de software.

Almacenamiento del estado

Cada módulo almacena su estado en un espacio de nombres de clave-valor controlado dentro del multistore de la aplicación.

Interfaces de cliente

Las herramientas de línea de comandos, los servicios gRPC, los endpoints REST y otras interfaces permiten a las carteras, los nodos, los exploradores y las aplicaciones enviar transacciones o consultar el estado.

¿Qué es BaseApp?

BaseApp es el tipo de aplicación fundacional que coordina la ejecución de transacciones y la actividad de los módulos en una blockchain de Cosmos SDK.

La documentación oficial de BaseApp lo describe como el motor de ejecución que utilizan todas las cadenas de Cosmos SDK.

BaseApp implementa Application Blockchain Interface, que permite la comunicación entre la aplicación de blockchain y CometBFT.

Recibe solicitudes del motor de consenso, gestiona contextos de ejecución, enruta transacciones, coordina módulos y confirma el estado de la aplicación.

La configuración principal de la aplicación de una cadena crea BaseApp y lo conecta con módulos, keepers, almacenes, middleware y hooks del ciclo de vida.

BaseApp proporciona infraestructura compartida para que cada equipo de blockchain no tenga que crear su propio enrutador de transacciones, medidor de gas, caché de estado o sistema de hooks de bloque.

¿Qué es ABCI?

ABCI son las siglas de Application Blockchain Interface.

Es el protocolo mediante el cual el motor de consenso se comunica con la aplicación de blockchain.

ABCI separa el consenso y la red de la lógica específica de transición de estado de la aplicación.

CometBFT puede utilizar llamadas ABCI para inicializar la cadena, comprobar transacciones, finalizar bloques, confirmar el estado y obtener actualizaciones del conjunto de validadores.

Esta separación permite a los desarrolladores centrarse en las reglas de la aplicación y utilizar un motor de consenso probado para la producción de bloques y la finalidad.

La arquitectura simplificada es: CometBFT, ABCI, BaseApp, módulos y estado de la aplicación.

¿Qué es CometBFT?

CometBFT es un motor de consenso tolerante a fallos bizantinos que se utiliza habitualmente con aplicaciones de Cosmos SDK.

Gestiona la red entre pares, la propagación de transacciones, las propuestas de bloques, los votos de los validadores y la finalización de bloques.

Cosmos SDK y CometBFT realizan funciones distintas, aunque suelen desplegarse juntos.

CometBFT determina el orden final de las transacciones, mientras que la aplicación de Cosmos SDK determina qué hacen esas transacciones.

Un fallo en la lógica de la aplicación puede producir resultados no deseados aunque el motor de consenso funcione correctamente.

Por tanto, una cadena segura necesita tanto una configuración de consenso fiable como código de aplicación determinista y seguro.

¿Qué son los módulos de Cosmos SDK?

Los módulos de Cosmos SDK son componentes reutilizables que gestionan áreas definidas de funcionalidad y estado de la blockchain.

Cada módulo puede definir mensajes, consultas, keepers, parámetros, datos génesis, eventos y operaciones del ciclo de vida de los bloques.

La guía oficial sobre la arquitectura de módulos explica cómo los módulos aíslan el estado y proporcionan interfaces controladas para la interacción entre módulos.

Un equipo de desarrollo puede incluir módulos estándar, modificar la configuración de la aplicación o crear módulos personalizados.

Los módulos permiten mantener organizada una blockchain a medida que incorpora nuevas funciones.

La modularidad no significa que se pueda añadir cualquier módulo sin realizar tareas de compatibilidad, seguridad o migración.

Módulos habituales de Cosmos SDK

Módulo Auth

El módulo

define los tipos básicos de cuentas y transacciones, y admite la autenticación básica de transacciones.

Participa en las comprobaciones de firmas, secuencias de cuentas, comisiones y otros requisitos de las transacciones.

La especificación del módulo de autenticación explica que las cuentas incluyen información utilizada para claves públicas, direcciones, números de cuenta y protección contra la repetición basada en secuencias.

Módulo Bank

El módulo

gestiona saldos de monedas de varios activos, transferencias, información sobre la oferta y restricciones aplicables a determinados movimientos de tokens.

Otros módulos pueden utilizar interfaces controladas de bank-keeper cuando necesiten acuñar, quemar, transferir o consultar saldos.

La documentación del módulo bank describe sus funciones de gestión de saldos y transferencias de activos múltiples.

Módulo Staking

El módulo

proporciona funciones Proof of Stake relacionadas con validadores, delegaciones, desvinculación, redelegación y actualizaciones del conjunto de validadores.

Módulo Slashing

El módulo

puede penalizar faltas de los validadores, como periodos prolongados de inactividad o firmas de bloques incompatibles, conforme a los parámetros de la cadena.

Módulo Distribution

El módulo

permite distribuir las comisiones de transacción y otras recompensas entre validadores, delegadores y recursos comunitarios designados.

Módulo Governance

El módulo

permite presentar propuestas on-chain, realizar depósitos y votaciones, contar votos y ejecutar de forma autorizada los mensajes de propuestas aprobadas.

Módulo Mint

El módulo

puede gestionar la emisión de tokens definida por el protocolo conforme a las reglas económicas configuradas para la aplicación.

Módulo Upgrade

El módulo

coordina las actualizaciones de software programadas y las migraciones de estado en alturas de bloque definidas.

Módulo Authorization

El módulo

permite que una cuenta conceda a otra autoridad limitada para ejecutar en su nombre determinados tipos de mensajes.

Módulo Fee Grant

El módulo

permite que una cuenta pague las comisiones de transacción de otra conforme a las asignaciones configuradas.

¿Qué es un keeper?

Un keeper es la capa de acceso al estado y de lógica de negocio de un módulo de Cosmos SDK.

Proporciona métodos tipados para leer y escribir los datos del módulo.

Los campos del almacén subyacente de un módulo suelen mantenerse privados para que el código externo no pueda modificar directamente su estado.

Los servidores de mensajes y consultas, así como los hooks de bloque, llaman a los métodos del keeper para interactuar con el estado.

Los demás módulos solo reciben las interfaces y capacidades de keeper que la aplicación les proporciona expresamente.

Este modelo aclara las dependencias entre módulos y reduce el acceso sin restricciones al estado compartido de la blockchain.

Una interfaz de keeper mal diseñada puede seguir exponiendo facultades peligrosas, por lo que deben revisarse cuidadosamente los límites de capacidades.

¿Cómo se comunican los módulos de Cosmos SDK?

Los módulos se comunican mediante interfaces de keeper definidas expresamente, en lugar de modificar directamente los almacenes de otros módulos.

El módulo staking puede llamar a un método aprobado de bank-keeper cuando haya que mover tokens vinculados entre cuentas de módulos.

El módulo governance puede llamar a un método autorizado para actualizar parámetros después de aprobarse una propuesta.

El módulo receptor sigue siendo responsable de aplicar sus propias reglas de estado.

Las interfaces explícitas facilitan las pruebas y auditorías de las facultades entre módulos.

Las dependencias circulares y los permisos excesivos pueden dificultar el mantenimiento y la seguridad de una aplicación.

¿Cómo se almacena el estado?

Cosmos SDK almacena el estado de la aplicación como pares clave-valor en almacenes específicos para cada módulo.

Las claves y los valores se representan en bytes, mientras que los módulos codifican y decodifican los datos estructurados mediante reglas de serialización definidas.

La guía de estado y almacenamiento de Cosmos SDK explica que los almacenes de los módulos se montan dentro de un multistore y se confirman conjuntamente.

Cada módulo controla su propio espacio de nombres y normalmente accede a él mediante una clave de almacén tipada y un keeper.

Al finalizar un bloque, la aplicación calcula una raíz de estado que representa el estado combinado de todos los módulos.

La raíz de estado se devuelve al motor de consenso y se incluye en el historial confirmado de la blockchain.

¿Qué es el multistore de Cosmos SDK?

El multistore es un contenedor que coordina los almacenes de estado independientes utilizados por los módulos de la aplicación.

Cada módulo puede mantener un espacio de claves independiente, mientras que todos los cambios de los módulos se confirman bajo una única raíz de estado de la aplicación.

Este diseño separa los datos de los módulos sin crear una blockchain independiente para cada uno.

La ejecución de transacciones puede utilizar un estado en caché para descartar los cambios de mensajes fallidos antes de actualizar el estado subyacente.

La implementación del almacén y la configuración de la base de datos pueden afectar al rendimiento de los nodos, la poda, las instantáneas y los requisitos de migración.

Cosmos SDK v0.54 introdujo cambios en los paquetes de Store v2 que requieren una migración cuidadosa al actualizar las aplicaciones.

¿Qué es el estado génesis?

El estado génesis es el estado inicial desde el que comienza una nueva blockchain.

Suele representarse en un fichero

que contiene la configuración de la cadena y sus módulos.

Los datos génesis pueden definir las cuentas iniciales, los saldos de tokens, los validadores, los parámetros de los módulos y otros registros iniciales.

Durante la inicialización de la cadena, BaseApp ejecuta la lógica génesis de cada módulo para validar y completar su estado.

Todos los nodos deben partir de datos génesis compatibles; de lo contrario, no calcularán el mismo estado de la blockchain.

Los errores en la oferta inicial de tokens, las direcciones, las claves de los validadores o los parámetros pueden requerir una corrección coordinada antes del lanzamiento de la red.

¿Cómo funcionan las transacciones de Cosmos SDK?

Una transacción de Cosmos SDK es una estructura de datos firmada que contiene uno o más mensajes, información de autenticación, un límite de gas y comisiones de transacción.

Cada mensaje representa una acción solicitada, como transferir tokens, delegar staking, votar o llamar a una función de un módulo personalizado.

El usuario firma la transacción con una clave privada asociada a la cuenta emisora.

Un nodo decodifica los bytes enviados y comprueba si la transacción cumple los requisitos del mempool.

Una vez que el consenso incluye la transacción en un bloque, BaseApp ejecuta su middleware de autenticación y dirige cada mensaje al gestor correspondiente.

Los gestores que se ejecutan correctamente actualizan el estado del módulo y emiten eventos que las aplicaciones externas pueden indexar.

Ciclo de vida de una transacción de Cosmos SDK

Creación de la transacción

Una cartera o aplicación crea los mensajes y añade la información de cuenta, comisiones, gas, cadena y firma.

Firma

El titular de la cuenta firma los bytes de firma definidos con la clave privada autorizada de la cuenta.

Difusión

La transacción codificada se envía a un nodo a través de una interfaz de cliente compatible.

CheckTx

Antes de admitir la transacción en su mempool, el nodo realiza comprobaciones preliminares de firmas, números de secuencia, comisiones, precio del gas y formato de la transacción.

Ordenación por consenso

Los validadores utilizan el proceso de consenso para acordar un bloque que contiene un conjunto ordenado de transacciones.

Ejecución de AnteHandler

BaseApp ejecuta el middleware previo a los mensajes para la autenticación, la gestión de secuencias, las comisiones y la configuración del gas.

Ejecución de mensajes

Cada mensaje se dirige, según su URL de tipo, al servidor de mensajes del módulo correspondiente.

Procesamiento posterior

La aplicación puede configurar gestores posteriores para ejecutar lógica tras el procesamiento de los mensajes.

Confirmación del estado

Las transiciones de estado que se completan correctamente contribuyen a la nueva raíz de estado de la aplicación confirmada para el bloque.

¿Qué es AnteHandler?

AnteHandler es un middleware que se ejecuta antes de que se procesen los mensajes de una transacción.

Puede validar firmas, comprobar las secuencias de las cuentas, deducir comisiones, establecer un medidor de gas y aplicar condiciones de transacción específicas de la aplicación.

Si AnteHandler rechaza una transacción, sus mensajes no se ejecutan.

Según la documentación actual de BaseApp, las comisiones y las actualizaciones de secuencia realizadas durante un procesamiento previo satisfactorio pueden quedar confirmadas incluso si falla la ejecución posterior de los mensajes.

Esto significa que un usuario puede pagar una comisión de transacción aunque la acción cripto solicitada no se complete correctamente.

La lógica personalizada de AnteHandler debe ser determinista en todos los validadores.

¿Qué es un mensaje de Cosmos SDK?

Un mensaje es una solicitud estructurada para realizar una transición de estado específica.

Algunos ejemplos son enviar tokens, crear un validador, delegar staking, presentar una propuesta de gobernanza o modificar datos personalizados de la aplicación.

Cada tipo de mensaje tiene campos definidos, reglas para los firmantes, requisitos de validación y un método asociado en el servidor de mensajes.

BaseApp dirige los mensajes según sus URL de tipo registradas.

Las aplicaciones pueden incluir varios mensajes en una transacción.

Por lo general, los cambios de estado de los mensajes son atómicos: si falla un mensaje, se impide que se confirmen parcialmente las escrituras de mensajes de la transacción.

¿Qué son las consultas?

Las consultas leen el estado de la blockchain sin solicitar una transición de estado.

Una cartera puede consultar saldos, posiciones de staking, propuestas de gobernanza, parámetros de módulos e información relacionada con las transacciones.

Los módulos de Cosmos SDK suelen exponer servicios de consulta gRPC que BaseApp dirige al servidor de consultas correspondiente.

Las consultas no pasan por el AnteHandler habitual de las transacciones ni deducen una comisión de transacción de blockchain del mismo modo.

El resultado de una consulta puede variar entre nodos si estos muestran alturas de bloque diferentes o no disponen de un historial completo.

Cuando estos detalles afectan al resultado, las aplicaciones deben identificar la cadena consultada, la altura del bloque y la fuente de datos.

¿Qué es el gas en Cosmos SDK?

El gas es una medida utilizada para limitar los recursos de cálculo y almacenamiento que consume la ejecución de una transacción.

Operaciones como verificar firmas, leer o escribir el estado y procesar los bytes de una transacción pueden consumir gas.

Una transacción declara un límite de gas que representa la cantidad máxima de gas que autoriza para su ejecución.

Una transacción que agote su límite de gas falla, aunque el mensaje subyacente fuera válido.

Los calendarios y costes de gas pueden variar entre cadenas de Cosmos SDK, ya que la aplicación controla parámetros importantes y detalles de implementación.

¿Cómo se calculan las comisiones de transacción de Cosmos SDK?

Una fórmula simplificada calcula la comisión multiplicando el límite de gas por el precio del gas seleccionado.

Comisión de transacción = límite de gas × precio del gas

Una transacción con un límite de gas de 200,000 y un precio de gas de 0.025 unidades por gas tiene una comisión de 5,000 unidades mínimas del token.

Comisión de transacción = 200,000 × 0.025 = 5,000

Los validadores pueden configurar precios mínimos del gas para filtrar las transacciones enviadas a sus nodos.

Una transacción cuya comisión sea inferior al mínimo de un nodo puede rechazarse antes de entrar en el mempool de ese nodo.

La comisión mostrada debe indicar la denominación del token y su conversión decimal.

Cuentas de Cosmos SDK

Una cuenta de Cosmos SDK suele incluir una dirección, un número de cuenta, un número de secuencia y datos de clave pública cuando esta se ha revelado on-chain.

El número de secuencia ayuda a impedir que se vuelva a reproducir reiteradamente la misma transacción firmada.

El envío de transacciones con una secuencia desactualizada puede provocar su rechazo.

Las aplicaciones pueden definir tipos de cuenta distintos de la cuenta básica si necesitan funciones de vesting, multifirma, permisos u otras funciones especializadas.

La dirección de una cuenta no demuestra la identidad legal de la persona u organización que controla su clave privada.

Perder la clave privada o el método de recuperación puede provocar una pérdida permanente del control si no existe otro sistema de autorización.

Formatos de dirección de Cosmos SDK

Las cadenas de Cosmos SDK suelen mostrar direcciones codificadas en Bech32 con un prefijo legible específico de la cadena.

El prefijo ayuda a distinguir en las interfaces legibles las direcciones de cuenta, de validador y de consenso.

Dos cadenas pueden mostrar direcciones distintas a partir de material de clave relacionado porque utilizan prefijos o reglas de dirección diferentes.

El prefijo por sí solo no demuestra que una dirección pertenezca a la blockchain o al destinatario previsto.

Antes de transferir criptomonedas, los usuarios deben comprobar el ID de la cadena, el tipo de dirección, el destino completo y la ruta del activo admitida.

Staking en Cosmos SDK

El módulo staking de Cosmos SDK permite que las cadenas mantengan un sistema de validadores Proof of Stake.

Los titulares de tokens nativos pueden delegar tokens de staking a los validadores conforme a las reglas de la cadena.

La selección de validadores puede determinarse según el poder de voto vinculado y los límites configurados para el conjunto de validadores.

La especificación de staking de Cosmos SDK define las transiciones de estado de validadores, delegaciones, desvinculación, redelegación y conjunto de validadores.

El módulo utiliza participaciones de delegación como mecanismo contable para el conjunto de tokens delegados a cada validador.

Los parámetros de staking, como la denominación del bono, el límite de validadores, el periodo de desvinculación y los registros históricos, los selecciona cada cadena.

Validadores y delegadores

Un validador opera infraestructura que participa en las propuestas de bloques, las votaciones y las tareas de consenso cuando forma parte del conjunto activo de validadores.

Un delegador asigna poder de staking a un validador sin necesidad de operar la infraestructura de validación.

Los validadores pueden cobrar comisiones sobre las recompensas distribuidas a sus delegadores.

Los delegadores siguen expuestos al rendimiento del validador, los cambios de comisiones, el slashing, las demoras de desvinculación, la volatilidad del token y el riesgo del protocolo.

La delegación no transfiere la propiedad como lo haría una venta ordinaria de tokens, pero los tokens quedan sujetos a las reglas del módulo de staking.

Los derechos y riesgos concretos dependen de la configuración de la aplicación de la cadena.

Desvinculación y redelegación

La desvinculación inicia el proceso de retirar una delegación del staking.

Es posible que los tokens no puedan transferirse durante el periodo de desvinculación establecido por la cadena.

También pueden seguir expuestos a sanciones por conductas del validador que reúnan los requisitos y se hayan producido mientras estaban vinculados.

La redelegación traslada la exposición de staking de un validador a otro conforme a las reglas del protocolo.

El módulo de staking registra las redelegaciones inmaduras para reducir los intentos de eludir sanciones mediante cambios repetidos de validador.

Las interfaces de las carteras deben mostrar los plazos de finalización y las restricciones, en lugar de presentar la desvinculación como una retirada inmediata.

Slashing en Cosmos SDK

El slashing es una sanción del protocolo que puede reducir el valor en staking o excluir a un validador de la participación activa en el consenso.

La especificación de slashing de Cosmos SDK abarca la supervisión de la actividad de los validadores, su puesta en cuarentena, las firmas incompatibles y el comportamiento de tombstoning.

Una cadena puede configurar las sanciones y los requisitos relativos a los bloques omitidos mediante sus parámetros.

Los delegadores pueden compartir las pérdidas derivadas del slashing, ya que sus tokens contribuyen al stake del validador.

Un validador puede quedar en cuarentena temporalmente por incumplimientos de actividad definidos.

Las faltas graves de consenso pueden dar lugar a sanciones más severas y restricciones permanentes conforme a las reglas de la cadena.

Gobernanza en Cosmos SDK

El módulo de gobernanza permite a los participantes que cumplan los requisitos presentar propuestas y votar sobre decisiones de la blockchain.

Una propuesta puede contener uno o más mensajes ejecutables y no limitarse a una recomendación textual informal.

Entre las posibles acciones de gobernanza se incluyen cambiar parámetros de módulos, gastar recursos comunitarios designados o programar actualizaciones de software.

El proceso de propuestas puede incluir un periodo de depósito, un periodo de votación, un requisito de cuórum, un umbral de aprobación y un umbral de veto.

Cada cadena puede configurar sus reglas de gobernanza de manera distinta.

La aprobación on-chain no puede obligar a los validadores a ejecutar software defectuoso o no disponible, por lo que las actualizaciones importantes también requieren coordinación operativa.

Autorización en Cosmos SDK

El módulo de autorización permite que un otorgante autorice a un beneficiario a ejecutar determinados mensajes en su nombre.

La documentación oficial de autorización de Cosmos SDK describe las concesiones como permisos asociados a tipos de mensaje específicos.

Una concesión puede ser amplia o estar restringida mediante una lógica de autorización personalizada.

Una autorización para enviar tokens puede incluir un límite de gasto y una lista opcional de destinos aprobados.

Antes de crear una concesión, los usuarios deben revisar el tipo de mensaje permitido, la fecha de expiración, los límites de gasto y las restricciones de destinatarios.

Una cuenta autorizada que se vea comprometida puede hacer un uso indebido de todas las acciones que permita una concesión activa.

Actualizaciones de software de Cosmos SDK

Las actualizaciones de software de una blockchain pueden cambiar la lógica de los módulos, los formatos de almacenamiento, las interfaces y el comportamiento relacionado con el consenso.

El módulo

permite a una cadena programar un plan de actualización para una altura de bloque determinada.

La especificación del módulo upgrade explica cómo las propuestas de gobernanza pueden programar o cancelar planes de actualización.

Los operadores de nodos deben instalar el binario compatible correcto antes de que entre en vigor la actualización programada.

Un gestor de actualización puede ejecutar migraciones de módulos y transformar los datos almacenados al formato que requiere el nuevo software.

Una coordinación deficiente puede interrumpir la producción de bloques o dividir a los operadores entre versiones incompatibles.

Cosmos SDK e IBC

IBC es un protocolo que permite a blockchains compatibles verificar e intercambiar datos entre cadenas.

Una cadena de Cosmos SDK puede integrar módulos IBC para admitir transferencias de tokens, cuentas entre cadenas, mensajes de contratos y otras aplicaciones intercadena.

La documentación oficial de IBC-Go explica que las cadenas habilitadas para IBC pueden intercambiar datos codificados en bytes a través de conexiones de protocolo sin permisos.

IBC no se limita a cadenas creadas con Cosmos SDK, aunque la implementación en Go suele integrarse en aplicaciones del SDK.

Desde IBC-Go v10, IBC Classic e IBC v2 existen como versiones de protocolo independientes dentro de la familia de versiones.

Una conexión utiliza el protocolo y los módulos de aplicación compatibles con ambos sistemas participantes.

¿Cómo funciona una transferencia de tokens IBC?

Una transferencia de tokens IBC comienza cuando un usuario envía una solicitud de transferencia en la cadena de origen.

La aplicación de origen mantiene en depósito o quema la representación correspondiente, conforme a la ruta de transferencia del activo.

Se confirma un paquete con los datos de la transferencia y, posteriormente, se retransmite a la cadena de destino.

La cadena de destino verifica la prueba requerida y crea o libera la representación correspondiente del activo.

Los relayers transportan los datos de los paquetes y las pruebas, pero no tienen que ser de confianza para modificar el contenido válido de los paquetes.

Los usuarios siguen expuestos a riesgos de selección de canal, seguimiento del activo, liquidez, aplicación, cliente, consenso y cadena receptora.

¿Cosmos SDK admite contratos inteligentes?

Cosmos SDK se centra en los módulos nativos de blockchain, pero puede ampliarse con una máquina virtual para ejecutar contratos inteligentes.

Esto permite combinar módulos a nivel de protocolo con aplicaciones programables desplegadas por los usuarios.

Un equipo de desarrollo puede elegir una máquina virtual según los requisitos de lenguaje, compatibilidad, rendimiento y seguridad.

La compatibilidad con contratos inteligentes no se habilita automáticamente en todas las aplicaciones de Cosmos SDK.

Añadir una máquina virtual amplía la funcionalidad, pero también aumenta la superficie de ataque y la complejidad operativa de la aplicación.

Cosmos SDK frente a los contratos inteligentes

Un módulo de Cosmos SDK se ejecuta como lógica nativa de la aplicación incluida en el software de blockchain que utilizan los validadores.

Un contrato inteligente se ejecuta dentro de una máquina virtual proporcionada por una aplicación de blockchain existente.

Los módulos nativos pueden acceder a hooks a nivel de protocolo e interfaces de estado estrechamente integradas.

Los contratos inteligentes suelen poder desplegarse sin que todos los validadores tengan que instalar un nuevo binario de la cadena.

Actualizar la lógica de los módulos nativos suele requerir una actualización coordinada de la cadena.

El modelo más adecuado depende de si la función necesita control a nivel de protocolo, despliegue sin permisos, ejecución aislada o iteraciones rápidas de la aplicación.

Cosmos SDK frente a Cosmos Hub

Cosmos SDK es un software utilizado para crear blockchains, mientras que Cosmos Hub es una blockchain concreta creada con la pila tecnológica de Cosmos.

El SDK no cuenta con una única criptomoneda nativa que deban compartir todas las cadenas.

Cada aplicación de Cosmos SDK puede definir sus propias denominaciones de tokens, reglas de oferta, activo de staking y política de comisiones.

Una decisión de gobernanza de una cadena independiente no controla automáticamente todas las demás cadenas basadas en el SDK.

Los desarrolladores no deben considerar los parámetros de Cosmos Hub como valores predeterminados universales de Cosmos SDK.

Ventajas de Cosmos SDK

Los componentes modulares pueden reducir la cantidad de código fundacional de blockchain que un equipo debe desarrollar por su cuenta.

La arquitectura específica para aplicaciones da a los desarrolladores control sobre la lógica del protocolo, las comisiones, los permisos, la gobernanza y la economía de los tokens.

Los límites del estado de los módulos y las interfaces de keeper pueden facilitar la comprensión y auditoría de las facultades.

La compatibilidad nativa con IBC puede proporcionar una comunicación estandarizada entre cadenas.

El framework admite tanto módulos predefinidos como lógica de aplicación personalizada.

El código de código abierto, la documentación, las herramientas de prueba y el uso existente en producción pueden facilitar el desarrollo y la revisión.

Estas ventajas no eliminan la necesidad de un diseño seguro, auditorías, pruebas, operaciones de validadores y análisis económico.

Limitaciones de Cosmos SDK

Lanzar una cadena independiente requiere validadores, nodos, monitorización, actualizaciones, gobernanza y mantenimiento a largo plazo.

Una nueva red debe desarrollar una seguridad económica o basada en permisos suficiente para su modelo de amenazas.

Los módulos personalizados pueden contener defectos graves de lógica, autorización o migración de estado.

Las actualizaciones de módulos y dependencias pueden introducir cambios incompatibles en la configuración de la aplicación.

La conectividad entre cadenas añade riesgos relacionados con clientes, relayers, enrutamiento y cadenas de destino.

La flexibilidad de una arquitectura específica para aplicaciones puede generar complejidad, ya que dos cadenas basadas en el SDK pueden utilizar parámetros y módulos muy distintos.

Los usuarios no deben dar por sentado que todas las cadenas creadas con el framework tienen la misma seguridad, descentralización o protección de activos.

Seguridad de Cosmos SDK

La seguridad depende de la versión del SDK, el código personalizado de la aplicación, la configuración del consenso, la infraestructura de los validadores, la gestión de claves, la gobernanza y los protocolos conectados.

Todas las transiciones de estado deben ser deterministas y validarse frente a entradas no autorizadas.

Los keepers solo deben exponer las capacidades que necesitan otros módulos.

Las autoridades administrativas, las claves de actualización, las facultades de gobernanza y los controles de emergencia deben documentarse y probarse.

Los desarrolladores deben utilizar dependencias compatibles, revisar los avisos de seguridad, ejecutar simulaciones, probar migraciones y solicitar auditorías independientes para las aplicaciones de gran valor.

La página de auditorías de Cosmos Stack incluye enlaces a revisiones de seguridad publicadas de los componentes principales.

La política de recompensas por errores de Cosmos Stack ofrece un proceso coordinado para comunicar vulnerabilidades de forma privada.

Riesgos de seguridad habituales de Cosmos SDK

Ejecución no determinista

El código que depende de la hora local, de una iteración impredecible, de servicios externos o de un comportamiento numérico incoherente puede hacer que los validadores calculen estados distintos.

Errores de permisos de keeper

Una interfaz de keeper demasiado amplia puede permitir que un módulo realice cambios no autorizados en otro módulo.

Autorización incorrecta de mensajes

Un gestor de mensajes puede provocar cambios de estado no autorizados si no verifica el firmante o la autoridad correctos.

Errores génesis

Los saldos no válidos, los registros duplicados, los datos incorrectos de los validadores o los parámetros inseguros pueden comprometer una cadena antes de su primer bloque.

Fallos de actualización

Una lógica de migración incorrecta puede corromper el estado o impedir que los nodos se reinicien en la altura de bloque prevista para la actualización.

Fallos de diseño económico

El software puede funcionar según lo previsto y, aun así, los incentivos, la inflación, las reglas de colateral o los umbrales de gobernanza inseguros pueden causar pérdidas económicas.

Compromiso de claves de validador

El robo o la configuración incorrecta de las claves de validador pueden interrumpir las operaciones o provocar comportamientos de consenso que pueden ser sancionados mediante slashing.

Vulnerabilidades en dependencias

Una cadena puede heredar vulnerabilidades de seguridad de dependencias obsoletas del SDK, el consenso, IBC, la criptografía, la base de datos o la red.

Cómo crear una blockchain con Cosmos SDK

Definir el propósito de la cadena

El equipo debe definir los usuarios, los activos, los tipos de transacciones, los supuestos de seguridad, la estructura de gobernanza y los requisitos regulatorios.

Seleccionar una versión del SDK

La aplicación debe partir de una rama de versiones con soporte y fijar dependencias compatibles.

Elegir módulos estándar

El equipo puede seleccionar módulos para cuentas, transferencias, staking, gobernanza, recompensas, autorización y actualizaciones.

Desarrollar módulos personalizados

Los módulos personalizados pueden definir mensajes, keepers, consultas, eventos, parámetros, lógica de génesis y hooks del ciclo de vida.

Configurar la integración de la aplicación

Los almacenes, keepers, dependencias entre módulos, middleware, servicios de mensajes, servicios de consulta y el orden de los hooks deben conectarse correctamente.

Definir el estado génesis

El estado inicial de la cadena debe generarse, validarse, revisarse y distribuirse de forma coherente entre los operadores de nodos.

Probar el determinismo y las transiciones de estado

Las pruebas unitarias, las pruebas de integración, las simulaciones, las pruebas fuzz y las redes de prueba con varios nodos pueden revelar problemas de lógica y de consenso.

Revisar la seguridad

Los módulos de alto riesgo, los permisos, la emisión de tokens, las actualizaciones y las integraciones entre cadenas deben someterse a una revisión de seguridad específica.

Lanzar una red de prueba

Una red de prueba permite a los operadores y desarrolladores practicar con el estado génesis, las transacciones, los cambios de validador, los fallos y las actualizaciones.

Coordinar el lanzamiento en producción

Los validadores deben utilizar binarios, archivos de génesis, configuración de red y procedimientos operativos compatibles.

Desarrollo de módulos de Cosmos SDK

Un módulo personalizado suele definir su modelo de estado antes de implementar los mensajes de transacción.Los archivos Protocol Buffer pueden definir las estructuras de mensajes, consultas, génesis y datos.Un keeper proporciona acceso controlado al estado y lógica de negocio reutilizable.Un servidor de mensajes valida las solicitudes de transacción e invoca las operaciones del keeper.Un servidor de consultas proporciona acceso de solo lectura al estado del módulo.El módulo puede registrar servicios, interfaces, almacenes, gestores de génesis, migraciones y hooks de bloque en la aplicación.Los desarrolladores deben probar los estados fallidos y las llamadas no autorizadas, en lugar de probar únicamente las transacciones que se ejecutan correctamente.

Hooks del ciclo de vida del bloque

Los módulos de Cosmos SDK pueden ejecutar lógica definida en distintas fases de la ejecución de un bloque.La lógica PreBlock se ejecuta antes de BeginBlock y puede preparar el estado que necesita el bloque.La lógica BeginBlock se ejecuta cerca del inicio de la ejecución del bloque y puede realizar tareas programadas del módulo.A continuación, se procesan las transacciones en el orden acordado.La lógica EndBlock se ejecuta tras procesar las transacciones y puede preparar las actualizaciones de validadores o finalizar los cálculos del módulo.ModuleManager coordina el orden de los hooks, y un orden incorrecto puede provocar errores en la aplicación o estados inesperados.

Eventos e indexación

Los módulos de Cosmos SDK pueden emitir eventos durante la ejecución de transacciones y bloques.Los eventos pueden describir acciones como transferencias, delegaciones, votos, cambios de parámetros o actividades personalizadas de la aplicación.Los exploradores y sistemas de análisis pueden indexar estos eventos para ofrecer interfaces de usuario con funciones de búsqueda.Un evento es un resultado observable de la ejecución, no la fuente autoritativa del estado.Las aplicaciones deben consultar el estado confirmado cuando necesiten conocer el resultado canónico actual.Los campos de los eventos y las configuraciones de indexación pueden cambiar entre versiones de la aplicación.

Gobernanza y parámetros de Cosmos SDK

Los parámetros de un módulo son valores de configuración on-chain que controlan aspectos definidos de su funcionamiento.Por ejemplo, pueden incluir depósitos de gobernanza, límites de validadores, periodos de staking, ajustes de emisión y condiciones de slashing.Los parámetros suelen modificarse mediante un mensaje autorizado, no mediante una transacción de usuario ordinaria sin restricciones.Una cuenta del módulo de gobernanza puede actuar como autoridad para los mensajes de actualización de parámetros.Los desarrolladores deben validar cada nuevo valor de parámetro para evitar que la gobernanza sitúe accidentalmente el módulo en un estado no válido.La flexibilidad de los parámetros no debe sustituir a las actualizaciones explícitas del software cuando sea necesario cambiar la lógica subyacente de transición de estado.

Rendimiento de Cosmos SDK

El rendimiento depende de la lógica de la aplicación, la configuración de la base de datos, la complejidad de las transacciones, el hardware, las condiciones de la red, los ajustes de consenso y el tamaño del estado.Una transferencia sencilla no consume los mismos recursos que una transacción compleja que involucra varios módulos.Todos los validadores deben completar una ejecución determinista dentro de los tiempos previstos por la red.El crecimiento del estado puede aumentar con el tiempo los costes de almacenamiento, snapshots, sincronización y consultas.La medición de gas, la poda, los índices, la caché y una lógica eficiente en los keepers pueden afectar al rendimiento de los nodos.Cosmos SDK v0.54 incluye compatibilidad experimental con Block-STM para la ejecución paralela de transacciones, pero su adopción en producción requiere pruebas cuidadosas de compatibilidad y corrección.

¿Qué es Block-STM?

Block-STM es un método experimental de ejecución que intenta procesar en paralelo transacciones compatibles y, al mismo tiempo, conservar un resultado final determinista.

La documentación de Cosmos SDK sobre Block-STM describe la ejecución paralela optimista durante la finalización del bloque.

Es posible que las transacciones que acceden a estados en conflicto deban volver a ejecutarse o procesarse en un orden seguro.La ejecución paralela puede mejorar el rendimiento en cargas de trabajo independientes, pero ofrecer ventajas limitadas cuando la mayoría de las transacciones modifican el mismo estado.No deben activarse funciones experimentales únicamente porque una prueba de rendimiento muestre un mayor número de transacciones.

Operaciones de nodos de Cosmos SDK

Un nodo completo almacena el estado de la blockchain, se comunica con sus pares, valida bloques y ofrece las interfaces configuradas.Un nodo validador también gestiona las tareas de firma de consenso cuando su validador está activo.Los operadores deben proteger las claves privadas y las interfaces remotas, supervisar el uso del disco, instalar actualizaciones compatibles y mantener una conectividad de red fiable.Los servicios públicos de llamada a procedimiento remoto deben aplicar límites de solicitudes y controles de acceso adecuados a su modelo de amenazas.Las copias de seguridad deben proteger la configuración y los datos necesarios para la recuperación sin crear copias adicionales de las claves de firma activas.Un sistema de monitorización debe detectar bloques omitidos, fallos de procesos, pérdida de pares, agotamiento del espacio en disco, problemas de sincronización del estado y comportamientos anómalos de la aplicación.

Cómo evaluar una blockchain basada en Cosmos SDK

Confirma las versiones exactas de SDK, CometBFT, IBC y los módulos que utiliza la cadena.Revisa si la aplicación incluye módulos personalizados importantes o lógica controlada por administradores.Examina la distribución de validadores, la participación en el consenso, la concentración del staking y las prácticas de gestión de claves.Lee los parámetros de gobernanza de la cadena, el proceso de actualización y las facultades de emergencia.Identifica los modelos de activos nativos y puenteados, así como las autoridades capaces de acuñar, congelar o restringir tokens.Revisa las auditorías de seguridad, las vulnerabilidades divulgadas, la cobertura de pruebas y el historial de incidentes.Comprueba si las rutas, los clientes o las cadenas conectadas de IBC añaden supuestos de seguridad externos.El mero uso de Cosmos SDK no determina si una red cripto concreta es segura o adecuada para un usuario.

Malentendidos habituales sobre Cosmos SDK

Un malentendido habitual es pensar que Cosmos SDK es una blockchain, cuando en realidad es un framework para crear blockchains independientes.Otro malentendido es creer que todas las cadenas basadas en el SDK comparten el mismo conjunto de validadores.Normalmente, las cadenas independientes mantienen su propia seguridad y gobernanza, salvo que adopten un diseño específico de seguridad compartida.Algunos usuarios suponen que todos los activos de cadenas basadas en el SDK pueden transferirse automáticamente mediante IBC.Las transferencias de IBC requieren módulos compatibles, clientes activos, rutas válidas y relayers operativos.Otro error es asumir que los módulos estándar no pueden personalizarse mediante la lógica de la aplicación, los parámetros o la selección de versiones.Los usuarios también pueden confundir el token nativo de una cadena con el framework de software utilizado para crearla.

Preguntas frecuentes

¿Cuál es la definición más sencilla de Cosmos SDK?

Cosmos SDK es un framework de código abierto en Go para crear blockchains Layer 1 y libros mayores distribuidos personalizables.

¿Cosmos SDK es una blockchain?

No, es un software que se utiliza para crear blockchains, no una blockchain por sí mismo.

¿Cosmos SDK es una criptomoneda?

No. Cada aplicación creada con él puede definir sus propias reglas para criptomonedas y tokens.

¿Qué lenguaje de programación utiliza Cosmos SDK?

Cosmos SDK se desarrolla principalmente en Go.

¿Cuál es la última versión de Cosmos SDK?

El repositorio oficial identifica v0.54.3 como la última versión a julio de 2026.

¿Qué es BaseApp?

BaseApp es el motor de ejecución que conecta las llamadas de consenso con el procesamiento de transacciones, los módulos y el estado de la blockchain.

¿Qué es ABCI?

ABCI es la interfaz mediante la que un motor de consenso se comunica con la aplicación blockchain.

¿Qué es CometBFT?

CometBFT es un motor de consenso y red que se utiliza habitualmente para ordenar y finalizar transacciones en aplicaciones de Cosmos SDK.

¿Qué es un módulo de Cosmos SDK?

Un módulo es un componente de aplicación reutilizable responsable de una parte definida de la lógica y el estado de una blockchain.

¿Qué es un keeper?

Un keeper es la capa de acceso controlado al estado y de lógica de negocio de un módulo.

¿Pueden los desarrolladores crear módulos personalizados para Cosmos SDK?

Sí, los desarrolladores pueden crear módulos con mensajes, estados, consultas, parámetros, eventos y hooks del ciclo de vida personalizados.

¿Qué es el módulo bank?

El módulo bank gestiona saldos de criptomonedas, transferencias de múltiples activos, información sobre la oferta y determinadas restricciones de tokens.

¿Qué es el módulo auth?

El módulo auth define los tipos básicos de cuentas y transacciones y participa en la autenticación de transacciones.

¿Qué es el módulo staking?

El módulo staking gestiona validadores, delegaciones, periodos de desvinculación, redelegaciones y actualizaciones de validadores de Proof of Stake.

¿Qué es el módulo slashing?

El módulo slashing sanciona determinadas faltas de los validadores, como el tiempo de inactividad o las firmas de consenso incompatibles.

¿Qué es el módulo de gobernanza?

El módulo de gobernanza gestiona propuestas, depósitos, votaciones, recuentos y la ejecución autorizada de acciones aprobadas.

¿Qué es el módulo upgrade?

El módulo upgrade programa cambios de software coordinados y migraciones de estado en alturas de bloque definidas.

¿Qué es una transacción de Cosmos SDK?

Una transacción de Cosmos SDK es una estructura firmada que contiene mensajes, datos de autenticación de cuenta, un límite de gas y comisiones.

¿Qué es un mensaje en Cosmos SDK?

Un mensaje es una solicitud estructurada para que un módulo realice una transición de estado concreta en la blockchain.

¿Puede una transacción contener varios mensajes?

Sí, una transacción puede contener varios mensajes que se procesan en secuencia.

¿Qué ocurre cuando falla un mensaje?

Por lo general, las escrituras de estado de los mensajes se revierten de forma atómica, aunque pueden seguir aplicándose efectos del procesamiento previo, como las comisiones y los cambios de secuencia.

¿Qué es el AnteHandler?

AnteHandler es un middleware de preejecución que gestiona firmas, secuencias, comisiones, gas y otras comprobaciones de transacciones.

¿Qué es el gas en Cosmos SDK?

El gas mide y limita los recursos computacionales y de almacenamiento consumidos durante la ejecución de una transacción.

¿Cómo se calculan las comisiones de transacción?

Un cálculo simplificado consiste en multiplicar el límite de gas de la transacción por el precio del gas seleccionado.

¿Todas las cadenas de Cosmos SDK cobran las mismas comisiones?

No, las cadenas pueden utilizar distintos tokens para las comisiones, precios del gas, mínimos y políticas de comisiones.

¿Qué es el estado génesis?

El estado génesis es el conjunto inicial de datos de cuentas, tokens, validadores, parámetros y módulos a partir del cual comienza una nueva cadena.

¿Cosmos SDK es compatible con Proof of Stake?

Sí, sus módulos staking y slashing pueden admitir un sistema de validadores Proof of Stake configurable.

¿La delegación garantiza beneficios por staking?

No, las recompensas pueden variar y los delegadores están expuestos a la volatilidad del token, las comisiones, el tiempo de inactividad, el slashing y los riesgos del protocolo.

¿Qué es un periodo de desvinculación?

Es el plazo definido por la cadena que debe transcurrir antes de que los tokens elegibles que se han retirado del staking vuelvan a ser transferibles.

¿Pueden comunicarse entre sí las cadenas de Cosmos SDK?

Pueden hacerlo si implementan protocolos, aplicaciones, clientes y rutas de IBC compatibles.

¿Qué es IBC?

IBC es un protocolo para la comunicación verificada de datos entre blockchains independientes compatibles.

¿IBC requiere relayers de confianza?

Los relayers transportan datos, mientras que las cadenas receptoras verifican las pruebas del protocolo en lugar de confiar en que los relayers determinen cuál es el estado válido.

¿IBC elimina los riesgos entre cadenas?

No, los usuarios siguen expuestos a riesgos de aplicación, cliente, ruta, consenso, activos, liquidez y cadena de destino.

¿Cosmos SDK es compatible con contratos inteligentes?

Sí, una cadena puede incorporar una máquina virtual compatible para ejecutar contratos inteligentes.

¿Cuál es la diferencia entre un módulo y un contrato inteligente?

Un módulo funciona como lógica nativa de la cadena, mientras que un contrato inteligente se ejecuta en una máquina virtual proporcionada por la cadena.

¿Cosmos SDK es lo mismo que Cosmos Hub?

No, Cosmos SDK es un framework de desarrollo, mientras que Cosmos Hub es una blockchain creada con el stack de Cosmos.

¿Todas las cadenas de Cosmos SDK comparten validadores?

No, las cadenas independientes suelen operar con conjuntos de validadores separados, salvo que adopten deliberadamente un sistema de seguridad compartida.

¿Puede un token utilizar el mismo símbolo en distintas cadenas del SDK?

Sí, los símbolos no son únicos a escala global, por lo que los usuarios deben verificar la cadena, la denominación, el contrato y la ruta de transferencia.

¿Qué es Store v2?

Store v2 es el paquete de almacenamiento actualizado de Cosmos SDK, incluido en los requisitos de migración de v0.54.

¿Qué es Block-STM?

Block-STM es un sistema experimental para la ejecución paralela determinista de transacciones compatibles durante la finalización del bloque.

¿Todas las blockchains de Cosmos SDK son seguras?

No, la seguridad depende del código, el sistema de validadores, la configuración, la gobernanza, las dependencias, las operaciones y el diseño económico.

¿Puede haber vulnerabilidades en el código personalizado de Cosmos SDK?

Sí, los módulos personalizados pueden presentar defectos de autorización, contabilidad, determinismo, migración y diseño económico.

¿Cómo debe actualizarse una cadena de Cosmos SDK?

Los operadores deben revisar los cambios incompatibles, probar las migraciones, coordinar la altura de actualización e instalar binarios compatibles antes de la activación.

¿Qué deben comprobar los usuarios antes de utilizar una cadena basada en el SDK?

Los usuarios deben revisar sus versiones, validadores, gobernanza, módulos personalizados, controles de activos, auditorías, actualizaciones y dependencias entre cadenas.

¿Cuál es la principal ventaja de Cosmos SDK?

Su principal ventaja es la capacidad de ensamblar y personalizar la lógica blockchain a nivel de protocolo a partir de módulos reutilizables.

¿Cuál es la principal limitación de Cosmos SDK?

Su flexibilidad hace que cada cadena sea considerablemente responsable de proteger, operar, gobernar y actualizar su propia red, así como de garantizar su sostenibilidad económica.

Conclusión

Cosmos SDK es un framework de código abierto en Go para crear blockchains Layer 1 personalizables, libros mayores distribuidos y redes cripto específicas para aplicaciones.Proporciona módulos reutilizables para cuentas, transferencias de tokens, comisiones, staking, gobernanza, autorización, recompensas y actualizaciones de software.BaseApp coordina la ejecución de transacciones, las operaciones del ciclo de vida de los módulos, las consultas, el gas y el estado, y se comunica con un motor de consenso a través de ABCI.Los módulos aíslan su estado y ofrecen interfaces controladas de keeper para la lógica de negocio y la comunicación entre módulos.La integración de IBC permite a blockchains independientes compatibles intercambiar datos verificados y mantener sus propios estados de aplicación y gobernanza.La flexibilidad del SDK permite diseñar blockchains especializadas, pero no garantiza la seguridad, la descentralización, la interoperabilidad ni el éxito económico.Los desarrolladores deben probar cuidadosamente la ejecución determinista, los permisos de los keepers, el estado génesis, las migraciones, las operaciones de los validadores y los protocolos conectados.Los usuarios que evalúen una blockchain basada en Cosmos SDK deben analizar los módulos, parámetros, validadores, gobernanza, actualizaciones, controles de activos e historial de seguridad de esa red concreta, en lugar de juzgarla únicamente por el framework que utiliza.