¿Cómo operan las cadenas compatibles con ADI Chain L3? Modelos de despliegue y flujo de liquidación

Última actualización 2026-07-22 03:21:01
Tiempo de lectura: 9m
Las cadenas L3 compatibles con ADI Chain son ZK Rollups de Layer 3 que se liquidan en ADI L2, que a su vez se liquida en Ethereum L1, formando así una cadena de validez L3→L2→L1. Cada L3 cuenta con su propio Sequencer, Prover y contrato Diamond Proxy, mientras que Bridgehub y StateTransitionManager se comparten; los lotes se liquidan en L2 usando Commit, Prove y Execute, y la finalidad se transmite hacia arriba en el stack.

Las cadenas compatibles L3 de ADI Chain son Rollups de conocimiento cero de capa 3 que se liquidan en ADI Chain (L2), mientras que L2 se liquida en la red principal de Ethereum (L1). Las instituciones pueden operar cadenas independientes según la jurisdicción o la línea de negocio y definir políticas de cumplimiento adaptadas. De acuerdo con el modelo de seguridad dual descrito en el resumen de ADI Chain, L3 hereda garantías criptográficas tanto de L2 como de L1, aislando los entornos de ejecución y los dominios de cumplimiento del estado compartido de L2.

Para gobiernos, bancos y consorcios industriales, L3 permite "un ecosistema, reglas diferentes": los activos regulados circulan en cadenas dedicadas, las aplicaciones abiertas funcionan en otra L3 o en L2, y todas las capas se interconectan mediante el puente de L2.

¿Dónde se encuentra L3 en la arquitectura por capas de ADI Chain?

ADI Chain utiliza una jerarquía de liquidación de tres niveles: L3→L2→L1. Las cadenas L3 ejecutan transacciones localmente y mantienen estados independientes; L2 (ADI Chain) verifica las pruebas de validez por lotes de L3 y almacena las raíces de estado de L3; L1 (Ethereum) verifica las pruebas por lotes de L2 y finaliza el estado global. Cada capa transmite seguridad hacia arriba mediante pruebas de validez de conocimiento cero, impidiendo que transiciones de estado inválidas sean aceptadas por una capa superior.

A diferencia del despliegue de DApps directamente en L2, L3 ofrece un aislamiento físico de ejecución: cada L3 tiene su propio Sequencer, Prover y contrato Diamond Proxy, cuyos estados no interfieren entre sí. Varias L3 pueden desplegarse en el mismo ecosistema, compartiendo contratos de infraestructura como Bridgehub (registro de cadenas) y StateTransitionManager (STM). ADI L2 alcanza un rendimiento aproximado de 2 000–10 000 TPS; la incorporación de múltiples L3 permite escalar aún más la capacidad por aplicación o jurisdicción.

Capa Ubicación de ejecución Destino de envío de pruebas Latencia típica de confirmación
Cadena L3 Sequencer local de L3 ADI Chain (L2) Segundos (confirmación suave)
ADI Chain (L2) Sequencer de L2 Red principal de Ethereum (L1) Minutos (confirmación L2)
Ethereum (L1) Contratos verificador Finalización de raíz de estado Horas (finalidad L1)

La tabla muestra que L3 no es una cadena pública independiente, sino un dominio de ejecución personalizable integrado en ADI L2 y Ethereum L1. ADI L2, como zkRollup, hereda la seguridad económica de Ethereum; L3 añade una capa adicional de cumplimiento institucional.

Arquitectura por capas de ADI Chain L3: de L3 a L2 a Ethereum L1 Figura 1. Posición de las cadenas compatibles ADI Chain L3 en la arquitectura por capas L3→L2→L1 y relación entre los componentes principales.

¿Cuáles son los componentes principales del ecosistema L3?

