Todo lo que necesitas saber sobre los canales IBC: FAQs (Parte 2)

https://medium.com/the-interchain-foundation/everything-you-need-to-know-about-ibc-channels-faqs-part-2-44249a7b7e0b

Los canales son un componente crucial del protocolo de Comunicación Inter Blockchain (IBC) al permitir la comunicación de aplicación a aplicación. Para los desarrolladores que implementan IBC en sus aplicaciones, es útil tener un sólido entendimiento de los canales, ya que es la capa de abstracción con la que interactuarán más.

En la Parte 1 de esta serie de dos publicaciones de blog, discutimos los fundamentos de los canales IBC y su importancia para los desarrolladores de aplicaciones. En esta segunda parte, abordamos preguntas frecuentes y conceptos erróneos comunes sobre los canales.

Preguntas frecuentes ¿Cuáles son las razones por las cuales un canal se cerraría?

Un canal puede cerrarse por cualquiera de las siguientes 3 razones:

Debido a un tiempo de espera de paquete en un canal ordenado. Debido a una toma de control del 66% por parte de validadores maliciosos en una cadena. Debido a un ataque de cliente ligero en el que la cadena comprometida puede engañar a la contraparte haciéndole creer que ha cerrado su extremo del canal. ¿Cómo se cierran los canales?

Un canal se cierra cuando un módulo llama a chanCloseInit para cerrar su extremo del canal. Posteriormente, el módulo de la contraparte llama a chanCloseConfirm para cerrar su extremo del canal.

Si se recibe un paquete fuera de orden en un canal ordenado, ¿el canal se cierra automáticamente?

No, no se cierra automáticamente. El paquete simplemente es rechazado por el núcleo de IBC hasta que un relevo envíe el paquete esperado con la secuencia correcta (consulte la sección 'Tipos de canales' en la parte 1 para obtener más información).

¿Cada módulo (transferencia, cuentas entre cadenas, consultas entre cadenas, etc.) tiene su propio canal?

Sí, lo tiene. Cada módulo, como transferencia/cuentas entre cadenas/consultas entre cadenas, se enlaza a un puerto y luego abre un canal utilizando ese puerto.

¿Los canales están ordenados en el caso de cuentas entre cadenas?

Sí, actualmente todos los canales que utilizan cuentas entre cadenas son canales ordenados. Por lo tanto, si un paquete expira, el canal se cierra y se necesita negociar un nuevo canal. Hacerlo evita errores innecesarios. Por ejemplo, un usuario envía 2 transacciones ICA, el paquete n.º 3 para transferir tokens y el paquete n.º 4 para apostar esos tokens. Si los canales fueran desordenados, podría haber un escenario en el que el n.º 4 se entregue antes que el n.º 3, lo que causaría un error.

¿Puede una cadena tener múltiples canales para el mismo módulo de transferencia?

Aunque no hay razón para que una cadena tenga múltiples canales para el módulo de transferencia, es posible hacerlo. Sin embargo, crear dos o más canales para transferencia es redundante y no ofrece beneficios (a menos que sean dos versiones diferentes). También hace que el mismo token enviado a través de dos canales diferentes no sea fungible. Consulta la sección sobre 'fungibilidad de tokens' en la parte 1 para entender por qué esto es así.

¿Puede un canal estar conectado a múltiples canales?

Hasta la fecha, todos los canales son mapeos de 1 a 1. Esto significa que el canal-141 en Cosmos Hub solo estará conectado al canal-0 en Osmosis y a ningún otro.

¿Puede una cadena tener dos o más canales con el mismo ID de canal?

No, esto no es posible. En una cadena dada, todos los canales tienen un ID de canal único. El ID se incrementa cada vez que se abre un nuevo canal en una cadena.

¿Se necesita un apretón de manos de canal cada vez que se envía un paquete IBC?

No, un apretón de manos de canal solo es necesario para abrir o cerrar un canal. Una vez que se ha abierto un canal, los paquetes pueden fluir a través de él libremente.

¿Es posible actualizar un módulo de la versión 1 a la versión 2 manteniendo el mismo canal?

