Las blockchains dispares necesitan tener una forma de comunicarse para que los usuarios puedan interactuar con datos y activos en múltiples blockchains de forma fácil, por lo que el protocolo de Comunicación Inter-Blockchain (IBC) se estableció para funcionar como una capa de transporte entre blockchains. El ecosistema de Cosmos adoptó IBC primero, pero al ser un protocolo generalizable, IBC ha encontrado su camino en muchos otros ecosistemas.

ICS-02 describe los requisitos para la construcción de clientes ligeros, incluido cómo IBC gestiona los datos de clientes ligeros. Los clientes son necesarios para que IBC funcione, que son algoritmos de verificación arbitrarios para probar información en cadena, que generalmente está codificada en formato IBC, de un lugar a otro.

Desde la perspectiva de IBC, cada cadena normalmente es identificada por su cliente ligero. La verificación más común ocurre entre dos máquinas de estado que se comunican; utilizando un cliente ligero, una cadena fuente puede verificar actualizaciones desde una cadena de destino sin descargar toda su información. Debido a que los clientes ligeros son una herramienta versátil, pueden utilizar múltiples métodos para realizar la verificación de estado.

Verificación de Prueba de Consenso

Una nota sobre algoritmos de consenso

El consenso blockchain se asegura de que todos los nodos que participan en una red estén sincronizados. Mediante la verificación del consenso, el cliente ligero demuestra que un número suficiente de validadores firmaron el encabezado. Este tipo de verificación es el uso más popular de IBC.

Los algoritmos de consenso suelen variar en sus conjuntos de reglas y en lo que priorizan. Sin embargo, la heterogeneidad en dos algoritmos de consenso diferentes podría dificultar la comunicación entre cadenas a través de IBC. Por ejemplo, las cadenas de Cosmos utilizan el algoritmo de consenso Tendermint, que tiene finalidad de un solo slot, también conocida como finalidad rápida. Por otro lado, el consenso de Ethereum no tiene finalidad de un solo slot y, por lo tanto, tiene una finalidad más lenta porque valora la vivacidad sobre la seguridad, mientras que IBC es más compatible con algoritmos de consenso que valoran la seguridad. Debido a esta diferencia en cuándo se consideran 'finales' los bloques, existe dificultad en cómo las dos cadenas pueden enviar y verificar bloques entre sí.

En tal caso, se puede implementar un cliente ligero virtual que pueda tener una vista del cliente ligero en una cierta altura de bloque antes de que se alcance la finalidad. Inicialmente, IBC se enfocó en su adopción dentro de cadenas basadas en Tendermint, lo que fue evidente en la forma en que se definieron la especificación del cliente y la implementación. Después de esta fase inicial, la Cliente Refactormayor flexibilidad y facilidad en el desarrollo de clientes ligeros para cadenas con otros algoritmos de consenso y características.

Clientes Ligeros: Máquinas de Estado

Un "máquina de estados" puede ser toda una blockchain (libro contable replicado) o un único proceso que firma operaciones con una llave privada (consenso mínimo), como una computadora portátil o un teléfono móvil.

Comúnmente, pensamos en las máquinas de estado como blockchains con registros distribuidos, por lo que al establecer IBC entre blockchains, el cliente ligero de una cadena de destino es alojado por la cadena fuente. La cadena fuente también mantiene un estado de confianza de la cadena de destino, que es establecido por un saludo de conexión entre las dos cadenas. El protocolo IBC utiliza un predicado de validez, que es un algoritmo que verifica si las actualizaciones de estado de una cadena de destino son válidas. Para funcionar, un cliente ligero necesita un predicado de validez y un estado de confianza para la cadena fuente.

tipo de cliente vs. instancia de cliente

Los clientes ligeros están diseñados para ser lo más eficientes posible para admitir una gran cantidad de instancias de cliente para muchas cadenas. Para lograr esto, el algoritmo del cliente ligero no reproduce todas las transiciones de estado, lo que de lo contrario lo convertiría en un nodo completo.

Clientes Ligeros: Máquinas en Solitario

Una máquina individual es un dispositivo como una computadora portátil, una interfaz web, un teléfono móvil o un proceso externo. Una máquina individual puede establecer comunicacióncon un libro mayor replicado si esa cadena de bloques utiliza IBC para el transporte.

Como ejemplo, IBC puede habilitar un protocolo de transferencia custodialque reduce los costos de integración para nuevas cadenas. Esto es importante porque los custodios centralizados enfrentan un proceso tedioso y costoso al integrar nuevas redes, lo que requiere ejecutar un nodo completo e infraestructura RPC para cada cadena integrada. En lugar de eso, el custodio puede operar un cliente de máquina individual que facilita transferencias entre cadenas, creación/quema de monedas. La verificación sería realizada por el cliente de la máquina conectada dirigida por el custodio.

Los clientes de máquinas individuales muestran cómo IBC abre la conectividad más allá de simplemente las blockchains. En el ejemplo anterior, puede permitir que las instituciones interactúen fácilmente con las blockchains públicas a través de IBC. Este es solo un ejemplo de líneas comerciales que interactúan con las blockchains sin necesidad de poner en marcha una cadena completa o mantener hardware pesado para trabajar con ellas.

Verificación Más Allá de Pruebas de Consenso