El ecosistema L3 despliega infraestructura compartida en la capa de liquidación L2 y contratos específicos de cadena y nodos operativos en cada L3. Bridgehub actúa como registro central, gestionando la correspondencia entre ID de cadena y direcciones de contrato, el enrutamiento de mensajes entre cadenas y la configuración a nivel de ecosistema. StateTransitionManager se encarga del registro de nuevas cadenas, las actualizaciones de protocolo y la gestión de parámetros de verificación compartidos. Cada cadena L3 cuenta con un contrato Diamond Proxy bajo el patrón Facet para actualizaciones modulares, gestionando el envío y verificación por lotes, almacenamiento de raíces de estado y administración de validadores.

En la operación de L3, cada cadena ejecuta un Sequencer, un Prover y un conjunto de billeteras Operator (responsables de Commit, Prove y Execute respectivamente). En L2, el Prover de L2 agrega transacciones nativas de L2 y liquidaciones de L3 en pruebas enviadas a L1. Validator Timelock impone un retraso entre Commit y Execute, permitiendo detectar anomalías.

El diseño Facet de Diamond Proxy permite actualizar de forma independiente la lógica de ejecución, consulta y gestión. La combinación de infraestructura de registro compartida en L2 con estado de ejecución aislado en cada L3 es una característica distintiva de ADI Chain frente al modelo general de L2 "una sola cadena, muchas aplicaciones"; en la comparación ADI Chain vs Arbitrum y Base, el soporte nativo de L3 y el modelo Bridgehub son diferenciadores clave.

¿Cuáles son los tres modelos de despliegue para cadenas L3?

ADI Chain L3 admite modelos gestionados por ADI, operados por el cliente y híbridos, cubriendo necesidades institucionales desde cero operaciones hasta control total.

Modelo Sequencer Prover Claves de contrato Mejor para
Gestionado por ADI Operado por ADI Pruebas generadas por ADI ADI mantiene claves de gobernanza y operación Instituciones que buscan despliegue llave en mano sin carga de infraestructura
Operado por cliente Cliente ejecuta nodos Cliente opera nodos GPU de prueba Claves transferidas a billeteras del cliente Instituciones que requieren control total sobre operaciones y soberanía de datos
Híbrido Cliente o ADI (configurable) Cliente o ADI (configurable) Gobernanza al cliente; operaciones pueden delegarse a ADI Instituciones que buscan control de gobernanza con operaciones externalizadas opcionalmente

El despliegue de contratos utiliza control de acceso basado en roles: Governor gestiona actualizaciones de protocolo, Admin gestiona acciones de emergencia, Operator ejecuta Commit por lotes, Prove Operator envía pruebas y Execute Operator ejecuta lotes verificados. La propiedad puede transferirse completamente a un multisig del cliente o entregarse en fases. El ecosistema L3 sigue un patrón de "desplegar una vez, añadir cadenas incrementalmente": Bridgehub y STM se despliegan una vez a nivel de ecosistema y nuevas cadenas L3 se incorporan como contratos independientes.

En modo operado por cliente, el Prover requiere GPU NVIDIA H100 o H200 (70–140 GB VRAM) y memoria del sistema de 64 GB o más; el Sequencer requiere al menos 8 núcleos de CPU, 32 GB de RAM y un endpoint público de transacciones. Las billeteras Operator deben tener $ADI tokens como gas de L2 para operaciones on-chain en Commit, Prove y Execute.

¿Cómo funciona el flujo de liquidación Commit-Prove-Execute?

Cuando los lotes de L3 se liquidan en L2, pasan por Commit, Prove y Execute. El Sequencer empaqueta las transacciones de L3 en lotes; el Operator envía una transacción Commit a L2 que lleva diferencias de estado (cambios en slots de almacenamiento), información de despliegue de contratos y hashes de mensajes L2→L3—no instantáneas completas de estado—para reducir el coste de datos.

En la fase Prove, el Prover genera una prueba de validez utilizando el sistema Airbender (FRI/STARK → FFLONK SNARK pipeline), garantizando criptográficamente que las transiciones de estado cumplen las reglas de ejecución de L3. En la fase Execute, activada tras la verificación de la prueba en L2, la nueva raíz de estado de L3 se escribe en el contrato Diamond Proxy y el lote se marca como finalizado.

