Vitalik Buterin: Verificación formal es una defensa clave ante IA y errores en Ethereum

Vitalik Buterin dedicó una nueva publicación a explicar por qué la verificación formal, reforzada por inteligencia artificial, podría convertirse en una herramienta decisiva para mejorar la seguridad y la eficiencia del software crítico, desde protocolos criptográficos hasta componentes clave de Ethereum.

***

• Buterin sostiene que la verificación formal puede ayudar a construir software más seguro y eficiente, aunque advierte que no elimina todos los riesgos.
• El cofundador de Ethereum vincula esta técnica con áreas sensibles como STARKs, ZK-EVM, consenso bizantino, criptografía poscuántica y la propia EVM.
• También plantea que la IA puede acelerar tanto la búsqueda de fallos como la creación de pruebas formales, lo que obligará a separar mejor los sistemas entre un “núcleo seguro” y bordes más inseguros.

 

---

Vitalik Buterin publicó un extenso análisis sobre el avance de la verificación formal y su potencial para redefinir la seguridad del software en Ethereum y en otros entornos críticos. Su texto parte de una idea simple: un programa informático es también un objeto matemático, así que en principio es posible demostrar, con pruebas comprobables por máquina, que cierto código cumple propiedades específicas.

Para Buterin, este enfoque ha comenzado a ganar fuerza en los círculos de investigación y desarrollo más avanzados de Ethereum.

El patrón al que apunta combina código escrito en lenguajes de muy bajo nivel, o directamente en Lean, con pruebas matemáticas que pueden verificarse de forma automática. Según recuerda, Yoichi Hirai ha llegado a describir esta ruta como la “forma final del desarrollo de software”.

El punto de fondo no es solo académico. En un ecosistema donde contratos inteligentes inmutables pueden custodiar grandes sumas y donde un error puede ser explotado sin remedio, la posibilidad de verificar propiedades clave del software se vuelve especialmente relevante. Buterin sitúa esta conversación en un contexto más amplio, atravesado además por el auge de la IA y su capacidad para encontrar vulnerabilidades con mayor rapidez.

Como introducción, Buterin repasa qué significa la verificación formal. En esencia, se trata de escribir pruebas de teoremas matemáticos de forma que un sistema informático pueda comprobarlas. Para ilustrarlo, recurre al ejemplo clásico de la sucesión de Fibonacci y la propiedad según la cual cada tercer número es par, mientras los demás son impares.

Ese razonamiento puede expresarse de forma intuitiva para humanos, pero también en código Lean, un lenguaje utilizado para redactar y verificar pruebas. Ahí aparece una de las tensiones centrales de su texto: lo que resulta natural para una persona no siempre coincide con lo que entiende mejor una computadora. La verificación formal puede ser rigurosa, pero también poco intuitiva y laboriosa.

Buterin sostiene que esa dificultad ayudó a mantener este campo como un nicho durante décadas. Sin embargo, añade que la situación está cambiando con rapidez gracias a la inteligencia artificial, que ya puede asistir en la producción de código y en la redacción de pruebas formales. A su juicio, eso vuelve posibles tareas que antes eran demasiado costosas o directamente inviables.

De la matemática al software crítico

El ensayo avanza luego hacia uno de los casos de uso que Buterin considera más cercanos y urgentes: verificar la corrección de programas criptográficos o de seguridad. Si puede formalizarse qué significa “seguro” en un protocolo, entonces también puede intentarse demostrar que cierto código satisface esa propiedad bajo determinadas hipótesis.

Como ejemplo, menciona trabajos que buscan probar formalmente garantías de seguridad en sistemas de mensajería cifrada como Signal. En esos casos, la tarea no consiste solo en decir que un protocolo es sólido en teoría, sino en demostrar que una implementación concreta del software conserva esas propiedades en la práctica. Ese matiz es importante porque, desde la perspectiva del usuario, la confianza real recae sobre el código que efectivamente se ejecuta.

Buterin afirma que este tipo de pruebas podría reforzar la “trustlessness”, ya que no obligaría a cada usuario a inspeccionar toda la base de código. Bastaría con revisar las afirmaciones probadas sobre el sistema y confiar en la verificación automática. No obstante, introduce enseguida varias advertencias importantes.

Entre ellas, destaca que es fácil olvidar demostrar la propiedad realmente importante, suponer condiciones que luego no se cumplen, o concentrarse solo en una parte del sistema mientras otras capas siguen expuestas. Incluso una herramienta como Lean puede contener errores. Por eso insiste en que la verificación formal no equivale a una garantía absoluta de seguridad.

