Seguridad de Memoria de Move VM vs Reentrada de EVM: Por qué el Modelo de Recursos de Aptos y Sui Elimina Clases Enteras de Vulnerabilidades en Contratos Inteligentes
El hackeo de la DAO de 2016 drenó 35,7 millones en 22 incidentes distintos solo en 2024. La misma clase de vulnerabilidad — un atacante que realiza una retrollamada a un contrato antes de que se actualice su estado — continúa acechando al ecosistema EVM a pesar de años de educación para desarrolladores, herramientas de auditoría y patrones probados en batalla.
Aptos y Sui, ambos construidos sobre el lenguaje Move, adoptan un enfoque fundamentalmente diferente: hacen que categorías enteras de vulnerabilidades sean imposibles por diseño.
La causa raíz: Cómo ocurre la reentrada en EVM
Para entender por qué Move es diferente, ayuda comprender exactamente por qué la reentrada es posible en Ethereum en primer lugar.
Los contratos de Solidity pueden llamar a contratos externos a mitad de la ejecución. Cuando el contrato A llama al contrato B, la ejecución se transfiere por completo a B. B puede entonces realizar una retrollamada a A — "reentrando" en él — antes de que A haya terminado de actualizar su estado interno. Si la lógica de retiro de A se ve así:
// Patrón vulnerable
function withdraw(uint amount) external {
require(balances[msg.sender] >= amount);
(bool success, ) = msg.sender.call{value: amount}(""); // llamada externa primero
balances[msg.sender] -= amount; // actualización de estado después
}
El contrato de un atacante puede recibir ETH en la retrollamada, llamar inmediatamente a withdraw de nuevo y drenar los fondos antes de que balances[msg.sender] se decremente. Esto es exactamente lo que le sucedió a la DAO — el contrato del atacante llamó recursivamente a la función de retiro 3,6 millones de veces en un bucle.
La solución suena simple: actualizar el estado antes de realizar llamadas externas (el patrón "Checks-Effects-Interactions"). Pero los desarrolladores lo olvidan. Los auditores lo pasan por alto. El patrón es una convención impuesta solo por la diligencia humana, no por el lenguaje en sí.
El enfoque de Move: Los recursos no se pueden duplicar ni destruir
Move fue diseñado desde cero para prevenir esta clase de errores a nivel del sistema de tipos. El concepto central es el sistema de tipos lineales (linear type system) y los tipos de recursos.
En Move, un recurso es un tipo especial de valor que:
- No se puede copiar — solo se puede mover entre ubicaciones de almacenamiento
- No se puede descartar — debe consumirse explícitamente o almacenarse en algún lugar
- Tiene un único propietario en cualquier momento dado — rastreado por la VM, no por un mapeo (mapping)
Esto suena abstracto, pero las implicaciones son concretas. Considere cómo funciona una transferencia de tokens:
- En Solidity, el saldo de un token es un
uint256en un mapeo. El número puede manipularse teóricamente si el orden de actualización es incorrecto. - En Move, un token es un objeto de recurso real que vive en el almacenamiento de una cuenta. Lo mueves físicamente de una ubicación a otra — no existe un estado intermedio donde el recurso resida en dos lugares o en ninguno.
La Move VM impone estas invariantes a nivel de bytecode, no a nivel de código fuente. Incluso si un desarrollador escribe código con errores, la VM rechazará cualquier transacción que intente duplicar o descartar silenciosamente un recurso.
Por qué la reentrada es estructuralmente imposible en Move
La reentrada requiere dos condiciones: la capacidad de llamar a código externo a mitad de la ejecución y un estado compartido mutable que pueda manipularse durante esa retrollamada. Move rompe ambas.
Move no permite el despacho dinámico (dynamic dispatch) de la forma en que lo hace Solidity. No hay llamadas externas arbitrarias que pasen el control a un código desconocido. Las funciones deben llamarse estáticamente — el receptor de la llamada se conoce en tiempo de compilación. Esto significa que un atacante no puede desplegar un contrato que reentre en su módulo durante una retrollamada, porque su módulo nunca entrega la ejecución a un contrato externo desconocido.
Además, el modelo de objetos de Move en Sui y Aptos utiliza un sistema de propiedad (ownership) donde los objetos se pasan explícitamente dentro y fuera de las funciones. Un objeto que ha sido "movido" a una función no es accesible en ningún otro lugar hasta que la función lo devuelva. El acceso concurrente al mismo recurso en una sola transacción simplemente no es posible.
Investigaciones publicadas en 2025 confirman: "En Move, la reentrada no es posible ya que las retrollamadas dinámicas no son posibles — una diferencia fundamental con Solidity donde la reentrada sigue siendo una amenaza importante".
Prevención de doble gasto sin bloqueos mutex
En los sistemas basados en EVM, la protección contra el doble gasto depende de una programación cuidadosa. Los desarrolladores deben asegurarse manualmente de que un token no se pueda gastar dos veces en una transacción rastreando diligentemente las actualizaciones de estado.
El sistema de tipos lineales de Move hace que el doble gasto sea estructuralmente imposible. Debido a que un recurso no se puede copiar, gastar una moneda literalmente la elimina del almacenamiento de su cuenta. No hay forma de gastar el mismo recurso dos veces en una transacción porque, después del primer gasto, el recurso ya no existe bajo su control. La VM impone esto — no es una convención, es una restricción.
Esto también se extiende a los objetos de capacidad (capability objects) en Sui. Un recurso Capability, una vez consumido, no puede volver a utilizarse. Compare esto con los patrones de control de acceso de EVM, donde una capacidad es típicamente un rol codificado en un booleano o mapeo de direcciones, que puede verificarse varias veces.
Un incidente del mundo real en Sui resalta un matiz: se descubrió que un DEX tenía un fallo donde la lógica de retiro no imponía restricciones de un solo uso en una referencia mutable a una capacidad — no en la capacidad misma. Esto demuestra que, si bien el modelo de recursos de Move elimina clases enteras de errores, los desarrolladores aún pueden introducir errores de lógica al trabajar con referencias en lugar de recursos propios. La superficie de amenaza se reduce drásticamente, pero no a cero.
Desbordamiento de enteros: Otro problema que Move resuelve por defecto
En las primeras versiones de Solidity (anteriores a la 0.8.0), la aritmética de enteros realizaba un ciclo de desbordamiento (wrap around) de forma silenciosa. Esto permitía a los atacantes manipular los saldos de los tokens activando condiciones de desbordamiento, una vulnerabilidad que contribuyó a varios exploits de DeFi de alto perfil.
Solidity 0.8.0 introdujo la comprobación automática de desbordamiento, pero solo tras años de daños. Move ha incluido esta protección desde su creación: cualquier transacción que provoque un desbordamiento de enteros se aborta automáticamente. No hay opción de exclusión, no existe un equivalente a unchecked por defecto, y no hay contratos heredados con el comportamiento antiguo de los que preocuparse.
Verificación formal: Move Prover frente a la auditoría de EVM
La historia de seguridad de Move se extiende más allá del lenguaje hasta sus herramientas. El Move Prover es una herramienta de verificación formal integrada junto con el propio lenguaje, no una ocurrencia de último momento.
Con Move Prover, los desarrolladores escriben especificaciones directamente en sus archivos fuente de Move utilizando un lenguaje de especificación. Estas especificaciones se verifican matemáticamente frente a la implementación. Una especificación podría afirmar: "Tras la ejecución de esta función, el suministro total de monedas permanece inalterado". El Prover confirmará que esto es siempre cierto o proporcionará un contraejemplo que muestre exactamente cuándo falla.
Esto es categóricamente diferente de cómo funcionan la mayoría de las auditorías de Solidity:
| Aspecto | Move Prover | Herramientas de auditoría de Solidity |
|---|---|---|
| Tipo de verificación | Prueba matemática | Coincidencia de patrones / fuzzing |
| Cobertura | Completa (dentro del alcance de la especificación) | Mejor esfuerzo |
| Integración | Parte de la cadena de herramientas del lenguaje | Herramientas de terceros (Slither, Certora) |
| Momento | Tiempo de desarrollo | Auditoría previa al despliegue |
| Coste | Gratuito, en el repositorio | Auditorías manuales costosas |
Herramientas como Slither para Solidity realizan análisis estáticos y detectan patrones de vulnerabilidad conocidos. Certora Prover para Solidity sí admite la verificación formal y puede expresar un conjunto más amplio de propiedades, incluidos los invariantes entre transacciones. Pero Certora requiere escribir especificaciones en un lenguaje separado y ejecutar un flujo de trabajo independiente, lo que lo convierte en un paso de auditoría especializado en lugar de una herramienta de desarrollo cotidiana.
La integración más estrecha de Move Prover significa que la verificación formal es algo que los desarrolladores de Aptos y Sui pueden ejecutar localmente durante el desarrollo, no solo como un costoso filtro de auditoría. El propio framework de Aptos se distribuye con especificaciones de Move Prover para su biblioteca estándar, proporcionando una base de seguridad que los desarrolladores de aplicaciones heredan.
El riesgo residual: Lo que Move no elimina
El diseño de Move no es una garantía de seguridad universal. Las auditorías del mundo real de los contratos de Move revelan que los desarrolladores aún pueden introducir:
- Errores de lógica en las reglas de negocio (la categoría más común)
- Errores de control de acceso al utilizar referencias mutables en lugar de recursos propios
- Defectos de diseño económico en los protocolos DeFi (manipulación de oráculos de precios, ataques de préstamos rápidos o flash loans)
- Errores de interacción entre módulos cuando varios módulos interactúan de formas inesperadas
Un estudio de 2024 auditó manualmente 652 contratos de Move e identificó ocho tipos de defectos, la mitad de los cuales no habían sido reportados anteriormente. La superficie de ataque es menor que la de Solidity, pero sigue existiendo.
La mejor postura de seguridad en Aptos y Sui combina especificaciones de Move Prover, auditorías de terceros y análisis de seguridad económica, no solo la confianza en las protecciones integradas del lenguaje.
Por qué esto es importante para los constructores de DeFi en 2025
Las cifras cuentan una historia cruda. En 2024, las vulnerabilidades de los contratos inteligentes le costaron al sector DeFi más de 35,7 millones de esa cifra, una categoría que sería estructuralmente inexistente en una cadena basada en Move con un TVL equivalente.
Para los desarrolladores que crean aplicaciones financieras, la elección de la VM es, en efecto, una elección sobre su modelo de amenazas por defecto. Construir en EVM significa adoptar el patrón Checks-Effects-Interactions (Verificaciones-Efectos-Interacciones) como una disciplina obligatoria. Construir en Move significa que la reentrada simplemente no está en su modelo de amenazas en absoluto; su equipo puede centrar su atención de seguridad en los errores de lógica y el diseño económico en su lugar.
Esta no es una diferencia menor. Las herramientas de verificación formal funcionan mejor cuando la superficie de amenaza es más pequeña. Los auditores pueden profundizar más cuando no están gastando ciclos en clases de vulnerabilidades bien conocidas. La carga cognitiva de los desarrolladores que escriben código correcto disminuye cuando el lenguaje impone invariantes críticos automáticamente.
La capa de infraestructura
Las garantías de seguridad solo importan si los desarrolladores pueden realmente construir en estas cadenas a escala. Ejecutar su propio nodo de Aptos o Sui para acceder a la red implica una sobrecarga operativa significativa: aprovisionamiento de hardware, actualizaciones de software, supervisión y respuesta a incidentes.
BlockEden.xyz proporciona acceso API de nivel empresarial para Aptos y Sui, permitiendo a los desarrolladores construir sobre las garantías de seguridad de Move sin gestionar la infraestructura de nodos. Explore nuestros servicios para crear aplicaciones Web3 más seguras.
La combinación de un lenguaje con seguridad de memoria, la prevención estructural de reentrada y la verificación formal integrada convierte a Aptos y Sui en una plataforma convincente para aplicaciones DeFi de alto riesgo. Move no solo facilita la escritura de contratos inteligentes seguros, sino que hace que ciertas clases de fallos catastróficos sean matemáticamente imposibles.
Fuentes consultadas:
- Reentrancy Attacks and The DAO Hack Explained — Chainlink
- Formal verification in Solidity and Move: insights from a comparative analysis — arXiv 2502.13929
- Move Fast & Break Things, Part 2: A Sui Security Primer — Zellic
- The 5 Smart Contract Vulnerabilities That Cost DeFi $1.4 Billion in 2024 — Medium
- Top 10 Smart Contract Vulnerabilities in 2025 — Hacken
- Analyzing and detecting four types of critical security vulnerabilities in Move smart contracts — Springer