Autor: Lisa A., Taiko Labs; Traducción: Golden Finance xiaozou
Este artículo explorará diferentes métodos de mensajería entre cadenas L2 desde la perspectiva del resumen, centrándose en la comunicación entre cadenas sin confianza. Analizaremos brevemente el enfoque del estado de lectura directa, el enfoque del cliente ligero y la prueba de almacenamiento. También cubriremos los mecanismos de agregación de pruebas, la transmisión de mensajes entre cadenas de terceros confiables y las soluciones principales de cadenas cruzadas de ZK. Finalmente, veamos cómo las 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 "integrado" que se puede utilizar 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 las raíces estatales
Tipo 1: lectura directa del estado raíz; se puede realizar mediante códigos de operación o precompilados. Sin embargo, aún no se ha implementado, por lo que no se requieren pruebas.
· Brecht Devos describió un posible método para leer directamente el estado en un artículo de investigación: “...podríamos exponer un contrato precompilado que puede llamar directamente a contratos inteligentes en la cadena de destino. Esta precompilación inserta y ejecuta directamente el código de contrato inteligente de. la otra cadena. Esto garantiza que el contrato inteligente siempre tenga acceso al último estado disponible de una manera eficiente y fácilmente demostrable”.
· También hay una descripción relacionada en la RFP de Optimism "Prueba de concepto de llamada estática remota".
Tipo 2: Generación de pruebas, es decir, probar una afirmación sobre una cadena de bloques en otra cadena de bloques.
Hay dos métodos de "mensajería entre cadenas con prueba":
· Comunicación entre cadenas sin confianza, es decir, sin un tercero de confianza (por ejemplo, utilizando clientes ligeros o prueba de almacenamiento). El enfoque sin confianza se puede utilizar tanto para que terceros generen pruebas como para que los participantes de la comunicación entre cadenas generen pruebas ellos mismos.
· Compartir pruebas entre diferentes acumulaciones para garantizar operaciones entre cadenas. Este método no se discutirá en este artículo. Actualmente se encuentra en la etapa de investigación y exploración y no se considera una solución que pueda usarse ampliamente.
1.2 Método de “paso de mensajes entre cadenas con prueba”
1.2.1 Mensajería entre cadenas de cliente ligero
Demostrar los datos de la cadena B.
· Obtener datos de prueba de Merkel del nodo completo de la cadena B (nodo de archivo si se requiere almacenamiento de prueba de 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 como datos de llamada al contrato de prueba en la cadena A;
· El contrato de prueba calcula el valor hash del bloque basándose en 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 verifica si el valor hash es válido;
· Los datos de prueba se verifican con la raíz del estado bytes32 en el encabezado del bloque.
1.2.2 Prueba de almacenamiento
Hay dos opciones de "flujo de trabajo" para la prueba de almacenamiento:
· Generar prueba de almacenamiento → uso en la cadena
· Generar prueba de almacenamiento → generar prueba zk → usar en la cadena
También puede haber una entidad que empaquete varias colecciones de pruebas en una sola prueba (incluidas las pruebas de almacenamiento y las pruebas zk). Este es un paso de optimización opcional y no se discutirá aún.
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 certificado de almacenamiento
· La prueba de almacenamiento nos permite utilizar compromisos de confidencialidad para demostrar que cierta información existe en la cadena de bloques y es auténtica;
· La prueba de almacenamiento ha sido parte de la comunidad criptográfica desde la llegada de los árboles Merkle en 1979. Sin embargo, los certificados de almacenamiento básicos suelen ser bastante grandes. La innovación moderna radica en combinar pruebas de almacenamiento con cálculos demostrables para crear pruebas concisas que puedan verificarse en cadena.
Para generar una prueba de almacenamiento, se debe proporcionar un bloque de datos específico y su ruta Merkle o Verkle asociada en el árbol Merkle. La ruta consta de los hashes hermanos necesarios para reconstruir el hash raíz utilizando el mismo algoritmo hash.
Para verificar la prueba de almacenamiento, el receptor puede volver a calcular el hash raíz utilizando los datos proporcionados y la ruta Merkle o Verkle. 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, la prueba de almacenamiento de tipo Ethereum pesa aproximadamente 4 kb, lo cual es bastante grande para liberar toda la prueba de almacenamiento en la cadena de destino, ya que la verificación de la prueba sería muy costosa. Por lo tanto, es razonable utilizar ZKP (por ejemplo, ZK-SNARK) para la compresión, lo que puede hacer que la prueba sea más pequeña y el costo de verificación más bajo.
(3) Desenrollar ZKP
Después de obtener ZKP, los usuarios de la cadena de destino pueden desenrollar las pruebas que obtuvieron (por ejemplo, acceder al estado histórico a través de encabezados de bloque o hashes de bloque).
El desenrollado se puede realizar de las siguientes maneras:
Acumulación en cadena: todo el proceso de reconstrucción del encabezado del bloque a partir de la prueba se realiza directamente en la cadena de bloques. Desventajas: altas tarifas de gas y consumo de recursos informáticos. Ventajas: sin tiempo de prueba adicional, baja latencia porque no es necesario generar pruebas fuera de la cadena de bloques.
Compresión en cadena: elimine información redundante o innecesaria de los datos, o utilice 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. Desventajas: comprimir y descomprimir datos puede implicar cálculos adicionales, pero este retraso puede ser insignificante. El algoritmo de compresión utilizado puede tener un impacto negativo en la seguridad de los datos. Ventajas: costes de datos reducidos.
Almacenamiento fuera de la cadena: almacene datos fuera de la cadena y coloque bloques de datos específicos en la cadena a pedido. Esto es relevante para soluciones que necesitan almacenar grandes cantidades de datos por algún motivo (por ejemplo, nodos de archivo de Ethereum a partir del bloque de génesis). Desventajas: Igual que la compresión en cadena. Ventajas: reduce aún más los costos de datos.
1.2.3 Tercero de confianza
Una solución completa entre cadenas también debería implicar una solución de mensajería cruzada con un tercero confiable (como oráculos, puentes centralizados, etc.).
1.2.4 Sistemas de prueba “universales”
En el caso de utilizar un mecanismo de plataforma de agregación de pruebas compartida, la entrega de mensajes se puede acelerar recibiendo hashes de bloque establecidos dentro de la plataforma de agregación, y la liquidación aquí también manejará la entrega de mensajes (pero si algo sale mal con la plataforma de agregación de pruebas, ¿qué hacer? ).
1.2.5 Algunos problemas desconocidos en la mensajería entre cadenas de 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 eficaz para la mensajería entre cadenas? En términos generales, para Ethereum L2 (que tiene acceso directo a los hashes de bloque de L1) y el propio Ethereum, si una cadena puede ejecutar un cliente ligero, etc. en otra cadena, puede verificar los orígenes desde ese encabezado de bloque de cadena externo, lo cual es suficiente para personas sin confianza. mensajería entre cadenas.
¿Se utiliza el circuito ZK para la generación de prueba de cadena cruzada en una escala adecuada? En algunos casos, especialmente cuando la capa de consenso (que requiere verificación de las operaciones entre cadenas) es muy grande, los circuitos utilizados para la mensajería entre cadenas ZK pueden ser órdenes de magnitud mayores que el almacenamiento acumulado y en cadena, y la sobrecarga computacional también será importante. Es de suponer que este problema podría superarse con un enfoque más centralizado.
2. Ejemplo de solución de mensajería entre cadenas
· Succinct Labs utiliza clientes ligeros para verificar el consenso desde la cadena de origen hasta la capa de consenso de la cadena de destino. La idea específica es que existe 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.
· Lagrange Labs crea pruebas de estado entre cadenas no interactivas. La red de prueba de Lagrange es responsable de crear el estado raíz. Cada nodo de Lagrange contiene parte de una clave privada fragmentada, que se utiliza para probar el estado de una cadena específica. Cada raíz de estado es una raíz de Verkle con signo de umbral que se puede utilizar para probar el estado de una cadena específica en un momento específico. La raíz de estado es completamente universal y se puede utilizar en pruebas de estado para demostrar el estado actual de cualquier contrato o billetera en la cadena.
· Herodotus utiliza prueba de almacenamiento ZKP para proporcionar contratos inteligentes y acceder sincrónicamente a datos en cadena de otras capas de Ethereum. Para la verificación, utiliza mensajería nativa L1<>L2 para sincronizar hashes de bloques entre paquetes acumulativos de Ethereum.
· =nil; Foundation (Mina, L1) permite contratos inteligentes en Ethereum para verificar la validez de los estados de Mina. Genere pruebas de estado para fines especiales que sean económicas de verificar en Ethereum (las pruebas nativas de Mina son caras en Ethereum). Se supone que (en algún momento en el futuro) las aplicaciones pueden usar directamente las herramientas de generación de pruebas de Mina para verificar la validez de las transacciones entre cadenas. =nil; Foundation también tiene un Proof Market donde los usuarios/proyectos pueden comprar/vender principalmente certificados SNARK que permiten el acceso a datos sin confianza.
Axiom: si Axiom ha generado un ZKP para el libro mayor hasta ahora (no necesita generar un ZKP para un bloque de datos específico), puede pasar este ZKP a la cadena (como un repetidor) e incluso proporcionar acceso a esa visita de ZKP. .
3. Mensajería entre cadenas L2
Descargo de responsabilidad: la mensajería entre cadenas todavía está evolucionando para la mayoría de las L2. Todo el análisis a continuación se basa en información de código abierto. Dicho esto, las soluciones mencionadas en el artículo pueden estar en las etapas de exploración y prueba, y el resumen puede eventualmente adoptar otros métodos.
(1) Taiko
· Taiko almacena el valor hash del bloque de cada cadena. Para cada par de cadenas, implementa dos contratos inteligentes que almacenan los hashes de cada uno. En el caso de L2←→L1, cada vez que se crea un bloque L2 en Taiko, el hash del bloque circundante en L1 se almacena en el contrato TaikoL2. Se utiliza el mismo método de operación en el caso de L1←→L2.
· 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 a verificar. El último hash hermano conocido de la raíz de Merkle se puede obtener llamando a la solicitud eth_getProof utilizando RPC estándar en la "cadena de origen".
· Luego, simplemente envíalos para que se verifiquen con el último hash de bloque conocido almacenado en una lista en la "cadena de destino". El validador tomará un valor (una hoja en el árbol de Merkle) y el hash hermano para volver a calcular la raíz de Merkle y verificar si coincide con la raíz almacenada en la lista de hashes de bloque de la cadena objetivo.
(2) Red de estrellas
Starknet utiliza prueba de almacenamiento para mensajes entre cadenas sin confianza.
Protocolo de mensajería L2 → L1
· Durante la ejecución de una transacción Starknet, el contrato en Starknet envía un mensaje L2→L1.
· Luego agregue los parámetros del mensaje (que contienen el contrato del receptor y los datos relacionados en L1) 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).
· La dirección del destinatario en L1 puede acceder y utilizar el mensaje como parte de la transacción L1 volviendo a proporcionar los parámetros del mensaje.
· Los mensajes entre cadenas se almacenan en el árbol troncal.
L2 → L1
L1 → L2
(3) Optimismo
· La comunicación entre L1 y L2 se logra mediante dos contratos inteligentes especiales llamados "mensajeros".
· Para transacciones de Optimismo (L2) a Ethereum (L1), es necesario proporcionar una prueba Merkle sobre el mensaje en L1 después de escribir la raíz del estado. Una vez que la transacción de prueba pasa a formar 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 el mensaje al contrato L1 de destino.
· Los mensajes entre cadenas se almacenan en el árbol troncal.
(4) Arbitraje
· Los tickets reintentables son el método canónico de Arbitrum para crear mensajes L1 a L2, es decir, transacciones L1 que inicializan mensajes que se ejecutarán en L2. Se puede enviar un reintento en L1 por una tarifa fija (dependiendo únicamente del tamaño de los datos de 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 se puede desacoplar/asincrónicamente de la ejecución en L2. Los reintentos proporcionan atomicidad entre operaciones entre cadenas. Si la solicitud de transacción L1 se envía exitosamente (es decir, no hay reversión), entonces existe una fuerte garantía de que la ejecución reintentable en L2 eventualmente tendrá éxito.
· Arbitrum tiene dos troncos: la cadena Nitro se mantiene en el formato de árbol estatal de Ethereum, que es un árbol Merkle. El árbol de aserción almacena el estado de la cadena Arbitrum confirmado en Ethereum mediante "aserción". Las reglas para hacer 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 (reintentables) de Arbitrum, aunque existen algunas diferencias notables. Parte del estado L2 de la cadena Arbitrum (la parte que se certifica en cada RBlock) es la raíz Merkle de todos los mensajes L2 a L1 en el historial de la cadena. Después de que se confirma el RBlock probado (generalmente aproximadamente una semana después de la prueba), la raíz de Merkle contenida en el contrato de la Bandeja de salida se publica en L1. El contrato de Bandeja de salida permite a los usuarios ejecutar sus mensajes.
(5) Polígono zkEVM
· Bridge SC de zkEVM utiliza un árbol Merkle especial llamado árbol de salida para cada red que participa en comunicaciones o transacciones de activos.
· Utiliza raíces de Merkle (en un árbol de estado separado) y se puede encontrar un diagrama de arquitectura de puente en github.
· La implementación de zkEVM Bridge SC ha realizado varios cambios basados en el contrato de depósito de Ethereum 2.0. Por ejemplo, utiliza un árbol Merkle de solo anexos especialmente diseñado, pero adopta la misma lógica que el contrato de depósito Ethereum 2.0. Otras diferencias están relacionadas con los hash base y los nodos hoja.
· La característica principal del contrato inteligente Polygon zkEVM Bridge es el uso de Exit Tree y Exit Tree global, donde la raíz del Exit Tree global es la principal fuente del estado de verdad. Por lo tanto, hay dos administradores raíz de salida globales diferentes para L1 y L2, y una lógica separada para Bridge SC.
(6) Desplazarse
· El contrato puente implementado en Ethereum y Scroll permite 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 conectar activos ERC-20 entre L1 y L2. Para enviar un mensaje o fondos desde Ethereum a Scroll, el usuario llama a la transacción sendMessage en el contrato Bridge. El relé indexará esta transacción en L1 y la enviará al secuenciador para su inclusión en el bloque L2. En el contrato puente L2, el proceso de envío de mensajes desde Scroll a Ethereum es similar.
· Los mensajes entre cadenas se almacenan en colas de mensajes normales. El secuenciador ingiere mensajes entre cadenas de esta cola y los agrega a la cadena como transacciones regulares.
(7)Era zksync
Descargo de responsabilidad: esta sección trata solo sobre la era zksync y puede diferir de la mensajería entre cadenas en ZK Stack, un marco modular para construir supercadenas ZK soberanas.
· Cada paquete de transacciones tiene un mensaje L2->L1 independiente.
· No es posible enviar transacciones directamente desde L2 a L1. Sin embargo, puede enviar mensajes de cualquier longitud a Ethereum desde zkSync Era y luego usar contratos inteligentes L1 para procesar los mensajes recibidos en Ethereum. zkSync Era tiene una función de prueba de solicitud que devolverá un parámetro booleano que indica si el mensaje se envió correctamente a L1. Recupere la prueba de Merkle contenida en el mensaje observando en 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: https://github.com/matter-labs/era-contracts/blob/main/ethereum/contracts/bridge/L1ERC20Bridge.sol
4. Conclusión
La comunicación entre cadenas es indispensable para 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 Buterin). La mayoría de las soluciones de cadena cruzada que se utilizan actualmente están diseñadas para que L1←→L2 cubra la funcionalidad de retiro. Estas soluciones se pueden extender a más blockchains. Pero al mismo tiempo, se pueden implementar soluciones de comunicación entre cadenas más avanzadas, como "estado de lectura directa" que no requiere prueba alguna o "prueba de almacenamiento" que no requiere confianza. Para la mayoría de las L2, todavía hay espacio para el desarrollo y el progreso en la comunicación entre cadenas.