A disputa do LayerZero aprofunda-se após o esvaziamento da ponte rsETH de $290 milhões

A Kelp DAO desafia a versão do LayerZero sobre um exploit na ponte rsETH de $290 milhões, argumentando que a falha veio dos próprios padrões da plataforma, e não de uma configuração incomum. A disputa agora centra-se em quem controlava as chaves, o código e os avisos.

O que aconteceu no exploit

No sábado, os atacantes esvaziaram 116.500 rsETH, no valor de cerca de $290 milhões, da ponte alimentada pelo LayerZero da Kelp, após envenenarem os servidores usados para verificar transferências. O ataque não afetou os contratos principais de restaking da Kelp, e a pausa de emergência ocorreu 46 minutos depois.

Essa pausa bloqueou duas tentativas subsequentes que teriam liberado mais ~$200 milhões em rsETH. Além disso, uma fonte familiarizada com a resposta da Kelp afirmou que a violação permaneceu limitada à camada da ponte.

Como a Kelp diz que a configuração funcionou

A Kelp planeja argumentar que o DVN comprometido era a própria infraestrutura do LayerZero, e não um verificador de terceiros escolhido pelo protocolo. O memorando revisado pela CoinDesk afirma que o ataque usou servidores do LayerZero que verificavam se as transações entre cadeias eram legítimas.

No entanto, a fonte da Kelp disse que os servidores de backup foram inundados com tráfego lixo, o que levou o verificador a ser direcionado para os nós comprometidos. Toda essa infraestrutura foi construída e operada pelo LayerZero, afirmou a fonte.

O protocolo também discorda da alegação de que ignorou orientações para abandonar uma configuração de verificador único. Através de um canal de comunicação direto aberto desde julho de 2024, a Kelp afirma que não recebeu recomendações específicas para alterar a configuração do DVN do rsETH.

Por que a configuração está sob escrutínio

A análise pós-morte do LayerZero afirmou que a KelpDAO escolheu uma configuração de DVN 1-de-1, apesar das recomendações para usar redundância multi-DVN. Na prática, uma configuração 1/1 significa que um validador pode aprovar uma mensagem entre cadeias sozinho, enquanto configurações com múltiplos validadores reduzem o risco de falha de ponto único.

Além disso, a fonte da Kelp disse que o guia de início rápido do LayerZero e a configuração padrão do GitHub apontam para a mesma estrutura 1/1. A fonte acrescentou que 40% dos protocolos no LayerZero atualmente usam essa configuração.

A mesma configuração aparece no Guia de Início Rápido do LayerZero V2 OApp, onde o arquivo layerzero.config.ts de exemplo atribui um DVN obrigatório e nenhum DVN opcional. Esse é exatamente o modelo que a Kelp afirma ter seguido.

Críticos dizem que a culpa está mal colocada

Pesquisadores de segurança também estão contestando. O desenvolvedor da equipe principal do Yearn Finance, Artem K, conhecido no X como @banteg, afirmou que o código de implantação público do LayerZero usa padrões de verificação de fonte única em Ethereum, BSC, Polygon, Arbitrum e Optimism.

Ele também observou que a implantação deixa um endpoint público exposto, que revela a lista de servidores configurados a qualquer um que consulte. Dito isso, ele afirmou que não consegue provar qual configuração a Kelp usou.

O gerente da comunidade Chainlink, Zach Rynes, foi mais incisivo no X, acusando o LayerZero de desviar a responsabilidade e jogar a Kelp debaixo do ônibus por confiar em uma configuração que o próprio LayerZero apoiava. Ele disse que a empresa tentava transferir a culpa por sua própria infraestrutura comprometida.

A CoinDesk entrou em contato com o LayerZero para comentários e não recebeu resposta até a publicação. Enquanto isso, o LayerZero prometeu deixar de assinar mensagens para qualquer aplicação que use uma configuração de verificador único, o que forçará uma migração mais ampla na sua rede.

No final, a disputa sobre esse incidente do LayerZero não é mais apenas sobre uma ponte. Tornou-se um teste de documentação, padrões e responsabilidade na segurança entre cadeias.