Resumen Técnico: MPC-Patch-Bench

1. Planteamiento del Problema

Los benchmarks actuales a nivel de repositorio para evaluar la reparación de código mediante Modelos de Lenguaje de Gran Escala (LLM), como SWE-bench, son estructuralmente inadecuados para el software de Computación Multipartita Segura (MPC). Los autores identifican tres fallos estructurales primarios al intentar trasplantar benchmarks de propósito general al dominio de MPC:

1. Dominio de la Infraestructura Genérica: Los repositorios de MPC están compuestos en gran medida por infraestructura genérica de Python (CI/CD, wrappers de API) en lugar de lógica criptográfica central, lo que provoca que los benchmarks ingenuos midan ingeniería de software estándar en lugar de razonamiento específico de MPC.
2. Falta de Pruebas Estandarizadas: Las correcciones de alto valor en MPC carecen a menudo de las pruebas estandarizadas de "Fallo-a-Aprobación" (F2P) y "Aprobación-a-Aprobación" (P2P) requeridas por los rigurosos procesos de extracción. Por ejemplo, la aplicación de un filtrado estricto de SWE-bench a 7,305 pull requests (PRs) de MPC resultó en solo 42 instancias viables.
3. Insuficiencia de la Evaluación Funcional: La corrección funcional estándar (pasar las pruebas) es insuficiente para MPC. Un parche de MPC también debe satisfacer garantías de seguridad criptográfica (por ejemplo, la obliviosidad de los datos, la integridad del intercambio de secretos) y fidelidad numérica (evitar la deriva de anillos finitos o de punto fijo), aspectos que las pruebas unitarias estándar no pueden detectar.

Consecuentmente, los esfuerzos específicos de MPC actuales se limitan a la síntesis a nivel de operador o tareas de un solo framework, dejando un vacío en la evaluación de agentes de LLM en la reparación de MPC real a nivel de repositorio.

2. Metodología

El artículo presenta MPC-Patch-Bench, un benchmark a nivel de repositorio que consta de 205 instancias totalmente verificadas y curadas de cinco de los principales frameworks de MPC: CrypTen, tf-encrypted, MP-SPDZ, SecretFlow y PySyft. La construcción y evaluación se basan en dos marcos centrales:

A. Marco de Curación de Datos

Este marco convierte los PRs brutos en instancias de benchmark ejecutables mediante un proceso de dos etapas:

1. Agente de Curación Específico del Dominio: Un agente de IA filtra 7,305 PRs brutos a través de tres capas criptográficas para retener solo aquellos que ejercitan un razonamiento genuino de MPC:
   • Capa 1 (Verificación de Primitivas): Verifica la manipulación de primitivas centrales (por ejemplo, intercambio de secretos, Transferencia Obliviosa).
   • Capa 2 (Lógica de Protocolo): Distingue entre correcciones que abordan la corrección matemática de MPC y los wrappers de sistema genéricos.
   • Capa 3 (Especificidad del Dominio): Asegura que la resolución requiere restricciones especializadas (por ejemplo, gestión de la obliviosidad de datos o de la truncación de punto fijo).
   • Enrutamiento: Los candidatos se enrutan según puntuaciones de confianza; los PRs de alta confianza se aceptan automáticamente, mientras que los de confianza media se someten a revisión humana. Esto redujo el grupo a 1,175 candidatos criptográficamente relevantes.
2. Motor de Completitud Humano-IA: Para abordar la falta de pruebas estandarizadas en los PRs de MPC, un experto humano actúa como copiloto de un agente de síntesis. El humano aporta la intuición del dominio y verifica la corrección criptográfica, mientras que el agente sintetiza los enunciados de problemas faltantes, los parches de prueba F2P/P2P y los entornos de ejecución. Este proceso rescató PRs de alto valor pero incompletos, expandiendo el conjunto de datos final de las 42 instancias obtenidas mediante filtrado estricto a 205 instancias totalmente verificadas.

B. El Verificador de MPC

Para evaluar los parches generados por LLM, los autores diseñaron un verificador de flujo dual que va más allá de las pruebas funcionales:

