¿Por qué PerpDex "se apagó"? Análisis completo de la caída de Lighter durante 4 horas.

El 11 de octubre, el mercado de Activos Cripto experimentó el mayor evento de Obtener liquidación en la historia, con un monto total de liquidación de aproximadamente 19 mil millones de dólares. En esta prueba extrema del mercado, varias plataformas de Comercio de futuros Descentralización (Perp Dex) sufrieron caídas, siendo Lighter la más afectada por el accidente de caída, lo que llevó a pérdidas en el fondo de Proveedor de liquidez (LLP) y generó una amplia discusión en el mercado sobre la plataforma PerpDex.

Como una empresa de seguridad Web3 que ha auditado múltiples Perp Dex como Surf Protocol y Tifo.trade, Beosin en este artículo utilizará su experiencia acumulada durante años en análisis técnico y de datos en cadena para ayudar a todos a comprender en profundidad las razones detrás del incidente de caída de Lighter.

Marco técnico de Lighter

Lighter se destaca en la ola de PerpDex con su característica de cero comisiones de transacción, atrayendo a numerosos usuarios para operar en su plataforma. Lighter está construido sobre zkLight, un L2 específico de ZK Rollup, para mejorar el rendimiento de las transacciones y la eficiencia de la coincidencia de órdenes. Su mecanismo operativo central se muestra en la siguiente imagen:

Ordenador: como la primera parada de interacción del usuario, es responsable de recibir las órdenes de transacción y de ordenar y empaquetar las transacciones en un Batch (paquete de datos de procesamiento por lotes de transacciones).

Motor de emparejamiento: recibe batches del ordenante y sigue estrictamente la lógica de emparejamiento de “prioridad de precio, prioridad de tiempo”. Cada emparejamiento exitoso prepara datos para generar pruebas de conocimiento cero, asegurando que cualquier persona pueda verificar la equidad del proceso de emparejamiento posteriormente, evitando la posibilidad de manipulación.

Prover (Prover): Genera una prueba ZK-SNARK concisa a partir de las operaciones del motor de emparejamiento, utilizada para la verificación posterior de la corrección de la ejecución del emparejamiento y la transformación del estado.

Contrato de mainnet: Responsable de verificar las pruebas de conocimiento cero presentadas por los validadores. Una vez que la verificación se completa con éxito, se actualizará la raíz de estado, y así, el resultado de la transacción obtendrá la confirmación final en Ethereum.

Además del diseño anterior, Lighter ofrece a los usuarios la función de tesorería, donde los usuarios pueden depositar fondos en el Lighter Liquidity Pool (LLP), el cual asume tres funciones: provisión de liquidez, generación de precios y asunción de riesgos. Los participantes del LLP pueden compartir los ingresos de la plataforma y las ganancias generadas por las pérdidas de las contrapartes, al mismo tiempo que asumen parte del riesgo cuando los usuarios obtienen liquidación, en conjunto con el sistema de liquidación de Lighter, formando un mecanismo de amortiguación de riesgos.

Revisión del tiempo de inactividad de Lighter

El 11 de octubre de 2025, la escala de liquidación de contratos en el mercado de Activos Cripto alcanzó un récord histórico. En esta extrema situación, Lighter sufrió múltiples horas de interrupción del servicio, lo que impidió a los usuarios operar sus posiciones, y los LLP perdieron aproximadamente un 5.35%.

Beosin, a través del análisis de los datos en cadena del periodo principal de este evento (hora de Pekín, 11 de octubre de 2025, de 00:17 a 05:08), ha descubierto que Lighter ha perdido 3 Batch desde Batch#55661, y comenzó a recuperar la producción de Batch a partir de las 00:17 (a las 00:23, Lighter publicó un anuncio indicando que los pedidos de los usuarios no podían ser procesados o ejecutados).

La plataforma Lighter manejaba un volumen de transacciones de aproximadamente 4005 transacciones/minuto antes de la caída. A partir de las 00:17, el volumen de transacciones se disparó, el Batch#55665 contiene 560 bloques, el volumen de transacciones procesadas fue de 196913, lo que significa que se necesitaba procesar aproximadamente 65638 transacciones por minuto, alrededor de 16 veces el volumen habitual.

