Riepilogo Tecnico: MPC-Patch-Bench

1. Definizione del Problema

Gli attuali benchmark a livello di repository per la valutazione della riparazione di codice tramite Large Language Model (LLM), come SWE-bench, sono strutturalmente inadeguati per il software di Calcolo Multi-Parte Sicuro (MPC). Gli autori identificano tre fallimenti strutturali primari nel tentativo di trasporre i benchmark general-purpose nel dominio MPC:

1. Dominanza di Infrastrutture Generiche: I repository MPC sono composti in gran parte da infrastrutture Python generiche (CI/CD, wrapper API) piuttosto che da logica crittografica centrale, il che causa una misurazione del ragionamento standard di ingegneria del software anziché del ragionamento specifico per l'MPC nei benchmark ingenui.
2. Mancanza di Test Standardizzati: Le correzioni ad alto valore nell'MPC spesso mancano dei test standardizzati "Fail-to-Pass" (F2P) e "Pass-to-Pass" (P2P) richiesti dalle rigide pipeline di estrazione. Ad esempio, applicando un filtraggio rigoroso basato su SWE-bench a 7.305 pull request (PR) grezze di MPC, si sono ottenuti solo 42 casi d'uso validi.
3. Insufficienza della Valutazione Funzionale: La corretta funzionalità standard (superamento dei test) è insufficiente per l'MPC. Una patch MPC deve anche soddisfare garanzie di sicurezza crittografica (ad es., data-obliviousness, integrità del secret sharing) e fedeltà numerica (evitando il drift di anelli finiti o di virgola fissa), che i normali unit test non possono rilevare.

Di conseguenza, gli sforzi specifici per l'MPC sono limitati alla sintesi a livello di operatore o a task di singolo framework, lasciando un vuoto nella valutazione di agenti LLM su riparazioni MPC reali a livello di repository.

2. Metodologia

Il paper introduce MPC-Patch-Bench, un benchmark a livello di repository composto da 205 istanze completamente verificate e curate da cinque importanti framework MPC: CrypTen, tf-encrypted, MP-SPDZ, SecretFlow e PySyft. La costruzione e la valutazione si basano su due framework core:

A. Framework di Curatela dei Dati

Questo framework converte le PR grezze in istanze di benchmark eseguibili attraverso un processo in due fasi:

1. Agente di Curatela Specifico del Dominio: Un agente IA filtra 7.305 PR grezze attraverso tre livelli crittografici per trattenere solo quelle che esercitano un vero ragionamento MPC:
   • Livello 1 (Controllo dei Primitivi): Verifica la manipolazione di primitivi core (ad es., secret sharing, Oblivious Transfer).
   • Livello 2 (Logica del Protocollo): Distingue le correzioni che affrontano la correttezza matematica dell'MPC dai generici wrapper di sistema.
   • Livello 3 (Specificità del Dominio): Assicura che la risoluzione richieda vincoli specializzati (ad es., gestione della data-obliviousness, della troncatura a virgola fissa).
   • Routing: I candidati vengono instradati in base ai punteggi di confidenza; le PR ad alta confidenza sono accettate automaticamente, mentre quelle a media confidenza sono sottoposte a revisione umana. Questo ha ridotto il pool a 1.175 candidati crittograficamente rilevanti.
2. Motore di Completamento Umano-IA: Per affrontare la mancanza di test standardizzati nelle PR MPC, un esperto umano co-pilota con un agente di sintesi. L'umano fornisce l'intuizione del dominio e verifica la correttezza crittografica, mentre l'agente sintetizza le dichiarazioni di problema mancanti, le patch di test F2P/P2P e gli harness di esecuzione. Questo processo ha salvato istanze ad alto valore ma incomplete, espandendo il dataset finale da 42 istanze (ottenute tramite filtraggio rigoroso) a 205 istanze completamente verificate.

B. Il Verificatore MPC

Per valutare le patch generate dagli LLM, gli autori hanno progettato un verificatore a doppio stream che va oltre il testing funzionale:

