Introducción al ecosistema

La red Cosmos no es una blockchain per se, sino que más bien se trata de un ecosistema en el que conviven varias blockchains interconectadas en simultáneo. Sobre Cosmos no se implementan dApps, sino que éstas son deployadas sobre las llamadas App-chains, las cuales son blockchains con casos de usos específicos que están construidas sobre Cosmos.

Por este motivo, es que Cosmos se conoce como un protocolo de Layer 0 centrado en escalabilidad horizontal, el cual provee la infraestructura de base para comunicar las blockchains construidas sobre éste. Por ejemplo, podemos encontrar L1s con diversos propósitos cómo NFTs, DeFi, infraestructura y demás

Cosmos desde su inicio tuvo y tiene una visión de un mundo multi-chain en donde múltiples blockchains soberanas se comunican entre sí. Para esto, cuenta con un conjunto de herramientas open-source que configuran el buque insignia de la red: el Cosmos SDK, Tendermint y el IBC.

Cosmos proporciona un framework para deployar blockchains sin necesidad de construirlas desde cero, el Cosmos SDK. Esto facilita la experiencia de desarrollo al contar con una base de construcción segura y probada.

El Cosmos SDK es un software modular que simplifica el proceso de creación de blockchains, llevando a que desarrollar y lanzar una nueva chain sea tan fácil como deployar un smart contract. El objetivo del Cosmos SDK es permitir a los desarrolladores crear fácilmente blockchains personalizadas desde cero que puedan ser interoperables de forma nativa con otras blockchains.

Tendermint es el mecanismo de consenso original de Cosmos basado en Proof of Stake.

Por su diseño, las blockchains que utilizan Tendermint cuentan con 150 validadores como tope máximo. Los 150 principales validadores con mayor voting-power de la red serán los encargados de producir nuevos bloques.

Tendermint soporta instant-finality, de modo que nunca se crean forks siempre y cuando más de ⅓ de los validadores sean honestos. Los usuarios pueden estar seguros que sus txs están finalizadas tan pronto como se añade un bloque a la red.

Hubs y Zones

El ecosistema de Cosmos cuenta con 2 grandes (y a la vez confusas) divisiones: Zones y Hubs.

Las Zones son blockchains de aplicaciones específicas, interoperables y que se conectan entre sí mediante el IBC, mientras que los Hubs son blockchains cuyo propósito es conectar Zones mientras limita la cantidad de conexiones y evita ataques de doble gasto entre Zones. En síntesis, los Hubs funcionan para interconectar Zones.

El rol de un Hub es facilitar las transferencias entre blockchains. Si una blockchain se conecta a un Hub a través del IBC, automáticamente va a tener acceso a todas las demás blockchains (Zones) que están conectadas a ella.

Una vez que una Zone crea una conexión mediante el IBC con un Hub, automáticamente tiene acceso a todas las demás zones que están conectadas a ese Hub.

Para Cosmos, por diseño cualquier blockchain es considerada una Zone (Ethereum, Bitcoin, Solana..), mientras que las blockchains que se construyen mediante el Cosmos SDK son consideradas App-Chains (Osmosis, Juno, Secret..)

Cada blockchain es responsable de su propia seguridad, por lo que las blockchains pueden fallar con más frecuencia ya que no comparten seguridad entre sí. Cada App-Chain cuenta con su propio conjunto de validadores asegurando la red, por lo que podemos entender a éstas como L1s independientes pero interconectadas. Cada una debe elegir el nivel de seguridad suficiente para su propósito.

Cosmos Hub

El Cosmos Hub es una blockchain independiente gobernada y asegurada por ATOM. No es posible desarrollar smart contracts sobre ésta, ya que su único propósito es actuar como intermediaria entre Zones.

El primer Hub del ecosistema de Cosmos fue el Cosmos Hub. Las denominaciones de ‘Cosmos’ y ‘Cosmos Hub’ pueden presentar confusiones, pero están claramente distinguidas. Podemos entender más fácilmente ‘Cosmos’ como una layer 0 en donde se encuentran montadas varias blockchains, mientras que el Cosmos Hub es una de esas blockchains sobre el Cosmos, el cual actúa como Hub para conectar las Zones.

Si bien el Hub por excelencia siempre fue considerado el Cosmos Hub por la seguridad que provee al contar con 188M de ATOM asegurando la red (~$1.7B) y actuar como puerta de entrada entre Cosmos → CEXs, en definitiva nada impide que cualquier otra Zone pueda convertirse en un Hub; pero esto es medido más que nada por consenso social de los usuarios.