El autor enmarca esta discusión en un entorno tecnológico más hostil. Describe un escenario donde los fallos de software ya son graves por sí mismos, pero se vuelven todavía más peligrosos cuando afectan contratos inteligentes con valor económico, sistemas de conocimiento cero o futuras generaciones de modelos de IA capaces de automatizar la detección de bugs.

Frente a ese panorama, Buterin rechaza las visiones que concluyen que la defensa perdió definitivamente la ventaja ante el ataque. También se distancia de las posturas que responderían cerrando el código o abandonando la idea de sistemas abiertos. Su postura es más optimista: cree que la presión actual es dura, pero transitoria, y que a largo plazo pueden emerger defensas estructuralmente más fuertes.

Una herramienta poderosa, no una panacea

Buterin conecta la verificación formal con una tendencia más larga en ingeniería de software. Menciona sistemas de tipos, lenguajes seguros en memoria, mejoras de arquitectura como sandboxing y permisos, mejores metodologías de pruebas, patrones de codificación más maduros y bibliotecas auditadas. En su lectura, la verificación formal no llega para reemplazar todo lo anterior, sino para acelerar y profundizar esa trayectoria.

Donde más valor ve es en los casos donde el objetivo es mucho más simple que la implementación. Allí la relación entre complejidad del código y claridad de la propiedad buscada juega a favor de la prueba formal. En Ethereum, ubica en esa categoría varias tecnologías de frontera, entre ellas firmas resistentes a la computación cuántica, STARKs, algoritmos de consenso y ZK-EVMs.

Sobre STARKs, subraya que se trata de piezas de software muy complejas, pero con una propiedad central relativamente limpia de expresar: si una prueba afirma que un programa P, una entrada x y una salida y están vinculados por cierto hash H, entonces o bien el hash está roto o bien P(x) = y. Esa simplicidad relativa vuelve atractiva la idea de una implementación completamente verificada.

En esa línea menciona proyectos como Arklib, orientado a construir una implementación de STARK formalmente verificada, y VCV-io, enfocado en infraestructura fundacional para verificar algoritmos criptográficos que pueden ser dependencias dentro de esos sistemas. También destaca evm-asm, un esfuerzo para construir una implementación completa de la EVM con verificación formal.

En el caso de la EVM, reconoce que la propiedad de seguridad no es tan elegante como en un STARK. Allí el objetivo principal es probar equivalencia con otra implementación escrita en Lean, diseñada para maximizar intuición y legibilidad. Eso no elimina la posibilidad de errores conceptuales compartidos entre versiones, pero sí reduce drásticamente el riesgo de defectos graves en una implementación aislada.

Además, Buterin recuerda que la resistencia a ataques de denegación de servicio, una propiedad cuya importancia se comprendió con fuerza tras experiencias dolorosas, sí puede especificarse con relativa claridad. Algo parecido ocurre con el consenso tolerante a fallos bizantinos, un terreno donde ya hubo pruebas humanas que no detectaron errores y donde hoy se intenta formalizar y demostrar propiedades en Lean.

Seguridad y eficiencia al mismo tiempo

Uno de los tramos más llamativos del texto aparece cuando Buterin enlaza la verificación formal con la eficiencia del software. Usa como ejemplo nuevamente evm-asm, una implementación de la EVM escrita directamente en ensamblador RISC-V. La elección no es casual: muchos provers de ZK-EVM funcionan probando RISC-V y compilando clientes de Ethereum hacia esa arquitectura.

Si la implementación está escrita de forma nativa en RISC-V, explica, eso podría acercarla al máximo de eficiencia posible en ese entorno. Además, RISC-V puede emularse de manera eficiente en computadoras comunes y ya existe hardware compatible. Buterin agrega que, para completar el cuadro, también se necesita verificar la implementación de RISC-V o la aritmetización del prover, y señala que ya hay trabajos en esa dirección.

Lo que antes implicaba escribir manualmente en ensamblador y asumir grandes riesgos de comprensión podría cambiar con IA y pruebas formales. Su propuesta es separar radicalmente dos objetos: por un lado, una implementación optimizada solo para velocidad; por otro, una especificación o versión en alto nivel orientada a la legibilidad humana. Luego, una prueba matemática demostraría la equivalencia entre ambas.

Esa división permitiría, según Buterin, “volver al futuro”. La IA podría redactar el ensamblador o incluso el código en Lean, mientras también produciría pruebas sobre sus propiedades. El usuario verificaría automáticamente la prueba una vez y después ejecutaría la versión rápida. Para él, ahí reside una de las promesas más poderosas del nuevo paradigma.

Los límites reales de la corrección “demostrable”