Actualmente, esto no es posible en ibc-go. Actualizar un módulo o agregar una nueva característica/intermediario en ambos lados de un canal requiere una actualización de toda la red o negociar un nuevo canal. Pero con el lanzamiento de la capacidad de actualización de canales más adelante este año, los canales pueden aprovechar nuevas características y los módulos pueden actualizarse manteniendo el canal existente.

¿Es posible limitar la cantidad de tokens que fluyen dentro/fuera de un canal?

Sí, con el uso de un intermediario de limitación de velocidad. Consulta aquí la especificación e implementaciones del limitador de velocidad en Go y para contratos CosmWasm en un envoltorio Go.

¿Es posible limitar ciertas denominaciones de tokens para que no fluyan hacia una cadena?

Sí, consulta este PR fusionado sobre cómo agregar un intermediario IBC que actúa esencialmente como un firewall para ciertas denominaciones y evita que se transfieran a una cadena conectada mediante IBC.

¿Cómo se reabren los canales?

Una vez que un canal se cierra, no se puede volver a abrir el mismo canal con el mismo ID de canal.

La reutilización de ID de canal se evita para evitar la repetición de paquetes. Cada paquete se identifica de manera única por su ID de puerto, ID de canal y secuencia. Cuando se abre un nuevo canal, la secuencia del paquete se restablece a cero. Por lo tanto, el uso del mismo ID de puerto y ID de canal puede hacer que los paquetes que se procesaron anteriormente se reproduzcan nuevamente.

Si un cliente ligero expira o queda congelado, ¿es posible mantener los canales existentes mientras se revive el cliente?

Sí, un cliente ligero congelado o caducado puede ser revivido con una propuesta de gobernanza exitosa. Si la propuesta se aprueba, el cliente se reactiva y todos los canales existentes construidos sobre ese cliente se vuelven a abrir. Puedes consultar nuestra documentación para obtener más información sobre cómo revivir un cliente.

¿Qué es un puerto?

Un puerto es una construcción lógica que aplica capacidades de objeto. Los puertos garantizan que el único módulo que puede abrir un canal en un puerto particular es el módulo que está vinculado a ese puerto. Cuando un módulo se vincula a un puerto, se le emite una capacidad que el módulo debe reclamar.

Los puertos designan un espacio de nombres para los módulos, como 'transfer' para las transferencias de tokens ICS-20 o 'icacontroller' para el submódulo del controlador ICA.

¿Tener múltiples canales aumenta el rendimiento de la cadena?

No, no lo hace en ibc-go porque Tendermint procesa transacciones de manera secuencial. Tener un canal o múltiples canales entre dos cadenas dará como resultado el mismo rendimiento.

¿Quién establece los parámetros de tiempo de espera?

El módulo que envía el paquete.

¿Se pueden establecer los tiempos de espera en cero?

Se puede establecer en cero ya sea el sello de tiempo de tiempo de espera o la altura de tiempo de espera, pero no ambos.

¿Los relayers deben pagar tarifas por enviar un paquete que agotó el tiempo de espera?

Sí, deben hacerlo. Un relayer necesita realizar cálculos que implican gastar gas, incluso si el paquete agota el tiempo de espera en la cadena receptora.

¿Tienen plazos las confirmaciones?

No, no los tienen. Debe haber al menos un mensaje que se pueda enviar de forma asincrónica. De lo contrario, se produce un problema circular donde si existieran plazos para las confirmaciones, entonces el mensaje que prueba que la confirmación agotó el tiempo de espera podría agotar su propio tiempo de espera, y así sucesivamente, lo que causaría un bucle interminable.

¿Dónde puedo ver todos los canales IBC existentes y sus respectivos IDs?

Puedes verlo aquí en mintscan o en el registro de la cadena.

Conclusión Si tienes alguna pregunta adicional después de leer las preguntas frecuentes, no dudes en contactarnos en los canales de desarrolladores o de soporte en nuestro Discord. Y si eres un desarrollador de cadena, un desarrollador de aplicaciones o un desarrollador de clientes ligeros interesado en utilizar IBC, encontrarás toda la información que necesitas en nuestro portal para desarrolladores o en nuestra documentación de ibc-go.