Across V4 presenta una arquitectura de cadena cruzada nueva y mejorada.
El sistema combina intenciones y pruebas de conocimiento cero (ZKP) para expandirse a más cadenas, más rápido.
Aquí está el desglose técnico. 🧵
Anteriormente, Across usaba "puentes canónicos" o adaptadores específicos de la cadena para verificar los mensajes del HubPool de Ethereum.
Esto funcionó bien para L2 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 existe una forma canónica de verificar el estado de Ethereum. Esto significaba construir adaptadores personalizados o no admitir esas cadenas en absoluto.
Ninguna de esas son soluciones óptimas. Así que descubrimos una mejor manera de usar ZKP.
Este es el proceso:
Cuando los repetidores completan pedidos de cadena cruzada, las transacciones se agrupan en paquetes de reembolso de repetidores, que luego son verificados por Optimistic Oracle de @UMAProtocol.
Esto siempre sucede en la red principal de Ethereum.
Una vez que se verifica un paquete, Across HubPool activa el proceso de liquidación.
Luego escribe los hashes de mensajes de pago en el contrato HubPoolStore en ranuras de almacenamiento específicas.
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 pagar a un repetidor en una cadena de destino.
Tenga en cuenta que los mensajes L1 → L2 pueden representar varios reembolsos (incluidos los rellenos lentos). Esto se debe a que son haces de raíces.
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 anclaje para la verificación ZK en sentido descendente.
Un servicio llamado finalizador escucha esos eventos.
Una vez que detecta uno nuevo, inicia un proceso para demostrar que el hash del mensaje se escribió realmente en Ethereum.
Cada mensaje, para el que 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 finalidad de Ethereum no es instantánea.
Una vez que el finalizador envía los datos a la API de ZK, la API espera a través de la ventana de finalidad 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 se incluyó en ese bloque o antes, las firmas requeridas estarán disponibles para comenzar a generar la prueba ZK.
El finalizador consulta la API de ZK para generar una prueba de que se escribió un hash de mensaje específico 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 retransmisores en cualquier cadena de destino.
La API de ZK prepara entradas de prueba que incluyen (pero no se limitan a):
- Encabezados de baliza finalizados
- Firmas del comité de sincronización
- Pruebas de almacenamiento de Merkle de la capa de ejecución de Ethereum
Estos forman la base para generar la prueba.
Across implementa una pila genérica en las cadenas de destino:
- Un contrato de verificador (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 forma 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 gastos generales de integración.
Solo intenciones + ZK.
¿Por qué es esto un gran problema?
Expande 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 puente centralizado y refuerza el papel de Ethereum como la raíz de la verdad entre cadenas.
8.26 K
42
El contenido al que estás accediendo se ofrece por terceros. A menos que se indique lo contrario, OKX no es autor de la información y no reclama ningún derecho de autor sobre los materiales. El contenido solo se proporciona 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 enlazado para más detalles e información. OKX no es responsable del contenido alojado en sitios de terceros. Los holdings de activos digitales, incluidos stablecoins y NFT, suponen un alto nivel de riesgo y pueden fluctuar mucho. Debes considerar cuidadosamente si el trading o holding de activos digitales es adecuado para ti según tu situación financiera.