💻 computer science

Computer Science Conferences Should Require Nonrepudiable Experimental Results

Este documento de posición sostiene que las conferencias de informática deben adoptar protocolos a prueba de manipulaciones e inrepudiables para vincular criptográficamente los resultados experimentales reportados con los cálculos reales, abordando las brechas actuales de verificación mediante un modelo de amenazas formal y una implementación de referencia denominada K-Veritas.

Autores originales: Mamadou K. Keita, Christopher Homan

Publicado 2026-05-12

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Mamadou K. Keita, Christopher Homan

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

El Problema Central: La Ciencia de "Confía en mí, hermano"

Imagina que eres un juez en un concurso de cocina. Un chef presenta una receta y afirma que su pastel es el mejor del mundo. Te entrega una foto del pastel y una descripción escrita de cómo lo preparó.

El sistema actual es así: El chef firma una lista de verificación diciendo: "Sí, usé huevos reales" y "Sí, lo horneé durante 30 minutos". Incluso podrían mostrarte un video de ellos horneando. Pero aquí está la trampa: El chef controla el video. Podrían haber editado el video para mostrar un pastel real mientras en realidad te sirven un recorte de cartón. O podrían haber horneado 50 pasteles, elegido el que se veía perfecto y decirte que ese fue el único que hicieron.

En informática, específicamente en Aprendizaje Automático (IA), esto es exactamente lo que sucede. Los investigadores presentan artículos con tablas de números (resultados) y listas de verificación. Los revisores (los jueces) están ocupados y no pueden volver a ejecutar los experimentos. Deben tomar los números por fe. Los autores de este artículo argumentan que este sistema está roto porque depende de la honestidad en lugar de la prueba.

La Solución Propuesta: El Recibo de "Caja Negra"

Los autores proponen una nueva regla para las conferencias de informática: No repudio experimental.

Piensa en esto como un recibo a prueba de manipulaciones para un experimento científico.

No repudio es una palabra de seguridad sofisticada que significa: "No puedes negar que hiciste esto y no puedes cambiar el registro más tarde".
El objetivo es vincular los números en el artículo al momento real en que la computadora realizó el trabajo, de una manera que el autor no pueda falsificar ni alterar.

Cómo Funcionaría (La Herramienta "K-Veritas")

Los autores construyeron una herramienta prototipo llamada K-Veritas para demostrar que esto es posible. Así es como funciona, usando una metáfora:

Imagina que el investigador es un chef y la computadora es la cocina.

El Envoltorio: En lugar de simplemente decirle a la computadora que "horne el pastel", el investigador usa una herramienta especial (K-Veritas) que envuelve el proceso de horneado.
El Testigo Silencioso: Esta herramienta actúa como un testigo silencioso e independiente de pie en la cocina. No toca los ingredientes (los datos) ni cambia la receta (el código). Solo observa.
La Instantánea: Mientras la computadora trabaja, el testigo toma instantáneas de:
- El código exacto que se está utilizando.
- El tiempo que tomó.
- La electricidad y el calor utilizados (para probar que la máquina estaba realmente trabajando duro).
- Los números finales que la computadora imprimió.
El Sobre Sellado: Una vez terminado el experimento, el testigo sella todas estas instantáneas en un "sobre" digital y lo firma con una clave especial que solo el testigo tiene. El investigador nunca obtiene esta clave.
El Resultado: El investigador presenta su artículo junto con este sobre firmado. Los revisores de la conferencia pueden abrir el sobre y verificar: "¿La computadora realmente funcionó durante 40 minutos? ¿Coincidía el código? ¿Coinciden los números con lo que se imprimió?"

Si el investigador intenta cambiar un número en el artículo más tarde, el sello se rompe y la firma se vuelve inválida.

Por Qué Fallan los Métodos Actuales

El artículo explica por qué las actuales "redes de seguridad" no funcionan:

Listas de verificación: Pedirle a un chef que firme un papel diciendo "Usé huevos reales" no prueba que no usaron huevos de plástico.
Compartir código: Solo porque el chef comparta la receta no significa que horneó el pastel que afirmó. Podrían compartir una receta funcional pero reportar resultados de un pastel diferente y mejor que hornearon en secreto.
Herramientas de registro: Las herramientas que rastrean el progreso son como un diario escrito por el chef. Si el chef quiere ocultar un error, simplemente puede editar el diario.
Pre-registro: Esto es como el chef prometiendo antes de empezar: "Hornearé un pastel de chocolate". Esto evita que cambien el plan, pero no prueba que realmente hornearon el pastel o que los números que reportan son reales.