Fase Operator Contenido enviado Resultado en L2
Commit Operator Diferencias de estado, info de despliegue, hashes de mensajes Datos del lote on-chain, esperando prueba
Prove Prove Operator Prueba de validez ZK Prueba verificada por contrato verificador
Execute Execute Operator Ejecutar lote verificado Raíz de estado de L3 actualizada, lote finalizado

Un ciclo completo de liquidación consume aproximadamente 747 000 Gas en total (Commit ~136 000, Prove ~494 000, Execute ~117 000), cada fase pagada en $ADI desde billeteras Operator. En producción, los Provers FRI y SNARK pueden ejecutarse en paralelo en particiones GPU separadas, mejorando el rendimiento de lotes en aproximadamente 15 %–20 %; un solo Prover en la configuración objetivo soporta unos 15–20 TPS.

Flujo de liquidación Commit Prove Execute de ADI Chain L3 con probador Airbender Figura 2. Flujo desde el empaquetado de transacciones hasta Commit, Prove y Execute de liquidación en L2 para un lote L3.

La configuración recomendada de Prover es NVIDIA H200 (140 GB VRAM), con 2 Provers FRI en paralelo y 1 Prover SNARK dedicado (~33 GB VRAM). Las instituciones en modo operado por cliente deben planificar clústeres GPU y conexiones RPC L2 de baja latencia con antelación para mantener la cadencia de envío de lotes.

¿Cómo se propaga la finalidad de L3 a Ethereum?

Los tipos de confirmación de transacciones L3 evolucionan a lo largo de L3→L2→L1 conforme avanza la liquidación. Tras incluir el Sequencer de L3 una transacción en un bloque, los usuarios reciben confirmación suave en segundos y pueden utilizar los activos transferidos de inmediato; la confirmación suave depende de la honestidad del Sequencer y aún no tiene finalidad criptográfica.

Tras el Commit de un lote L3 en L2, entra en la etapa de confirmación L2 (normalmente minutos). Una vez completados Prove y Execute en L2, la raíz de estado de L3 se escribe en el contrato de la cadena L2 y no puede revertirse. El Prover de L2 prueba el estado de L2—including liquidaciones de L3—a Ethereum L1; tras la confirmación por contratos verificador en L1, la cadena de liquidación completa alcanza finalidad L1 (normalmente horas).

Las liquidaciones grandes o los retiros entre cadenas deben esperar confirmación L2 o L1; las interacciones cotidianas pueden basarse en confirmación suave. Validator Timelock introduce un retraso configurable entre Commit y Execute, reservando tiempo para detección de anomalías.

¿Qué casos de uso se adaptan a cadenas L3 compatibles?

L3 responde a la lógica de "aislamiento de reglas, seguridad compartida": los bancos operan vías soberanas de stablecoin, los gestores de activos despliegan contratos RWA con acceso KYC, y los gobiernos pueden tokenizar datos por jurisdicción. Los despliegues operados por cliente implican responsabilidad por clústeres GPU y listas blancas RPC; los gestionados por ADI trasladan operaciones a ADI.

Resumen

Las cadenas compatibles L3 de ADI Chain utilizan una arquitectura ZK Rollup de tres capas (L3→L2→L1) para que las instituciones hereden la seguridad de Ethereum y obtengan dominios de ejecución independientes con reglas de cumplimiento adaptadas por jurisdicción. Bridgehub y StateTransitionManager proporcionan infraestructura de registro y actualización compartida; cada L3 mantiene aislamiento de estado mediante Diamond Proxy, un Sequencer y Prover independientes. Los lotes se liquidan en L2 mediante Commit, Prove y Execute; el sistema de pruebas Airbender y la infraestructura GPU (H100/H200) permiten la generación de pruebas de validez; la finalidad se propaga desde la confirmación suave de L3 hasta la finalidad criptográfica de L2 y L1. Los tres modelos de despliegue cubren diferentes necesidades operativas y de gobernanza, adecuados para stablecoins soberanas, RWA, pagos transfronterizos y tokenización de datos gubernamentales.

Preguntas frecuentes

¿Qué es un L3 en ADI Chain?

