Saltar para o conteúdo principal

Segurança de Memória da Move VM vs Reentrância da EVM: Por que o Modelo de Recursos de Aptos e Sui Elimina Classes Inteiras de Vulnerabilidades de Contratos Inteligentes

· 11 min de leitura
Dora Noda
Dora Noda
Software Engineer

O hack da DAO de 2016 drenou $ 60 milhões do Ethereum em uma única tarde. Nove anos depois, os ataques de reentrada ainda custam aos protocolos DeFi $ 35,7 milhões em 22 incidentes distintos apenas em 2024. A mesma classe de vulnerabilidade — um invasor chamando de volta um contrato antes que seu estado seja atualizado — continua a assombrar o ecossistema EVM, apesar de anos de educação de desenvolvedores, ferramentas de auditoria e padrões testados em batalha.

Aptos e Sui, ambas construídas na linguagem Move, adotam uma abordagem fundamentalmente diferente: elas tornam categorias inteiras de vulnerabilidades impossíveis por design.

A Causa Raiz: Como a Reentrada na EVM Acontece​

Para entender por que a Move é diferente, ajuda entender exatamente por que a reentrada é possível no Ethereum, para começar.

Contratos Solidity podem chamar contratos externos no meio da execução. Quando o contrato A chama o contrato B, a execução é transferida inteiramente para B. B pode então chamar de volta o contrato A — "reentrando" nele — antes que A tenha terminado de atualizar seu estado interno. Se a lógica de retirada de A for parecida com esta:

// Padrão vulnerável
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}(""); // primeira chamada externa
    balances[msg.sender] -= amount;                         // segunda atualização de estado
}

O contrato de um invasor pode receber ETH no callback, chamar imediatamente withdraw novamente e drenar fundos antes que balances[msg.sender] seja sequer decrementado. Foi exatamente isso que aconteceu com a DAO — o contrato do invasor chamou recursivamente a função de retirada 3,6 milhões de vezes em um loop.

A correção parece simples: atualizar o estado antes de fazer chamadas externas (o padrão "Checks-Effects-Interactions"). Mas os desenvolvedores esquecem. Os auditores deixam passar. O padrão é uma convenção imposta apenas pela diligência humana, não pela linguagem em si.

A Abordagem Move: Recursos Não Podem Ser Duplicados ou Destruídos​

A Move foi projetada do zero para evitar essa classe de erro no nível do sistema de tipos. O conceito central é o sistema de tipos lineares e os tipos de recursos.

Na Move, um recurso é um tipo especial de valor que:

  • Não pode ser copiado — ele só pode ser movido entre locais de armazenamento
  • Não pode ser descartado — ele deve ser explicitamente consumido ou armazenado em algum lugar
  • Tem um único proprietário em qualquer momento — rastreado pela VM, não por um mapeamento

Isso parece abstrato, mas as implicações são concretas. Considere como funciona uma transferência de token:

  • Na Solidity, o saldo de um token é um uint256 em um mapeamento. O número pode teoricamente ser manipulado se a ordem de atualização estiver errada.
  • Na Move, um token é um objeto de recurso real que vive no armazenamento de uma conta. Você move-o fisicamente de um local para outro — não existe um estado intermediário onde o recurso existe em dois lugares, ou em lugar nenhum.

A Move VM impõe esses invariantes no nível do bytecode, não no nível do código-fonte. Mesmo que um desenvolvedor escreva um código com bugs, a VM rejeitará qualquer transação que tente duplicar ou descartar silenciosamente um recurso.

Por que a Reentrada é Estruturalmente Impossível na Move​

A reentrada requer duas condições: a capacidade de chamar código externo no meio da execução e um estado compartilhado mutável que possa ser manipulado durante esse callback. A Move quebra ambos.

A Move não permite despacho dinâmico da mesma forma que a Solidity. Não há chamadas externas arbitrárias que passam o controle para um código desconhecido. As funções devem ser chamadas estaticamente — o destinatário da chamada (callee) é conhecido em tempo de compilação. Isso significa que um invasor não pode implantar um contrato que reentre em seu módulo durante um callback, porque seu módulo nunca entrega a execução a um contrato externo desconhecido.

