MultiversX suspendió las operaciones de su mainnet después de que un atacante intentara explotar un problema de atomicidad transaccional en la capa de máquina virtual de la red, dejando cambios inválidos registrados en la blockchain. El equipo detuvo la producción de bloques, puso un parche en pruebas de shadow fork y dijo que evalúa una recuperación dirigida. No se ha revelado una cifra confirmada de pérdidas.

Lo que MultiversX confirmó

• El problema involucraba la atomicidad transaccional.
• Se registraron cambios inválidos en la blockchain.
• Las operaciones de la mainnet fueron suspendidas.
• Un parche entró en pruebas de shadow fork.
• Se estaba evaluando una recuperación dirigida.

Lo que sigue sin saberse

• Si los usuarios perdieron fondos permanentemente.
• Qué cuentas o contratos fueron afectados.
• Cómo el atacante provocó la falla.
• Qué método de recuperación se adoptará.
• Cuándo reabrirá cada servicio.

La detención congeló el problema—no lo deshizo

En su actualización del incidente, MultiversX dijo que un atacante intentó explotar un problema de atomicidad en la capa de máquina virtual de la mainnet. Los desarrolladores suspendieron las operaciones de la red mientras rastreaban los cambios de estado resultantes y preparaban un parche. No se había revelado una cifra confirmada de pérdidas.

Detener la producción de bloques evita que nuevas transacciones se construyan sobre registros que ya podrían ser incorrectos. También bloquea otro intento con el mismo método mientras los ingenieros determinan qué saldos o entradas de contratos fueron afectados.

La pausa no deshace los cambios que la red ya aceptó. Esos registros siguen siendo el punto de partida utilizado por wallets, aplicaciones y puentes hasta que MultiversX adopte un plan de recuperación.

Al verificarlo el 20 de septiembre, la página de estado de MultiversX clasificaba el sistema como parcialmente degradado. La API pública, xPortal, Explorer, Wallet, Bridge, xExchange y xLaunchpad mostraban rendimiento degradado, mientras que la gateway y el index figuraban como operativos.

Esas etiquetas describen servicios individuales y no confirman que el procesamiento normal de transacciones se haya reanudado. Restaurar las interfaces tampoco resolvería el problema contable subyacente. Para entender por qué, conviene empezar por la atomicidad transaccional.

La atomicidad es la versión blockchain de "todo o nada"

Una transacción de contrato inteligente puede contener varias operaciones conectadas. Un saldo podría reducirse, otro aumentarse y un pool de liquidez actualizarse. La ejecución atómica exige que la secuencia completa tenga éxito antes de que cualquiera de esos cambios se vuelva permanente.

Resultado esperado: cada paso requerido tiene éxito y todos los cambios seman juntos. Si cualquier paso falla, ninguno de los cambios de la transacción debería confirmarse.

Falla de atomicidad: una operación falla, pero un cambio de estado anterior permanece. La red puede entonces registrar un resultado parcial que no debería haber existido por sí solo.

Este es un ejemplo simplificado de atomicidad, no una reconstrucción del incidente de MultiversX. Una transacción rota podría dejar un saldo de cuenta, un suministro de tokens o un registro de contrato inconsistente con el resultado previsto. MultiversX no ha revelado qué tipo de datos fue alterado, por lo que no hay evidencia suficiente para afirmar que el atacante creó tokens, drenó un contrato específico o robó un monto conocido.

La finalidad prueba acuerdo, no ejecución libre de errores

La finalidad blockchain significa que los validadores han acordado qué bloque y estado resultante pertenecen a la cadena canónica. No prueba que el software usado para calcular ese estado estuviera libre de defectos.

Los validadores ejecutan las mismas reglas de protocolo y comparan sus resultados. Si esas reglas contienen la misma falla en todos los nodos, los validadores pueden acordar consistentemente un resultado que el protocolo nunca tuvo la intención de permitir. El consenso puede establecer qué estado aceptó la red; no puede garantizar que un error de software no haya ayudado a producir ese estado.

Instalar software corregido evita que la misma ruta de ejecución vuelva a funcionar, pero no decide qué debe hacerse con los cambios ya registrados. MultiversX debe identificar las entradas afectadas y dar a los validadores una forma reproducible de verificar que la actividad no relacionada permanece intacta.

El shadow fork ofrece un ensayo antes de reiniciar la mainnet

MultiversX ha preparado un parche para probarlo en un entorno de shadow fork. Un shadow fork copia el historial y estado relevantes de la mainnet en un entorno aislado, permitiendo a los ingenieros reproducir condiciones reales de red sin experimentar con saldos en vivo.

