Reason to trust
How Our News is Made
Strict editorial policy that focuses on accuracy, relevance, and impartiality
Ad discliamer
Morbi pretium leo et nisl aliquam mollis. Quisque arcu lorem, ultricies quis pellentesque nec, ullamcorper eu odio.
LayerZero está enfrentando duras críticas por su respuesta al reciente exploit de $290 millones de KelpDAO después de que el protocolo de interoperabilidad omnicanal culpara a la configuración de verificador 1‑de‑1 de Kelp por el incidente.
LayerZero culpa a KelpDAO por el exploit de $290 M
Durante el fin de semana, el protocolo de restaking líquido KelpDAO fue víctima de un ataque que drenó más de $290 millones en rsETH del proyecto después de que actores maliciosos explotaran una vulnerabilidad en el puente impulsado por LayerZero.
Dos días después, LayerZero abordó el incidente, que se convirtió en el mayor hackeo DeFi de 2026, apenas semanas después de que el exploit de $285 millones del Drift Protocol [https://www.newsbtc.com/news/285m-solana-protocol-drift-largest-exploit-2026/] sacudiera a la industria.
LayerZero atribuyó el “ataque altamente sofisticado” al Lazarus Group de Corea del Norte, alegando que se trató de un ataque a la infraestructura cripto más que de una vulnerabilidad del protocolo, y afirmó que “no hay contagio a ningún otro activo o aplicación cross‑chain”.
Explicaron que el protocolo está construido sobre una “base de seguridad modular y configurable por la aplicación”, usando Redes de Verificadores Descentralizadas (DVNs), entidades independientes responsables de verificar la integridad de los mensajes cross‑chain.
Según el post, los atacantes envenenaron la infraestructura RPC downstream al “comprometer un quórum de los RPCs en los que la DVN de LayerZero Labs confiaba para verificar transacciones”.
Los atacantes, según el informe, intercambiaron binarios por una carga útil personalizada para falsificar mensajes y usaron ataques DDoS para forzar el conmutador a los nodos envenenados, lo que provocó que la DVN confirmara transacciones falsas.
Con base en esto, LayerZero [https://www.newsbtc.com/news/layerzero-soars-zero-debut-institutional-backing/] responsabilizó a KelpDAO por usar una configuración de verificador 1‑de‑1 en lugar de las recomendaciones multi‑DVN: “Este incidente estuvo aislado totalmente a la configuración rsETH de KelpDAO como consecuencia directa de su configuración de DVN única”.
La comunidad cripto critica la ‘falta de responsabilidad’
La comunidad cripto reaccionó al post‑mortem, compartiendo sus [https://www.newsbtc.com/news/crypto-winter-trading-volume-lowest-since-2023/] preocupaciones sobre la respuesta de LayerZero y criticando al protocolo por colocar toda la responsabilidad únicamente en la configuración de seguridad de Kelp.
“Imagina construir un puente y que los vehículos paguen por cruzarlo, el puente se colapsa y tú dices que es culpa suya por cruzarlo. Un acto clásico de payasadas de un montón de payasos sin responsabilidad”, escribió el usuario de X Saint [https://x.com/thesaint_/status/2046111507969188093?s=20].
Otros [https://x.com/ditto_/status/2046092665079656925?s=20] preguntaron por qué LayerZero incluyó una configuración “1‑de‑1” si el propósito de una DVN es una seguridad personalizable/modular. “Si el sistema permite esta opción, no es culpa del cliente que la eligió, es un defecto de diseño fundamental del sistema que lo permitió”, escribió el usuario Ditto.
“Al final del día, el hecho sigue siendo que el RPC de la DVN fue comprometido. DVN es un producto de LayerZero, y son ellos quienes lo vendieron a estos equipos”, añadió.
De manera similar, el community manager de Chainlink, Zach Rynes [https://x.com/ChainLinkGod/status/2046105500509675918?s=20] acusó al protocolo de desviar la responsabilidad por la compromisión de su propio nodo DVN.
También los criticó por “lanzar a KelpDAO bajo el autobús” por confiar en la configuración de LayerZero Labs que “apoyaron voluntariamente y solo bloquearon después de ser hackeados, todo mientras afirmaban que todo funcionaba según lo diseñado”.
Mientras tanto, el desarrollador del equipo central de Yearn Finance, Artem K [https://x.com/banteg/status/2046124661352644907?s=20] señaló en X que el ataque se describió como una compromisión de un nodo RPC y envenenamiento de RPC, pero que fue su propia infraestructura la que se vio comprometida. “Dado que no dice cómo ocurrió la brecha, no me apresuraría a volver a habilitar los puentes”, añadió.
¿Diagnóstico equivocado, solución equivocada?
El analista The Smart Ape también [https://x.com/the_smart_ape/status/2046156224303911011?s=20] afirma que LayerZero realizó un diagnóstico incorrecto y ofreció la solución equivocada. Notablemente, el post‑mortem del protocolo sugería migrar todas las aplicaciones con configuraciones DVN 1‑de‑1 a configuraciones multi‑DVN para evitar ataques similares.
Sin embargo, el analista señaló que los verificadores múltiples no impedirán el próximo ataque multimillonario, argumentando que pueden fallar ya que todas las DVNs leen los estados de cadena de los mismos pocos proveedores RPC, que en su mayoría están agrupados en AWS o GCP.
Si cinco DVNs “independientes” leen de los mismos tres proveedores RPC, un atacante que envenene esos tres RPC envenenará a los cinco verificadores simultáneamente. “Si todos tus verificadores son engañados de la misma manera al mismo tiempo, la matemática vuelve a colapsar a 1‑de‑1. Cinco clones no son cinco testigos”, añadió.
Para resolver esto, el analista sugirió que cada [https://www.newsbtc.com/news/iphone-users-warned-crypto-scams-can-trigger-coruna-ios-exploits/] verificador ejecute su propio nodo completo con diferente software cliente, alojado en distintos proveedores de nube, mantenido por diferentes equipos de operaciones, conectado con diferentes subconjuntos de la red Ethereum.
“El arreglo no es multi‑cualquier cosa. La solución es que los verificadores deben atestiguar su propio sustrato, no solo el estado de la cadena. Hasta que puedas auditar la topología upstream de una DVN, qué proveedores RPC, qué software cliente, qué nubes, qué regiones, ‘M‑of‑N secured’ es solo un copy de marketing para una propiedad que aún no se ha construido. Lazarus no rompió criptografía el 18 de abril. Rompieron tres servidores”, concluyó.
