Ataque de Mint Infinito
Definition pending verification.
Un ataque de mint infinito, a menudo denominado 'fallo de mint' o 'vulnerabilidad de reentrada' en el contexto de contratos inteligentes, es un tipo de exploit donde un atacante manipula la lógica de un contrato para mintear una cantidad arbitrariamente grande de tokens o activos. Esto ocurre típicamente en protocolos de finanzas descentralizadas (DeFi), particularmente aquellos que involucran mecanismos de minting de tokens, préstamos o colateralización. La vulnerabilidad central a menudo reside en cómo el contrato maneja las llamadas externas o actualiza su estado interno durante una transacción. Por ejemplo, un contrato podría permitir a un usuario depositar colateral, mintear un nuevo token basado en ese colateral y luego retirar el colateral, todo dentro de una sola transacción. Si el contrato mintea el nuevo token antes de verificar el depósito del colateral o actualizar su estado interno correctamente, un atacante podría activar la función de minting múltiples veces dentro del mismo contexto de transacción. Cada llamada podría mintear más tokens basándose en el mismo colateral inicial (o insuficientemente verificado), lo que lleva a la creación de cantidades 'infinitas' o enormemente infladas de tokens de la nada. Esto devalúa el token y puede agotar las reservas del protocolo. La prevención de tales ataques requiere un diseño cuidadoso de contratos inteligentes, incluido el uso del patrón 'Checks-Effects-Interactions' (Comprobaciones-Efectos-Interacciones), protectores de reentrada, actualizaciones de estado adecuadas antes de llamadas externas y auditorías exhaustivas.
graph LR
Center["Ataque de Mint Infinito"]:::main
Pre_logic["logic"]:::pre --> Center
click Pre_logic "/terms/logic"
Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
Rel_consciousness_simulation_hardware["consciousness-simulation-hardware"]:::related -.-> Center
click Rel_consciousness_simulation_hardware "/terms/consciousness-simulation-hardware"
Rel_cognitive_enhancement["cognitive-enhancement"]:::related -.-> Center
click Rel_cognitive_enhancement "/terms/cognitive-enhancement"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explícalo como si tuviera 5 años
Imagina una máquina de galletas mágica que se supone que te da una galleta por cada moneda de oro que metes. Si la máquina está rota, podrías meter una moneda, obtener una galleta, y luego usar *esa* galleta para engañar a la máquina haciéndole creer que metiste otra moneda, ¡obteniendo galletas infinitas!
🤓 Expert Deep Dive
Los ataques de mint infinito explotan fallos en la lógica de transición de estado de los contratos inteligentes, a menudo relacionados con la reentrada o el manejo incorrecto de llamadas externas. Un patrón común implica una función que: 1) Acepta entrada del usuario (por ejemplo, colateral). 2) Realiza una llamada externa (por ejemplo, a un contrato de token ERC777 que activa una devolución de llamada). 3) Actualiza el estado interno (por ejemplo, mintea tokens, actualiza saldos). Si la llamada externa activa una llamada reentrante de vuelta a la función original antes de que se actualice el estado (por ejemplo, el colateral se contabiliza por completo o se ajusta el saldo), el atacante puede explotarlo. Por ejemplo, en un protocolo de préstamos, un usuario deposita colateral C, llama a mint(loan_amount), que internamente llama a un contrato de token externo. La función de devolución de llamada de este contrato de token vuelve a entrar en la función mint, permitiendo al atacante mintear de nuevo usando el mismo colateral C antes de que la primera llamada mint complete su actualización de estado. El patrón 'Checks-Effects-Interactions' (Comprobaciones-Efectos-Interacciones) es crucial: verificar condiciones (Checks), actualizar el estado interno (Effects), luego interactuar con contratos externos (Interactions). Los protectores de reentrada (mutex) también pueden prevenir llamadas recursivas dentro del mismo contexto de transacción. Las vulnerabilidades también pueden surgir de las capacidades de reentrada de ERC777 o implementaciones de ERC20 defectuosas.