Kani lleva verificación formal a Rust

Si trabajas con Rust en software crítico, ya sabes dónde duele: una prueba que pasa no garantiza que el sistema sea correcto en todos los casos, y un bug que aparece solo en una combinación rara de entradas puede costar horas, dinero o una falla en campo. En firmware, control industrial, automoción o dispositivos conectados, no basta con “parece funcionar”. Necesitas algo más que unit tests y revisión manual.

Ahí es donde entra Kani. El proyecto, presentado como “A Model Checker for Rust” en arXiv, propone una forma práctica de hacer verificación formal sobre código Rust sin obligarte a reescribir todo el proyecto ni a abandonar el flujo de desarrollo habitual. Para equipos que construyen software embebido o componentes de alto riesgo, eso cambia la conversación: ya no se trata de si puedes verificar formalmente, sino de qué parte del sistema conviene verificar primero.

Qué es Kani y por qué importa

Kani es un model checker para Rust. Traducido a tierra firme: analiza tu código para explorar de forma sistemática muchos caminos de ejecución posibles y encontrar errores que las pruebas tradicionales suelen dejar pasar. No reemplaza tus tests, pero sí cubre otra clase de problemas, sobre todo los que aparecen por combinaciones de estados, ramas y entradas difíciles de reproducir.

La idea no es nueva en verificación formal, pero sí lo es el enfoque práctico para Rust. Rust ya aporta un modelo fuerte de memoria y seguridad en compilación, así que Kani aprovecha esa base para enfocarse en propiedades más finas: ausencia de desbordamientos, acceso inválido a memoria, supuestos no cumplidos y errores de lógica en funciones específicas. En vez de pedirte una demostración matemática completa de todo el sistema, te deja verificar piezas concretas.

Eso es útil para equipos en América Latina que muchas veces trabajan con presupuestos ajustados, hardware limitado y ciclos de entrega cortos. Si tu producto se vende en Ecuador, México, Colombia o Perú y corre en un dispositivo que no se puede reiniciar cada cinco minutos, encontrar un fallo antes de producción vale mucho más que agregar 20 pruebas más al pipeline.

La diferencia frente a tests y fuzzing

Los tests unitarios verifican casos que tú escribes. El fuzzing genera entradas aleatorias o semi-aleatorias para buscar comportamientos raros. Kani hace algo distinto: intenta cubrir de forma exhaustiva, dentro de límites concretos, los caminos posibles del programa modelado. Eso significa que puede encontrar bugs que no dependen de una entrada “rara”, sino de una combinación lógica que nunca pensaste probar.

Por ejemplo, un if anidado que solo falla cuando dos flags están activos al mismo tiempo. Un test manual puede no cubrir esa combinación. Un fuzzer puede tardar en llegar. Kani, en cambio, puede explorar esa rama de manera sistemática si el modelo y el alcance están bien definidos.

No es magia ni reemplazo total. Si el espacio de estados es enorme, el análisis puede volverse costoso. Pero para funciones críticas, validadores, parsers, controladores de estado o rutinas de seguridad, el retorno puede ser alto.

Cómo funciona a nivel práctico

Kani trabaja sobre código Rust y usa técnicas de model checking para explorar comportamientos posibles bajo ciertas restricciones. En la práctica, tú escribes o adaptas funciones para que sean verificables, defines propiedades o aserciones, y luego ejecutas el análisis. Si encuentra una violación, te devuelve un contraejemplo que muestra cómo llegar al fallo.

Ese contraejemplo es una de las partes más valiosas del enfoque. No recibes solo un “falló”. Recibes una traza que te ayuda a entender qué secuencia de decisiones llevó al problema. Para un equipo de firmware, eso ahorra tiempo de depuración porque puedes reproducir el escenario con más claridad que en un bug report tradicional.

Además, Kani encaja con la forma de pensar de Rust. No te pide abandonar el lenguaje ni introducir un DSL extraño. El objetivo es que puedas usar la verificación como una etapa adicional en el ciclo de desarrollo, especialmente en módulos donde el costo de un error es alto.

Qué tipo de errores busca