Si todos optan por utilizar Osmosis como Hub, éste será el Hub principal en última instancia. De hecho, actualmente el mayor volúmen de transacciones entre Zones lo lidera Osmosis, con ~$370M intercambiados en 30 días por sobre los ~$180M del Cosmos Hub, por lo que podríamos considerar a Ósmosis como el Hub principal.

Valor de ATOM

ATOM es víctima de su propio éxito, siendo su mayor fortaleza a la vez su mayor debilidad.

Desde el inicio, el valor del ecosistema Cosmos nunca se vio reflejado en el precio de ATOM, ya que éste cuenta con un approach separatista por sobre las demás chains sobre Cosmos. La total libertad que trae Cosmos para construir sobre él conlleva a que ATOM no encuentre un valor específico para las App-chains o Zones.

Cada App-chain que se construye con el Cosmos SDK o cada Zone que se conecta mediante el IBC no le retribuye necesariamente valor a ATOM como criptomoneda, algo que está por modificarse con las próximas actualizaciones de la red.

Una serie de actualizaciones al ecosistema de Cosmos están por ser lanzadas en el corto/mediano plazo, siendo las más significativas:

1. Liquid Staking permitirá a los stakers/delegators de ATOM obtener un token líquido representando su porcentaje de participación, y podrá ser usado en el ecosistema de igual forma que sucede en Lido con <> stETH o RocketPool <> rETH.
2. Interchain Security: actualmente, cada App-Chain construida en Cosmos debe iniciar con su propio conjunto de validadores para asegurar la red. Para una nueva blockchain con baja liquidez y sin valor inicial para el token subyacente, es una tarea difícil generar suficiente stake para asegurar la red, volviéndola vulnerable.

Uno de los problemas al lanzar una nueva L1 PoS, en la que la seguridad está dada por el valor del token nativo, es que se vuelve vulnerable de ser atacada si no logra tomar valor al lanzarse al mercado. Pocos validadores y poco valor del token stakeado se traducen en una blockchain indefensa.

Con esta actualización, Interchain Security permitirá que todas las chains conectadas entre sí compartan la misma seguridad.

Este upgrade busca que los validadores del Cosmos Hub, también puedan ser validadores en otra blockchain (conocida como 'consumer chain') que se esté por lanzar o ya esté operativa (e.g. Ósmosis). Para esto, primero se debe presentar y aprobar una propuesta de gobernanza en Cosmos Hub.

Si bien inicialmente se piensa en que el Cosmos Hub sea la blockchain estándar para asegurar otras redes, cualquier chain dentro de Cosmos puede ser usada para asegurar alguna otra.

ICS permitirá que los validadores del Cosmos Hub también se encarguen de producir bloques para la ‘consumer chain’. Para esto, los validadores deben ejecutar 2 full nodes: el del Cosmos Hub y el de la consumer chain.

Mediante el IBC, se sincroniza el Hub <> consumer chain para que siempre estén en sintonía, por ejemplo slasheando a validadores malintencionados. En otras palabras, la consumer chain hereda la seguridad del Cosmos Hub al contar con los mismos validadores para las dos App-chains.

Governance

El staking o delegación de ATOM otorga derechos para participar en el proceso de gobernanza. Para contar con una participación en la votación de Cosmos, es necesario dejar en stake o delegar ATOM a un validador activo en la red, los que son bloqueados por 14 días una vez delegados. El voting power es determinado por la cantidad nominal de ATOM en stake/delegados.

Por otro lado, para publicar una propuesta en gobernanza y que sea válida para entrar en fase de votación, es necesario alcanzar un mínimo de 64 ATOM depositados. Éste mínimo no necesariamente debe ser depositado por el usuario que presenta la propuesta.

Para prevenir el spam, el mínimo de ATOM puede ser depositado totalmente por el usuario que presenta la propuesta, pero también otros usuarios que apoyen dicha propuesta pueden depositar sus ATOM en favor de la propuesta, hasta conseguir 64 ATOM entre todos los contribuyentes.

Si un usuario deposita ATOM en apoyo a la propuesta, podrá retirarlos una vez finalice el período de votación.
Los delegadores heredan el voto de los validadores en los que están delegados, a menos que emitan su propio voto, lo que anulará las decisiones de los validadores.

El mínimo de tokens necesarios debe ser alcanzado dentro de las 2 semanas posteriores a la presentación de la propuesta, de lo contrario la propuesta no será válida para ser votada. Si el mínimo requerido es alcanzado, la propuesta entra en fase de votación por otras 2 semanas. Durante esta fase, los ATOM holders pueden elegir 4 opciones para votar: Si, No, NoWithVeto y Abstain.

