Una auditoría de smart contract es esencialmente una revisión de código realizada por especialistas en seguridad. Los auditores examinan el código fuente del contrato en busca de vulnerabilidades, errores de lógica y desviaciones respecto a la especificación. La auditoría típica para un protocolo DeFi toma entre 2 y 6 semanas y cuesta desde 50.000 hasta más de 500.000 dólares, dependiendo de la complejidad y de la firma auditora.
Lo que las auditorías detectan de manera confiable son los patrones de vulnerabilidad conocidos. Los ataques de reentrancy, los problemas de overflow y underflow de enteros, las configuraciones incorrectas de control de acceso y las vulnerabilidades de front-running tienen firmas bien documentadas que los auditores experimentados pueden identificar. Este es el tipo de bugs que tienen casos de prueba y herramientas de detección bien establecidos. Las herramientas de análisis automatizado como Slither y Mythril pueden detectar muchos de estos antes de que un auditor humano comience siquiera la revisión.
Donde las auditorías se vuelven menos confiables es en la detección de errores de lógica de negocio. Un contrato podría ser técnicamente seguro, sin vulnerabilidades explotables en su código, y aun así tener una falla lógica que permita la extracción de valor en formas que los diseñadores no pretendían. Estos bugs requieren que el auditor comprenda profundamente qué se supone que hace el protocolo y luego verifique que el código efectivamente lo haga. Esto es más difícil de lo que parece, especialmente para protocolos complejos con múltiples contratos que interactúan.
Los riesgos de composabilidad son particularmente difíciles de auditar. Un contrato podría comportarse de forma perfecta de manera aislada, pero generar vulnerabilidades cuando interactúa con otros protocolos. Los ataques con flash loans suelen explotar estos patrones de interacción. El contrato que se está auditando podría no tener ningún bug. El problema está en cómo responde a entradas inesperadas de otros contratos que no existían cuando se realizó la auditoría.
Los ataques económicos representan otra categoría que las auditorías tradicionales manejan de manera deficiente. La manipulación de oráculos, los ataques de gobernanza y los desequilibrios en pools de liquidez a menudo no son bugs de código. Son problemas de incentivos económicos que requieren análisis de teoría de juegos más que revisión de código. Algunas firmas auditoras han comenzado a sumar análisis económico a sus servicios, pero esto sigue siendo menos maduro que la auditoría tradicional de código.
El informe de auditoría en sí merece atención. La mayoría de las firmas auditoras clasifican los hallazgos por severidad: crítica, alta, media, baja e informativa. Una auditoría limpia no significa que no haya hallazgos. Significa que todos los hallazgos de severidad crítica y alta han sido atendidos. Los hallazgos bajos e informativos a menudo se reconocen pero no se corrigen, lo cual generalmente es razonable, pero vale la pena comprenderlo como usuario.
Múltiples auditorías de distintas firmas proporcionan una mejor cobertura que una sola auditoría, sin importar lo reputada que sea. Distintas firmas utilizan distintas metodologías y tienen distintas áreas de experiencia. Trail of Bits podría detectar algo que OpenZeppelin pase por alto, y viceversa. Los protocolos con mayor conciencia de seguridad obtienen de 2 a 3 auditorías y además mantienen programas continuos de bug bounty.
Los programas de bug bounty sirven como complemento continuo de las auditorías en un punto en el tiempo. Immunefi aloja bounties para cientos de protocolos, con recompensas que van desde miles hasta millones de dólares. La lógica económica es simple: pagarle a un hacker de sombrero blanco 500.000 dólares por encontrar un bug es mucho más barato que perder 50 millones por un exploit. Los protocolos que combinan auditorías con generosos bug bounties tienden a tener los mejores historiales de seguridad.
Para los usuarios, la conclusión práctica es que una auditoría es necesaria, pero no suficiente. Reduce significativamente la probabilidad de ciertos tipos de exploits, pero no elimina el riesgo. La presencia de una auditoría debería aumentar su confianza, pero no debería ser el único factor en su evaluación de riesgo. El tiempo en producción sin incidentes, el tamaño y la actividad del programa de bug bounty, y el historial del equipo del protocolo también importan.