Un L3 es un ZK Rollup de capa 3 que se liquida en ADI Chain (L2), permitiendo a instituciones, gobiernos o consorcios industriales operar cadenas independientes por jurisdicción con políticas de cumplimiento personalizadas. Cada L3 tiene su propio Sequencer, Prover y contrato Diamond Proxy, hereda seguridad de doble capa vía L2 y Ethereum, y comparte infraestructura de registro Bridgehub con otras L3 del ecosistema.

¿Cuál es la relación entre ADI Chain y Ethereum?

ADI Chain funciona como un zkRollup de L2 en Ethereum; las transiciones de estado por lotes en L2 requieren que los contratos verificador de L1 validen pruebas ZK antes de la finalización. Las cadenas L3 se liquidan adicionalmente en ADI L2, formando una cadena de pruebas de validez de tres capas L3→L2→L1. Los activos pueden moverse entre L1, L2 y L3 mediante puentes, con el modelo de seguridad heredando la seguridad económica de Ethereum en cada nivel.

¿ADI Chain es seguro?

ADI Chain utiliza pruebas de validez ZK, por lo que el estado inválido no puede ser aceptado en L1; los lotes de L3 también deben pasar verificación L2 antes de la finalización. El Sequencer proporciona confirmación suave en segundos; la finalidad criptográfica requiere verificación de pruebas en L2 y L1. Usuarios e instituciones deben considerar riesgos residuales en contratos de puente, gestión de claves operativas, infraestructura GPU autogestionada de L3 y la ventana entre confirmación suave y finalidad L1.

¿Qué modelos de despliegue están disponibles para cadenas L3?

ADI Chain L3 admite tres modelos: gestionado por ADI (ADI opera Sequencer, Prover y contratos), operado por cliente (la institución ejecuta nodos e infraestructura de pruebas GPU y mantiene las claves) y híbrido (la gobernanza permanece con el cliente, mientras que Sequencer y Prover pueden asignarse de forma flexible). La elección depende de cómo la institución equilibre carga operativa, soberanía de control y flexibilidad de cumplimiento.

¿Cuál es el flujo Commit-Prove-Execute para lotes L3?

El Sequencer de L3 empaqueta transacciones en lotes; el Operator envía diferencias de estado a L2; el Prover genera una prueba de validez ZK mediante el sistema Airbender y envía una transacción Prove; tras la verificación en L2, el Execute Operator activa la ejecución, escribiendo la raíz de estado de L3 en el contrato de cadena y finalizando el lote. Las tres fases consumen aproximadamente 747 000 Gas, pagados en $ADI.

¿Qué hardware se requiere para operar un Prover L3?

Los entornos de producción requieren GPU NVIDIA H100 o H200 con al menos 70 GB VRAM (140 GB recomendados), 64 GB o más de memoria del sistema y almacenamiento NVMe SSD para datos de testigos. La configuración recomendada incluye 2 Provers FRI en paralelo y 1 Prover SNARK dedicado (~33 GB VRAM), apuntando a unos 15–20 TPS. El Sequencer requiere al menos 8 núcleos de CPU, 32 GB de RAM y un endpoint público de transacciones.

Autor: Jayne
Descargo de responsabilidad
* La información no pretende ser ni constituye un consejo financiero ni ninguna otra recomendación de ningún tipo ofrecida o respaldada por Gate.
* Este artículo no se puede reproducir, transmitir ni copiar sin hacer referencia a Gate. La contravención es una infracción de la Ley de derechos de autor y puede estar sujeta a acciones legales.

Artículos relacionados

Tokenómica de RENDER: suministro, incentivos y captura de valor
Principiante

Tokenómica de RENDER: suministro, incentivos y captura de valor

RENDER actúa como el token nativo de Render Network y permite realizar pagos por servicios descentralizados de renderizado con GPU, incentivos para nodos y la gobernanza de la red. La red aplica un modelo exclusivo de Equilibrio de Quemado-Acuñación (BME): cada pago por tarea quema tokens, y en cada época se acuñan nuevos tokens como recompensa para los participantes, lo que crea un equilibrio en el suministro determinado por la demanda.
2026-03-27 13:23:38
La aplicación de Render en IA: cómo el hashrate descentralizado impulsa la inteligencia artificial
Principiante

