Autor: Lisa A., Taiko Labs; traducción: Jinse Finance xiaozou
Este artículo discutirá diferentes métodos de mensajería entre cadenas L2 desde la perspectiva del resumen, centrándose en la comunicación entre cadenas sin confianza. Veremos brevemente el enfoque de lectura de estado directo, el enfoque de cliente ligero y la prueba de almacenamiento. También cubriremos el mecanismo de agregación de pruebas, la transmisión de mensajes de cadena cruzada de terceros confiables y las soluciones centrales de cadena cruzada ZK. Finalmente, veamos cómo los diferentes L2 implementan la mensajería entre cadenas en la actualidad.
1. Introducción a la mensajería entre cadenas
Para la comunicación entre cadenas, todas las partes (L2, L3, etc.) deben tener acceso directo a la última raíz del estado de Ethereum.
Todas las capas de depósito tienen un mecanismo de cadena cruzada "incorporado" que se puede usar para acceder a la raíz del estado L1, que se pasará a L2 como un mensaje de depósito.
1**.1** Dos tipos de acceso a la raíz del estado
Tipo 1: leer la raíz del estado directamente: se puede hacer a través del código de operación o precompilado. Sin embargo, no se ha implementado hasta ahora, por lo que no se requiere prueba.
Brecht Devos describe un posible método de lectura directa del estado en un trabajo de investigación: "... podemos exponer un contrato precompilado que puede llamar directamente a un contrato inteligente en la cadena de destino. Este precompilado directamente en la cadena de origen inserta y ejecuta el código de contrato inteligente de otra cadena Esto garantiza que los contratos inteligentes siempre tengan acceso al último estado disponible de una manera eficiente y fácilmente comprobable”.
· También descrito en la RFP de Optimism "Prueba de concepto de invocación estática remota".
Tipo 2: Generación de prueba, es decir, probar una declaración sobre una cadena de bloques en otra cadena de bloques.
La "mensajería entre cadenas con pruebas" tiene dos enfoques:
· Comunicación entre cadenas sin confianza, es decir, sin terceros de confianza (p. ej., utilizando clientes ligeros o prueba de almacenamiento). El enfoque sin confianza se puede utilizar tanto para la generación de pruebas de terceros como para que los participantes de la comunicación entre cadenas generen pruebas ellos mismos.
Las pruebas se comparten entre diferentes acumulaciones para garantizar operaciones entre cadenas. Este enfoque, del que no se habla mucho en este artículo, se encuentra actualmente en la fase de investigación y exploración y no se considera una solución potencialmente aplicable.
1**.2** Método de "Mensajería entre cadenas con prueba"
1.2.1Mensajes entre cadenas de clientes ligeros
Demostrar los datos en la cadena B
Obtener datos de prueba de Merkle del nodo completo de la cadena B (nodo de archivo de archivo si se requiere prueba de almacenamiento para ciertos estados históricos);
Enviar el encabezado del bloque y los datos de prueba correspondientes al bloque de la cadena B que contiene el estado que queremos verificar al contrato del probador en la cadena A como datos de llamada;
El contrato del probador calcula el valor hash del bloque en función de los datos del encabezado del bloque, consulta el contrato inteligente del cliente ligero en la cadena A (rastrea el valor hash del bloque de la cadena B) y comprueba si el valor hash es válido;
Los datos de prueba se verifican con la raíz de estado bytes32 en el encabezado del bloque.
1**.2.2** Prueba de almacenamiento
La prueba de almacenamiento tiene dos opciones de "flujo de trabajo":
· Generar prueba de almacenamiento → usar en cadena
· Generar prueba de almacenamiento → generar prueba zk → usar en la cadena
También es posible que una entidad empaquete varias colecciones de pruebas en una sola prueba (tanto la prueba de almacenamiento como la prueba de zk). Este es un paso de optimización opcional y aún no se analiza.
Echemos un vistazo a las tres etapas principales del "flujo de trabajo" de prueba de almacenamiento: generar prueba de almacenamiento, generar prueba zk y usarla en la cadena.
(1) Generar prueba de almacenamiento
· La prueba de almacenamiento nos permite usar un compromiso confidencial para probar que cierta información existe en la cadena de bloques y es verdadera;
La prueba de almacenamiento ha sido parte del espacio criptográfico desde la llegada de los árboles de Merkle en 1979. Sin embargo, las pruebas de almacenamiento estándar suelen ser bastante grandes. La innovación moderna radica en combinar la prueba de almacenamiento con el cálculo comprobable para crear pruebas sucintas que se pueden verificar en cadena.
Para generar una prueba de almacenamiento, se debe proporcionar un bloque específico de datos y su ruta de Merkle o Verkle asociada en un árbol de Merkle. La ruta consta de los hashes hermanos necesarios para reconstruir el hash raíz utilizando el mismo algoritmo de hash.
Para verificar una prueba de almacenamiento, el destinatario puede usar los datos proporcionados y la ruta de Merkle o Verkle para volver a calcular el hash raíz. Si el hash raíz recalculado coincide con un hash raíz conocido, el destinatario puede estar seguro de que los datos son auténticos y forman parte del conjunto de datos enviado.
(2) Generar ZKP (Prueba de Conocimiento Cero)
Sin embargo, una Prueba de almacenamiento de tipo Ethereum es de aproximadamente 4 kb, bastante grande para publicar la Prueba de almacenamiento completa en la cadena de destino, ya que la verificación de la prueba sería muy costosa. Por lo tanto, es razonable usar ZKP (por ejemplo, ZK-SNARK) para la compresión, lo que puede hacer que la prueba sea más pequeña y más barata de verificar.
（3）Un****rollZKP
Después de obtener ZKP, los usuarios de la cadena de destino pueden desenrollar las pruebas obtenidas (p. ej., acceder al estado histórico a través de encabezados de bloque o hash de bloque).
El desenrollado se puede hacer de la siguiente manera:
Acumulación en cadena: Todo el proceso de reconstrucción de encabezados de bloque a partir de pruebas se realiza directamente en la cadena de bloques. Desventajas: alta tarifa de gas, consume recursos informáticos; ventajas: sin tiempo de prueba adicional, baja latencia, porque no hay necesidad de generar pruebas fuera de la cadena de bloques.
Compresión en cadena: elimine información redundante o innecesaria de los datos, o use estructuras de datos optimizadas para la eficiencia del espacio. Los datos comprimidos se envían a la cadena de bloques y se pueden descomprimir cuando sea necesario. Contras: la compresión y descompresión de datos puede significar un cálculo adicional, pero esta latencia puede ser insignificante. El algoritmo de compresión utilizado puede tener un impacto negativo en la seguridad de los datos; ventaja: reduce los costos de datos.
Almacenamiento fuera de la cadena: almacene datos fuera de la cadena y coloque bloques de datos específicos en la cadena bajo demanda. Esto es relevante para soluciones que necesitan almacenar grandes cantidades de datos por algún motivo (por ejemplo, nodos de archivo Ethereum del bloque génesis). Contras: igual que la compresión en cadena; Pros: reduce aún más los costos de datos.
1**.2.3** Tercero de confianza
Una solución completa de cadena cruzada también debe incluir soluciones de mensajería cruzada con terceros de confianza (como oráculos, puentes centralizados, etc.).
1**.2.4** Sistema de prueba “universal”
En el caso de un mecanismo de plataforma de prueba de agregación compartida, la mensajería puede acelerarse al recibir bloques hash que se liquidan dentro de la plataforma de agregación, y la liquidación aquí también manejará la mensajería (pero si hay un problema con la plataforma de agregación ¿qué hacer?).
1**.2.5 Algunos problemas desconocidos de la mensajería entre cadenas ZK******
¿Es factible la mensajería entre cadenas sin un tercero de confianza (que puede ser una sola entidad o varias entidades)? ¿Cuál es un mecanismo eficiente para el paso de mensajes entre cadenas? En general, para Ethereum L2 (con acceso directo a los hashes de bloque de L1) y Ethereum mismo, si una cadena puede ejecutar un cliente ligero, etc., lo cual es suficiente para mensajes entre cadenas sin confianza.
¿El circuito ZK utilizado para la generación de prueba de cadena cruzada está correctamente escalado? En algunos casos, especialmente cuando la capa de consenso (que debe verificarse para las operaciones entre cadenas) es muy grande, el circuito utilizado para el paso de mensajes entre cadenas ZK puede ser mucho más grande que el almacenamiento acumulativo y en cadena, y la sobrecarga computacional también es muy grande. Presumiblemente, este problema se puede superar con un enfoque más centralizado.
2**、Ejemplo de solución de mensajería entre cadenas**
· Su****Succinct Labs utiliza un cliente ligero para verificar el consenso desde la cadena de origen hasta la capa de consenso de la cadena de destino. La idea es que exista un protocolo de cliente ligero para garantizar que los nodos puedan sincronizar los encabezados de bloque del estado final de la cadena de bloques. ZKP se utiliza para generar pruebas de consenso.
· La****grange Labs crea una prueba de estado de cadena cruzada no interactiva. Lagrange demuestra que la red es responsable de crear la raíz del estado. Cada nodo de Lagrange contiene una parte de la clave privada de un fragmento, que da fe del estado de una cadena en particular. Cada raíz de estado es una raíz de Verkle con signo de umbral que se puede usar para atestiguar el estado de una cadena en particular en un momento en particular. La raíz del estado es completamente general y se puede usar en una prueba de estado para probar el estado actual de cualquier contrato o billetera en la cadena.
· He****rodotus utiliza la prueba de almacenamiento ZKP para proporcionar contratos inteligentes y acceder a datos en la cadena de otras capas de Ethereum de forma sincrónica. Para la validación, utiliza mensajes nativos L1<>L2 para sincronizar bloques hash entre acumulaciones de Ethereum.
=nil; Foundation (Mina, L1) permite contratos inteligentes en Ethereum para verificar la validez del estado de Mina. Genere pruebas de estado para fines especiales, baratas de verificar en Ethereum (las pruebas locales de Mina en Ethereum son caras). Hipotéticamente (en algún momento en el futuro) las aplicaciones pueden usar directamente la herramienta de generación de prueba de Mina para verificar la validez de las transacciones entre cadenas. = nil; Foundation también tiene un mercado de pruebas donde los usuarios/proyectos pueden comprar/vender principalmente pruebas de SNARK que permiten el acceso a datos sin confianza.
Axiom: si Axiom ha generado un ZKP para el libro mayor hasta el momento, no necesita generar un ZKP para un bloque específico, puede pasar este ZKP a la cadena (como retransmisor) o incluso proporciona acceso a este ZKP.
3. Mensajes entre cadenas L2
*Descargo de responsabilidad: la mensajería entre cadenas aún está evolucionando para la mayor parte de L2. Todos los análisis a continuación se basan en información de fuente abierta. Dicho esto, las soluciones mencionadas en el artículo pueden estar en la etapa de exploración y prueba, y el resumen puede eventualmente adoptar otros métodos. *
**(1)**Taiko
Taiko almacena hashes de bloque para cada cadena. Para cada par de cadenas, implementa dos contratos inteligentes que almacenan los hashes de cada uno. En el ejemplo de L2←→L1, cada vez que se crea un bloque L2 en Taiko, los valores hash de los bloques periféricos en L1 se almacenan en el contrato TaikoL2. También en el caso de L1←→L2, el modo de operación es el mismo.
La última raíz de Merkle conocida almacenada en la cadena de destino se puede obtener llamando a getCrossChainBlockHash(0) en el contrato TaikoL1/TaikoL2 y obtener el valor/mensaje para verificar. El hash hermano de la última raíz de Merkle conocida se puede obtener llamando a la solicitud eth_getProof utilizando un RPC estándar en la "cadena de origen".
Luego, simplemente envíelos para que se verifiquen con los últimos hashes de bloque conocidos almacenados en una lista en la "cadena de destino". El validador tomará un valor (una hoja en el árbol de Merkle) y hashes hermanos para volver a calcular la raíz de Merkle y verificar que coincida con la raíz almacenada en la lista de hashes de bloque de la cadena de destino.
**(2)**Starknet
Starknet usa Prueba de almacenamiento para mensajería entre cadenas sin confianza.
Protocolo de mensajería L2→L1
· Durante la ejecución de una transacción de Starknet, un contrato en Starknet envía un mensaje L2→L1.
Los parámetros del mensaje (que contienen el contrato del receptor y los datos relacionados en L1) se agregan luego a la actualización de estado relevante (árbol de almacenamiento principal).
· Los mensajes L2 se almacenan en L1 del contrato inteligente.
· Emitir un evento en L1 (almacenar parámetros de mensaje).
Las direcciones del receptor en L1 pueden acceder y usar el mensaje como parte de una transacción L1 al volver a proporcionar los parámetros del mensaje.
· Los mensajes de cadena cruzada se almacenan en el árbol troncal.
L2 → L1
L1 → L2
**(3)**Optimismo
La comunicación entre L1 y L2 se implementa mediante dos contratos inteligentes especiales llamados "mensajeros".
· Para las transacciones de Optimism (L2) a Ethereum (L1), es necesario proporcionar una prueba de Merkle del mensaje en L1 después de escribir la raíz del estado. Después de que esta transacción de prueba se convierte en parte de la cadena L1, comienza el período de desafío de error. Después de este período de espera, cualquier usuario puede "finalizar" la transacción activando una segunda transacción en Ethereum, enviando un mensaje al contrato L1 de destino.
· Los mensajes de cadena cruzada se almacenan en el árbol troncal.
（4）Ar****bitrum
Los tickets que se pueden volver a intentar son el método canónico que usa Arbitrum para crear mensajes L1 a L2, es decir, transacciones L1 que inicializan los mensajes que se ejecutarán en L2. Se puede enviar un Reintentable en L1 por una tarifa fija (dependiendo únicamente del tamaño de los datos de la llamada). El árbol de estado principal se utiliza para la comunicación entre cadenas de formatos de datos personalizados en contratos inteligentes. El envío de un ticket reintentable en L1 es separable/asincrónico de la ejecución en L2. Los reintentos proporcionan atomicidad entre operaciones entre cadenas. Si la solicitud de transacción L1 se envía con éxito (es decir, sin retroceder), entonces la ejecución Reintentable en L2 tiene una fuerte garantía de que eventualmente tendrá éxito.
Arbitrum tiene dos troncos: la cadena Nitro se mantiene en el formato de árbol de estado de Ethereum, un árbol Merkle. El Árbol de Afirmación almacena el estado de la cadena Arbitrum confirmado en Ethereum a través de "afirmación". Las reglas que hacen avanzar la cadena Arbitrum son deterministas. Esto significa que, dado el estado de una cadena y algunos valores de entrada nuevos, solo hay una salida válida. Por lo tanto, si el árbol de prueba contiene varias hojas, como máximo una hoja puede representar un estado de cadena válido.
El sistema Outbox de Arbitrum permite cualquier llamada de contrato de L2 a L1, es decir, un mensaje se inicia desde L2 y finalmente se ejecuta en L1. Los mensajes L2 a L1 (también conocidos como "mensajes salientes") tienen mucho en común con los mensajes L1 a L2 de Arbitrum (reintentables), aunque existen algunas diferencias notables. Parte del estado L2 de una cadena Arbitrum, es decir, la parte atestiguada en cada RBlock, es la raíz de Merkle de todos los mensajes L2 a L1 en el historial de la cadena. Una vez que se confirma el RBlock probado (generalmente alrededor de una semana después de la prueba), la raíz de Merkle se incluye en el contrato de bandeja de salida y se publica en L1. El contrato de bandeja de salida permite a los usuarios ejecutar sus mensajes.
**(5)**Polígono zkEVM
· El Bridge SC de este zkEVM utiliza un árbol Merkle especial llamado Árbol de salida para cada red que participa en la comunicación o transacción de activos.
Utiliza raíces de Merkle (en un árbol de estado separado), se puede encontrar un diagrama de arquitectura de puente en github.
El despliegue de zkEVM Bridge SC ha realizado varios cambios en función del contrato de depósito de Ethereum 2.0. Por ejemplo, utiliza un árbol Merkle de solo anexar especialmente diseñado, pero utiliza la misma lógica que el contrato de depósito de Ethereum 2.0. Otras diferencias se relacionan con hashes base y nodos hoja.
La característica principal del contrato inteligente Polygon zkEVM Bridge es el uso del árbol de salida y el árbol de salida global, donde la raíz del árbol de salida global es la fuente principal del estado de verdad. Por lo tanto, L1 y L2 tienen dos administradores raíz de salida global diferentes, y Bridge SC tiene una lógica separada.
(6)S****croll
· Los contratos puente implementados en Ethereum y Scroll permiten a los usuarios pasar mensajes arbitrarios entre L1 y L2. Además de este protocolo de mensajería, también creamos un protocolo de puente sin confianza para permitir a los usuarios unir los activos ERC-20 entre L1 y L2. Para enviar un mensaje o fondos desde Ethereum a Scroll, un usuario llama a la transacción sendMessage en el contrato de Bridge. Los repetidores indexarán esta transacción en L1 y la enviarán al ordenante para que la incluya en los bloques L2. En el contrato puente L2, el proceso de enviar un mensaje de Scroll back to Ethereum es similar.
· Los mensajes entre cadenas se almacenan en colas de mensajes normales. El ordenante ingiere mensajes entre cadenas de esta cola y los agrega a la cadena como transacciones regulares.
**(7)**Era zksync
*Descargo de responsabilidad: el contenido de esta sección es solo sobre zksync Era, que puede ser diferente de los mensajes entre cadenas en ZK Stack, que es un marco modular para construir una supercadena ZK soberana. *
· Cada paquete de transacciones tiene un único mensaje L2->L1.
· No es posible enviar transacciones directamente de L2 a L1. Sin embargo, puede enviar mensajes de cualquier longitud desde zkSync Era a Ethereum y luego procesar los mensajes recibidos en Ethereum utilizando el contrato inteligente L1. zkSync Era tiene una función de prueba de solicitud que devolverá un parámetro booleano que indica si el mensaje se envió con éxito a L1. Recupere la prueba de Merkle contenida en el mensaje observando Ethereum o utilizando el método zks_getL2ToL1LogProof de la API zksync-web3.
· Para L1→L2, el contrato inteligente zkSync Era permite al remitente solicitar una transacción en Ethereum L1 y pasar los datos a zkSync Era L2.
· Contrato puente:
4. Conclusión
La comunicación entre cadenas es parte integral de las aplicaciones "imprescindibles" para la adopción masiva de blockchain (por ejemplo, la billetera de recuperación social entre cadenas descrita en el artículo de Vitalik). La mayoría de las soluciones de cadenas cruzadas actualmente en uso están diseñadas para L1←→L2 para cubrir la función de retiro. Estas soluciones se pueden extender a más cadenas de bloques. Pero al mismo tiempo, se pueden implementar soluciones de comunicación entre cadenas más avanzadas, como "estado de lectura directa" sin ninguna prueba o "prueba de almacenamiento" sin confianza. Para la mayoría de las L2, todavía hay margen de mejora en la comunicación entre cadenas.
Ver originales
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Explore la comunicación entre cadenas desde la perspectiva del resumen
Autor: Lisa A., Taiko Labs; traducción: Jinse Finance xiaozou
Este artículo discutirá diferentes métodos de mensajería entre cadenas L2 desde la perspectiva del resumen, centrándose en la comunicación entre cadenas sin confianza. Veremos brevemente el enfoque de lectura de estado directo, el enfoque de cliente ligero y la prueba de almacenamiento. También cubriremos el mecanismo de agregación de pruebas, la transmisión de mensajes de cadena cruzada de terceros confiables y las soluciones centrales de cadena cruzada ZK. Finalmente, veamos cómo los diferentes L2 implementan la mensajería entre cadenas en la actualidad.
1. Introducción a la mensajería entre cadenas
Para la comunicación entre cadenas, todas las partes (L2, L3, etc.) deben tener acceso directo a la última raíz del estado de Ethereum.
Todas las capas de depósito tienen un mecanismo de cadena cruzada "incorporado" que se puede usar para acceder a la raíz del estado L1, que se pasará a L2 como un mensaje de depósito.
1**.1** Dos tipos de acceso a la raíz del estado
Tipo 1: leer la raíz del estado directamente: se puede hacer a través del código de operación o precompilado. Sin embargo, no se ha implementado hasta ahora, por lo que no se requiere prueba.
Brecht Devos describe un posible método de lectura directa del estado en un trabajo de investigación: "... podemos exponer un contrato precompilado que puede llamar directamente a un contrato inteligente en la cadena de destino. Este precompilado directamente en la cadena de origen inserta y ejecuta el código de contrato inteligente de otra cadena Esto garantiza que los contratos inteligentes siempre tengan acceso al último estado disponible de una manera eficiente y fácilmente comprobable”.
· También descrito en la RFP de Optimism "Prueba de concepto de invocación estática remota".
Tipo 2: Generación de prueba, es decir, probar una declaración sobre una cadena de bloques en otra cadena de bloques.
La "mensajería entre cadenas con pruebas" tiene dos enfoques:
· Comunicación entre cadenas sin confianza, es decir, sin terceros de confianza (p. ej., utilizando clientes ligeros o prueba de almacenamiento). El enfoque sin confianza se puede utilizar tanto para la generación de pruebas de terceros como para que los participantes de la comunicación entre cadenas generen pruebas ellos mismos.
Las pruebas se comparten entre diferentes acumulaciones para garantizar operaciones entre cadenas. Este enfoque, del que no se habla mucho en este artículo, se encuentra actualmente en la fase de investigación y exploración y no se considera una solución potencialmente aplicable.
1**.2** Método de "Mensajería entre cadenas con prueba"
1.2.1 Mensajes entre cadenas de clientes ligeros
Demostrar los datos en la cadena B
Obtener datos de prueba de Merkle del nodo completo de la cadena B (nodo de archivo de archivo si se requiere prueba de almacenamiento para ciertos estados históricos);
Enviar el encabezado del bloque y los datos de prueba correspondientes al bloque de la cadena B que contiene el estado que queremos verificar al contrato del probador en la cadena A como datos de llamada;
El contrato del probador calcula el valor hash del bloque en función de los datos del encabezado del bloque, consulta el contrato inteligente del cliente ligero en la cadena A (rastrea el valor hash del bloque de la cadena B) y comprueba si el valor hash es válido;
Los datos de prueba se verifican con la raíz de estado bytes32 en el encabezado del bloque.
1**.2.2** Prueba de almacenamiento
La prueba de almacenamiento tiene dos opciones de "flujo de trabajo":
· Generar prueba de almacenamiento → usar en cadena
· Generar prueba de almacenamiento → generar prueba zk → usar en la cadena
También es posible que una entidad empaquete varias colecciones de pruebas en una sola prueba (tanto la prueba de almacenamiento como la prueba de zk). Este es un paso de optimización opcional y aún no se analiza.
Echemos un vistazo a las tres etapas principales del "flujo de trabajo" de prueba de almacenamiento: generar prueba de almacenamiento, generar prueba zk y usarla en la cadena.
(1) Generar prueba de almacenamiento
· La prueba de almacenamiento nos permite usar un compromiso confidencial para probar que cierta información existe en la cadena de bloques y es verdadera;
La prueba de almacenamiento ha sido parte del espacio criptográfico desde la llegada de los árboles de Merkle en 1979. Sin embargo, las pruebas de almacenamiento estándar suelen ser bastante grandes. La innovación moderna radica en combinar la prueba de almacenamiento con el cálculo comprobable para crear pruebas sucintas que se pueden verificar en cadena.
Para generar una prueba de almacenamiento, se debe proporcionar un bloque específico de datos y su ruta de Merkle o Verkle asociada en un árbol de Merkle. La ruta consta de los hashes hermanos necesarios para reconstruir el hash raíz utilizando el mismo algoritmo de hash.
Para verificar una prueba de almacenamiento, el destinatario puede usar los datos proporcionados y la ruta de Merkle o Verkle para volver a calcular el hash raíz. Si el hash raíz recalculado coincide con un hash raíz conocido, el destinatario puede estar seguro de que los datos son auténticos y forman parte del conjunto de datos enviado.
(2) Generar ZKP (Prueba de Conocimiento Cero)
Sin embargo, una Prueba de almacenamiento de tipo Ethereum es de aproximadamente 4 kb, bastante grande para publicar la Prueba de almacenamiento completa en la cadena de destino, ya que la verificación de la prueba sería muy costosa. Por lo tanto, es razonable usar ZKP (por ejemplo, ZK-SNARK) para la compresión, lo que puede hacer que la prueba sea más pequeña y más barata de verificar.
（3）Un****roll ZKP
Después de obtener ZKP, los usuarios de la cadena de destino pueden desenrollar las pruebas obtenidas (p. ej., acceder al estado histórico a través de encabezados de bloque o hash de bloque).
El desenrollado se puede hacer de la siguiente manera:
Acumulación en cadena: Todo el proceso de reconstrucción de encabezados de bloque a partir de pruebas se realiza directamente en la cadena de bloques. Desventajas: alta tarifa de gas, consume recursos informáticos; ventajas: sin tiempo de prueba adicional, baja latencia, porque no hay necesidad de generar pruebas fuera de la cadena de bloques.
Compresión en cadena: elimine información redundante o innecesaria de los datos, o use estructuras de datos optimizadas para la eficiencia del espacio. Los datos comprimidos se envían a la cadena de bloques y se pueden descomprimir cuando sea necesario. Contras: la compresión y descompresión de datos puede significar un cálculo adicional, pero esta latencia puede ser insignificante. El algoritmo de compresión utilizado puede tener un impacto negativo en la seguridad de los datos; ventaja: reduce los costos de datos.
Almacenamiento fuera de la cadena: almacene datos fuera de la cadena y coloque bloques de datos específicos en la cadena bajo demanda. Esto es relevante para soluciones que necesitan almacenar grandes cantidades de datos por algún motivo (por ejemplo, nodos de archivo Ethereum del bloque génesis). Contras: igual que la compresión en cadena; Pros: reduce aún más los costos de datos.
1**.2.3** Tercero de confianza
Una solución completa de cadena cruzada también debe incluir soluciones de mensajería cruzada con terceros de confianza (como oráculos, puentes centralizados, etc.).
1**.2.4** Sistema de prueba “universal”
En el caso de un mecanismo de plataforma de prueba de agregación compartida, la mensajería puede acelerarse al recibir bloques hash que se liquidan dentro de la plataforma de agregación, y la liquidación aquí también manejará la mensajería (pero si hay un problema con la plataforma de agregación ¿qué hacer?).
1**.2.5 Algunos problemas desconocidos de la mensajería entre cadenas ZK******
¿Es factible la mensajería entre cadenas sin un tercero de confianza (que puede ser una sola entidad o varias entidades)? ¿Cuál es un mecanismo eficiente para el paso de mensajes entre cadenas? En general, para Ethereum L2 (con acceso directo a los hashes de bloque de L1) y Ethereum mismo, si una cadena puede ejecutar un cliente ligero, etc., lo cual es suficiente para mensajes entre cadenas sin confianza.
¿El circuito ZK utilizado para la generación de prueba de cadena cruzada está correctamente escalado? En algunos casos, especialmente cuando la capa de consenso (que debe verificarse para las operaciones entre cadenas) es muy grande, el circuito utilizado para el paso de mensajes entre cadenas ZK puede ser mucho más grande que el almacenamiento acumulativo y en cadena, y la sobrecarga computacional también es muy grande. Presumiblemente, este problema se puede superar con un enfoque más centralizado.
2**、Ejemplo de solución de mensajería entre cadenas**
· Su****Succinct Labs utiliza un cliente ligero para verificar el consenso desde la cadena de origen hasta la capa de consenso de la cadena de destino. La idea es que exista un protocolo de cliente ligero para garantizar que los nodos puedan sincronizar los encabezados de bloque del estado final de la cadena de bloques. ZKP se utiliza para generar pruebas de consenso.
· La****grange Labs crea una prueba de estado de cadena cruzada no interactiva. Lagrange demuestra que la red es responsable de crear la raíz del estado. Cada nodo de Lagrange contiene una parte de la clave privada de un fragmento, que da fe del estado de una cadena en particular. Cada raíz de estado es una raíz de Verkle con signo de umbral que se puede usar para atestiguar el estado de una cadena en particular en un momento en particular. La raíz del estado es completamente general y se puede usar en una prueba de estado para probar el estado actual de cualquier contrato o billetera en la cadena.
· He****rodotus utiliza la prueba de almacenamiento ZKP para proporcionar contratos inteligentes y acceder a datos en la cadena de otras capas de Ethereum de forma sincrónica. Para la validación, utiliza mensajes nativos L1<>L2 para sincronizar bloques hash entre acumulaciones de Ethereum.
=nil; Foundation (Mina, L1) permite contratos inteligentes en Ethereum para verificar la validez del estado de Mina. Genere pruebas de estado para fines especiales, baratas de verificar en Ethereum (las pruebas locales de Mina en Ethereum son caras). Hipotéticamente (en algún momento en el futuro) las aplicaciones pueden usar directamente la herramienta de generación de prueba de Mina para verificar la validez de las transacciones entre cadenas. = nil; Foundation también tiene un mercado de pruebas donde los usuarios/proyectos pueden comprar/vender principalmente pruebas de SNARK que permiten el acceso a datos sin confianza.
Axiom: si Axiom ha generado un ZKP para el libro mayor hasta el momento, no necesita generar un ZKP para un bloque específico, puede pasar este ZKP a la cadena (como retransmisor) o incluso proporciona acceso a este ZKP.
3. Mensajes entre cadenas L2
*Descargo de responsabilidad: la mensajería entre cadenas aún está evolucionando para la mayor parte de L2. Todos los análisis a continuación se basan en información de fuente abierta. Dicho esto, las soluciones mencionadas en el artículo pueden estar en la etapa de exploración y prueba, y el resumen puede eventualmente adoptar otros métodos. *
**(1)**Taiko
Taiko almacena hashes de bloque para cada cadena. Para cada par de cadenas, implementa dos contratos inteligentes que almacenan los hashes de cada uno. En el ejemplo de L2←→L1, cada vez que se crea un bloque L2 en Taiko, los valores hash de los bloques periféricos en L1 se almacenan en el contrato TaikoL2. También en el caso de L1←→L2, el modo de operación es el mismo.
La última raíz de Merkle conocida almacenada en la cadena de destino se puede obtener llamando a getCrossChainBlockHash(0) en el contrato TaikoL1/TaikoL2 y obtener el valor/mensaje para verificar. El hash hermano de la última raíz de Merkle conocida se puede obtener llamando a la solicitud eth_getProof utilizando un RPC estándar en la "cadena de origen".
Luego, simplemente envíelos para que se verifiquen con los últimos hashes de bloque conocidos almacenados en una lista en la "cadena de destino". El validador tomará un valor (una hoja en el árbol de Merkle) y hashes hermanos para volver a calcular la raíz de Merkle y verificar que coincida con la raíz almacenada en la lista de hashes de bloque de la cadena de destino.
**(2)**Starknet
Starknet usa Prueba de almacenamiento para mensajería entre cadenas sin confianza.
Protocolo de mensajería L2→L1
· Durante la ejecución de una transacción de Starknet, un contrato en Starknet envía un mensaje L2→L1.
Los parámetros del mensaje (que contienen el contrato del receptor y los datos relacionados en L1) se agregan luego a la actualización de estado relevante (árbol de almacenamiento principal).
· Los mensajes L2 se almacenan en L1 del contrato inteligente.
· Emitir un evento en L1 (almacenar parámetros de mensaje).
Las direcciones del receptor en L1 pueden acceder y usar el mensaje como parte de una transacción L1 al volver a proporcionar los parámetros del mensaje.
· Los mensajes de cadena cruzada se almacenan en el árbol troncal.
L2 → L1
L1 → L2
**(3)**Optimismo
La comunicación entre L1 y L2 se implementa mediante dos contratos inteligentes especiales llamados "mensajeros".
· Para las transacciones de Optimism (L2) a Ethereum (L1), es necesario proporcionar una prueba de Merkle del mensaje en L1 después de escribir la raíz del estado. Después de que esta transacción de prueba se convierte en parte de la cadena L1, comienza el período de desafío de error. Después de este período de espera, cualquier usuario puede "finalizar" la transacción activando una segunda transacción en Ethereum, enviando un mensaje al contrato L1 de destino.
· Los mensajes de cadena cruzada se almacenan en el árbol troncal.
（4）Ar****bitrum
Los tickets que se pueden volver a intentar son el método canónico que usa Arbitrum para crear mensajes L1 a L2, es decir, transacciones L1 que inicializan los mensajes que se ejecutarán en L2. Se puede enviar un Reintentable en L1 por una tarifa fija (dependiendo únicamente del tamaño de los datos de la llamada). El árbol de estado principal se utiliza para la comunicación entre cadenas de formatos de datos personalizados en contratos inteligentes. El envío de un ticket reintentable en L1 es separable/asincrónico de la ejecución en L2. Los reintentos proporcionan atomicidad entre operaciones entre cadenas. Si la solicitud de transacción L1 se envía con éxito (es decir, sin retroceder), entonces la ejecución Reintentable en L2 tiene una fuerte garantía de que eventualmente tendrá éxito.
Arbitrum tiene dos troncos: la cadena Nitro se mantiene en el formato de árbol de estado de Ethereum, un árbol Merkle. El Árbol de Afirmación almacena el estado de la cadena Arbitrum confirmado en Ethereum a través de "afirmación". Las reglas que hacen avanzar la cadena Arbitrum son deterministas. Esto significa que, dado el estado de una cadena y algunos valores de entrada nuevos, solo hay una salida válida. Por lo tanto, si el árbol de prueba contiene varias hojas, como máximo una hoja puede representar un estado de cadena válido.
El sistema Outbox de Arbitrum permite cualquier llamada de contrato de L2 a L1, es decir, un mensaje se inicia desde L2 y finalmente se ejecuta en L1. Los mensajes L2 a L1 (también conocidos como "mensajes salientes") tienen mucho en común con los mensajes L1 a L2 de Arbitrum (reintentables), aunque existen algunas diferencias notables. Parte del estado L2 de una cadena Arbitrum, es decir, la parte atestiguada en cada RBlock, es la raíz de Merkle de todos los mensajes L2 a L1 en el historial de la cadena. Una vez que se confirma el RBlock probado (generalmente alrededor de una semana después de la prueba), la raíz de Merkle se incluye en el contrato de bandeja de salida y se publica en L1. El contrato de bandeja de salida permite a los usuarios ejecutar sus mensajes.
**(5)**Polígono zkEVM
· El Bridge SC de este zkEVM utiliza un árbol Merkle especial llamado Árbol de salida para cada red que participa en la comunicación o transacción de activos.
Utiliza raíces de Merkle (en un árbol de estado separado), se puede encontrar un diagrama de arquitectura de puente en github.
El despliegue de zkEVM Bridge SC ha realizado varios cambios en función del contrato de depósito de Ethereum 2.0. Por ejemplo, utiliza un árbol Merkle de solo anexar especialmente diseñado, pero utiliza la misma lógica que el contrato de depósito de Ethereum 2.0. Otras diferencias se relacionan con hashes base y nodos hoja.
La característica principal del contrato inteligente Polygon zkEVM Bridge es el uso del árbol de salida y el árbol de salida global, donde la raíz del árbol de salida global es la fuente principal del estado de verdad. Por lo tanto, L1 y L2 tienen dos administradores raíz de salida global diferentes, y Bridge SC tiene una lógica separada.
(6)S****croll
· Los contratos puente implementados en Ethereum y Scroll permiten a los usuarios pasar mensajes arbitrarios entre L1 y L2. Además de este protocolo de mensajería, también creamos un protocolo de puente sin confianza para permitir a los usuarios unir los activos ERC-20 entre L1 y L2. Para enviar un mensaje o fondos desde Ethereum a Scroll, un usuario llama a la transacción sendMessage en el contrato de Bridge. Los repetidores indexarán esta transacción en L1 y la enviarán al ordenante para que la incluya en los bloques L2. En el contrato puente L2, el proceso de enviar un mensaje de Scroll back to Ethereum es similar.
· Los mensajes entre cadenas se almacenan en colas de mensajes normales. El ordenante ingiere mensajes entre cadenas de esta cola y los agrega a la cadena como transacciones regulares.
**(7)**Era zksync
*Descargo de responsabilidad: el contenido de esta sección es solo sobre zksync Era, que puede ser diferente de los mensajes entre cadenas en ZK Stack, que es un marco modular para construir una supercadena ZK soberana. *
· Cada paquete de transacciones tiene un único mensaje L2->L1.
· No es posible enviar transacciones directamente de L2 a L1. Sin embargo, puede enviar mensajes de cualquier longitud desde zkSync Era a Ethereum y luego procesar los mensajes recibidos en Ethereum utilizando el contrato inteligente L1. zkSync Era tiene una función de prueba de solicitud que devolverá un parámetro booleano que indica si el mensaje se envió con éxito a L1. Recupere la prueba de Merkle contenida en el mensaje observando Ethereum o utilizando el método zks_getL2ToL1LogProof de la API zksync-web3.
· Para L1→L2, el contrato inteligente zkSync Era permite al remitente solicitar una transacción en Ethereum L1 y pasar los datos a zkSync Era L2.
· Contrato puente:
4. Conclusión
La comunicación entre cadenas es parte integral de las aplicaciones "imprescindibles" para la adopción masiva de blockchain (por ejemplo, la billetera de recuperación social entre cadenas descrita en el artículo de Vitalik). La mayoría de las soluciones de cadenas cruzadas actualmente en uso están diseñadas para L1←→L2 para cubrir la función de retiro. Estas soluciones se pueden extender a más cadenas de bloques. Pero al mismo tiempo, se pueden implementar soluciones de comunicación entre cadenas más avanzadas, como "estado de lectura directa" sin ninguna prueba o "prueba de almacenamiento" sin confianza. Para la mayoría de las L2, todavía hay margen de mejora en la comunicación entre cadenas.