El equipo puede aplicar el parche, reproducir la secuencia afectada y probar una recuperación propuesta antes de que los validadores lo instalen en la mainnet. Ese proceso debería establecer:

• Si los nodos calculan el mismo estado reparado.
• Si los saldos no afectados permanecen intactos.
• Si las aplicaciones leen correctamente los registros corregidos.
• Si los puentes y exchanges pueden conciliar sus datos.
• Si los validadores pueden reiniciar sin producir cadenas competidoras.

Superar esas pruebas no reabriría todos los servicios automáticamente. El despliegue todavía requiere coordinación entre validadores, exchanges, puentes y los proveedores de infraestructura que conectan a usuarios y aplicaciones con MultiversX.

Una reparación dirigida evitaría rebobinar toda la cadena

MultiversX dijo que estaba evaluando una recuperación dirigida destinada a preservar el historial de transacciones finalizado y los registros legítimos de usuarios, abordando solo los cambios relacionados con el incidente. El proyecto no ha explicado cómo se implementaría esa corrección.

Corrección de estado dirigida. Solo se repararían los saldos, almacenamiento de contratos u otros registros conectados con el incidente, y las transacciones no relacionadas podrían permanecer en el historial finalizado. La principal dificultad es probar que la corrección incluye cada cambio inválido—y nada más.

Rebobinado amplio de la cadena. La network volvería a un bloque anterior y reconstruiría desde ahí. Las transacciones completadas después de ese punto podrían desaparecer incluso si no tenían conexión con el incidente. La principal dificultad es que las transferencias legítimas y la actividad de aplicaciones podrían necesitar repetirse o conciliarse.

El costo de un rebobinado más amplio fue visible tras el exploit de Tectonic, cuando los validadores de Cronos eliminaron casi 11,000 bloques que cubrían casi dos horas. El rebobinado revirtió la mayoría de los préstamos relacionados con el incidente aún registrados en Cronos, pero también revirtió transacciones no relacionadas completadas durante ese período. Los dos incidentes tienen causas distintas; el ejemplo de Cronos importa porque muestra el costo colateral de rebobinar un ledger compartido.

MultiversX dice que está considerando una reparación más estrecha, pero aún no ha mostrado cómo se aislarían los registros afectados. Una reparación dirigida no necesariamente eliminaría los bloques originales: el historial de transacciones podría seguir visible mientras un cambio de protocolo coordinado establece el estado que las aplicaciones y validadores reconocerán tras el reinicio. El método no puede evaluarse correctamente hasta que MultiversX publique su diseño de recuperación.

Qué deben hacer los usuarios de MultiversX durante la pausa

Para los holders comunes, la instrucción más simple es esperar. MultiversX no ha pedido a los usuarios migrar tokens, conectar wallets a un sitio web de recuperación ni aprobar una transacción correctiva.

• No enviar ni retransmitir transacciones.
• No depositar ni retirar EGLD ni ESDT a través de exchanges.
• Evitar mover esos activos mediante puentes cross-chain.
• Conservar el hash de transacción de todo lo enviado cerca de la detención.
• Ignorar enlaces de recuperación, migraciones y mensajes de soporte no solicitados.
• Esperar a que tanto MultiversX como la plataforma correspondiente confirmen la reapertura.

Una reparación de red sería adoptada por validadores y operadores de infraestructura. No requeriría que los usuarios revelen frases semilla ni envíen activos a una nueva dirección.

Las wallets y explorers también pueden necesitar tiempo para resincronizarse después de que se reanude la producción de bloques. Un saldo desactualizado o una transacción reciente faltante en una interfaz no indicaría, por sí solo, que los activos subyacentes han cambiado.

Un reinicio debe ser verificable

Reiniciar la producción de bloques restaurará la disponibilidad, pero por sí solo no responderá la pregunta de la finalidad. MultiversX todavía necesita revelar qué cuentas o contratos fueron afectados, cómo se calculó el estado reparado y cómo los validadores llegaron independientemente al mismo resultado.

Si ese registro muestra que solo se corrigieron los cambios relacionados con el incidente, la recuperación dirigida puede preservar más actividad legítima que un rebobinado amplio. Sin él, la red podría reanudarse mientras los usuarios siguen sin poder verificar por qué algunos cambios finalizados fueron alterados y otros se conservaron.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento financiero ni de inversión. Las condiciones de la red y las instrucciones de recuperación pueden cambiar a medida que MultiversX publique nuevas actualizaciones.