Quiero compartir algo bastante importante que quizás aún no comprendes completamente: la vulnerabilidad de reentrancy en contratos inteligentes. Si estás desarrollando dapps o trabajando con blockchain, esto es un conocimiento imprescindible.

¿En qué consiste el problema básico de reentrancy? Ocurre cuando un contrato inteligente llama a otro contrato, y ese contrato puede volver a llamar al contrato original mientras aún está en ejecución. Los atacantes pueden aprovechar este período para robar fondos.

Imagina que ContractA tiene 10 Ether y ContractB ha enviado 1 Ether a ese contrato. Cuando ContractB llama a la función de retiro, ContractA verifica si el saldo es mayor que 0, y si lo es, envía Ether de vuelta. Pero aquí está el problema: ContractA solo actualiza el saldo después de enviar el dinero. Entonces, durante el envío, si ContractB tiene una función fallback, puede volver a llamar a la función de retiro de ContractA. Como el saldo aún no se ha actualizado, la verificación pasará de nuevo, y recibirá otro Ether. Este ciclo continúa hasta que ContractA se quede sin fondos.

Voy a mostrarte tres formas de proteger el contrato contra este tipo de ataque de reentrancy.

La primera forma es usar el modificador nonReentrant. La idea es muy simple: bloqueas el contrato mientras la función se está ejecutando. Si alguien intenta volver a llamar esa función, será rechazado porque el contrato está bloqueado. Debes ejecutar todo el código y luego desbloquearlo, y en ese momento la verificación fallará si alguien intenta reentrar.

La segunda forma es usar el patrón Checks-Effects-Interactions. En lugar de actualizar el saldo después de enviar fondos, lo actualizas inmediatamente después de la verificación, pero antes del envío. De esta manera, incluso si otro contrato llama de nuevo, el saldo ya será 0, y la verificación fallará. Por eso, el orden es muy importante: primero verificar, luego aplicar efectos, y finalmente interactuar con otros contratos.

La tercera forma es crear un guardia global de reentrancy, especialmente útil cuando tienes múltiples contratos que interactúan entre sí. En lugar de proteger cada función individualmente, creas un contrato guardia compartido que mantiene el estado de bloqueo en un lugar central. Cuando cualquier contrato intenta ejecutar una función protegida, verifica con este guardia. Si el guardia indica que el contrato está bloqueado, la transacción se rechaza. Este método es muy potente porque previene reentrancy no solo en un contrato, sino entre varios contratos.

Te recomiendo aplicar las tres técnicas según la situación. Para funciones de retiro o transferencia de fondos, siempre usa nonReentrant o Checks-Effects-Interactions. Y si tu proyecto tiene un sistema complejo de contratos, considera usar un GlobalReentrancyGuard como capa adicional de protección.

Esta es una de las vulnerabilidades más comunes que causa pérdidas significativas, por lo que entender bien la reentrancy es fundamental si quieres escribir contratos inteligentes seguros.