Dopo l’attacco di domenica, il LayerZero exploit da 290 milioni di dollari su rsETH ha aperto uno scontro pubblico tra Kelp DAO e LayerZero sulla reale origine della falla.
Summary
Lo scontro tra Kelp DAO e LayerZero dopo l’attacco
Kelp DAO si prepara a contestare il post-mortem pubblicato da LayerZero sull’exploit di domenica, secondo una fonte vicina al dossier citata da CoinDesk. La memo che il protocollo intende diffondere, già visionata dalla testata, respinge l’idea che il team abbia ignorato avvertimenti ripetuti su una configurazione rischiosa.
Secondo Kelp, la configurazione compromessa non dipendeva da una scelta anomala fatta contro parere tecnico. Al contrario, il bridge si basava su infrastruttura e impostazioni predefinite riconducibili a LayerZero, inclusi i sistemi usati per verificare i messaggi cross-chain.
Kelp è un protocollo di liquid restaking che riceve ether dagli utenti, lo instrada in EigenLayer per generare rendimento e rilascia in cambio il token ricevuta rsETH. LayerZero, invece, fornisce l’infrastruttura di messaggistica cross-chain che trasferisce rsETH tra blockchain tramite i DVN, cioè le decentralized verifier networks.
Come si è sviluppato il LayerZero exploit sul bridge rsETH
Sabato gli attaccanti hanno sottratto 116.500 rsETH, per un controvalore di circa 290 milioni di dollari, dal bridge di Kelp alimentato da LayerZero. L’operazione è riuscita compromettendo i server su cui il verificatore faceva affidamento per controllare la validità delle transazioni.
Secondo la ricostruzione di Kelp, il DVN violato in quello che definisce un “sofisticato attacco sponsorizzato da uno Stato” faceva capo alla stessa LayerZero, non a un verificatore esterno. Gli aggressori avrebbero preso il controllo di due server dell’azienda e saturato quelli di backup con traffico spazzatura, costringendo il sistema a operare sui nodi compromessi.
Tuttavia, Kelp sostiene che tutta questa infrastruttura fosse costruita e gestita da LayerZero. Per questo il protocollo respinge la lettura secondo cui il problema sarebbe nato da una decisione autonoma e imprudente del suo team.
Che cosa significa configurazione 1/1
Nel post-mortem, LayerZero ha affermato che KelpDAO avrebbe scelto una configurazione DVN 1/1 nonostante la raccomandazione di adottare una ridondanza multi-verificatore. In pratica, una struttura 1/1 richiede l’approvazione di un solo validatore per autorizzare un messaggio cross-chain.
Questo schema elimina ogni secondo controllo e crea un singolo punto di fallimento. Al contrario, configurazioni come 2/3 o 3/5 impediscono che un solo soggetto possa convalidare da solo un messaggio falsificato.
Detto ciò, la fonte sostiene che nel canale diretto aperto con LayerZero da luglio 2024 non sarebbe mai arrivata un’indicazione specifica per modificare la configurazione DVN di rsETH. Questo punto è centrale nella replica di Kelp DAO.
Documentazione, codici pubblici e accuse di responsabilità
La contestazione non si limita alle conversazioni private. Secondo quanto riferito a CoinDesk, la quickstart guide di LayerZero e la configurazione GitHub predefinita indicano proprio un assetto 1/1, e circa il 40% dei protocolli sulla rete userebbe ancora lo stesso modello.
Inoltre, la configurazione adottata da Kelp comparirebbe anche nel V2 OApp Quickstart di LayerZero. Nel file di esempio layerzero.config.ts, ogni percorso viene impostato con un solo DVN obbligatorio e nessun DVN opzionale, replicando di fatto la stessa struttura 1/1 criticata nel post-mortem.
Alcuni ricercatori di sicurezza condividono questa lettura. Il developer del core team di Yearn Finance, Artem K, noto su X come @banteg, ha pubblicato un’analisi tecnica del codice di deployment pubblico di LayerZero, sostenendo che il setup di riferimento prevede verifiche da una sola fonte sulle principali chain.
Nella sua analisi cita Ethereum, BSC, Polygon, Arbitrum e Optimism. Inoltre, segnala che quel deployment lascia esposto un endpoint pubblico che può rivelare a chiunque interroghi il sistema l’elenco dei server configurati.
Tuttavia, Banteg precisa di non poter dimostrare con certezza quale configurazione abbia usato Kelp. Osserva però che LayerZero chiede di norma ai nuovi operatori di partire dal setup di default, lo stesso poi criticato nel resoconto sull’incidente.
Fondi a rischio, contratti salvi e migrazione forzata
Kelp afferma che i contratti principali di restaking non sono stati toccati e che l’incidente è rimasto confinato al livello del bridge. Inoltre, la pausa d’emergenza attivata 46 minuti dopo il drenaggio avrebbe bloccato altri due tentativi di attacco, evitando il rilascio di ulteriori circa 200 milioni di dollari in rsETH.
Nel frattempo, anche altre voci del settore hanno criticato LayerZero. Su X, il community manager di Chainlink, Zach Rynes, ha accusato l’azienda di scaricare la colpa per una propria infrastruttura compromessa e di aver esposto Kelp per essersi fidata di una configurazione supportata dalla stessa piattaforma.
In risposta, LayerZero ha annunciato che non firmerà più messaggi per applicazioni che usano una configurazione a verificatore singolo. La decisione imporrà una migrazione estesa ai protocolli coinvolti e riaccende il dibattito sulla sicurezza dei bridge cross-chain rispetto a soluzioni con controlli ridondanti.
Nel complesso, il caso mostra come il LayerZero exploit non riguardi solo l’attacco da 290 milioni, ma anche la ripartizione delle responsabilità tra infrastruttura, documentazione tecnica e scelte operative dei protocolli integrati.