La segunda mitad del texto adopta un tono más crítico. Buterin revisa una tradición extensa de objeciones a los métodos formales y a las pruebas de seguridad, tanto en criptografía como en ciencias de la computación. Cita, entre otros ejemplos, el trabajo de Menezes y Koblitz de 2004, que recordaba cómo un esquema de Rabin “demostrablemente” seguro en cierto modelo podía colapsar frente a ataques de texto cifrado elegido.

También menciona fallos encontrados en compiladores de C formalmente verificados, como problemas en CompCert señalados en 2011, y otro bug reportado en 2022 en CompCert-KVX. A eso suma vulnerabilidades descritas en 2026 por Nadim Kobeissi en software formalmente verificado de Cryspen, incluyendo comportamientos divergentes entre plataformas y un caso donde un texto cifrado malformado podía hacer colapsar el proceso.

Para Buterin, estos casos suelen agruparse en dos familias. La primera aparece cuando solo una parte del sistema está verificada y el resto conserva errores críticos. La segunda surge cuando la propiedad más importante ni siquiera fue especificada. También recuerda otros riesgos, como especificaciones equivocadas, pruebas con afirmaciones falsas aceptadas por el sistema o problemas en la frontera entre software y hardware.

Ese último punto es especialmente delicado en ataques por canal lateral. El hecho de que un algoritmo sea correcto en abstracto no impide que una clave se filtre por consumo eléctrico, transiciones de señal u otras formas de observación física. Cualquier prueba de resistencia en este terreno depende de modelos matemáticos del atacante, y esos modelos pueden quedarse cortos frente a mecanismos de fuga no contemplados.

La conclusión de Buterin es tajante: la llamada “corrección demostrable” no prueba, en el sentido humano más amplio, que un software sea correcto o seguro. Para una persona, “correcto” y “seguro” remiten a una comparación entre el comportamiento del sistema y las intenciones o expectativas humanas. Y esas intenciones son demasiado complejas para introducirlas directamente en una máquina.

Por eso, argumenta, la verificación formal no puede demostrar de manera definitiva lo que los usuarios entienden por seguridad o corrección. Lo que sí puede hacer, y ahí está su utilidad real, es comparar expresiones redundantes de nuestras intenciones y comprobar si son compatibles entre sí. Es una forma muy potente de reducir ambigüedad, no de eliminarla por completo.

Cómo empezar en la práctica

En la parte final, Buterin adopta un tono más pragmático. Sostiene que, en términos realistas, la mayoría de las personas no escribirán pruebas formales a mano, porque sigue siendo una tarea difícil y poco intuitiva. Su recomendación es apoyarse en modelos de IA para producir tanto el programa como las demostraciones asociadas.

Ese flujo de trabajo tiene una ventaja clave: es autoverificable. Si la IA no logra avanzar, el peor escenario es que se estanque o reformule mal el problema. La supervisión humana se concentra entonces en revisar que la afirmación demostrada corresponda realmente a la propiedad deseada. En otras palabras, el cuello de botella pasa de redactar cada prueba a validar que la meta formaliza bien la intención humana.

Buterin menciona herramientas y modelos que ha encontrado útiles para estas tareas. Dice que Claude y Deepseek 4 Pro son suficientes, y también menciona Leanstral, un modelo de pesos abiertos afinado específicamente para escribir Lean. Según su experiencia, Leanstral es algo peor que Deepseek 4 Pro, pero sigue siendo eficaz y puede ejecutarse localmente, aunque con lentitud.

El cierre del texto vuelve a la gran tesis política y técnica del ensayo. Si internet quiere conservar un modelo de seguridad que no dependa de confiar ciegamente en unas pocas organizaciones poderosas, será necesario poder confiar en el código incluso frente a adversarios potenciados por IA. La verificación formal asistida por IA, plantea Buterin, ofrece una vía seria para avanzar en esa dirección.

Su visión final es la de una arquitectura donde el software se divida cada vez más entre “bordes inseguros” y un “núcleo seguro”. Los bordes operarían en sandboxes y con autoridad limitada. El núcleo concentraría las funciones críticas y, por eso mismo, debería mantenerse pequeño, más fácil de auditar y protegido con herramientas formales. En esa lista, Buterin incluye al menos parte del kernel del sistema operativo, Ethereum, ciertas piezas de hardware e infraestructura ligada a IoT.

En ese mundo, concluye, la vieja idea de que los bugs son inevitables y de que solo cabe encontrarlos antes que el atacante podría dejar de ser la regla al menos en los sistemas más sensibles. La promesa no es perfección total, sino una seguridad mucho más fuerte donde más importa. Para Ethereum y para el software crítico en general, esa distinción podría volverse decisiva.

---

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público

Este artículo fue escrito por un redactor de contenido de IA