Aunque se está trabajando para que los clientes sean fáciles de implementar y actualizar, existe la opción de realizar verificaciones con validez o pruebas de fraude.

IBC Optimista: Los clientes pueden aceptar optimistamente encabezados entrantes a través de un relé fuera de la cadena que ejecuta un programa en alguna máquina virtual. En este escenario, hay una ventana de desafío donde se puede presentar una prueba de fraude. Lo positivo es que IBC Optimista reduce el costo de todo el sistema. Los inconvenientes incluyen el largo período de desafío de fraude y, dependiendo de la red, podría haber altos costos base para transferir activos, por ejemplo, para Ethereum, esto son 21,000 unidades de gas.

ZK-IBC: Los cálculos del cliente se realizan fuera de la cadena y se verifican en la cadena a través de ZKPs. No hay latencia mínima y el costo es menor que la verificación ingenua. Sin embargo, la verificación ZK puede ser costosa en la cadena y no hay una latencia máxima, lo que significa que un usuario podría estar esperando un tiempo para obtener confirmación. También pueden surgir problemas de incompatibilidad si el esquema de firma no es compatible con SNARK.

Debido a que los sistemas separados anteriores pueden tener algunos inconvenientes prohibitivos, se propone el ZK optimista para aprovechar los beneficios de ambos. Los beneficios de usar ambos reducen el costo del mantenimiento de la conexión e introducen un límite máximo de latencia mediante la incentivación de los relayers.

Optimistic ZK: La cadena fuente acepta optimistamente las cabeceras en cadena (posiblemente hay un mecanismo de participación para la seguridad). Luego, las pruebas de conocimiento cero se utilizan como pruebas de fraude en caso de mal comportamiento o pruebas de validez para reducir dinámicamente la latencia de la conexión.

Seguridad y Mala conducta

IBC no requiere ninguna suposición de confianza de terceros, que a menudo asumen los protocolos de interoperabilidad verificados externamente. Es simplemente un protocolo de transporte y sus propiedades de seguridad dependen de los tipos de cliente y conexión subyacentes y no de la cadena en sí. También depende del uso de pruebas de fraude, suposiciones de mayoría honesta, seguridad compartida a través de la disponibilidad de datos comunes, etc. El protocolo IBC no necesita conocer las identidades de las cadenas en ambos lados de una conexión, siempre y cuando los clientes de IBC se mantengan sincronizados con actualizaciones válidas.

En caso de mala conducta, es decir, las reglas de consenso establecidas por la cadena de destino son violadas por el cliente en una cadena fuente, el cliente en la cadena anfitriona sería congelado si se verifica la prueba de la mala conducta en la cadena fuente. La parte que presenció esto, como el retransmisor, puede enviar un mensaje con pruebas de esta mala conducta. El predicado de mala conducta es un algoritmo que se llama en situaciones como esta: si se demuestra la mala conducta, el cliente queda congelado y con suerte hay un sistema de gobernanza en su lugar para tomar medidas. Las repercusiones de la mala conducta son decididas por las cadenas participantes.

Construyendo con clientes ligeros

Aunque el IBC puede requerir cierta destreza técnica en el consenso y los aspectos internos de la cadena subyacente, no todas las complejidades son cruciales para construir utilizando el IBC, otro objetivo que tenemos con esta serie de artículos. La idea principal aquí es que el IBC es una herramienta poderosa dadas las diversas implementaciones de verificación que los clientes pueden llevar a cabo.

El ecosistema de Gate IBC está trabajando activamente para hacer que Gate sea una solución fácil de adoptar para los constructores. Algunas de las iniciativas que hemos discutido incluyen la reestructuración del cliente y los clientes virtuales. Por ejemplo, si una cadena desea actualizar el consenso, necesitará actualizar cada cadena a la que está conectada y sus clientes ligeros para mantenerse conectada, lo cual es un costoso proceso de gobernanza en cadena. Se están desarrollando clientes WASM para simplificar el desarrollo y la actualización de clientes ligeros a través de instancias de cliente implementadas como contratos inteligentes. Esto facilita la actualización de clientes ligeros sin detener la cadena y crear clientes en lenguajes como Rust, que es una opción popular entre varias máquinas de estado.

La conclusion importante es que los clientes de IBC pueden ser utilizados por cualquier persona y cualquier máquina para verificar el estado en cualquier blockchain, lo que los convierte en un poderoso catalizador para nuevos negocios y servicios en criptomonedas.

Este artículo fue patrocinado por Polymer para apoyar la educación comunitaria en torno a IBC y la interoperabilidad verdaderamente descentralizada.

Polymer Labs, compuesto por hábiles ingenieros de sistemas distribuidos e infraestructura, pioneros en cripto y operadores comerciales consumados, está a la vanguardia del avance de la interoperabilidad de Ethereum con IBC. Con valores técnicos basados en TCP/IP, la misión de Polymer es establecer la próxima generación de internet asegurando que la capa de interoperabilidad de la web descentralizada sea neutral, abierta, sin permisos y uniforme en todos los ecosistemas. Como creadores del Ethereum Interoperability Hub, el primer Layer 2 enfocado en habilitar la interoperabilidad de IBC, Polymer establece un nuevo estándar en la tecnología blockchain.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [eshitanandini]. Todos los derechos de autor pertenecen al autor original [ESHITA]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.