1. Stream di Testing Dinamico: Esegue il protocollo sicuro contro un oracolo in plaintext per rilevare il drift della fedeltà numerica (errori di precisione) e valida i casi limite algebrici tramite testing differenziale.
2. Analisi Statica della Sicurezza del Dominio (SAST): Esegue la scansione del codice sorgente per segnalare anti-pattern MPC, tra cui:
   • Reveal non sicuri (ad es., reveal() all'interno di loop).
   • Aritmetica insicura (ad es., coercizione raw di floating-point su tipi secret-shared).
   • Casting di tipo illegale (conversioni non autorizzate tra pubblico e privato).
   • Violazioni di regole crittografiche contestuali.

3. Contributi Chiave

• MPC-Patch-Bench: Il primo benchmark a livello di repository specificamente progettato per valutare la riparazione di codice LLM nel software MPC, contenente 205 istanze diverse ed eseguibili attraverso cinque framework.
• Pipeline di Curatela Innovativa: Una metodologia che combina un agente IA specifico del dominio con la collaborazione umano-IA per sintetizzare i test e le dichiarazioni di problema mancanti, superando il problema della "scarsità di test" nei repository MPC.
• Verifica Consapevole della Sicurezza: Un framework di valutazione a doppio stream che integra il testing differenziale dinamico e l'analisi statica per imporre la sicurezza crittografica e la fedeltà numerica, criteri assenti nei benchmark general-purpose.

4. Risultati

Gli autori hanno valutato otto LLM leader (inclusi Claude 3.5/4, GPT-4/5 e Gemini 2.5) sul benchmark:

• Risoluzione Funzionale: Anche il modello più forte (Sonnet 4.6) ha risolto funzionalmente solo il 22,9% dei 205 task. Le prestazioni variano significativamente per framework; le librerie in stile PyTorch (CrypTen) erano più trattabili, mentre i sistemi a livello di protocollo (MP-SPZ) rimanevano quasi irrisolti.
• Impatto della Verifica: L'applicazione del Verificatore MPC ha ridotto significativamente i tassi di risoluzione. Il tasso di risoluzione verificata per il top model è sceso al 17,1%.
• Rifiuto di Patch Funzionali: Fino al 40% delle patch che superavano i test funzionali è stato rifiutato dal verificatore a causa di violazioni della sicurezza o della fedeltà numerica.
• Riordinamento della Classifica: L'inclusione della verifica di sicurezza ha alterato la classifica dei modelli; ad esempio, Opus 4.6 ha superato Sonnet 4.6 nella classifica verificata nonostante la minore risoluzione funzionale, dimostrando che la correttezza funzionale e la sicurezza sono segnali distinti.

5. Significato e Rivendicazioni

Il paper sostiene che la sola correttezza funzionale sovrastima sostanzialmente l'affidabilità degli LLM nel software di preservazione della privacy. I risultati dimostrano che la riparazione MPC richiede capacità che vanno oltre ciò che i benchmark general-purpose catturano. Nello specifico:

• La valutazione standard fail-to-pass è insufficiente per il codice che deve aderire a rigorosi vincoli di sicurezza e fedeltà numerica.
• Una frazione non trascurabile di patch che superano i test standard fallisce i controlli di sicurezza o di fedeltà numerica, indicando che gli attuali LLM faticano con i vincoli specifici dell'ingegneria MPC.
• La metodologia funge da template per il benchmarking degli LLM in domini in cui la correttezza è determinata da altro rispetto ai soli esiti dei test, in particolare per il software sensibile alla sicurezza.

Gli autori segnalano limitazioni, tra cui la copertura attuale di soli cinque framework, e suggeriscono lavori futuri per estendere il benchmark ad altri stack crittografici come gli ibridi FHE (Fully Homomorphic Encryption) e gli ambienti Zero-Knowledge. Sottolineano inoltre che la loro pipeline di curatela è agnostica rispetto al repository e riutilizzabile per la costruzione di benchmark in altri domini specializzati.