La aplicación de Render en IA: cómo el hashrate descentralizado impulsa la inteligencia artificial

Render destaca frente a las plataformas dedicadas únicamente a la potencia de hash de IA por su red de GPU, su mecanismo de validación de tareas y su modelo de incentivos basado en el token RENDER. Esta combinación permite que Render se adapte de manera natural y conserve flexibilidad en determinados contextos de IA, en particular para aplicaciones de IA que implican procesamiento gráfico.
2026-03-27 13:13:15
0x Protocol vs Uniswap: ¿Cómo se diferencian los protocolos de Libro de órdenes del modelo AMM?
Intermedio

0x Protocol vs Uniswap: ¿Cómo se diferencian los protocolos de Libro de órdenes del modelo AMM?

Tanto 0x Protocol como Uniswap están diseñados para el trading descentralizado de activos, pero utilizan mecanismos de negociación diferentes. 0x Protocol emplea una arquitectura de libro de órdenes off-chain con liquidación on-chain, agregando liquidez de diversas fuentes para ofrecer infraestructura de trading a billeteras y DEX. Uniswap, en cambio, utiliza el modelo de Creador de mercado automatizado (AMM), permitiendo intercambios de activos on-chain a través de pools de liquidez. La diferencia principal entre ambos es la organización de la liquidez. 0x Protocol se orienta a la agregación de órdenes y al enrutamiento eficiente de operaciones, lo que lo convierte en una solución óptima para proporcionar soporte de liquidez esencial a aplicaciones. Uniswap aprovecha los pools de liquidez para ofrecer servicios de intercambio directo a los usuarios, consolidándose como una plataforma robusta de ejecución de operaciones on-chain.
2026-04-29 03:48:20
¿Cuáles son los componentes principales del protocolo 0x? Análisis de la arquitectura de Relayer, Mesh y API
Principiante

¿Cuáles son los componentes principales del protocolo 0x? Análisis de la arquitectura de Relayer, Mesh y API

0x Protocol crea una infraestructura de trading descentralizado con componentes clave como Relayer, Mesh Network, 0x API y Exchange Proxy. Relayer gestiona la transmisión de órdenes off-chain, Mesh Network facilita el intercambio de órdenes, 0x API ofrece una interfaz unificada para ofertas de liquidez y Exchange Proxy coordina la ejecución de operaciones on-chain y el enrutamiento de liquidez. Estos elementos permiten una arquitectura que integra la propagación de órdenes off-chain y la liquidación de operaciones on-chain, de modo que Billeteras, DEX y aplicaciones DeFi pueden acceder a liquidez de múltiples fuentes mediante una única interfaz unificada.
2026-04-29 03:06:50
¿Cuáles son las diferencias clave entre Solana (SOL) y Ethereum? Comparación de arquitecturas de cadenas públicas
Intermedio

¿Cuáles son las diferencias clave entre Solana (SOL) y Ethereum? Comparación de arquitecturas de cadenas públicas

Este artículo examina las diferencias clave entre Solana (SOL) y Ethereum en el diseño de la arquitectura, los mecanismos de consenso, las estrategias de escalabilidad y la estructura de los nodos, creando un marco claro y reutilizable para comparar cadenas públicas.
2026-03-24 11:58:38
Análisis en profundidad de Audiera GameFi: cómo Dance-to-Earn integra la IA con los juegos de ritmo
Principiante

Análisis en profundidad de Audiera GameFi: cómo Dance-to-Earn integra la IA con los juegos de ritmo

¿Cómo evolucionó Audition en Audiera? Descubre cómo los juegos de ritmo han ido más allá del entretenimiento tradicional para convertirse en un ecosistema GameFi impulsado por IA y blockchain. Explora los cambios clave y la evolución del valor derivados de la integración de mecánicas Dance-to-Earn, la interacción social y la economía de creadores.
2026-03-27 14:34:16