Além disso, o modelo de objetos da Move na Sui e na Aptos usa um sistema de propriedade (ownership) onde os objetos são passados explicitamente para dentro e para fora das funções. Um objeto que foi "movido para dentro" de uma função não está acessível em nenhum outro lugar até que a função o retorne. O acesso simultâneo ao mesmo recurso em uma única transação simplesmente não é possível.

Pesquisas publicadas em 2025 confirmam: "Na Move, a reentrada não é possível, pois callbacks dinâmicos não são possíveis — uma diferença fundamental em relação à Solidity, onde a reentrada continua sendo uma grande ameaça."

Prevenção de Gasto Duplo Sem Bloqueios Mutex​

Em sistemas baseados em EVM, a proteção contra gasto duplo depende de uma programação cuidadosa. Os desenvolvedores devem garantir manualmente que um token não possa ser gasto duas vezes em uma transação, rastreando as atualizações de estado diligentemente.

O sistema de tipos lineares da Move torna o gasto duplo estruturalmente impossível. Como um recurso não pode ser copiado, gastar uma moeda literalmente a remove do armazenamento da sua conta. Não há como gastar o mesmo recurso duas vezes em uma transação porque, após o primeiro gasto, o recurso não existe mais sob seu controle. A VM impõe isso — não é uma convenção, é uma restrição.

Isso também se estende aos objetos de capacidade (capability) na Sui. Um recurso Capability, uma vez consumido, não pode ser usado novamente. Compare isso com os padrões de controle de acesso da EVM, onde uma capacidade é tipicamente uma função (role) codificada em um booleano ou mapeamento de endereços, que pode ser verificada várias vezes.

Um incidente real na Sui destaca uma nuance: descobriu-se que uma DEX tinha uma falha onde a lógica de retirada falhava ao impor restrições de uso único em uma referência mutável para uma capacidade — não na capacidade em si. Isso demonstra que, embora o modelo de recursos da Move elimine classes inteiras de bugs, os desenvolvedores ainda podem introduzir erros de lógica ao trabalhar com referências em vez de recursos de propriedade. A superfície de ameaça é reduzida drasticamente, mas não a zero.

Transbordamento de Inteiros: Outro Problema que o Move Resolve por Padrão​

No Solidity antigo (pré-0.8.0), a aritmética de inteiros sofria "wrap around" silenciosamente em caso de transbordamento (overflow). Isso permitia que atacantes manipulassem saldos de tokens ao desencadear condições de overflow — uma vulnerabilidade que contribuiu para várias explorações de DeFi de alto perfil.

O Solidity 0.8.0 introduziu a verificação automática de overflow, mas apenas após anos de danos. O Move incluiu essa proteção desde a sua criação: qualquer transação que cause um transbordamento de inteiros é automaticamente abortada. Não há opção de exclusão, nenhum equivalente ao unchecked por padrão, e não há contratos legados com o comportamento antigo com os quais se preocupar.

Verificação Formal: Move Prover vs. Auditoria de EVM​

A história da segurança do Move estende-se além da linguagem, alcançando seu ferramental. O Move Prover é uma ferramenta de verificação formal construída juntamente com a própria linguagem — não uma reflexão tardia.

Com o Move Prover, os desenvolvedores escrevem especificações diretamente em seus arquivos de origem Move usando uma linguagem de especificação. Essas especificações são então verificadas matematicamente em relação à implementação. Uma especificação pode afirmar: "Após a execução desta função, o fornecimento total de moedas permanece inalterado". O Prover confirmará que isso é sempre verdade ou fornecerá um contraexemplo mostrando exatamente quando falha.

Isso é categoricamente diferente de como a maioria das auditorias de Solidity funciona:

AspectoMove ProverFerramentas de Auditoria Solidity
Tipo de verificaçãoProva matemáticaCorrespondência de padrões / fuzzing
CoberturaCompleta (dentro do escopo da especificação)Melhor esforço
IntegraçãoParte da cadeia de ferramentas da linguagemFerramentas de terceiros (Slither, Certora)
TimingTempo de desenvolvimentoAuditoria pré-implantação
CustoGratuito, no repositórioAuditorias manuais caras

