LayerZero Lança Relatório do Incidente rsETH: Reconstruindo Infraestrutura Afetada e Elevando o Padrão de Segurança Cross-Chain
LayerZero Lança Relatório do Incidente rsETH: Reconstruindo Infraestrutura Afetada e Elevando o Padrão de Segurança Cross-Chain
A interoperabilidade cross-chain tornou-se um componente fundamental para o DeFi em 2025-2026: tokens de restaking líquido, mercados de empréstimos multi-chain e padrões de emissão omnichain presumem que os ativos podem ser movidos com segurança entre redes. Mas o incidente rsETH é um lembrete de que a segurança das pontes não se trata apenas de contratos inteligentes—ela também envolve verificação off-chain, integridade da infraestrutura e escolhas de configuração.
Na sequência da exploração da ponte rsETH da KelpDAO (18 de abril de 2026), a LayerZero publicou uma declaração detalhada do incidente e uma atualização de acompanhamento explicando como uma mensagem cross-chain forjada foi finalmente aceita sob uma configuração de verificador único, e quais mudanças operacionais e de política está implementando daqui para frente. Você pode ler os relatórios originais aqui: Declaração do Incidente da KelpDAO e Atualização da LayerZero.
O que aconteceu (e o que não aconteceu)
O impacto: ponte rsETH drenada via mensagem forjada
Em 18 de abril de 2026, um atacante fez com que a rota da ponte rsETH da KelpDAO, baseada em LayerZero, liberasse aproximadamente 116.500 rsETH (cerca de US$ 292 milhões na época), ao ter uma mensagem cross-chain forjada verificada e executada no Ethereum. A LayerZero enfatizou que isso foi isolado à configuração rsETH da KelpDAO e que o protocolo LayerZero em si não foi explorado. Veja o resumo da LayerZero na declaração do incidente.
Atribuição: "TraderTraitor" ligado à RPDC
A LayerZero declarou ter confiança preliminar de que o atacante era um ator estatal altamente sofisticado, atribuindo o incidente ao Grupo Lazarus da RPDC, especificamente ao cluster TraderTraitor referenciado pelas autoridades dos EUA. Para um contexto sobre as táticas do "TraderTraitor" (engenharia social, entrega de malware e ataque a organizações de cripto), consulte o aviso conjunto dos EUA: Aviso TraderTraitor da CISA (AA22-108A).
O que não foi comprometido (segundo a LayerZero)
A declaração do incidente da LayerZero observa explicitamente que o ataque não foi resultado de um bug no protocolo LayerZero, e afirma que as chaves de assinatura DVN não foram roubadas diretamente. Em vez disso, o atacante visou as dependências de dados (RPC) do DVN e as suposições de disponibilidade ao redor. Detalhes estão na declaração do incidente.
O modo de falha central: "verificador único" encontra envenenamento de RPC + failover forçado
A explicação da LayerZero centra-se em uma classe crescente de ataques: envenenamento de RPC (alimentar um verificador com estado de cadeia manipulado) combinado com DoS / DDoS (forçar o sistema a depender das fontes envenenadas).
1) Nós RPC downstream foram comprometidos e mentiram seletivamente
De acordo com a LayerZero, o atacante obteve acesso à lista de nós RPC usados pelo DVN da LayerZero Labs, comprometeu um subconjunto e modificou o comportamento dos nós para que o DVN recebesse estado de cadeia falsificado—enquanto muitos sistemas de monitoramento continuavam a ver respostas "normais". A LayerZero descreve essa decepção seletiva em sua declaração do incidente.
Se você deseja uma introdução prática sobre por que os endpoints RPC são uma superfície de ataque de alta alavancagem para sistemas cripto, a visão geral da Chainstack é uma referência útil: Ataques de envenenamento de RPC em cripto. Para uma definição geral de RPC em sistemas distribuídos, consulte a visão geral da IBM: Chamada de Procedimento Remoto (RPC).
2) A disponibilidade de RPC externa foi atacada para acionar a dependência de nós comprometidos
A LayerZero relata que atividades de DDoS contra endpoints RPC externos saudáveis empurraram o comportamento de fallback do DVN para os endpoints envenenados, permitindo a verificação de uma mensagem associada a transações que nunca ocorreram como alegado. Essa "pressão de disponibilidade" é uma lição crucial para quem constrói sistemas de verificação off-chain: redundância não é apenas ter mais endpoints; é sobreviver a interrupções direcionadas sem confiar nos errados.
3) A configuração 1 de 1 do DVN da KelpDAO transformou o comprometimento em perda
O detalhe de configuração mais importante: a rota rsETH da KelpDAO usava uma configuração de DVN 1 de 1, com a LayerZero Labs atuando como o único verificador. A LayerZero argumenta que isso criou um único ponto de falha—nenhum verificador independente existia para rejeitar a mensagem forjada. Isso é discutido diretamente na declaração do incidente.
Uma análise aprofundada de terceiros que captura o ângulo "por que isso importou para o risco DeFi" é a nota de pesquisa da Galaxy: Análise da exploração KelpDAO / LayerZero.
Por que este incidente importa além de uma única ponte
A realidade de 2025-2026: "exploits de infraestrutura" estão escalando mais rápido que exploits de contrato
As conversas sobre segurança DeFi ainda superestimam auditorias e bugs on-chain. No entanto, muitos dos maiores incidentes agora se assemelham a invasões corporativas: comprometimento de endpoint, adulteração da cadeia de suprimentos, sequestro de sessão e ataques de disponibilidade—seguidos de extração on-chain.
No caso do rsETH, os contratos on-chain se comportaram como projetado; os inputs para o processo de verificação foram envenenados.
A composabilidade do DeFi transformou um dreno de ponte em um choque de liquidez
Uma preocupação downstream importante foi como a garantia sem lastro ou comprometida se propaga para os mercados de empréstimos. Análises pós-incidente destacaram a rapidez com que choques de confiança podem drenar liquidez, mesmo quando o código principal do protocolo de empréstimo funciona como pretendido. O artigo da Glassnode oferece uma perspectiva de estrutura de mercado: Anatomia de um Congelamento de Liquidez.
Resposta da LayerZero: mudanças de política, fortalecimento da configuração e alterações no DVN
As publicações da LayerZero descrevem três direções práticas:
1) "Chega de 1 de 1" para o DVN da LayerZero Labs
A LayerZero declara que não assinará/atestará mensagens para aplicativos que usam uma configuração de DVN 1 de 1, e que está entrando em contato com projetos que ainda operam com configurações de verificador único. Isso está detalhado na declaração do incidente e reforçado na Atualização da LayerZero.
2) Elevar o padrão padrão, mas incentivar equipes a fixar configurações
Em sua atualização de 8 de maio, a LayerZero recomenda aos construtores:
- Fixar configurações (não confiar em padrões mutáveis)
- Usar confirmações de bloco mais altas apropriadas para a cadeia
- Adotar redundância multi-DVN (pelo menos 2, idealmente 3-5)
Essas recomendações estão listadas na Atualização da LayerZero. Para implementadores, a LayerZero também faz referência a uma lista de verificação de integração em sua documentação: Lista de verificação de integrações LayerZero.
3) Reconstruir e substituir componentes RPC afetados
A LayerZero afirma que os nós RPC afetados foram depreciados e substituídos, e as operações do DVN foram retomadas com mudanças nas suposições de quórum RPC e redundância (detalhes na declaração do incidente e atualização).
Embora a arquitetura de segurança interna de cada equipe seja diferente, a direção se alinha com um pensamento mais amplo de "zero trust": minimizar privilégios permanentes, segmentar sistemas de produção e tratar redes internas como hostis por padrão—especialmente quando seu sistema atua como um verificador de valor externo.
Lições práticas para construtores: uma lista de verificação de 2026 para segurança de pontes cross-chain
Se você lança ou integra um ativo omnichain (wrappers do tipo OFT, pontes canônicas, derivativos de restaking), o incidente rsETH sugere uma ordem clara de prioridade:
-
Eliminar verificação unilateral
- Exigir N de M verificadores independentes (não "duas marcas na mesma pilha").
- Independência deve incluir: organização operadora, hospedagem, fontes RPC, monitoramento e resposta a incidentes.
-
Fortalecer a confiança em RPC e a lógica de failover
- Tratar endpoints RPC como inputs não confiáveis.
- Garantir que o failover não reduza silenciosamente a segurança (por exemplo, "se os endpoints falharem, confie em menos endpoints" é perigoso).
- Construir comportamento de "modo degradado": parar a verificação em vez de aceitar provas mais fracas sob pressão.
-
Projetar para disponibilidade adversarial
- Assumir que DDoS direcionado faz parte da cadeia de ataque.
- Modelar o que acontece quando apenas o subconjunto controlado pelo atacante permanece acessível.
-
Tornar o posture de segurança observável
- Publicar suas suposições de verificação em um dashboard ou documentação:
- Conjunto DVN, limites, confirmações, chaves de pausa, procedimentos de emergência
- Usuários e equipes de risco precisam ver o risco de configuração antes de um incidente.
- Publicar suas suposições de verificação em um dashboard ou documentação:
Lições práticas para usuários: como reduzir a exposição a riscos cross-chain
Mesmo que você nunca escreva uma linha de código, pode reduzir materialmente o risco:
- Tratar ativos "bridged" como uma classe de risco separada de ativos "nativos".
- Quando o rendimento parecer semelhante entre as cadeias, prefira locais onde a garantia depende de menos suposições off-chain.
- Mantenha apenas saldos operacionais em L2 / representações "bridged"; armazene participações de longo prazo em armazenamento a frio.
Autocustódia importa: por que uma carteira de hardware ainda é um controle central
Incidentes como o rsETH são sobre verificação e infraestrutura, mas muitas perdas grandes ainda começam com dispositivos comprometidos, roubo de credenciais e engenharia social. Uma carteira de hardware reduz o raio de explosão, mantendo as chaves privadas isoladas de navegação diária e malware de estação de trabalho.
Se você leva a autocustódia de longo prazo a sério, usar uma carteira de hardware como a OneKey ajuda a garantir que a assinatura de transações permaneça fora de seu ambiente conectado à internet—uma camada importante quando o ecossistema mais amplo está lidando com modelos de ameaça cada vez mais profissionais e ligados a estados.
Pensamento final: "configurações são segurança"
A exploração do rsETH provavelmente será lembrada menos como "um hack de ponte" e mais como uma lição sistêmica: a segurança do protocolo é modular agora, e o módulo mais fraco (muitas vezes configuração + infraestrutura) define o risco real.
À medida que a mensagens cross-chain se tornam o encanamento padrão para DeFi e ativos tokenizados, o padrão da indústria deve mudar de "código auditado" para suposições auditadas—incluindo diversidade de DVN, integridade de RPC e segurança de failover.
