Across V4 presenta una nueva y mejorada arquitectura crosschain.
El sistema combina intenciones y pruebas de conocimiento cero (ZKPs) para expandirse a más cadenas, más rápido.
Aquí está el desglose técnico. 🧵
Anteriormente, Across utilizaba "puentes canónicos" o adaptadores específicos de cadena para verificar mensajes del HubPool de Ethereum.
Esto funcionaba bien para L2s como Arbitrum y Optimism, que exponen el estado finalizado de Ethereum.
Pero este diseño era limitante…
Para cadenas que no son EVM como BSC, este modelo se descompone.
No hay una forma canónica de verificar el estado de Ethereum. Esto significaba construir adaptadores personalizados o no soportar esas cadenas en absoluto.
Ninguna de esas es una solución óptima. Así que encontramos una mejor manera utilizando ZKPs.
Aquí está el proceso:
Cuando los relayers completan órdenes crosschain, las transacciones se agrupan en paquetes de reembolso de relayers, que luego son verificados por el Oracle Optimista de @UMAProtocol.
Esto siempre ocurre en la red principal de Ethereum.
Una vez que un paquete es verificado, el Across HubPool activa el proceso de liquidación.
Luego escribe los hashes de los mensajes de reembolso en el contrato HubPoolStore en espacios de almacenamiento específicos.
Este evento de almacenamiento también ocurre en la red principal de Ethereum.
Cada hash de mensaje en el contrato HubPoolStore corresponde a una intención de reembolsar a un relayer en una cadena de destino.
Ten en cuenta que los mensajes de L1 → L2 pueden representar múltiples reembolsos (incluyendo llenados lentos). Esto se debe a que son paquetes raíz.
Cuando el contrato HubPoolStore escribe un hash de mensaje almacenado, emite un evento StoredCallData.
Este evento contiene el hash del mensaje y la ranura de almacenamiento.
El evento + los datos almacenados forman el ancla para la verificación ZK aguas abajo.
Un servicio llamado el finalizador escucha esos eventos.
Una vez que detecta uno nuevo, inicia un proceso para probar que el hash del mensaje fue efectivamente escrito en Ethereum.
Cada mensaje, para el cual se almacena el hash, tiene un objetivo que puede ser específico para su cadena.
Esta prueba permite que el mensaje se ejecute de forma segura en la cadena de destino.
Pero la finalización de Ethereum no es instantánea.
Una vez que el finalizador envía los datos a la API ZK, la API espera a través de la ventana de finalización de Ethereum antes de generar una prueba.
Para generar una prueba ZK válida, el comité de sincronización de Ethereum debe aprobar un bloque finalizado específico.
Si el mensaje fue incluido en o antes de ese bloque, las firmas requeridas estarán disponibles para comenzar a generar la prueba ZK.
El finalizador consulta la API ZK para generar una prueba de que un hash de mensaje específico fue escrito en una ranura de almacenamiento conocida de HubPoolStore en un bloque de Ethereum finalizado.
Esto permite la verificación sin confianza de los reembolsos de los relayers en cualquier cadena de destino.
La API ZK prepara entradas de prueba que incluyen (pero no se limitan a):
- Encabezados de faros finalizados
- Firmas del comité de sincronización
- Pruebas Merkle de almacenamiento de la capa de ejecución de Ethereum
Estos forman la base para generar la prueba.
Across despliega una pila genérica en cadenas de destino:
- Un contrato Verifier (valida la prueba ZK)
- SP1Helios de @Succinct (almacena el estado finalizado de Ethereum)
- Contrato UniversalSpokepool (verifica la autenticidad de los mensajes durante la ejecución)
Una vez que se verifica la prueba ZK y se confirma el estado, executeMsg() puede ejecutar de manera segura la carga útil en la cadena de destino.
Sin confianza. Seguro. Universal.
Esto significa que Across ya no necesita adaptadores personalizados para cada cadena.
Solo un pipeline que funciona en todas partes:
storeMsg() en Ethereum → prueba ZK → executeMsg() en cualquier cadena de destino que pueda verificar la prueba SP1Helios.
Sin suposiciones de confianza.
Sin sobrecarga de integración.
Solo Intenciones + ZK.
¿Por qué es esto un gran problema?
Amplía drásticamente el alcance de Across al desbloquear el soporte para cadenas de cola larga que no pueden verificar el estado de Ethereum de forma nativa y no tienen puentes canónicos.
Esto hace que la incorporación sea más rápida, segura y escalable.
Across no necesita un puente canónico para estas cadenas. Solo necesita la capacidad de verificar una prueba ZK del estado de Ethereum.
Esto reduce la sobrecarga de integración, evita el riesgo de puentes centralizados y refuerza el papel de Ethereum como la raíz de la verdad entre cadenas.
7,77 mil
42
El contenido de esta página lo proporcionan terceros. A menos que se indique lo contrario, OKX no es el autor de los artículos citados y no reclama ningún derecho de autor sobre los materiales. El contenido se proporciona únicamente con fines informativos y no representa las opiniones de OKX. No pretende ser un respaldo de ningún tipo y no debe ser considerado como un consejo de inversión o una solicitud para comprar o vender activos digitales. En la medida en que la IA generativa se utiliza para proporcionar resúmenes u otra información, dicho contenido generado por IA puede ser inexacto o incoherente. Lee el artículo vinculado para obtener más detalles e información. OKX no es responsable del contenido alojado en sitios de terceros. El holding de activos digitales, incluyendo stablecoins y NFT, implican un alto grado de riesgo y pueden fluctuar en gran medida. Debes considerar cuidadosamente si el trading o holding de activos digitales es adecuado para ti a la luz de tu situación financiera.