Ferramentas como o Slither para Solidity realizam análise estática e detectam padrões conhecidos de vulnerabilidade. O Certora Prover para Solidity suporta verificação formal e pode expressar um conjunto mais amplo de propriedades — incluindo invariantes entre transações. Mas o Certora exige a escrita de especificações em uma linguagem separada e a execução de um pipeline separado, tornando-o uma etapa de auditoria especializada em vez de uma ferramenta de desenvolvimento diária.

A integração mais estreita do Move Prover significa que a verificação formal é algo que os desenvolvedores Aptos e Sui podem executar localmente durante o desenvolvimento, não apenas como uma barreira de auditoria cara. O próprio framework Aptos é enviado com especificações do Move Prover para sua biblioteca padrão, fornecendo uma base de segurança que os desenvolvedores de aplicações herdam.

O Risco Residual: O que o Move não Elimina​

O design do Move não é uma garantia de segurança universal. Auditorias do mundo real de contratos Move revelam que os desenvolvedores ainda podem introduzir:

  • Erros de lógica em regras de negócio (a categoria mais comum)
  • Bugs de controle de acesso ao usar referências mutáveis em vez de recursos próprios (owned resources)
  • Falhas de design econômico em protocolos DeFi (manipulação de oráculos de preços, ataques de flash loan)
  • Bugs de interação entre módulos quando múltiplos módulos interagem de formas inesperadas

Um estudo de 2024 auditou manualmente 652 contratos Move e identificou oito tipos de defeitos, metade dos quais não haviam sido relatados anteriormente. A superfície de ataque é menor que a do Solidity, mas ainda existe.

A melhor postura de segurança na Aptos e Sui combina especificações do Move Prover, auditorias de terceiros e análise de segurança econômica — não apenas a confiança nas proteções integradas da linguagem.

Por que Isso é Importante para Construtores de DeFi em 2025​

Os números contam uma história impactante. Em 2024, as vulnerabilidades de contratos inteligentes custaram ao setor DeFi mais de US$ 1,4 bilhão. A reentrância contribuiu com US$ 35,7 milhões disso — uma categoria que seria estruturalmente zero em uma rede baseada em Move com TVL equivalente.

Para desenvolvedores que constroem aplicações financeiras, a escolha da VM é, na verdade, uma escolha sobre o seu modelo de ameaça padrão. Construir no EVM significa adotar o padrão Checks-Effects-Interactions como uma disciplina obrigatória. Construir no Move significa que a reentrância simplesmente não está no seu modelo de ameaça — sua equipe pode concentrar sua atenção de segurança em erros de lógica e design econômico.

Esta não é uma diferença pequena. As ferramentas de verificação formal funcionam melhor quando a superfície de ameaça é menor. Os auditores podem ir mais fundo quando não estão gastando ciclos em classes de vulnerabilidade bem compreendidas. A carga cognitiva dos desenvolvedores ao escrever código correto diminui quando a linguagem impõe invariantes críticos automaticamente.

A Camada de Infraestrutura​

Garantias de segurança só importam se os desenvolvedores puderem realmente construir nessas redes em escala. Executar seu próprio nó Aptos ou Sui para acessar a rede envolve uma sobrecarga operacional significativa — provisionamento de hardware, atualizações de software, monitoramento e resposta a incidentes.

O BlockEden.xyz fornece acesso à API de nível empresarial para Aptos e Sui, permitindo que os desenvolvedores construam sobre as garantias de segurança do Move sem gerenciar a infraestrutura de nós. Explore nossos serviços para construir aplicações Web3 mais seguras.

A combinação de uma linguagem segura para memória, prevenção estrutural de reentrância e verificação formal integrada torna a Aptos e a Sui plataformas atraentes para aplicações DeFi de alto risco. O Move não apenas torna mais fácil escrever contratos inteligentes seguros — ele torna certas classes de falhas catastróficas matematicamente impossíveis.

Fontes consultadas:

Share on Twitter