La Conexión con la "Revisión Falsa"

El artículo hace una comparación inteligente:

Las conferencias principales (como ICML) ahora prohíben a los revisores usar IA para escribir reseñas. ¿Por qué? Porque la comunidad no puede distinguir si una reseña es un pensamiento humano real o texto falso de un robot.
Los autores argumentan: Si no podemos confiar en una reseña falsa, definitivamente no podemos confiar en un resultado falso. Si una reseña necesita prueba de humanidad, un resultado científico necesita prueba de computación.

Lo Que Esta Herramienta Puede y No Puede Hacer

Los autores son honestos sobre los límites de su herramienta (K-Veritas):

Detiene: El engaño con editores de texto, la falsificación de números, la edición de registros después de los hechos, o afirmar que ejecutaste un experimento enorme cuando no lo hiciste.
No detiene: A un hacker súper sofisticado que pueda engañar al sistema operativo o al hardware de la computadora en sí (como una señal GPS falsa).
El Compromiso: Incluso si no detiene cada posible trampa, aumenta el costo de hacer trampa. Actualmente, hacer trampa solo requiere un editor de texto. Con este sistema, tendrías que ejecutar realmente el costoso experimento informático o hackear el cerebro de la computadora.

El Camino a Seguir

Los autores no dicen que K-Veritas sea la respuesta final. Lo llaman un "banco de pruebas" (un prototipo). Proponen un plan de tres pasos para la comunidad:

Voluntario: Permitir que los investigadores lo usen si quieren obtener una insignia "Verificada".
Esperado: Hacerlo una práctica estándar, como compartir código se está volviendo estándar.
Obligatorio: Eventualmente, exigirlo para todos los artículos con resultados experimentales.

La Conclusión

La ciencia se basa en la confianza, pero la confianza necesita evidencia. Este artículo argumenta que las conferencias de informática deberían dejar de pedirle a los investigadores que "por favor sean honestos" y comenzar a exigir recibos digitales que prueben que los números en el artículo provienen de una ejecución real y sin alteraciones de una computadora. Se trata de pasar de "Confía en mí" a "Muéstrame el recibo".

Resumen Técnico: Las Conferencias de Ciencias de la Computación Deben Exigir Resultados Experimentales No Repudiables

Definición del Problema
El artículo identifica una "brecha de verificación" estructural en las conferencias de ciencias de la computación, particularmente en el aprendizaje automático (ML). Las medidas actuales de reproducibilidad, como las listas de verificación autoinformadas (por ejemplo, NeurIPS), la evaluación opcional de artefactos, las plataformas de registro controladas por los autores (por ejemplo, Weights & Biases) y la preregistración, no logran vincular los resultados numéricos reportados con la ejecución real del código que los produjo. Estos mecanismos verifican la intención de divulgar o la usabilidad del código, pero no pueden responder a la pregunta fundamental: "¿La ejecución de entrenamiento descrita en este artículo produjo realmente los resultados que este artículo reporta?".

Los autores definen este modo de fallo específico como no repudiación de experimentos. Tomando prestado de la literatura de seguridad, la definen como la propiedad por la cual un autor no puede alterar, negar o tergiversar posteriormente el registro de lo que su computación produjo realmente. El sistema actual se basa en la confianza en la autoinformación, dejando a la comunidad vulnerable a la fabricación a nivel de texto, la manipulación de registros y la selección de informes de ejecuciones favorables.

Metodología y Solución Propuesta
Para abordar esto, los autores proponen un protocolo para generar atestaciones a prueba de manipulaciones y no repudiables de resultados experimentales. El núcleo de su metodología es un protocolo que debe satisfacer seis propiedades de seguridad específicas:

Pasividad: El observador no debe modificar la computación.
Ceguera de datos: El observador nunca debe acceder al conjunto de datos $D$ , asegurando que los datos propietarios permanezcan privados.
Vinculación a la ejecución: Las métricas reportadas deben estar vinculadas criptográficamente a la instancia de ejecución específica, verificada mediante telemetría en tiempo de ejecución (uso de CPU/GPU, memoria).
Evidencia de manipulación: Cualquier modificación al informe (métricas, hiperparámetros, marcas de tiempo) debe invalidar la firma criptográfica.
Separación de claves del autor: La clave de firma debe ser custodiada por un servicio de atestación independiente, no por el autor, lo que impide que el autor genere atestaciones arbitrarias.
Verificabilidad independiente: Cualquier tercera parte debe poder validar la atestación utilizando una clave pública sin confiar en el autor.