• NoWithVeto indica una oposición más fuerte a la propuesta que simplemente votar 'No'. Si el número de votos en 'NoWithVeto' es superior a ⅓ del total de votos, la propuesta se rechaza y los ATOM se queman, incluidos los tokens de los que contribuyeron a la propuesta. Esta opción de voto es básicamente para lidiar con el spam o si se considera que la propuesta es maliciosa.

Para que una propuesta sea aceptada y pase la votación, el umbral de votos a favor debe ser por lo menos del 50% durante 14 días, excluyendo los votos de abstención.

Los ATOM depositados son susceptibles de ser quemados cuando las propuestas:

• Expiran: los ATOM serán quemados si el período de depósito finaliza antes de alcanzar el mínimo necesario (64 ATOM)
• Quórum: es el porcentaje mínimo de poder de voto que debe emitirse sobre una propuesta para que el resultado sea válido. Para alcanzarlo, 40% de todos los ATOM en stake deben votar. Si la votación no alcanza quórum, los ATOM son quemados
• NoWithVeto: Si la propuesta alcanza el 33.4% del voting power.

En este ejemplo, si bien la propuesta #72 cuenta con ~80% de votos por Yes, todavía no alcanzó el quórum necesario para ser considerada válida, por lo que si al finalizar la votación sigue igual, los ATOM serán quemados.

IBC

Inter Blockchain Communication (o IBC) es un protocolo que permite a las blockchains que se conectan con éste comunicarse entre sí. Aunque técnicamente no es un bridge per se, ya que no solo transfiere tokens, sino que también puede leveragearse para transferencias de - data availability proofs, NFTs, slashing a validadores en otras Zones - podría pensarse como el bridge estándar que une a todo el ecosistema Cosmos. Actualmente 47 Zones están interconectadas mediante el IBC, llegando a tener un volumen máximo de $1B en 30 días.

Componentes del IBC:

• Clients:

Los clients son los encargados de verificar el light client* para otras blockchains. Éstos permiten que los clients de una blockchain verifiquen los headers de los bloques y los merkle proofs de otra blockchain con la misma seguridad que el light client de esa chain.

Los clients de una chain deben actualizarse continuamente con txs que contengan los headers y las firmas del validador de la otra chain. Éstos trackean el estado del consenso de las otras blockchains para asegurarse que no haya doble gasto o fraude en las transferencias, por lo que también trackean evidencias sobre la conducta de los validadores.

*Light client: es un client que descarga sólo los headers de los bloques, por lo que como el nombre indica, es más ligero que correr un full node el cual descarga el historial completo de la blockchain.

• Connections:

Una Connection es una relación persistente entre clients en dos chains diferentes (e.g Osmosis y Juno). Cuando dos chains quieren conectarse, cada una de ellas instala un client para la otra chain y después realiza lo que se llama un connection handshake, que es básicamente una conexión estable y continua entre las dos chains. Por lo que, si Osmosis y Juno quisieran establecer una Connection para conectarse por el IBC, Osmosis debería correr un client de Juno y viceversa

Las conexiones una vez establecidas, son responsables de facilitar todas las verificaciones cross-chain del estado del IBC. Es importante recalcar que en una sola Connection, pueden establecerse cualquier número de Channels.

• Channels:

Los channels son el punto donde la magia ocurre, es el lugar por donde efectivamente se transmiten los mensajes entre chains para la recepción de packets. Pueden haber varios channels abiertos sobre una sola Connection, pero lo más probable es que un solo channel sea mayormente utilizado para transferencias.

Por ejemplo, la Connection establecida entre Osmosis y Cosmos Hub cuenta con muchos channels abiertos, pero solamente el Channel 0 (Osmosis) <> Channel 141 (Cosmos Hub) es el que actualmente tiene uso. Los demás, no tienen volúmen alguno.

Si por el contrario, hubiese varios channels con volumen operando actualmente en vez de 1 solo, los tokens transferidos por los demás channels no serían fungibles entre sí, por lo que es lógico que solo se utilice un channel entre 2 blockchains.

Hoy en día, los channels solo pueden ser de ‘1-hop’, lo que significa que la transferencia de mensajes debe ser entre dos chains conectadas directamente (e.g. Osmosis → Cosmos Hub). Pero en un futuro, el IBC podrá soportar ‘múltiple-hops’ atómicos (en una sola tx) entre chains (e.g. Osmosis → Cosmos Hub → Juno), los que enrutarán las transferencias mediante el Cosmos Hub.