1. Flujo de Pruebas Dinámicas: Ejecuta el protocolo seguro contra un oráculo de texto plano para detectar la deriva de fidelidad numérica (errores de precisión) y valida casos de borde algebraicos mediante pruebas diferenciales.
2. Pruebas de Seguridad Estática (SAST) Específicas del Dominio: Realiza el escaneo del código fuente para señalar anti-patrones de MPC, incluyendo:
   • Revelaciones inseguras (por ejemplo, reveal() dentro de bucles).
     
   • Aritmética insegura (por ejemplo, coerción de punto flotante bruto sobre tipos con intercambio de secretos).
   • Conversiones de tipo ilegales (conversiones no autorizadas de público/privado).
   • Violaciones de reglas criptográficas conscientes del contexto.

3. Contribuciones Clave

• MPC-Patch-Bench: El primer benchmark a nivel de repositorio diseñado específicamente para evaluar la reparación de código de LLM en software de MPC, que contiene 205 instancias diversas y ejecutables en cinco frameworks.
• Pipeline de Curación Novedoso: Una metodología que combina un agente de IA específico del dominio con la colaboración humano-IA para sintetizar las pruebas y los enunciados de problemas faltantes, superando el problema de la "escasez de pruebas" en los repositorios de MPC.
• Verificación Consciente de la Seguridad: Un marco de evaluación de flujo dual que integra pruebas diferenciales dinámicas y análisis estático para imponer la seguridad criptográfica y la fidelidad numérica, criterios ausentes en los benchmarks de propósito general.

4. Resultados

Los autores evaluaron ocho de los principales LLMs (incluyendo Claude 3.5/4, GPT-4/5 y Gemini 2.5) en el benchmark:

• Resolución Funcional: Incluso el modelo más fuerte (Sonnet 4.6) resolvió funcionalmente solo el 22.9% de las 205 tareas. El rendimiento varió significativamente según el framework; las librerías de estilo PyTorch (CrypTen) fueron más tratables, mientras que los sistemas a nivel de protocolo (MP-SBPDZ) permanecieron casi sin resolver.
• Impacto de la Verificación: La aplicación del Verificador de MPC redujo significativamente las tasas de resolución. La resolución verificada para el mejor modelo cayó al 17.1%.
• Rechazo de Parches Funcionales: Hasta el 40% de los parches que pasaron las pruebas funcionales fueron rechazados por el verificador debido a violaciones de seguridad criptográfica o de fidelidad numérica.
• Reordenamiento de la Tabla de Clasificación: La inclusión de la verificación de seguridad alteró el ranking de los modelos; por ejemplo, Opus 4.6 superó a Sonnet 4.6 en la tabla de clasificación verificada a pesar de tener una menor resolución funcional, demostrando que la corrección funcional y la seguridad son señales distintas.

5. Significado y Reclamaciones

El artículo afirma que la corrección funcional por sí sola sobreestima sustancialmente la fiabilidad de los LLM en el software de preservación de la privacidad. Los resultados demuestran que la reparación de MPC exige capacidades que van más allá de lo que capturan los benchmarks de propósito general. Específicamente:

• La evaluación estándar de fallo-a-aprobación es insuficiente para el código que debe adherirse a estrictas garantías de seguridad y fidelidad numérica.
• Una fracción no trivial de los parches que pasan las pruebas estándar fallan en las comprobaciones de seguridad o numéricas, lo que indica que los LLM actuales luchan con las restricciones específicas de la ingeniería de MPC.
• La metodología sirve como plantilla para evaluar LLMs en dominios donde la corrección se determina por algo más que los resultados de las pruebas, particularmente en software sensible a la seguridad.

Los autores señalan las limitaciones, incluyendo la cobertura actual de solo cinco frameworks, y sugieren trabajos futuros que extiendan el benchmark a otros stacks criptográficos como híbridos de cifrado totalmente homomórfico (FHE) y entornos de conocimiento cero (zero-knowledge). También enfatizan que su pipeline de curación es agnóstico al repositorio y reutilizable para construir benchmarks en otros dominios especializados.