Para demostrar la viabilidad de este problema, los autores construyeron K-Veritas, una implementación de referencia en Go. K-Veritas funciona como un envoltorio binario independiente que los autores invocan mediante un prefijo de comando (por ejemplo, kveritas run -- python train.py). Opera de la siguiente manera:

Captura: Captura stdout/stderr de forma no bloqueante, analiza las métricas y genera hashes de los archivos fuente antes y después de la ejecución.
Telemetría: Un muestreador en segundo plano registra la utilización de hardware (tiempo de CPU, memoria, uso de GPU) en intervalos.
Sellado: Al cerrar la sesión, calcula un digesto canónico SHA-256 de toda la sesión (hashes de archivos, flujos de stdout, métricas, muestras de hardware).
Firma: Envía solo este digesto de 64 caracteres a un servicio de atestación remoto. El servicio, que posee la clave privada, devuelve una firma RSA-PSS. El autor nunca ve la clave privada.
Salida: El sistema genera un informe PDF firmado y un archivo comprimido firmado que contiene el código fuente presente en el momento de la ejecución.

Resultados y Demostraciones
El artículo presenta dos formas principales de evidencia:

El ejercicio de la "Tabla no confiable": Los autores demuestran que dos tablas de resultados, una de una ejecución real y otra generada por un modelo de lenguaje para ser plausible, son indistinguibles para un revisor humano. Esto ilustra que la plausibilidad no es un sustituto de la autenticidad.
Entorno de pruebas K-Veritas: Los autores ejecutaron K-Veritas en dos ejecuciones de entrenamiento distintas: un Keras LSTM sintético y un RoBERTa-base ajustado finamente en SST-2. El sistema capturó con éxito:
- Huellas digitales de hardware (modelos de GPU/CPU).
- Duración del entrenamiento y métricas finales (pérdida, precisión).
- Hashes del código fuente y de stdout.
- Una puntuación de "Consistencia Métrica-Hardware (HMC)", que señala anomalías (por ejemplo, una métrica reportada sin actividad de hardware correspondiente).
- Firmas RSA-PSS válidas.

Los autores señalan explícitamente que K-Veritas es un entorno de pruebas, no una solución final. Evita con éxito la fabricación casual y moderada (edición de texto, manipulación de registros, selección de informes ingenua), pero reconoce que no puede derrotar a adversarios privilegiados con acceso al kernel o al firmware (por ejemplo, suplantación de telemetría a nivel de sistema operativo).

Contribuciones Clave

Definición conceptual: El artículo define formalmente la "no repudiación de experimentos" como una clase de problema distinta, separándola de la reproducibilidad (¿puede reejecutarse?) y la replicabilidad (¿produce el mismo resultado?).
Modelo de amenazas: Describe un modelo de amenazas integral, distinguiendo entre ataques que los protocolos de solo software pueden derrotar (fabricación, edición de registros) y aquellos que no pueden (compromiso del kernel/hardware).
Especificación de protocolo: Define las propiedades de seguridad necesarias para cualquier protocolo compatible, enfatizando la separación de la clave de firma del autor.
Implementación: Proporciona K-Veritas como una prueba de concepto de que tal protocolo puede implementarse sin requerir que los autores compartan datos sensibles o modifiquen su lógica central de entrenamiento.

Significado y Afirmaciones
El artículo argumenta que la no repudiación debe tratarse como un requisito de primera clase para las conferencias de ciencias de la computación, similar a la prohibición de revisiones generadas por IA en ICML 2025. Los autores afirman que, así como la comunidad reconoce las revisiones fabricadas como una amenaza que requiere intervención política, los resultados fabricados deben tratarse con la misma severidad.

El significado del trabajo radica en desplazar la carga de la prueba de "confiar en el autor" a "verificar la ejecución". Los autores proponen una ruta de adopción de tres fases (Voluntario $\to$ Esperado $\to$ Requerido) en un horizonte de 3 a 8 años. Enfatizan que, aunque el sistema no es perfecto contra adversarios a nivel estatal, cambia fundamentalmente la economía de la fabricación: trasladando el costo de un simple editor de texto al requisito de ejecutar computación real o comprometer un kernel.

El artículo concluye llamando a una organización independiente y sin fines de lucro para mantener el estándar, asegurando que ninguna entidad única controle la verificación de la legitimidad científica. El marco se presenta como generalizable más allá del ML a cualquier campo que dependa de pipelines computacionales para afirmaciones empíricas.