Acabo de escribir un análisis sobre reentrancy - un problema de seguridad que todavía muchos desarrolladores pasan por alto al construir contratos inteligentes.

En pocas palabras, reentrancy es cuando un contrato inteligente es llamado varias veces antes de completar la primera llamada. Imagina esto: ContractA está ejecutando una función, llama a ContractB, y ContractB vuelve a llamar a ContractA mientras aún no ha terminado. Esa es la vulnerabilidad que un atacante puede explotar.

Un ejemplo concreto: EtherStore tiene 10 Ether, ContractB ha enviado 1 Ether. Cuando ContractB llama a la función de retiro, verifica si el saldo es mayor que 0, y si lo es, envía Ether de vuelta. Pero aquí está el peligro: la actualización del saldo a 0 ocurre después de enviar el Ether. Por lo tanto, el atacante puede crear una función fallback que, al recibir Ether, vuelva a llamar a la función de retiro una vez más. Este ciclo continúa hasta que se agoten todos los Ether.

Voy a mostrar tres formas de prevenir reentrancy:

Primero, usar el modificador nonReentrant. Esta forma bloquea el contrato mientras la función está en ejecución, por lo que nadie puede volver a entrar. Es simple pero efectivo para una sola función.

En segundo lugar, aplicar el patrón Checks-Effects-Interactions. En lugar de actualizar el saldo después de enviar el Ether, actualízalo antes. De esta forma, incluso si se produce una llamada recursiva, el saldo ya será 0 y la verificación fallará.

En tercer lugar, crear un contrato separado llamado GlobalReentrancyGuard. Esta técnica usa una variable de estado compartida para controlar la reentrancy en múltiples contratos a la vez. Es especialmente útil cuando tu proyecto tiene varios contratos que interactúan entre sí. En lugar de verificar en cada contrato, lo haces en un lugar centralizado.

El problema de reentrancy no es nuevo, pero sigue siendo una de las vulnerabilidades más comunes. He visto que muchos desarrolladores aún no aplican estas medidas de forma consistente. Si trabajas con Solidity, asegúrate de entender bien este problema y de aplicar al menos uno de estos tres métodos en tu proyecto. La seguridad de los contratos inteligentes no es opcional, es obligatoria.