Ataque de Mint Infinito
Definition pending verification.
Um ataque de mint infinito, frequentemente referido como 'glitch de mint' ou 'vulnerabilidade de reentrância' no contexto de contratos inteligentes, é um tipo de exploração onde um atacante manipula a lógica de um contrato para mintar uma quantidade arbitrariamente grande de tokens ou ativos. Isso geralmente ocorre em protocolos de finanças descentralizadas (DeFi), particularmente aqueles que envolvem mecanismos de mintagem de tokens, empréstimos ou colateralização. A vulnerabilidade central muitas vezes reside em como o contrato lida com chamadas externas ou atualiza seu estado interno durante uma transação. Por exemplo, um contrato pode permitir que um usuário deposite colateral, mint um novo token com base nesse colateral e, em seguida, retire o colateral, tudo dentro de uma única transação. Se o contrato mintar o novo token antes de verificar o depósito do colateral ou atualizar seu estado interno corretamente, um atacante pode acionar a função de mintagem várias vezes dentro do mesmo contexto de transação. Cada chamada pode mintar mais tokens com base no mesmo colateral inicial (ou insuficientemente verificado), levando à criação de quantidades 'infinitas' ou vastamente infladas de tokens do nada. Isso desvaloriza o token e pode drenar as reservas do protocolo. A prevenção de tais ataques requer um design cuidadoso de contratos inteligentes, incluindo o uso do padrão 'checks-effects-interactions' (verificações-efeitos-interações), guardas de reentrância, atualizações de estado adequadas antes de chamadas externas e auditorias completas.
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;
🧒 Explique como se eu tivesse 5 anos
Imagine uma máquina de biscoitos mágica que deveria te dar um biscoito para cada moeda de ouro que você coloca. Se a máquina estiver quebrada, você pode conseguir colocar uma moeda, pegar um biscoito e, em seguida, usar *esse* biscoito para enganar a máquina, fazendo-a pensar que você colocou outra moeda, obtendo biscoitos infinitos!
🤓 Expert Deep Dive
Ataques de mint infinito exploram falhas na lógica de transição de estado de contratos inteligentes, muitas vezes relacionadas à reentrância ou ao manuseio incorreto de chamadas externas. Um padrão comum envolve uma função que: 1) Aceita entrada do usuário (por exemplo, colateral). 2) Realiza uma chamada externa (por exemplo, para um contrato de token ERC777 que aciona um callback). 3) Atualiza o estado interno (por exemplo, minta tokens, atualiza saldos). Se a chamada externa acionar uma chamada reentrante de volta para a função original antes que o estado seja atualizado (por exemplo, o colateral seja totalmente contabilizado ou o saldo seja ajustado), o atacante pode explorar isso. Por exemplo, em um protocolo de empréstimo, um usuário deposita colateral C, chama mint(loan_amount), que internamente chama um contrato de token externo. A função de fallback deste contrato de token reentra na função mint, permitindo que o atacante mint novamente usando o mesmo colateral C antes que a primeira chamada mint conclua sua atualização de estado. O padrão 'Checks-Effects-Interactions' é crucial: verificar condições (Checks), atualizar o estado interno (Effects), e então interagir com contratos externos (Interactions). Guardas de reentrância (mutexes) também podem prevenir chamadas recursivas dentro do mesmo contexto de transação. Vulnerabilidades também podem surgir das capacidades de reentrância do ERC777 ou implementações ERC20 falhas.