Modular es actualmente un término popular en web3 que una serie de protocolos y proyectos utilizan para describirse a sí mismos. Celestia popularizó el término al introducir el concepto de cadenas de bloques modulares. Nuestro objetivo es reducir el enfoque y el uso del término a una definición muy específica de interoperabilidad modular. También presentaremos un marco para pensar y evaluar blockchains modulares y protocolos de interoperabilidad.

Desglosando los protocolos de blockchain

Hay algunas capas componibles en la pila de blockchain modular:

• Disponibilidad de datos (DA)
• Secuenciación u ordenación de transacciones (TO)
• Ejecución
  - Liquidación

Tenga en cuenta que el consenso no se incluye aquí porque se puede agrupar en cualquiera de las capas anteriores para permitir la verificación de una prueba de consenso en lugar de verificar las reglas de la capa funcional directamente.

Por ejemplo, se podría implementar un paquete acumulativo de un solo nodo sobre Celestia sin consenso que se basa en pruebas de fraude para convencer a un tercero de la corrección. Esto se llamaría un resumen optimista. Si cambiamos la prueba de fraude por una prueba de conocimiento cero (zk), obtendríamos un resumen de zk. Si agregamos el consenso, podemos usar la prueba del consenso para convencer a un tercero de la corrección. Esto se llamaría un resumen pesimista.

Desglosando los protocolos de interoperabilidad

Un protocolo de interoperabilidad completo tiene tres capas bien definidas con una clara separación entre ellas.

Una definición simple de cada capa de interoperabilidad:

• Aplicación: ¿Qué significan los paquetes de datos?
• Transporte: ¿Cómo traducimos el estado de la otra cadena en conversaciones de aplicación <> aplicación y paquetes de datos?
• Estado: ¿Cómo se dan cuenta las cadenas de bloques del estado de cada una?

Definición de interoperabilidad modular

Dado que modular es un término que a menudo se usa y es relevante en varios contextos, intentaremos relacionar nuestra definición de un protocolo de interoperabilidad modular con las capas definidas anteriormente, así como con la definición de Celestia de una cadena de bloques modular. Celestia define una cadena de bloques modular como una cadena de bloques que subcontrata completamente al menos una capa funcional a una cadena externa. Definimos un protocolo de interoperabilidad modular como uno que subcontrata completamente la capa de transporte.

La diferencia clave entre los dos es que la capa que define los protocolos de interoperabilidad es la capa de transporte . La analogía aquí, usando el modelo OSI como ejemplo, es que si cambia TCP/UDP por otro protocolo de transporte, obtiene un protocolo de red completamente diferente. Además, la capa de estado se puede establecer a través de una variedad de medios y no define únicamente un protocolo de interoperabilidad (por ejemplo, clientes ligeros, pruebas de conocimiento cero, pruebas de fraude optimista, etc.). La lógica de la capa de aplicación también se puede generalizar y no hace que un protocolo de interoperabilidad sea compatible con otro. Por ejemplo, cambiar el transporte IBC por una capa de transporte diferente hace que el nuevo protocolo sea incompatible con las cadenas habilitadas para IBC .

La capa de estado también se puede subcontratar en parte, pero la subcontratación por sí sola no hace que el protocolo sea modular, ya que no es la capa que define los protocolos de interoperabilidad. Se considera totalmente en cadena cuando cada cadena ejecuta directamente la lógica de cliente ligero de su contraparte. La capa de estado se considera parcialmente en la cadena cuando la lógica del cliente ligero se ejecuta fuera de la cadena y se verifica en la cadena mediante pruebas de conocimiento cero (zk) o cuando se utiliza un tercero de confianza.

Además, la modularización de cadenas monolíticas tiene implicaciones en la capa de estado de los protocolos de interoperabilidad. Por ejemplo, una única cadena lógica ya no se puede representar mediante un único cliente ligero porque las pruebas de varias capas funcionales ahora se obtienen de varias cadenas.

Polímero el centro de transporte IBC

Polymer está construyendo el primer protocolo de interoperabilidad verdaderamente modular que subcontrata completamente la capa de transporte y subcontrata parcialmente la capa de estado. Como se ve en el siguiente diagrama, la capa de transporte de IBC se ejecuta en Polymer, mientras que la capa de aplicaciones de IBC se ejecuta en la cadena habilitada para IBC. Con este diseño, habilitar IBC en una nueva cadena usando Polymer es tan fácil como desplegar un roll up en Celestia . Polymer subcontrata en parte la capa de estado mediante el uso de conexiones zk-IBC para conectarse a cadenas recién habilitadas para IBC mientras el verificador zk se encuentra en la cadena (no se muestra en el diagrama anterior por simplicidad).

construyamos juntos

Construyamos un futuro donde IBC sea el protocolo de interoperabilidad estándar para todas las cadenas. Las ideas para mejorar el IBC siempre son bienvenidas. Ven a chatear con nosotros en discord . También estamos contratando . ¡La innovación se acelera cuando todos trabajamos juntos!

¡Gracias por las conversaciones Jim (Catalyst) y Josh (Astria)!

Acerca del polímero

Polymer cree en un futuro multicadena conectado principalmente por un estándar industrial de código abierto, desarrollado por la comunidad y mantenido, IBC x Polymer. Polymer es el primer centro de transporte de IBC enfocado en expandir IBC a todas las cadenas. El concentrador Polymer integra la capa de transporte IBC con cadenas conectadas. En la capa de estado, abre conexiones zk-IBC a todas las cadenas integradas. Esta es una arquitectura de confianza minimizada basada en la verificación de prueba de estado de cliente ligero.

¡Sigue nuestro Twitter , visita nuestro sitio web y únete a nuestra comunidad en Discord !