Kani es especialmente útil para detectar fallos como estos:

1. Desbordamientos aritméticos en tipos enteros.
2. Condiciones de acceso inválido a memoria o índices fuera de rango.
3. Ramas lógicas imposibles o supuestos que no se cumplen.
4. Violaciones de invariantes en estructuras de datos.
5. Comportamientos incorrectos bajo entradas simbólicas o no deterministas.

En software embebido, esto importa mucho porque una rutina que controla un sensor o un actuador suele depender de estados pequeños pero delicados. Una validación incorrecta puede dejar un dispositivo colgado, consumir batería de más o mandar una señal equivocada a hardware real.

Dónde encaja en tu flujo

Kani no suele entrar como herramienta de “todo el proyecto”, sino como verificación por módulos. Piensa en piezas como:

• Parsers de protocolos.
• Conversores de unidades.
• Máquinas de estado.
• Lógica de seguridad.
• Funciones matemáticas o de control.

Si tu equipo ya usa CI, puedes agregar Kani como una verificación adicional para los módulos más sensibles. Eso te permite detectar regresiones antes de llegar a staging o a una placa física.

Qué aporta al ecosistema Rust

Rust ganó mucha tracción por seguridad de memoria y concurrencia, pero eso no significa que el software escrito en Rust sea correcto por defecto. Un programa puede ser memory-safe y aun así hacer algo incorrecto. Kani cubre ese hueco: te ayuda a razonar sobre propiedades más allá del compilador.

Ese punto es clave para el ecosistema. A medida que Rust se usa más en kernels, servicios de infraestructura, automatización industrial y dispositivos conectados, crece la necesidad de herramientas que no solo detecten bugs, sino que ayuden a demostrar que ciertas clases de errores no existen. Kani empuja justo en esa dirección.

La propuesta también baja la barrera de entrada a la verificación formal. Muchas herramientas clásicas de verificación se sienten pesadas, académicas o demasiado alejadas del flujo real de producto. Kani intenta ser más directo: escribir Rust, definir propiedades, correr el checker y leer el contraejemplo. Para un equipo de ingeniería, eso suena mucho más razonable que rediseñar el proceso completo.

Un ejemplo simple de uso conceptual

Imagina una función que recibe un valor de sensor y devuelve un estado de alarma. Si el valor está fuera de rango, debe rechazarlo. Si está dentro, debe clasificarlo en normal, advertencia o crítico. El riesgo no está solo en las entradas válidas, sino en los bordes: 0, 1, 255, o el máximo que admite el tipo.

Con tests, tú eliges algunos de esos casos. Con Kani, puedes expresar propiedades como “nunca debe producirse un acceso fuera de rango” o “si la entrada está en cierto intervalo, la salida debe pertenecer a este conjunto”. Luego el checker explora combinaciones y te dice si existe una ruta que rompa esas reglas.

Eso es muy útil cuando el bug aparece solo con valores extremos o estados raros, que son exactamente los que más molestan en campo.

Cuándo te conviene usarlo

No todo proyecto necesita verificación formal completa. Si estás haciendo una app web, probablemente no sea tu primera prioridad. Pero si trabajas en firmware, control industrial, sistemas médicos, aeroespaciales, telecom o infraestructura crítica, Kani sí puede darte valor desde etapas tempranas.

También conviene cuando el costo de una falla es alto aunque el módulo sea pequeño. Un parser de comandos en un dispositivo puede parecer trivial, pero un error ahí puede bloquear actualizaciones, corromper estados o abrir una ruta de ataque. En esos casos, verificar propiedades específicas tiene más sentido que seguir sumando tests sin cobertura clara.

Para equipos en LatAm, el criterio práctico suele ser este: usa Kani donde el riesgo técnico o de negocio justifique un análisis más profundo. No necesitas aplicarlo a todo. De hecho, empezar pequeño suele dar mejores resultados.

Señales de que sí vale la pena

• El módulo controla hardware real.
• La función tiene muchas ramas y pocos casos de prueba confiables.
• Ya sufriste bugs por valores límite o estados no previstos.
• El costo de una falla en producción es alto.
• Necesitas evidencia más sólida para auditoría, certificación o revisión interna.

