Mantle respalda la corrección de Reth en op-reth v1.6.3 tras el error del 5 de noviembre; los activos están seguros
Puntos clave
- •Mantle Network lanzó op-reth mantle-v1.6.3, una versión de su propia línea de producción que traslada la corrección upstream de Reth en lugar de pasar a la versión upstream más reciente.
- •La firma de seguridad Blockaid reveló el 5 de noviembre que los nodos sin parche podrían generar raíces de estado incorrectas y devolver pruebas de estado erróneas a través de eth_getProof, el método RPC que las aplicaciones y los puentes utilizan para verificar el estado en cadena.
- •La corrección upstream llegó a Reth el 3 de noviembre, dos días antes de la revelación pública, en versiones parcheadas que incluían Reth v2.10.0 y op-reth v2.8.1.
- •Blockaid clasificó el problema como un error de corrección y no como un exploit, y no encontró pérdidas de fondos, mientras que Mantle confirmó que los activos están seguros, que no se requiere acción de los usuarios ni migración de base de datos.
- •Como la mayoría de las cadenas de OP Stack comparten el cliente op-reth, el error generó un riesgo correlacionado entre redes que de otro modo serían independientes, lo que provocó respuestas como la publicación de node-reth v1.5.3 por parte de Base y la integración de un backport por parte de Celo.

Mantle Network permaneció en línea durante un error de raíz de estado presente en Reth, el cliente de ejecución upstream detrás de su stack op-reth, que afectaba de manera más amplia a las redes compatibles con Ethereum. El equipo lanzó op-reth mantle-v1.6.3, una versión de la propia línea de producción de Mantle que traslada la corrección upstream del error en lugar de saltar a la versión upstream más reciente. En un anuncio en X, Mantle informó que los activos están seguros, no se requiere acción de los usuarios ni migración de base de datos, y pidió a los operadores de nodos que actualicen (publicación).
Un incidente breve con mucho en juego
El episodio fue breve e invisible para los usuarios finales, lo que podría hacerlo parecer poco importante. No lo es: las raíces de estado son compromisos criptográficos que se utilizan para demostrar la validez de los saldos de las cuentas y el almacenamiento de los contratos, y un cálculo incorrecto puede hacer que los nodos se detengan, devuelvan pruebas inválidas o se desvíen de la cadena canónica. "Para que una Layer 2 se asiente en Ethereum, la corrección en esta capa es fundamental", subrayó el anuncio de Mantle.
Qué ocurrió y quién fue afectado
La falla estaba en Reth, una implementación en Rust de un cliente de ejecución de Ethereum, y en op-reth, su variante de OP Stack desplegada por varias redes de Layer 2. El 5 de noviembre, la firma de seguridad Blockaid reveló que los nodos sin parche podrían producir raíces de estado incorrectas y devolver pruebas de estado erróneas a través de eth_getProof, el método RPC que las aplicaciones y los puentes utilizan para verificar el estado en cadena. Blockaid clasificó el problema como un error de corrección y no como un exploit, y no encontró pérdidas de fondos. La corrección upstream había llegado a Reth el 3 de noviembre —dos días antes de la revelación pública de Blockaid— incluida en versiones parcheadas como Reth v2.10.0 y op-reth v2.8.1.
La respuesta se extendió por todo el ecosistema. Base publicó node-reth v1.5.3 y confirmó haber verificado nuevamente la corrección de su nodo, mientras que Celo integró un backport. Mantle eligió un camino distinto: parchear directamente su línea de producción en lugar de actualizar a la versión más reciente —la vía del backport, que entrega una corrección específica a una línea de versiones existente sin incorporar cambios no relacionados de versiones upstream más nuevas.
Por qué importa para el ecosistema cripto en general
Los clientes de ejecución se encuentran entre los componentes menos visibles pero más trascendentales de la infraestructura blockchain. Los desarrolladores extienden APIs y ejecutan indexadores sobre ellos. Las instituciones dependen de custodios, exchanges y proveedores de datos. Cada una de estas capas se apoya en que los nodos lleguen a un consenso sobre el estado. Una raíz de estado incorrecta no significa necesariamente fondos robados —puede significar pruebas inexactas, sincronización detenida o aplicaciones que reciben datos inconsistentes.
Cuando los puentes y los servicios de mensajería entre cadenas dependen de un estado demostrable, incluso una inconsistencia breve puede desencadenar detenciones preventivas. Esas detenciones fueron una respuesta defensiva, no el resultado de una explotación, pero demuestran la rapidez con la que un solo error en un cliente puede generar disrupciones en todo el ecosistema.
El episodio también resalta la importancia de la diversidad de clientes, y sus límites. La capa de ejecución de Ethereum se beneficia de ejecutar múltiples clientes, lo que reduce el riesgo sistémico si uno falla. Sin embargo, la mayoría de las cadenas de OP Stack comparten op-reth. Por lo tanto, un error en ese componente común genera un riesgo correlacionado entre redes que de otro modo serían independientes.
Qué sigue para Mantle y las redes de OP Stack
El paso inmediato es la adopción por parte de los operadores. Un parche solo reduce el riesgo una vez que los operadores de nodos, los proveedores de RPC, los validadores y los equipos de infraestructura lo despliegan, y se espera que los operadores planifiquen actualizaciones y prueben sus nodos. Blockaid aconsejó a los protocolos y puentes verificar que sus proveedores estén parcheados.
A más largo plazo, el episodio subraya tres patrones: revelaciones y backports más rápidos para líneas de producción que no pueden actualizarse de inmediato; más contingencias para errores de clientes, incluida la verificación de pruebas para mensajes entre cadenas cuando estas no son confiables; y un análisis continuo de las dependencias compartidas entre las cadenas de OP Stack.
Para Mantle, la prueba es la continuidad. Su propuesta fundacional se basa en la escalabilidad, las bajas comisiones y la liquidación confiable para las finanzas descentralizadas, los juegos y las aplicaciones de consumo. Permanecer en línea durante un error upstream respalda esa propuesta, pero la red todavía necesita demostrar que su línea de producción se mantiene sincronizada con los parches de seguridad upstream. La seguridad blockchain, al final, también se trata del software que calcula el estado —y de la velocidad con la que se parchea.