Cross-Chains: ¿Cómo las cadenas de bloques se comunican entre sí?
Reconocida como una tecnología integral, examinamos las cadenas cruzadas para comprender mejor cómo las cadenas de bloques pueden comunicarse entre sí.
Cuando las cadenas de bloques se construyeron por primera vez, se imaginó que podían proporcionar una solución de « talla única », lo que significa que todas las transacciones, contratos inteligentes o cualquier otra cosa se realiza en una sola cadena. Sin embargo, ahora está claro que dicho sistema no es tan práctico, especialmente cuando existen límites de escalabilidad y limitaciones de innovación.
A-cadena de cruz es el intero p erability entre dos blockchains relativamente independientes. En otras palabras, permite que las cadenas de bloques se comuniquen entre sí porque están construidas de manera estandarizada. La implementación entre cadenas está representada principalmente por el intercambio de activos y la transferencia de activos, que es tanto una parte importante del mundo blockchain como una dirección de investigación clave de PPIO. Con cadenas cruzadas, se pueden evitar las limitaciones de una sola cadena. Hoy exploraremos la estructura lógica del protocolo de cadena cruzada de Cosmos, una de las plataformas de cadena cruzada más prometedoras.
La interacción entre cadenas se puede dividir en cadenas cruzadas isomórficas y cadenas cruzadas heterogéneas de acuerdo con las diferentes tecnologías subyacentes. Para las cadenas isomorfas, el mecanismo de seguridad, el algoritmo de consenso, la topología de la red y la lógica de verificación de la generación de bloques son consistentes y la interacción entre cadenas entre ellos es relativamente simple.
Por otro lado, la interacción entre cadenas de cadenas heterogéneas es relativamente compleja e incluye tecnología como el algoritmo PoW para Bitcoin y el algoritmo de consenso PBFT para Tendermint. La composición del bloque y el mecanismo de garantía determinista son bastante diferentes, por lo que no es fácil diseñar un mecanismo de interacción directa entre cadenas. La interacción entre cadenas entre cadenas heterogéneas generalmente requiere servicios auxiliares de terceros.
¿Cómo realizar el isomorfismo a través de cadenas?
Las cadenas desarrolladas en base a Tendermint pueden adoptar cadenas cruzadas isomorfas . El principio de transferencia de activos entre cadenas isomorfas en Cosmos es el siguiente.
Dado que Tendermint utiliza el algoritmo de consenso PBFT + POS, un bloque solo se envía a la red cuando 2⁄3 de los certificadores están de acuerdo. La información del Validador se puede verificar verificando el encabezado del bloque para verificar si el encabezado del bloque es legal en una determinada cadena. Como ejemplo, Tendermint está desarrollando dos cadenas: Cadena A y Cadena B. Ahora suponga que los activos deben transferirse a través de la cadena. En primer lugar, las dos cadenas, A y B, se registrarán entre sí. En el proceso de registro, A y B reconocen su separación. La cadena luego enviará los respectivos bloques de génesis y ChainID (utilizados para representar diferentes cadenas) entre sí. Dado que el bloque de génesis contiene la información del Validador, después del registro, las cadenas A y B tendrán la información del Validador de la otra cadena, así como la información del encabezado del bloque.
Ahora los activos de A deben transferirse a B. Primero, el usuario puede enviar un paquete de transacciones de cadena cruzada packageTx a A. A ejecuta packageTx, destruye o bloquea los activos relacionados y luego escribe packageTx en la salida. La salida se puede considerar como un buzón donde se colocan todas las transacciones entre cadenas notificadas externamente.
Para notificar a la cadena B de los eventos que ocurren en la cadena A, se necesita un relé. El retransmisor es responsable de reenviar mensajes entre cadenas desde la salida de la cadena A a la salida de la cadena B. En esta situación, el retransmisor consulta el packageTx en la salida de la cadena A y obtiene la prueba Merkle de packageTx. La información se empaqueta en la transacción IBC Package PostTx y se envía a la cadena B, que consulta la información del encabezado del bloque en cuanto a dónde se encuentra packageTx. También empaqueta la información del encabezado del bloque en IBCUpdate Chain Tx y la envía a la cadena B. Tenga en cuenta que el retransmisor paga el costo de transacción tanto de IBC Package PostTx como de IBCUpdate Chain Tx.
Después de que la cadena B recibe la transacción IBCPacketPostTx, primero verifica si el encabezado del bloque en IBCUpdateChainTx es parte de la cadena A a través del Validator en esa cadena, y luego verifica si la prueba Merkle de la transacción entre cadenas en IBCPacketPostTx es igual al bloque hash de encabezado en IBCUpdateChainTx. Cuando todos los controles pasan, la cadena B comienza a realizar operaciones relacionadas (para la cadena B, esto significa generar activos relacionados, etc.).
Método de implementación de cadena cruzada isomórfica
La cadena cruzada en Cosmos se implementa mediante el protocolo IBC. Los siguientes paquetes de protocolo IBC definidos en el ecosistema Cosmos: IBCRegisterChainTx, IBCUpdateChainTx, IBCPacketCreateTx, IBCPacketPostTx.
IBCRegisterChainTx
El siguiente código se usa al comienzo de la cadena cruzada para registrar y enviar el Bloque Génesis. El Validador se lo dará a la otra parte. Este código solo se puede ejecutar una vez y varias ejecuciones informarán de un error.
tipo IBCRegisterChainTx struct {BlockchainGénesis}type BlockchainGenesis struct {Cadena de ID de cadenaCuerda de Génesis}
IBCUpdateChainTx
Se utiliza para transferir la información más reciente del bloque, la altura del bloque y la información de la cabeza del bloque en la cadena actual a otra cadena.
escriba IBCUpdateChainTx struct {Encabezado tm.HeaderComprometerse tm.Commit// TODO: NextValidators}
IBCPacketCreateTx
Cuando la cadena recibe el paquete de transacciones, realizará transacciones entre cadenas y colocará información relevante en la salida.
escriba IBCPacketCreateTx struct {Paquete}type Packet struct {SrcChainID cadenaCadena DstChainIDSecuencia uint64Type string // redundante ahora que Type () es un método en Payload?Payload Payload}
IBCPacketPostTx
Este paquete contiene la prueba Merkle después de que se ejecuta la transacción de cadena cruzada, que luego es enviada por el retransmisor a otra cadena.
escriba IBCPacketPostTx struct {FromChainID string // La fuente inmediata del paquete, no siempre Packet.SrcChainIDFromChainHeight uint64 // La altura del bloque en el que se comprometió el paquete, para verificar la pruebaPaqueteProof * merkle.IAVLProof // Prueba de Merkle}
#plugin
Podemos ver en el protocolo anterior que estos paquetes de protocolos son en realidad una transacción. Tendermint dispone de un módulo plug-in para facilitar nuestra ampliación. Podemos implementar la interfaz en el complemento y realizar transacciones entre cadenas con los complementos de IBC.
tipo interfaz de complemento {// El nombre de este complemento debe ser corto.Nombre () cadena// Ejecutar una transacción desde ABCI DeliverTxRunTx (almacenar KVStore, ctx CallContext, txBytes [] byte) (res abci.Result)// Otros manejadores de mensajes ABCISetOption (almacenar KVStore, clave, cadena de valor) (cadena de registro)InitChain (tienda KVStore, vals [] * abci.Validator)BeginBlock (almacenar KVStore, hash [] byte, encabezado * abci.Header)EndBlock (tienda KVStore, altura uint64) abci.ResponseEndBlock}
El código anterior es la definición de la interfaz del complemento. Se puede ver que el complemento es muy similar a la interfaz ABCI, por lo que la transacción IBC se entrega al complemento en deliverTx.
// ABCI :: DeliverTxfunc (aplicación * BaseApp) DeliverTx (txBytes [] byte) (res abci.Result) {// Exec txcambiar tx: = tx. (tipo) {caso * tipos.// Realizar operaciones normalescaso * tipos.AppTx:// Ejecuta la transacción en el complementocomplemento: = pgz.GetByName (tx.Name)res = plugin.RunTx (caché, ctx, tx.Data)volver resdefecto:return abci.ErrBaseEncodingError.SetLog ("Tipo tx desconocido")}volver res}
PegZone de cadena cruzada heterogénea
Para las cadenas que usan algoritmos de consenso POW, como Bitcoin y Ethereum, ¿cómo pueden operar a través de cadenas usando el protocolo IBC de Tendermint? Debido al algoritmo POW utilizado en estas cadenas, no podemos verificar los bloques de estas cadenas a través del Validator. Tampoco podemos usar la prueba de Merkle para demostrar la legitimidad de las transacciones entre cadenas en estas cadenas. Además, los bloques generados por el algoritmo de consenso POW son probabilísticamente finales y tienen la posibilidad de ser revertidos. Necesitamos asegurarnos de que las transacciones entre cadenas sean realmente definitivas y no se deshagan.
Sobre la base de las consideraciones anteriores, utilizamos el esquema PegZone para realizar encadenamiento cruzado heterogéneo. PegZone en sí es en realidad una cadena de proxy desarrollada por Tendermint, que rastrea el estado de la cadena original en tiempo real y establece un umbral de seguridad para esperar a que crezca el bloque de la cadena original. Cuando el número alcanza el umbral de seguridad, se considera que el estado de la cadena original tiene una finalidad pseudo-real (pequeña probabilidad de reversión), que es el mismo principio que la verificación de la billetera del cliente ligero. Por ejemplo, el umbral de seguridad de Bitcoin generalmente se establece en 6, mientras que el umbral de seguridad de ETF se puede establecer en 20 o 100. PegZone en sí tiene finalidad en tiempo real y se puede conectar al Cosmos Hub a través de IBC para lograr la cadena cruzada.
La siguiente imagen usa PegZone, o Peggy, junto con Ethereum como ejemplo de encadenamiento cruzado.
Como se puede ver en la imagen de arriba, PegZone se puede dividir en cinco partes:
- Contrato inteligente: el papel de la administración fiduciaria de activos en la custodia de tokens en Ethereum y Cosmos. Proporciona principalmente cuatro métodos: bloquear, desbloquear, acuñar y grabar.
- Testigo: Es un nodo Ethereum a gran escala que monitorea el evento del contrato Ethereum y espera que se generen 100 bloques. El Witness Tx encapsulado se envía a PegZone para probar el cambio de estado en la cadena de bloques Ethereum.
- PegZone: PegZone es una cadena de bloques basada en Tendermint que mantiene la información de la cuenta del usuario, permite la transferencia de activos entre usuarios y proporciona consultas sobre transacciones.
- Firmante: Secp256k1 se utiliza para firmar transacciones para que las firmas puedan validarse de manera eficiente mediante contratos inteligentes; esto corresponde al conjunto de claves públicas verificadoras de contratos inteligentes.
- Retransmisor : el retransmisor es responsable de todos los envíos de transacciones. Este rol reenvía el SignTx firmado al contrato inteligente.
Cosmos Hub Role
En la demostración de cadena cruzada de basecoin en Cosmos, dos cadenas, Cadena A y Cadena B, están entrecruzadas y se envían IBC Register Chain Tx entre sí para su registro. Al cruzar la cadena, los paquetes de protocolo IBC se envían directamente para llevar a cabo la operación de cadena cruzada de los activos. Sin embargo, esta conexión directa tiene un problema. A medida que aumenta la cantidad de Zonas (que son equivalentes a una cadena de bloques independiente) a las que se accede a la red, la cantidad de enlaces aumentará en un orden cuadrado si la comunicación se implementa directamente. Tomemos como ejemplo 100 zonas conectadas a la red. Si cada zona necesita establecer directamente una conexión IBC, la red necesita n (n-1) / 2 = 4950 enlaces de comunicación. Obviamente, un crecimiento tan rápido abrumará a la red.
El concepto de Hub puede resolver el problema relacionado con este problema. En el ecosistema Cosmos, todas las Zonas se registrarán y enviarán paquetes IBC al Hub.
Modo de operación del concentrador
Los concentradores gestionan muchas zonas. Todas las zonas deben registrarse con un concentrador. El Hub rastrea el estado de cada Zona. Cada Zona reporta toda la información de bloque nuevo que produce al Hub. Al mismo tiempo, cada Zona también necesita sincronizar el estado del Hub. En lugar de comunicarse directamente entre Zonas, cada Zona se comunica indirectamente enviando IBC al Hub.
Cuando una Zona establece una conexión IBC al Hub, puede acceder automáticamente a otras Zonas conectadas al Hub, lo que significa que una Zona no necesita conectarse a otras Zonas.
Cuando una zona recibe tokens de otra zona conectada al concentrador, solo necesita confiar en el concentrador y esa zona, no en todas las demás zonas de la red.
Resumen
Nuestro segundo estudio de Cosmos cubrió el diseño arquitectónico de su plataforma de cadena cruzada, cómo respaldar la modularización para construir cadenas isomorfas y cómo respaldar el acoplamiento de cadenas heterogéneas externas a través del Puente. También observamos la característica más importante del sistema Cosmos, que es que todas las cadenas del sistema Cosmos son cadenas isomórficas y pueden soportar el flujo de cadenas cruzadas de activos de manera más conveniente. Todas las zonas comparten un conjunto de protocolos de red, mecanismos de consenso y métodos de almacenamiento de datos, y pueden modularizar nuevas cadenas de bloques de zonas a través de interfaces API.
En la actualidad, los proyectos de cadena cruzada se encuentran en la etapa exploratoria, y la promoción de proyectos de cadena cruzada en el futuro depende de un aterrizaje sustancial de aplicaciones de cadena de bloques. La necesidad de transacciones entre cadenas depende del uso de aplicaciones blockchain, que dependen del uso de funciones y derechos representados por el certificado, en lugar de solo transacciones, como cadenas de activos, predictores de cadenas cruzadas, escenarios de retención de activos y, en última instancia, el establecimiento de una red de circulación para conectar las islas de activos digitales. En el futuro, PPIO puede utilizar activos de otras cadenas para pagar el almacenamiento y el ancho de banda, realizar activos de datos e intercambiar estos activos mediante tecnología de cadena cruzada.
You cannot copy content of this page