Quero compartilhar algo bastante importante que talvez você ainda não tenha entendido completamente — que é a vulnerabilidade de reentrancy em contratos inteligentes. Se você está desenvolvendo dapps ou trabalhando com blockchain, isso é um conhecimento obrigatório.

Qual é o problema básico da reentrancy? Ela ocorre quando um contrato inteligente chama outro contrato, e esse contrato pode fazer uma chamada de volta ao contrato original enquanto ainda está em execução. Um atacante pode explorar esse período para roubar fundos.

Imagine que o ContratoA tenha 10 Ether e o ContratoB tenha enviado 1 Ether para ele. Quando o ContratoB chama a função de saque, o ContratoA verifica se o saldo é maior que 0, e se for, envia Ether de volta. Mas aqui está o problema — o ContratoA só atualiza o saldo após enviar o dinheiro. Então, durante o envio, se o ContratoB tiver uma função fallback, ele pode chamar novamente a função de saque do ContratoA. Como o saldo ainda não foi atualizado, a verificação passa novamente, e ele recebe mais 1 Ether. Esse ciclo continua até que o ContratoA fique sem fundos.

Vou mostrar três maneiras de proteger o contrato contra esse tipo de ataque de reentrancy.

A primeira é usar o modificador nonReentrant. A ideia é bem simples — você bloqueia o contrato enquanto a função está sendo executada. Se alguém tentar chamar novamente essa função, a chamada será rejeitada porque o contrato está bloqueado. Você precisa executar todo o código primeiro e só então desbloquear, e nesse momento a verificação falhará se alguém tentar reentrar.

A segunda é usar o padrão Checks-Effects-Interactions. Em vez de atualizar o saldo após enviar o dinheiro, você atualiza imediatamente após a verificação, mas antes de fazer a transferência. Assim, mesmo que outro contrato chame de volta, o saldo já estará zerado, e a verificação falhará. Por isso, a ordem é muito importante — verificar primeiro, depois aplicar efeitos (atualizar saldo), e por último interagir com outros contratos.

A terceira é criar um guard global de reentrancy, especialmente útil quando você tem vários contratos interagindo entre si. Em vez de proteger cada função individualmente, você cria um contrato de guarda comum, que armazena o estado de bloqueio em um lugar central. Quando qualquer contrato tenta executar uma função protegida, ela verifica com esse guard. Se o guard indicar que o contrato está bloqueado, a transação é rejeitada. Essa abordagem é poderosa porque impede reentrancy não só dentro de um contrato, mas também entre múltiplos contratos.

Recomendo aplicar todas as três técnicas conforme a situação. Para funções de saque ou transferência de ativos, sempre use nonReentrant ou Checks-Effects-Interactions. E, se seu projeto tiver um sistema complexo de contratos, considere usar o GlobalReentrancyGuard como uma camada adicional de proteção.

Essa vulnerabilidade é uma das mais comuns e que causam grandes perdas, então entender bem o reentrancy é fundamental se você quer escrever contratos inteligentes seguros.