Estudiar los exploits de contratos inteligentes del pasado es excelente para convertirse en un mejor desarrollador de Solidity. He pasado algún tiempo recientemente revisando muchos de los exploits que han ocurrido en los últimos años. Entender la causa raíz de un hackeo es una gran manera de aprender a pensar de manera diferente sobre la escritura de código. También te da una mejor intuición sobre qué componentes son más críticos al mirar nuevas bases de código. Recomiendo a cualquiera que quiera mejorar su juego en Solidity que revise los exploits pasados en @RektHQ o consulte la documentación de @phylaxsystems, donde tenemos desgloses de hacks y cómo las afirmaciones podrían haberlos prevenido. Al estudiar estos hacks pasados, me he dado cuenta de que a menudo los exploits son posibles debido a la falta de verificaciones en el código o cálculos incorrectos que llevan a los protocolos a entrar en estados en los que no deberían estar. Una vez que ha ocurrido el exploit, el error a menudo parece obvio. Necesitamos asegurarnos de que los protocolos tengan más facilidad para identificar estos problemas. Muchos protocolos se beneficiarían de dedicar tiempo a definir invariantes y asegurarse de que no puedan ser violados. Escribir afirmaciones es una excelente manera de asegurarse de que estas invariantes nunca puedan ser violadas. El último exploit en el que pasé tiempo investigando fue el exploit de Abracadabra de marzo de 2025, donde se perdieron ~$13 millones: El Error: sendValueInCollateral() extrajo tokens reales pero olvidó actualizar las variables contables internas. El Exploit: orderValueInCollateral() seguía reportando el mismo valor de colateral incluso después de que se eliminaran tokens. Resultado: El atacante pidió prestado contra "colateral fantasma" repetidamente hasta que se drenaron los fondos. Una afirmación que verifica la simple invariante de que el "colateral reportado" coincide con el "colateral real" habría prevenido el hackeo.