• Packets:

Los packets son los objetos/data enviados a través de los channels.

El único caso de uso de los packets hoy en día es la transferencia de tokens fungibles, permitiendo que los tokens se envíen de una chain a otra. El funcionamiento es casi el mismo que el de cualquier bridge actual, en donde los tokens se bloquean/desbloquean en una chain, y la representación de ese token lockeado en la otra chain se mintea/quema en la chain de destino.

Pero la transferencia de tokens fungibles es solo el comienzo de toda una gama de packets por implementarse!

Otro tipo de packet fue incluido recientemente en la última actualización de Cosmos - v7 Theta - la cual introduce el concepto de Inter-chain Accounts (ICA). ICA permite la creación de cuentas en una blockchain ‘Host’, que serán controladas por la misma cuenta pero en distinta blockchain, denominada ‘Controller’.

Con esto, por ejemplo, podremos manejar y ejecutar transacciones desde nuestra cuenta en Ósmosis, pero firmando una tx desde Juno, simplemente por el hecho de estar conectadas mediante el IBC. De esta forma, una wallet en el Cosmos Hub se vuelve universal para todas.

Juno incluyó en la propuesta #28 un upgrade para habilitar ICA en la red, convirtiéndose así en la primer blockchain en soportar esta actualización.

• Relayer:

El relayer es el responsable de ejecutar todo el proceso de transferencia. Funciona corriendo light clients de las chains conectadas, por lo que debe mantener ambos clients actualizados y rastrear el último estado de consenso de cada chain para que la verificación de las proofs enviadas sean válidas.

Correr un relayer es permissionless, pero por el momento no hay ningún incentivo para hacerlo ya que no pueden recibir fees, por lo que no cuentan con ganancias. Los únicos que cuentan con un incentivo para mantener los relayers son las App-chains que buscan incentivar el flujo de usuarios/liquidez entre todo el ecosistema.

Algunas consideraciones a tener en cuenta:

• Los relayers no pueden modificar los packets que reciben, porque la chain receptora verifica cada packet del IBC mediante light clients antes de confirmarlo en la chain que lo recibe.
• Los relayers no tienen acceso a los fondos. Lo único que pueden hacer es transferir las proofs a la chain de destino. Si no transportan éstas proofs dentro de los 100 bloques posteriores al submit de la tx: existe un timeout, por lo que se cancela la tx y los fondos vuelven a los usuarios originales.
• El único acto malicioso que podrían cometer es el de censurar txs, pero incluso en este caso, otro relayer podría tomar la proof y transmitirla hacia la chain de destino. Eventualmente, cualquier usuario podría correr su propio relayer y concluir la transferencia cross-chain, lo único que hace falta son incentivos.

Funcionamiento del IBC

Ejemplo: la blockchain A envía 10 tokens ATOM a la blockchain B

• Tracking: continuamente, la chain B recibe los headers de la chain A y viceversa. Esto permite que cada chain rastree el estado del consenso de los validadores de la otra
• Bonding: Cuando se inicia la transferencia IBC, los ATOM se bloquean en la chain A
• Proof Relay: una prueba de que los 10 ATOM están lockeados se transmite de la chain A a la chain B
• Validación: La prueba se verifica en la blockchain B contra el header de la chain A. Entonces, la chain B entiende que los ATOM están lockeados en la chain A porque recibió esa prueba, y mintea una representación de los activos bloqueados en la chain B.

Ahora, los tokens que se han creado en la chain B no son ATOM reales, ya que ATOM solo puede existir en la chain A. Lo que existe es una representación de ATOM en la chain B de la chain A, junto con una prueba de que estos ATOM están lockeados en la chain A.

Para volver a su chain de origen, se utiliza un mecanismo similar en donde se queman los wrapped ATOM y se desbloquean los ATOM en la chain original.

Peg-zones

Una característica única de Cosmos es que cualquier tipo de blockchain se puede conectar a su ecosistema, pero dependiendo del tipo de finality de la misma se requiere un paso extra. Por este motivo es que se le conoce como ‘Internet of Blockchains’

• Blockchains con Instant-finality

Las blockchains que cuentan con instant-finality en su mecanismos de consenso pueden fácilmente conectarse al Cosmos mediante el IBC. Por ejemplo: Solana, Polygon, Near y Polkadot son algunas chains compatibles que podrían conectarse sin mayores complicaciones.

• Blockchains con finality probabilística