Si tu respuesta es “sí” a dos o más de esas señales, probablemente convenga probarlo en una parte acotada del sistema.

Señales de que quizá no sea prioridad

• El código cambia todos los días y todavía no está estable.
• La lógica es muy dependiente de I/O externo difícil de modelar.
• El equipo aún no tiene cobertura mínima de tests.
• El riesgo de negocio del módulo es bajo.

Ahí puede ser mejor fortalecer primero pruebas, linters y revisión de diseño, y dejar Kani para cuando el módulo madure.

Cómo empezar sin complicarte

La forma más sensata de adoptar Kani es elegir una función pequeña y crítica. No empieces por el sistema completo. Empieza por algo que puedas entender en una sola sesión y que tenga una propiedad clara.

Un flujo razonable sería este:

1. Elige una función pura o casi pura.
2. Define una propiedad concreta, por ejemplo “no hay overflow” o “la salida siempre cae en este rango”.
3. Aísla dependencias externas y reemplázalas por valores modelables.
4. Ejecuta Kani sobre ese módulo.
5. Revisa el contraejemplo si falla y ajusta el código o la propiedad.

Ese enfoque reduce fricción y hace que el equipo vea resultados rápido. No necesitas esperar a una integración enorme para sacar valor.

Qué mirar en un primer piloto

Un piloto útil debería darte respuestas claras a tres preguntas:

• ¿La herramienta detecta fallos reales en tu base de código?
• ¿Cuánto tiempo tarda el análisis en un módulo pequeño?
• ¿Qué tan fácil es traducir un bug encontrado en una corrección concreta?

Si el piloto encuentra un problema en una función crítica, ya justificó su lugar. Si no encuentra nada pero el modelo era demasiado simple, entonces el siguiente paso es refinar el alcance, no descartar la herramienta.

Tabla rápida de adopción

Lo que significa para equipos de software crítico en LatAm

En nuestra región, muchos equipos no tienen lujo de sobra: poca gente, hardware compartido, deadlines ajustados y clientes que quieren estabilidad desde la primera versión. En ese contexto, herramientas como Kani no son un capricho académico. Son una forma de priorizar mejor el tiempo de ingeniería.

Si construyes para industria, energía, logística, agro o monitoreo remoto, es común que el software termine corriendo en entornos donde actualizar es costoso. Un bug pequeño puede significar una visita técnica, una parada o una pérdida de datos. Verificar formalmente las partes más delicadas ayuda a reducir ese riesgo antes de que llegue al cliente.

También hay un ángulo de madurez técnica. Adoptar Rust ya fue una decisión orientada a seguridad y control. Incorporar verificación formal práctica es el siguiente paso lógico para equipos que quieren subir el estándar sin volver el proceso inmanejable.

Un caso realista de uso

Piensa en una empresa que fabrica dispositivos de telemetría para granjas o instalaciones industriales en Ecuador. El firmware recibe datos de sensores, aplica umbrales y decide cuándo enviar alertas. Si la lógica de umbrales falla, el sistema puede saturar la red con alertas falsas o, peor aún, dejar pasar una condición peligrosa.

Con Kani, el equipo podría verificar que ciertas combinaciones de entrada nunca lleven a una salida inválida. No resuelve todo el problema, pero sí reduce la probabilidad de que una regla crítica quede mal implementada.

Ese tipo de mejora no siempre se ve en una demo, pero sí en menos incidentes, menos retrabajo y menos tiempo apagando incendios.

Tabla resumen

Si quieres revisar la fuente original, puedes leer el trabajo en arXiv y la documentación del proyecto para ver el alcance exacto y los ejemplos de uso:

• https://arxiv.org/abs/2607.01504
• https://model-checking.github.io/kani/
• https://github.com/model-checking/kani

Kani no elimina la necesidad de pensar bien el diseño, escribir tests o revisar código. Pero sí te da una capa extra de confianza cuando el fallo no puede quedar librado al azar. Si trabajas con Rust en sistemas embebidos o componentes críticos, vale la pena tenerlo en el radar y probarlo donde más duele.