A continuación se muestra un gráfico estadístico del número de transacciones procesadas en cada Batch desde las 00:17 hasta las 05:08 del 11 de octubre:

Elaborado por Beosin

El 11 de octubre a las 04:56, el Batch#55743 alcanzó el número máximo de transacciones procesadas, completando 639370 transacciones en 2 minutos, lo que equivale a 79.8 veces el número de transacciones procesadas por minuto en períodos normales. Al analizar los datos de este evento de Lighter, descubrimos que el Batch de Lighter puede contener hasta 1600 bloques, cada bloque puede contener un máximo de 500 transacciones, lo que teóricamente permite procesar 800000 transacciones por Batch, mientras que la máxima medida fue de 639370.

Lo anterior son las transacciones que la plataforma Lighter ha procesado con éxito, y hay muchos usuarios que no pudieron ajustar sus posiciones debido a fallas en la presentación de transacciones (caída del sistema) y no pudieron registrar datos en la cadena. Desde la perspectiva de la arquitectura técnica, esta caída del sistema y las pérdidas de LLP se deben principalmente a 2 razones:

1. Aparte de los problemas de acceso y envío de pedidos en la página frontal, el ZK Rollup de Lighter depende de un único ordenante para la ordenación y empaquetado de transacciones. Aunque se logra la verificación de resultados a través de ZK Proof, la centralización del ordenante genera un riesgo de punto único de fallo. Durante los períodos de caída brusca, el ordenante y la base de datos no pueden soportar la carga repentina, lo que puede provocar daños en los índices y bloqueo de transacciones en la base de datos, causando directamente la interrupción de la conexión entre el motor de emparejamiento y el usuario. 2. El proceso de generación y envío de pruebas de ZK-SNARK se convierte en un cuello de botella cuando el volumen de transacciones aumenta repentinamente. En condiciones extremas, las operaciones de emparejamiento y liquidación que aumentan simultáneamente envían solicitudes al nodo generador de pruebas ZK. Es posible que la plataforma no haya establecido un mecanismo de reserva de recursos para operaciones de alta prioridad como la liquidación, lo que genera competencia por recursos entre las solicitudes de generación de pruebas de transacciones ordinarias y liquidaciones, agravando aún más el retraso en la respuesta del sistema, lo que impide la ejecución oportuna del proceso de liquidación y amplifica las pérdidas de los usuarios. A nivel operativo, según la respuesta del CEO de Lighter, Vladimir Novakovski, “Lighter planeaba originalmente realizar una actualización de la base de datos durante el fin de semana en que ocurrió esta caída para adaptarse a la creciente demanda de transacciones”. Desde este evento, esta “elección incorrecta de la ventana de actualización” se debió a la falta de preparación de su equipo ante los riesgos del mercado; en el proceso de rápida expansión de la plataforma, no pudieron completar la actualización de infraestructura a tiempo, lo que finalmente llevó a una falla sistémica de la plataforma en condiciones extremas. Este incidente revela un problema central que enfrenta PerpDex: cómo mantener el funcionamiento normal de la plataforma en condiciones extremas. En cuanto a la seguridad de los contratos inteligentes, los equipos de proyectos en el espacio de Perp Dex deben llevar a cabo auditorías de seguridad de contratos exhaustivas y profesionales. Beosin ya ha proporcionado servicios de auditoría de seguridad para Surf Protocol, Tifo.trade y otros Perp Dex, abarcando múltiples aspectos como la seguridad del código de los contratos inteligentes, la corrección de la lógica de implementación del negocio (negociación apalancada, liquidación, gestión de pools de liquidez, etc.), optimización de gas del código de contratos, y la identificación y reparación de vulnerabilidades potenciales, ayudando con éxito a los equipos de proyectos a reparar múltiples vulnerabilidades de riesgo medio a alto.

Además, el equipo del proyecto Perp Dex también necesita considerar la redundancia de la arquitectura y los mecanismos de emergencia. En el futuro, con la aplicación de tecnologías como los múltiplos ordenadores y la programación dinámica de recursos, Perp Dex tiene el potencial de resolver este cuello de botella actual, servir a más usuarios y convertirse en la infraestructura central de las finanzas encriptadas.