Para conectar blockchains que no cuentan con instant-finality (e.g. Bitcoin, Ethereum) el mecanismo para conectarse al Cosmos requiere de un paso extra:

Una Peg-Zone es una blockchain que actúa como un bridge entre Cosmos y las blockchains que no tienen instant-finality, como las blockchains PoW. Por diseño la Peg-Zone sí cuenta con instant-finality y, por lo tanto, es compatible con el IBC. Su única función es la de actuar como intermediaria entre Cosmos y blockchains que no están conectadas al IBC.

Axelar y Gravity bridge

Actualmente existen 2 peg-zones que son activamente usadas en Cosmos: Axelar y Gravity bridge, los cuales funcionan casi de la misma forma salvo algunas diferencias en términos de eficiencia de gas en Ethereum. Los dos bridges son blockchains independientes que actúan como punto de acceso de otras blockchains EVM al ecosistema de Cosmos.

Los dos están bridges diseñados para atraer tokens ERC-20 de Ethereum a Cosmos y viceversa, con la diferencia que Axelar acepta redes EVM tales como Avalanche, Polygon, Fantom y Moonbeam, mientras que en Gravity bridge solo es posible conectarse directamente con Ethereum.

De esta forma, ATOM y todos los demás tokens del ecosistema Cosmos pueden ser tradeados en Uniswap y otros DEX de Ethereum.

El funcionamiento de los dos bridges es simple, ya que necesita haber un acuerdo entre los validadores que aseguran la red:

• Enviamos 50 Dai al contrato gravity.sol o AxelarGatewayProxyMultisig.sol en Ethereum, especificando nuestra address en Cosmos
• Los validadores en Cosmos de ven esto y mintean 50 Dai en la respectiva blockchain (Axelar o Gravity)
• Para volver a Ethereum o cualquier otra red que sea aceptada, los validadores queman los tokens que queramos transferir en Cosmos y envían una tx en la blockchain de destino especificando la cantidad de tokens a liberar.

La función principal de estos contratos en Ethereum es bloquear los tokens ERC-20, para que los tokens minteados en Cosmos estén respaldados 1-1.

Los validadores de las respectivas blockchains (Axelar y Gravity) controlan estos contratos, en proporción a su correspondiente voting-power en Cosmos. Entonces, para que una tx sea válida y aceptada, ésta debe contar con la firma de ⅔ del voting-power total de los validadores en Cosmos. Si un validador firma una actualización maliciosa, el stake que dejó en garantía en Cosmos le será removido, por lo que también será removido del bridge en Ethereum.

Para que los validadores tengan certeza de qué es lo que efectivamente está sucediendo en la blockchain de Ethereum, deben ejecutar un full node de esta red.

La diferencia sustancial entre éstos dos bridges la encontramos en la seguridad: Los contratos de Axelar en las redes EVM que soporta se tratan de una multisig 9/16 en la mayoría de los casos, con los respectivos poderes para actualizar el código del contrato.

Las multisig son controladas por los 16 principales validadores de la red medidos por voting-power, por lo que los firmantes van cambiando con el tiempo acorde cambia su voting-power. De coludir 9 de los 16 principales validadores de Axelar, la seguridad del bridge se vería comprometida.

No hace falta remontarnos mucho tiempo atrás para conocer los catastróficos desenlaces que tuvieron bridges controlados por multisig y lo frágil que pueden llegar a ser. Con una rápida búsqueda, ejemplos encontramos de sobra: Harmony bridge, comprometidas 2 pks de 5, pero sin dudas el más sangriento fue el recordado hack de Ronin

Por otro lado, el contrato de Gravity bridge es inmutable, por lo que no hay forma de introducir vulnerabilidades vía PKs de multisig comprometidas / actualizaciones maliciosas o con ausencia de audits.
De igual forma es preciso recalcar que, de encontrarse un bug o falla en el contrato gravity.sol, no será posible actualizarlo o repararlo.

Todos los validadores de éstas dos redes participan activamente en la firma de los respectivos contratos en las redes que soportan (Gravity: Ethereum ; Axelar: Ethereum, Polygon, Fantom..), en consecuencia uno de los puntos de falla de seguridad recae en los validadores. Para comprometer la seguridad de los contratos de los bridges, es necesario comprometer el propio conjunto de validadores de las redes.

Aclaración: Lo único que hacen los validadores de Cosmos en Ethereum (y las demás redes) es firmar y asegurarse que los tokens transferidos de una red a otra son legítimos. En el caso de Axelar, se suma un segundo factor de vulnerabilidad al contar con una multisig capaz de actualizar los contratos.