Resumo Técnico: MPC-Patch-Bench

1. Definição do Problema

Os atuais benchmarks de nível de repositório para avaliar a reparação de código por Grandes Modelos de Linguagem (LLMs), como o SWE-bench, são estruturalmente inadequados para software de Computação Multipartidária Segura (MPC). Os autores identificam três falhas estruturais primárias ao tentar transpor benchmarks de propósito geral para o domínio de MPC:

1. Dominância de Infraestrutura Genérica: Repositórios de MPC são compostos majoritariamente por infraestrutura genérica em Python (CI/CD, wrappers de API), em vez de lógica criptográfica central, fazendo com que benchmarks ingênuos meçam engenharia de software padrão em vez de raciocínio específico de MPC.
2. Falta de Testes Padronizados: Correções de alto valor em MPC carecem dos testes padronizados de "Falha-para-Passagem" (F2P) e "Passagem-para-Passagem" (P2P) exigidos por pipelines de extração rígidos. Por exemplo, aplicar o filtro rigoroso do SWE-bench a 7.305 Pull Requests (PRs) brutos de MPC resultou em apenas 42 instâncias viáveis.
3. Insuficiência da Avaliação Funcional: A correção funcional padrão (passar nos testes) é insuficiente para MPC. Um patch de MPC também deve satisfazer garantias de segurança criptográfica (ex: invisibilidade de dados, integridade de compartilhamento de segredos) e fidelidade numérica (evitando deriva de anel finito ou de ponto fixo), o que testes unitários padrão não conseguem detectar.

Consequentemente, os esforços específicos de MPC existentes limitam-se à síntese de nível de operador ou tarefas de framework único, deixando uma lacuna na avaliação de agentes de LLM em reparação de MPC de nível de repositório no mundo real.

2. Metodologia

O artigo apresenta o MPC-Patch-Bench, um benchmark de nível de repositório composto por 205 instâncias totalmente verificadas, curadas de cinco grandes frameworks de MPC: CrypTen, tf-encrypted, MP-SPDZ, SecretFlow e PySyft. A construção e a avaliação baseiam-se em dois frameworks principais:

A. Framework de Curadoria de Dados

Este framework converte PRs brutos em instâncias executáveis de benchmark através de um processo de dois estágios:

1. Agente de Curadoria de Domínio Específico: Um agente de IA filtra 7.305 PRs brutos através de três camadas criptográficas para reter apenas aqueles que exercitam raciocínio genuíno de MPC:
   • Camada 1 (Verificação de Primitiva): Verifica a manipulação de primitivas centrais (ex: secret sharing, Oblivious Transfer).
   • Camada 2 (Lógica de Protocolo): Distingue correções que abordam a correção matemática de MPC de wrappers de sistema genéricos.
   • Camada 3 (Especificidade de Domínio): Garante que a resolução exija restrições especializadas (ex: invisibilidade de dados, gerenciamento de truncamento de ponto fixo).
   • Roteamento: Os candidatos são roteados com base em pontuações de confiança; PRs de alta confiança são aceitos automaticamente, enquanto os de confiança média passam por revisão humana. Isso reduziu o conjunto para 1.175 candidatos criptograficamente relevantes.
2. Mecanismo de Conclusão Humano-IA: Para abordar a falta de testes padronizados em PRs de MPC, um especialista humano atua como copiloto com um agente de síntese. O humano fornece intuição de domínio e verifica a correção criptográfica, enquanto o agente sintetiza enunciados de problemas ausentes, patches de teste F2P/P2P e harnesses de execução. Este processo resgatou casos de alto valor, porém incompletos, expandindo o dataset final de 42 instâncias obtidas por filtragem rigorosa para 205 instâncias totalmente verificadas.

B. O Verificador de MPC

Para avaliar os patches gerados por LLMs, os autores projetaram um verificador de fluxo duplo que vai além dos testes funcionais:

1. Fluxo de Teste Dinâmico: Executa o protocolo seguro contra um oráculo de texto puro para detectar deriva de fidelidade numérica (erros de precisão) e valida casos de borda algébricos via teste diferencial.
2. SAST (Teste de Segurança de Aplicação Estático) de Domínio Específico: Realiza varredura de código-fonte para sinalizar anti-padrões de MPC, incluindo:
   • Revelações inseguras (ex: reveal() dentro de loops).
   • Aritmética insegura (ex: coerção de ponto flutuante bruto em tipos de secret-shared).
   • Conversão de tipo ilegal (conversões não autorizadas entre público/privado).
   • Violações de regras criptográficas dependentes de contexto.

3. Principais Contribuições

• MPC-Patch-Bench: O primeiro benchmark de nível de repositório especificamente desenhado para avaliar a reparação de código de LLM em software de MPC, contendo 205 instâncias diversas e executáveis em cinco frameworks.
• Pipeline de Curadoria Inovador: Uma metodologia combinando um agente de IA de domínio específico com colaboração humano-IA para sintetizar testes e enunciados de problemas ausentes, superando o problema da "escassez de testes" em repositórios de MPC.
• Verificação Consciente de Segurança: Um framework de avaliação de fluxo duplo que integra teste diferencial dinâmico e análise estática para impor segurança criptográfica e fidelidade numérica, critérios ausentes em benchmarks de propósito geral.

4. Resultados

Os autores avaliaram oito LLMs líderes (incluindo Claude 3.5/4, GPT-4/5 e Gemini 2.5) no benchmark:

• Resolução Funcional: Mesmo o modelo mais forte (Sonnet 4.6) resolveu funcionalmente apenas 22,9% das 205 tarefas. O desempenho variou significativamente por framework; bibliotecas estilo PyTorch (CrypTen) foram mais tratáveis, enquanto sistemas de nível de protocolo (MP-SPZ) permaneceram quase insolúveis.
• Impacto da Verificação: A aplicação do Verificador de MPC reduziu significativamente as taxas de resolução. A resolução verificada para o principal modelo caiu para 17,1%.
• Rejeição de Patches Funcionais: Até 40% dos patches que passaram nos testes funcionais foram rejeitados pelo verificador devido a violações de segurança criptográfica ou de fidelidade numérica.
• Reordenamento do Leaderboard: A inclusão da verificação de segurança alterou o ranking dos modelos; por exemplo, o Opus 4.6 ultrapassou o Sonnet 4.6 no leaderboard verificado, apesar da menor resolução funcional, demonstrando que a correção funcional e a segurança criptográfica são sinais distintos.

5. Significância e Alegações

O artigo afirma que a correção funcional sozinha superestima substancialmente a confiabilidade de LLMs em software de preservação de privacidade. Os resultados demonstram que a reparação de MPC exige capacidades que vão além do que os benchmarks de propósito geral capturam. Especificamente:

• A avaliação padrão de falha-para-passagem é insuficiente para códigos que devem aderir a rigorosas garantias de segurança e fidelidade numérica.
• Uma fração não trivial de patches que passam nos testes padrão falham nas verificações de segurança ou numéricas, indicando que os LLMs atuais lutam com as restrições específicas da engenharia de MPC.
• A metodologia serve como um template para benchmarking de LLMs em domínios onde a correção é determinada por mais do que apenas resultados de testes, particularmente em software sensível à segurança.

Os autores observam limitações, incluindo a cobertura atual de apenas cinco frameworks, e sugerem trabalhos futuros estendendo o benchmark para outros stacks criptográficos, como híbridos de criptografia totalmente homomórfica (FHE) e ambientes de conhecimento zero (zero-knowledge). Eles também enfatizam que seu pipeline de curadoria é agnóstico ao repositório e reutilizável para construir benchmarks em outros domínios especializados.