Verificación formal versus auditorías: por qué "verificamos el código" ya no es suficiente

Solía ​​​​dormir profundamente después de las auditorías. Ya no lo hago. La primera vez que vi cómo un protocolo posterior a la auditoría perdía 30 millones de dólares debido a una interacción estatal que los auditores pasaron por alto, me dije a mí mismo que era un caso límite. La segunda vez, culpé al alcance. La tercera vez (alrededor de la quinta autopsia que leí esa semana) me di cuenta de que el problema no eran los auditores. Fue la metodología. Las auditorías son seres humanos que leen código y escriben pruebas. Los humanos extrañan cosas. Las pruebas pierden caminos. Y en un contrato inteligente que maneja capital real, “probablemente lo tengamos todo” no es un modelo de seguridad. Es un deseo. Índice El patrón se ha vuelto sombríamente predecible. Un protocolo recauda capital, encarga una auditoría a una empresa respetada, recibe un informe, soluciona los problemas señalados, implementa y anuncia "auditado" a su comunidad. Meses después, a veces semanas, el dinero se acabó. Team Finance perdió 14,5 millones de dólares en octubre de 2022. Dos firmas de auditoría independientes habían revisado el código base. Uno de ellos había señalado la vulnerabilidad de la función migratoria. El contrato fue explotado de todos modos. El 18 de abril de 2026, el puente impulsado por LayerZero de Kelp DAO se quedó sin 116,500 rsETH, aproximadamente $292 millones y alrededor del 18% de todo el suministro circulante del token. Se convirtió en el mayor exploit DeFi de 2026. La conclusión post mortem: no se rompió ningún contrato inteligente. Ninguna primitiva criptográfica se vio comprometida. Los contratos se ejecutaron exactamente como estaban escritos. La falla se produjo en la infraestructura del verificador fuera de la cadena: una configuración de un solo DVN que permitía a un atacante falsificar un mensaje entre cadenas. El informe de auditoría no pudo haber captado esto porque no había nada malo en el código del contrato. En 2025, las pérdidas totales en Web3 alcanzaron los 3.375 millones de dólares en 313 incidentes de seguridad importantes. Cuando una auditoría se convierte en una casilla de verificación (algo que hace un proyecto para señalar diligencia en lugar de un proceso que reduce significativamente el riesgo), la industria tiene un problema estructural. Y lo hace. Permítanme ser preciso sobre lo que proporciona una auditoría de contrato inteligente, porque la industria tiende a pasarlo por alto. Una auditoría implica que un equipo de investigadores de seguridad lea su código, ejecute analizadores estáticos, escriba casos de prueba personalizados y documente lo que encuentran. Las mejores empresas detectan vulnerabilidades de reentrada, desbordamientos de enteros, problemas de control de acceso, errores lógicos y casos económicos extremos peligrosos. Sus informes son detallados y genuinamente valiosos. Pero una auditoría está limitada por la atención humana y el conjunto de escenarios que consideran los auditores. Ninguna auditoría explora exhaustivamente todas las vías de ejecución posibles a través de un contrato. El espacio de estados de un contrato inteligente no trivial (toda combinación posible de entradas, estados de almacenamiento, contextos de llamadas y secuencias de ejecución) es demasiado vasto para que cualquier humano o fuzzer lo cubra exhaustivamente. El fuzzing detecta aproximadamente el 80% de los problemas mediante la generación de entradas aleatorias. El 20% restante se esconde en casos extremos matemáticos a los que las entradas aleatorias nunca llegan. Es posible que un auditor que pruebe un escenario de primer depósito nunca construya el estado exacto donde totalSupply es 1 y totalAssets es tipo(uint256).max, lo que crea un ataque de inflación. Una auditoría responde: "¿Encontramos errores?" No responde, y estructuralmente no puede, responder: "No existen errores". Esto no es una crítica a los auditores. Es una limitación matemática del método. La verificación formal es una categoría de aseguramiento fundamentalmente diferente. En lugar de que los humanos lean el código y busquen problemas, la verificación formal traduce los contratos inteligentes en especificaciones matemáticas y luego utiliza un probador automatizado para buscar exhaustivamente cualquier ruta de ejecución que viole esas especificaciones. El probador no se cansa. No pasa por alto los casos extremos porque se le acabó el tiempo. No deja de considerar un escenario porque parecía improbable. Explora sistemáticamente todo el espacio de estados definido por la especificación. Si el probador encuentra una infracción (una transición de estado que, según la especificación, debería ser imposible pero el código lo permite), el contrato no pasa la verificación. El equipo lo arregla y vuelve a verificar. Si el demostrador no encuentra violaciones, ha producido una prueba matemática. No es una probabilidad. No es un nivel de confianza alto. Una prueba de que dentro de las propiedades especificadas, el código no puede comportarse de una manera no especificada. La frase clave: dentro de las propiedades especificadas. La verificación formal demuestra lo que usted especifica. Si especifica cosas incorrectas o no especifica una propiedad importante, la prueba no lo cubre. Es por eso que escribir especificaciones precisas (las invariantes, las reglas de transición de estado, las propiedades de control de acceso) es tan importante como ejecutar el probador. El argumento más fuerte a favor de la verificación formal no es teórico. Son los errores concretos que aún contiene el código de envío, revisado por múltiples expertos humanos. DAI de MakerDAO, una de las bases de código más analizadas en DeFi, contenía una violación de su propia invariante central desde su primer lanzamiento en noviembre de 2019 hasta mayo de 2022. Este fue un error matemático en la explicación fundamental del protocolo.