Por que o PerpDex "parou"? Revisão completa da queda de 4 horas do Lighter

No dia 11 de outubro, o mercado de ativos de criptografia passou pela maior liquidação da história, com um total de liquidações de aproximadamente 19 bilhões de dólares. Neste extremo teste de mercado, várias plataformas de negociação de Futuros Perpétuos descentralizadas (Perp Dex) apresentaram falhas, sendo que a Lighter teve a falha mais grave, resultando em perdas no fundo de provedores de liquidez (LLP) que geraram uma ampla discussão no mercado sobre a plataforma PerpDex.

Como uma empresa de segurança Web3 que auditou várias Perp Dex, como Surf Protocol e Tifo.trade, a Beosin, neste artigo, irá usar anos de experiência acumulada em tecnologia e análise de dados em blockchain para ajudar todos a entender melhor as causas do incidente de falha do Lighter.

Estrutura Técnica Lighter

Lighter destaca-se na onda do PerpDex com a sua característica de zero taxas de transação, atraindo numerosos usuários para negociar na sua plataforma. Lighter é construído sobre o zkLight, uma L2 específica de ZK Rollup, para melhorar o desempenho das transações e a eficiência de correspondência do livro de ordens. O seu mecanismo de operação central é mostrado na figura abaixo:

Classificador: como o primeiro ponto de interação do usuário, é responsável por receber instruções de negociação e classificar e empacotar as transações em Batch (pacote de dados de processamento em lote).

Motor de correspondência: recebe Batch do classificador e segue rigorosamente a lógica de correspondência “prioridade de preço, prioridade de tempo”. Cada correspondência bem-sucedida prepara dados para gerar provas de conhecimento zero, garantindo que qualquer pessoa possa verificar posteriormente a equidade do processo de correspondência, evitando a possibilidade de manipulação.

Provedor (Prover): Gera uma prova ZK-SNARK concisa das operações do motor de correspondência, para validação posterior da correção da execução da correspondência e da transição de estado.

Contrato da mainnet: responsável por validar as provas de conhecimento zero apresentadas pelos provadores. Uma vez que a validação é bem-sucedida, a raiz de estado é atualizada, e assim o resultado da transação obtém a confirmação final na Ethereum.

Além do design acima, o Lighter oferece aos usuários a funcionalidade de tesouraria, permitindo que os usuários depositem fundos no Lighter Liquidity Pool (LLP), que desempenha as funções de provedor de liquidez, geração de cotações e aceitação de risco. Os participantes do LLP podem compartilhar os lucros da plataforma e os lucros gerados pelas perdas contrapartes, ao mesmo tempo que assumem parte do risco quando os usuários são liquidadas, em conjunto com o sistema de liquidação do Lighter, formando um mecanismo de amortecimento de risco.

Revisão da Queda do Lighter

No dia 11 de outubro de 2025, o volume de liquidação de contratos no mercado de criptografia atingiu um recorde histórico. Durante esta extrema volatilidade, o Lighter teve várias horas de interrupção de serviço, impedindo os usuários de gerirem as suas posições, resultando numa perda de aproximadamente 5,35% para o LLP.

A Beosin, através da análise dos dados em cadeia do período principal deste evento (horário de Pequim, 11 de outubro de 2025, 00:17-05:08), descobriu que o Lighter perdeu 3 Batches a partir do Batch#55661, e começou a recuperar a produção de Batches a partir das 00:17 (às 00:23, o Lighter publicou um aviso informando que os pedidos dos usuários não podiam ser processados ou executados).

A plataforma Lighter processou normalmente cerca de 4005 transações/minuto antes da falha, e a partir das 00:17, o volume de transações disparou. O Batch#55665 contém 560 blocos, com um total de 196913 transações processadas, necessitando de cerca de 65638 transações para ser processadas por minuto, o que é aproximadamente 16 vezes o volume normal.

Abaixo está o gráfico estatístico do número de transações processadas em cada ponto de tempo de submissão dos Batch de 11 de outubro das 00:17 às 05:08:

Produzido pela Beosin

Em 11 de outubro às 04:56, o Batch#55743 atingiu o número máximo de transações processadas, completando 639370 transações em 2 minutos, o que equivale a 79,8 vezes o número de transações processadas por minuto em um período normal. Ao analisar os dados deste evento do Lighter, descobrimos que o Batch do Lighter pode acomodar até 1600 blocos, com cada bloco podendo conter até 500 transações, o que resulta em uma capacidade teórica de processamento de 800000 transações por Batch, enquanto o máximo medido foi de 639370.

Acima estão as transações processadas com sucesso pela plataforma Lighter, ainda há muitos usuários que não conseguiram ajustar suas posições (paralisação) devido à falha na submissão das transações, resultando em dados não registrados na cadeia. Do ponto de vista da arquitetura técnica, esta paralisação e a perda de LLP foram causadas principalmente por 2 razões:

1. Além de problemas de acesso à página da frente e envio de pedidos, o ZK Rollup da Lighter depende de um único ordenado para a ordenação e empacotamento de transações. Embora a verificação de resultados seja realizada através de ZK Proof, a centralização do ordenado leva a riscos de falha única. Durante períodos de queda acentuada, o ordenado e o banco de dados não conseguem suportar a carga repentina, o banco de dados pode sofrer danos nos índices e bloqueios de transações, levando diretamente a interrupções na conexão entre o motor de correspondência e o cliente. 2. O processo de geração e envio de provas de ZK-SNARK torna-se um gargalo quando o volume de transações aumenta drasticamente. Em condições extremas, as operações de correspondência de transações e liquidação que aumentam de forma síncrona fazem solicitações simultâneas ao nó de geração de provas ZK. A plataforma pode não ter estabelecido um mecanismo de reserva de recursos para operações de liquidação de alta prioridade, levando a uma competição por recursos entre as solicitações de geração de provas de transações normais e liquidações, o que agrava ainda mais o atraso na resposta do sistema, tornando impossível a execução oportuna do processo de liquidação e ampliando as perdas dos usuários. No nível operacional, de acordo com a resposta do CEO da Lighter, Vladimir Novakovski, “a Lighter originalmente planejou uma atualização do banco de dados no fim de semana em que ocorreu esta queda para se adequar à crescente demanda por transações”. A partir deste evento, essa “escolha errada da janela de atualização” é resultado da preparação insuficiente da equipe para o risco de mercado, e durante a rápida expansão da plataforma, não conseguiu completar atualizações de infraestrutura em tempo hábil, levando finalmente a uma falha sistêmica da plataforma em condições extremas. Este evento revela um desafio central que o PerpDex enfrenta: como manter a operação normal da plataforma em condições extremas. Em termos de segurança de contratos inteligentes, as equipes de projetos no espaço Perp Dex devem realizar auditorias de segurança abrangentes e profissionais. A Beosin já forneceu serviços de auditoria de segurança para Perp Dex como Surf Protocol e Tifo.trade, abrangendo a segurança do código do contrato inteligente, a correção da lógica de implementação de negócios (negociação alavancada, liquidação, gestão de pools de liquidez, etc.), otimização de gás do código do contrato, descoberta e correção de vulnerabilidades potenciais, ajudando com sucesso as equipes de projetos a corrigir várias vulnerabilidades de médio a alto risco.

Além disso, a equipe do projeto Perp Dex precisa considerar a redundância da arquitetura e os mecanismos de emergência. No futuro, com a aplicação de tecnologias como múltiplos ordenadores e agendamento dinâmico de recursos, o Perp Dex espera resolver esse gargalo atual, atendendo mais usuários e tornando-se a infraestrutura central das finanças encriptadas.