1.0 ¿Qué es IBC?
El protocolo IBC (Inter-Blockchain Communication) se está desarrollando para estandarizar la transferencia de datos entre cadenas. Si una blockchain individual es un planeta, IBC es el transbordador espacial que lleva los paquetes de información a través de una ruta diseñada para minimizar los esfuerzos de todas las partes interesadas (gestores de red, productores de bloques, desarrolladores de blockchains y usuarios finales). Al igual que Internet conecta diferentes categorías de ordenadores situados en otras partes del mundo, IBC desea crear una superautopista a través de la cual la información fiable, ordenada y autenticada pueda transportarse de forma segura de una blockchain a otra sin escuchar a escondidas.
1.0 IBC de AntelopeIO
El protocolo AntelopeIO IBC promete probar instantáneamente que un evento ha ocurrido en otra red habilitada para AntelopeIO IBC. Como muestra la figura 1, AntelopeIO IBC comprende dos tipos de prueba: prueba de bloque y prueba de acción. La prueba de bloque puede dividirse a su vez en dos partes: prueba pesada y prueba ligera.
Figura 1: Protocolo de AntelopeIO IBC.
Un contrato inteligente se instanciará cuando una cadena de bloques implemente el protocolo AntelopeIO IBC. Cualquier tipo de aplicación (transferencia de tokens fungibles, transferencia de tokens no fungibles, creación y mantenimiento de cuentas entre cadenas, consultas entre cadenas, etc.) puede construirse sobre Antelope IBC. Una vez establecido el contrato inteligente, los usuarios utilizan un único esquema de prueba o una combinación de múltiples esquemas para comunicarse a través de IBC.
Las redes Blockchain que adoptan el protocolo AntelopeIO IBC son:
3.0 IBC de Cosmos
El IBC de Cosmos se divide principalmente en dos capas: capa de transporte y capa de aplicación, como se muestra en la figura 2.
Figura 2 : Capas primarias del IBC de Cosmos.
Los mensajes que se comunican a través de Cosmos IBC se cifran dentro de paquetes de datos que se ordenan, autentican y transportan utilizando una capa de transporte. Los componentes clave de la capa de transporte se muestran en la figura 3.
Figura 3: Componentes clave de la capa de transporte del protocolo IBC de Cosmos.
Los clientes ligeros del IBC Cosmos no almacenan el historial completo de todos los mensajes presentes en una blockchain. Más bien, se conectan a un nodo y verifican las cabeceras de los bloques. En la figura 4 se muestran los distintos tipos de clientes disponibles.
Figura 4 : Clientes ligeros del IBC de Cosmos.
Las "Solo Machines" (teléfonos, portátiles, navegadores, etc.) pueden conectarse a las máquinas habilitadas para IBC utilizando Solo Machine Client.
Las "State Machines" que son replicadas usando el algoritmo de consenso Tendermint pueden interactuar con otras "State Machines" replicadas o "Solo Machines" usando Tendermint Client.
Los "Wasm Clients" (Clientes Wasm) son clientes actualizables dinámicamente.
Los clientes del Acuerdo Recursivo de Prefijo Derivado de Antepasado (GRANDPA) basado en GHOST pueden ser implementados por blockchains que utilicen el gadget de finalidad GRANDPA para comunicarse con otras máquinas de estado o máquinas en solitario.
Un relayer es un proceso fuera de la cadena que puede recuperar el estado de otros ledgers que se comunican mediante el protocolo IBC y publicar transacciones en ellos. El relayer debe estar conectado con una cuenta financiada en cada cadena. Si desea conectar varias cadenas, debe utilizar un repetidor para cada par de cadenas.
Connection semantics (semántica de conexión) es un protocolo para establecer una conexión segura entre dos cadenas que tienen un cliente ligero de otra cadena.
Channel and Packet semantics (semántica de canales y paquetes) proporciona un mecanismo de entrega de mensajes al protocolo IBC. Cada canal está asociado a una conexión concreta, y una conexión puede tener cualquier número de canales asociados.
La asignación de puertos entre los distintos tipos de módulos se decide mediante el algoritmo de asignación de puertos. A un módulo IBC se le puede asignar cualquier número de puertos.
La máquina de estado de una cadena de bloques funciona como gestor del vector commitment (compromiso del vector). Tiene la capacidad y la responsabilidad de añadir o eliminar elementos del compromiso.
Host State Machine Requirements (requisitos de la máquina de estado del host) definen el conjunto mínimo de interfaces que deben implementarse y las propiedades que debe cumplir una máquina de estado.
IBC handler interface (interfaz del manejador IBC) comprende métodos para manejar clientes IBC, conexiones, canales y retransmisión de paquetes.
Routing module (módulo de enrutamiento) acepta datagramas externos y llama al controlador IBC para que se encargue de los apretones de manos y la retransmisión de paquetes.
Application layer (capa de aplicación) describe la semántica de codificación y procesamiento de paquetes. La Figura 5 muestra diferentes aplicaciones de IBC.
Figura 5: Capas de aplicación del protocolo Cosmos IBC.
La primera y más importante aplicación de IBC es la transferencia fungible de tokens entre cadenas. Con este estándar, los usuarios pueden transferir activos de una cadena habilitada para IBC a otra cadena habilitada para IBC sin necesidad de permisos adicionales.
Interchain account (Cuenta Interchain) es un protocolo de gestión de cuentas entre cadenas, mediante el cual los usuarios de una cadena habilitada para IBC pueden crear y controlar cuentas de otras cadenas habilitadas para IBC del mismo modo que lo hacen los sistemas nativos.
La seguridad interchain se mantiene utilizando cross-chain validation (validación entre cadenas). Permite que una cadena de proveedores ofrezca seguridad a varias cadenas de consumidores.
General Relayer Incentivisation Mechanism (mecanismo general de Incentivación de reemisores) sirve para gestionar el pago de tasas además del IBC.
IBC Middleware (software intermedio IBC) engloba las interfaces y la lógica de la máquina de estados que debe implementar un módulo para funcionar correctamente como middleware entre el núcleo IBC y una aplicación de subrayado.
Cross chain query module (módulo de consulta de cadenas cruzadas) engloba las estructuras de datos y la lógica de la máquina de estados que permite realizar consultas de cadenas cruzadas entre cadenas habilitadas para IBC.
El módulo de transferencia de tokens no fungibles comprende estructuras de datos, lógica de manejo de máquinas de estado y procesos de codificación para la transferencia de tokens no fungibles de una cadena habilitada para IBC a otra cadena habilitada para IBC.
Las siguientes blockchains han implementado Cosmos IBC:
4.0 Comparación entre AntelopeIO IBC y Cosmos IBC
Criterio | AntelopeIO IBC | Cosmos IBC |
Cross-chain confirmation | Instantánea | Instantánea |
¿Quién puede adoptar? | Cualquier blockchain | Cualquier blockchain |
¿Qué aplicación puede desarrollarse? | Cualquier tipo de dAPP, como transferencia de tokens fungibles, transferencia de tokens no fungibles, creación y mantenimiento de cuentas entre cadenas, consulta entre cadenas, fragmentación de la utilidad de tokens, etc. | Cualquier tipo de dAPP, como transferencia de tokens fungibles, transferencia de tokens no fungibles, creación y mantenimiento de cuentas entre cadenas, consulta entre cadenas, etc. |
Tarifas de Gas | Muy baja | Baja |
Escalabilidad | Cualquier número de cadenas puede ser conectado. | Cualquier número de cadenas puede ser conectado. |
5.0 Conclusión
Inter-Blockchain Communication (comunicación entre cadenas de bloques), que crea superautopistas entre cadenas de bloques insulares, es la próxima ola de desarrollo de cadenas de bloques. Existen muchos otros protocolos de comunicación entre cadenas (MAP, Layerzero, celer, etc.) además de AntelopeIO IBC y Cosmos IBC. En el futuro, la coalición Antelope sólo aceptará aquellas blockchains que dispongan de infraestructura para establecer IBC.
Autor: Sukanta Manna
Editor(es): Markus Hinrichs, Randall Roland, Thian
Traductor: Thian
Fuentes y Referencias: