Me desperté con el hack de rsETH, empecé a buscar en Google.

Muchas personas están acusando a Kelp de negligencia.
Luego encontré la investigación recién publicada de @stacy_muur sobre la explotación, y hasta ahora esta es la pieza más detallada en CT.
Resumen breve de lo que realmente ocurrió ↓
Se drenaron aproximadamente 116,500 rsETH (~$292M) de la puente.
Pero esto NO fue:
– una explotación de acuñación
– no fue un error en el contrato inteligente
– no fue reentrancy
Esto es importante.
Lo que ocurrió fue un mensaje falso de cadena cruzada que Ethereum aceptó como real.
Piensa en ello así:
Ethereum recibió un mensaje que decía
“oye, libera fondos – fueron quemados en la otra cadena”
Excepto… nunca fueron quemados.
El mensaje parecía 100% legítimo estructuralmente, por lo que el sistema lo ejecutó.
Importante:
– El colateral rsETH en la red principal está intacto
– Los titulares existentes de rsETH no enfrentan una reducción directa en este momento
Y aquí está la imagen realista de las zonas de responsabilidad:
@KelpDAO:
▪ Configuración DVN 1:1. Este es el mínimo configuración de LayerZero.
▪ Esta configuración estuvo en vigor durante al menos 90 días – no fue un error apresurado
▪ 11 de 12 rutas entrantes de Kelp eran 1-a-1 – este era su patrón estándar
▪ Kelp respondió y congeló contratos, bloqueando ataques adicionales
@LayerZero_Core:
▪ El único DVN requerido es el etiquetado en Etherscan como "LayerZero: DVN"
▪ Un paquete fue verificado y comprometido por este DVN sin un evento fuente real
▪ El mismo DVN opera normalmente en cientos de otras rutas
Básicamente, el DVN de LayerZero es el componente que verificó un mensaje. Si eso fue debido a una clave comprometida, un error de software o una entrada upstream defectuosa, sigue siendo la pregunta central sin respuesta.