Un ordenador puede darte un resultado correcto sin ofrecerte una forma práctica de demostrar cómo lo obtuvo. Microsoft Research presentó el 15 de octubre de 2026 Magnetar, una máquina virtual criptográfica que ejecuta programas y genera, junto a su salida, una prueba pequeña de que el cálculo se realizó como estaba definido. Otra persona puede verificar esa prueba en milisegundos sin repetir todo el trabajo ni conocer los datos privados utilizados.
La propuesta pertenece al campo de las pruebas de conocimiento cero y la computación verificable. No es una nueva inteligencia artificial, no comprueba que una decisión sea ética y tampoco demuestra que los datos de entrada sean verdaderos. Su función es más concreta: certificar criptográficamente que un programa determinado produjo una salida determinada a partir de unas entradas comprometidas.
El avance que reivindica el equipo está en combinar tres propiedades que rara vez coinciden: admitir programas generales compilados para RISC-V, apoyarse solo en funciones hash estándar y producir pruebas mucho más deprisa que otros sistemas comparables evaluados por los autores. Esta combinación puede interesar a servicios financieros, agentes de IA, cadenas de suministro y sistemas que deben justificar cálculos sin revelar información sensible.
Qué es Magnetar y qué significa «probar un programa»
Magnetar es una zero-knowledge virtual machine o zkVM. Una máquina virtual ejecuta instrucciones para una arquitectura concreta; en este caso, RV64I, una versión de 64 bits de RISC-V. La diferencia es que Magnetar no se limita a calcular. También construye un certificado criptográfico de esa ejecución.
Imagina una empresa que aplica una política automática para decidir si una operación cumple ciertos límites. Podría publicar el resultado y una prueba de que ejecutó exactamente la política acordada. El verificador no tendría que confiar en los servidores de la empresa ni repetir millones de instrucciones. Tampoco necesitaría recibir los datos confidenciales si la prueba se configura con la propiedad de conocimiento cero.
La prueba no responde a todas las preguntas posibles. Si el programa contiene un error, Magnetar puede demostrar fielmente que ese programa erróneo se ejecutó. Si alguien introdujo datos falsos, la prueba no convierte esos datos en verdaderos. La garantía es de integridad de ejecución: enlaza programa, entradas comprometidas y salida.
Por qué las pruebas de conocimiento cero han sido difíciles de generalizar
Las pruebas de conocimiento cero se estudian desde los años ochenta. Permiten demostrar que una afirmación es cierta sin revelar la información secreta que la sustenta. El concepto es potente, pero llevarlo a programas cotidianos ha chocado con tres barreras.
La primera es el coste. Producir una prueba puede requerir mucho más trabajo que ejecutar el programa original. Aunque el verificador responda en milisegundos, el demostrador puede consumir tiempo, memoria y energía considerables.
La segunda es la especialización. Muchos sistemas obligan a traducir la lógica a circuitos aritméticos diseñados para criptografía. Esa traducción requiere expertos, complica los cambios y puede introducir vulnerabilidades. Una zkVM de propósito general intenta evitar esa reescritura: el desarrollador compila su programa para un procesador que el sistema sabe probar.
La tercera es la base criptográfica. Algunos diseños utilizan curvas elípticas, retículas o funciones creadas para acelerar circuitos. No significa que sean automáticamente inseguros, pero cada familia plantea supuestos, tamaños, costes y planes de migración distintos. Magnetar apuesta por SHA-256 o SHA-3 y por aritmética sobre campos binarios, una decisión pensada para reducir dependencias criptográficas especiales.
Rust, Go y C: dónde está la promesa de uso general
El artículo técnico describe un sistema para ejecuciones RV64I. En la práctica, un programa escrito en Rust, Go o C puede compilarse para esa arquitectura. Microsoft pone como ejemplo un intérprete de la máquina virtual de Ethereum: si se ejecuta dentro de Magnetar, puede producir pruebas sobre contratos existentes sin convertir manualmente cada contrato en un circuito nuevo.
Esto no significa que cualquier aplicación vaya a funcionar sin adaptación. El entorno debe proporcionar las entradas, limitar interacciones con el exterior y representar de forma determinista operaciones como el tiempo, la red o el acceso a archivos. También hay que decidir qué información permanece privada y qué compromisos se publican.
Para una organización acostumbrada a encadenar servicios, la transición de un prototipo a un flujo verificable exige documentar cada paso. Una formación sobre automatización local con n8n puede servir para aprender a descomponer procesos, mientras que un itinerario para crear aplicaciones y productos con IA ayuda a entender el ciclo de construcción. Son recursos comerciales independientes: ninguno convierte por sí solo un flujo en una prueba criptográfica.
Qué rendimiento afirma el estudio
En un MacBook Pro con procesador M4 Max y doce núcleos de rendimiento, los autores midieron entre 7,2 y 8,7 millones de ciclos por segundo al probar ejecuciones de 222 ciclos. Las pruebas ocupaban alrededor de 600 KiB y se verificaban entre 11 y 13 milisegundos. Una versión optimizada alcanzó entre 9,5 y 12,8 millones de ciclos por segundo.
El equipo comparó quince cargas, desde funciones hash hasta transferencias de tokens dentro de un intérprete pequeño de EVM. Según el artículo, Magnetar obtuvo medias geométricas de velocidad aproximadamente 39 veces superiores a SP1 Hypercube, 18 veces a Jolt-Dory y 9,6 veces a Jolt-Akita. El blog resume el resultado como una mejora media de entre 10 y 39 veces frente a sistemas comparables.
Estas cifras son resultados experimentales de los autores, no una garantía para cualquier servidor o aplicación. Dependen del hardware, el tamaño de la ejecución, el código, la configuración de seguridad y el método de comparación. Tampoco deben confundirse ciclos probados por segundo con el rendimiento de la aplicación original: generar una prueba sigue añadiendo trabajo.
Por qué importa que la verificación dure unos milisegundos
En muchos sistemas distribuidos, una operación se calcula una vez y se revisa muchas veces. Un banco, un regulador, un cliente y un auditor pueden necesitar la misma garantía. Si cada parte repite el cálculo, se duplican costes y aparecen discrepancias de entorno. Una prueba breve puede circular junto al resultado y verificarse de manera independiente.
La verificación rápida también permite recursión: probar que otra prueba se verificó correctamente. Magnetar divide cálculos largos en piezas y combina sus certificados. Esa propiedad resulta relevante para historiales extensos, libros de registro o cadenas de operaciones donde no conviene conservar y repetir toda la ejecución.
La ventaja potencial no es solo ahorrar computación. También puede cambiar el modelo de confianza: el receptor comprueba una evidencia criptográfica en vez de depender exclusivamente de logs mantenidos por el mismo operador que produjo el resultado.
Qué relación puede tener con los agentes de inteligencia artificial
Un agente puede leer datos, llamar herramientas y modificar sistemas. Hoy solemos revisar sus acciones mediante permisos, registros y evaluaciones posteriores. Una capa de computación verificable podría añadir pruebas de que ciertas operaciones respetaron una política codificada: por ejemplo, que un pago no superó un límite o que una transformación omitió campos protegidos.
La palabra importante es «codificada». Magnetar no interpreta una norma ambigua ni decide qué política debería aplicarse. Solo puede probar propiedades que el programa y sus entradas expresen. Un agente todavía puede recibir una instrucción maliciosa, elegir una herramienta equivocada o perseguir un objetivo mal especificado. Nuestra guía sobre controles frente a la inyección de instrucciones aborda esas capas previas.
La atribución también sigue siendo necesaria. Saber que un programa se ejecutó correctamente no identifica por sí solo quién autorizó el código o los datos. El análisis sobre identidad y trazabilidad de commits explica por qué conviene conservar autoría, revisión y procedencia además de comprobar el resultado técnico.
Cinco usos posibles, todavía sujetos a integración
- Procesamiento financiero privado. Probar que una cartera cumple límites o que una liquidación siguió reglas acordadas sin revelar todas las operaciones.
- Auditoría de agentes. Adjuntar evidencia de que una acción pasó por controles deterministas antes de ejecutarse.
- Cadenas de suministro. Certificar transformaciones de registros sin compartir bases completas entre empresas.
- Cálculo delegado. Encargar una tarea a infraestructura externa y verificar el resultado sin repetirla.
- Sistemas de registro. Combinar pruebas de muchas etapas para comprobar una historia larga con una verificación breve.
Son escenarios plausibles derivados de las capacidades descritas, no implantaciones comerciales confirmadas por el anuncio. Cada uno necesita software adicional, gestión de claves, definición de políticas, controles de entrada y análisis jurídico. La tecnología no elimina las obligaciones de protección de datos ni convierte cualquier tratamiento en legítimo.
Los límites que no deben perderse en el titular
No prueba la verdad del mundo. Puede demostrar que un cálculo usó un conjunto de datos, pero no que esos datos representen correctamente a una persona, una máquina o un mercado.
No corrige el programa. La ejecución de un algoritmo sesgado o vulnerable también puede probarse perfectamente. Antes hacen falta revisión de requisitos, pruebas de seguridad y validación del código.
No equivale a anonimato automático. Una prueba puede ocultar entradas, pero el resultado, los metadatos o la frecuencia de las operaciones aún pueden revelar información. El diseño de privacidad debe analizar el sistema completo.
No elimina el coste del demostrador. La verificación es rápida, pero generar pruebas consume recursos. Una adopción responsable debe medir latencia, memoria, energía y coste por tarea real.
No está demostrado que domine todos los casos. Las comparaciones cubren quince cargas y configuraciones concretas. Otros sistemas pueden priorizar pruebas más pequeñas, distinto hardware, herramientas más maduras o propiedades que Magnetar no busca optimizar.
Cómo evaluar una futura implementación
Antes de adoptar una zkVM, una empresa debería empezar por una operación acotada y responder seis preguntas. ¿Qué afirmación necesita demostrar? ¿Quién construye y revisa el programa? ¿Cómo se comprometen las entradas? ¿Qué datos deben permanecer secretos? ¿Cuánto cuesta generar una prueba en producción? ¿Qué ocurre cuando el verificador rechaza el resultado?
Después conviene reproducir los benchmarks con el propio código y hardware. Una cifra de laboratorio no sustituye una prueba con el tamaño de datos, la concurrencia y los fallos del servicio. También deben fijarse versiones del compilador, la zkVM y las dependencias para que una evidencia pueda reconstruirse.
Por último, el verificador tiene que ser sencillo, independiente y observable. Si la organización confía ciegamente en una interfaz que dice «prueba válida», solo habrá trasladado la confianza a otra caja negra.
Hechos, inferencias y predicciones
Hechos confirmados: Microsoft Research publicó Magnetar el 15 de octubre de 2026; el sistema prueba ejecuciones RV64I; su seguridad se apoya en funciones hash estándar; el estudio informa pruebas de unos 600 KiB verificadas entre 11 y 13 milisegundos y compara quince cargas sobre un M4 Max.
Inferencia razonable: admitir programas compilados puede reducir el trabajo especializado frente a circuitos diseñados uno a uno. La reducción real dependerá de las restricciones del entorno y del esfuerzo necesario para hacer deterministas las entradas y llamadas externas.
Predicción: agentes y servicios regulados incorporarán más artefactos verificables junto a sus resultados. Magnetar muestra una ruta técnica, pero el anuncio no demuestra que vaya a convertirse en el estándar ni que esté listo para sustituir las auditorías actuales.
Preguntas frecuentes
¿Magnetar es una herramienta de inteligencia artificial?
No. Es una zkVM para computación verificable. Puede utilizarse dentro de sistemas con IA, pero su función es generar y comprobar pruebas criptográficas de ejecución.
¿Una prueba confirma que el resultado es correcto?
Confirma que el resultado procede del programa y las entradas comprometidas según las reglas del sistema. No garantiza que el programa esté bien diseñado ni que los datos de origen sean verdaderos.
¿Por qué se describe como poscuántico?
Porque el diseño evita depender de curvas elípticas y se apoya en funciones hash estándar. Esa elección busca resistir los ataques cuánticos conocidos contra la criptografía de clave pública tradicional, aunque cualquier sistema debe seguir evaluándose a medida que avanza la investigación.
¿Se puede usar ya en producción?
La publicación presenta una implementación de investigación y resultados experimentales. Antes de un uso real hacen falta revisar código, licencia, soporte, integración, modelo de amenazas y rendimiento con la carga propia.
Conclusión: demostrar la ejecución no sustituye entenderla
Magnetar acerca una idea ambiciosa: que un resultado digital llegue acompañado de una evidencia breve y verificable. Su combinación de RISC-V, campos binarios y funciones hash estándar intenta hacer esa garantía más general, rápida y duradera.
El valor práctico aparecerá cuando las pruebas se integren con controles de acceso, procedencia de datos, revisión de código y responsabilidades claras. Una prueba criptográfica puede reducir la confianza ciega en quien ejecuta el cálculo. No puede sustituir la decisión humana sobre qué programa merece ejecutarse, qué datos son legítimos y qué consecuencias son aceptables.