💻 computer science

Computer Science Conferences Should Require Nonrepudiable Experimental Results

Este artigo de posição argumenta que as conferências de ciência da computação devem adotar protocolos à prova de adulteração e não repudiáveis para vincular criptograficamente os resultados experimentais relatados às computações reais, abordando as lacunas atuais de verificação por meio de um modelo formal de ameaças e uma implementação de referência chamada K-Veritas.

Autores originais: Mamadou K. Keita, Christopher Homan

Publicado 2026-05-12

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Mamadou K. Keita, Christopher Homan

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

O Problema Central: Ciência "Confie em Mim, Irmão"

Imagine que você é um juiz em uma competição de culinária. Um chef submete uma receita e afirma que seu bolo é o melhor do mundo. Eles lhe entregam uma foto do bolo e uma descrição escrita de como o fizeram.

O sistema atual é assim: O chef assina uma lista de verificação dizendo, "Sim, usei ovos reais", e "Sim, assiei por 30 minutos". Eles podem até mostrar um vídeo de si mesmos assando. Mas aqui está a pegadinha: O chef controla o vídeo. Eles poderiam ter editado o vídeo para mostrar um bolo real enquanto, na verdade, lhe serviam um recorte de papelão. Ou, poderiam ter assado 50 bolos, escolhido aquele que parecia perfeito e dito que esse foi o único que fizeram.

Na ciência da computação, especificamente em Aprendizado de Máquina (IA), é exatamente isso que acontece. Pesquisadores submetem artigos com tabelas de números (resultados) e listas de verificação. Revisores (os juízes) estão ocupados e não podem reexecutar os experimentos. Eles precisam aceitar os números na fé. Os autores deste artigo argumentam que esse sistema está quebrado porque depende da honestidade em vez de prova.

A Solução Proposta: O Recibo "Caixa Preta"

Os autores propõem uma nova regra para conferências de ciência da computação: Não Repúdio Experimental.

Pense nisso como um recibo à prova de adulteração para um experimento científico.

Não Repúdio é uma palavra de segurança sofisticada que significa: "Você não pode negar que fez isso, e não pode alterar o registro posteriormente."
O objetivo é vincular os números no artigo ao momento real em que o computador realizou o trabalho, de uma forma que o autor não possa falsificar ou alterar.

Como Funcionaria (A Ferramenta "K-Veritas")

Os autores criaram uma ferramenta protótipo chamada K-Veritas para mostrar que isso é possível. Eis como funciona, usando uma metáfora:

Imagine que o pesquisador é um chef e o computador é a cozinha.

O Wrapper: Em vez de apenas dizer ao computador para "assar o bolo", o pesquisador usa uma ferramenta especial (K-Veritas) que envolve o processo de assamento.
A Testemunha Silenciosa: Esta ferramenta age como uma testemunha silenciosa e independente parada na cozinha. Ela não toca nos ingredientes (os dados) e não muda a receita (o código). Ela apenas observa.
A Instantânea: Enquanto o computador trabalha, a testemunha tira instantâneos de:
- O código exato sendo usado.
- O tempo que levou.
- A eletricidade e o calor usados (para provar que a máquina estava realmente trabalhando duro).
- Os números finais que o computador imprimiu.
O Envelope Lacrado: Uma vez que o experimento termina, a testemunha sela todos esses instantâneos em um "envelope" digital e assina com uma chave especial que apenas a testemunha possui. O pesquisador nunca recebe essa chave.
O Resultado: O pesquisador submete seu artigo junto com este envelope assinado. Os revisores da conferência podem abrir o envelope e verificar: "O computador realmente rodou por 40 minutos? O código corresponde? Os números correspondem ao que foi impresso?"

Se o pesquisador tentar alterar um número no artigo mais tarde, o lacre se rompe e a assinatura torna-se inválida.

Por Que os Métodos Atuais Falham

O artigo explica por que as atuais "redes de segurança" não funcionam:

Listas de Verificação: Pedir a um chef para assinar um papel dizendo "Usei ovos reais" não prova que eles não usaram ovos de plástico.
Compartilhamento de Código: Só porque o chef compartilha a receita não significa que eles assaram o bolo que afirmaram. Eles poderiam compartilhar uma receita funcional, mas relatar resultados de um bolo diferente e melhor que assaram secretamente.
Ferramentas de Log: Ferramentas que rastreiam o progresso são como um diário escrito pelo chef. Se o chef quiser esconder um erro, eles podem simplesmente editar o diário.
Pré-registro: Isso é como o chef prometendo antes de começar, "Vou assar um bolo de chocolate". Isso impede que mudem o plano, mas não prova que eles realmente assaram o bolo ou que os números que relatam são reais.

A Conexão com "Resenhas Falsas"

O artigo faz uma comparação inteligente:

Conferências de topo (como a ICML) agora proíbem revisores de usar IA para escrever resenhas. Por quê? Porque a comunidade não consegue dizer se uma resenha é um pensamento humano real ou um texto falso de um robô.
Os autores argumentam: Se não podemos confiar em uma resenha falsa, definitivamente não podemos confiar em um resultado falso. Se uma resenha precisa de prova de humanidade, um resultado científico precisa de prova de computação.

O Que Esta Ferramenta Pode e Não Pode Fazer

Os autores são honestos sobre os limites de sua ferramenta (K-Veritas):

Ela impede: Trapaças com editores de texto, falsificação de números, edição de logs após o fato, ou alegar que executou um experimento enorme quando não o fez.
Ela não impede: Um hacker super-sofisticado que possa enganar o sistema operacional ou o próprio hardware do computador (como um sinal de GPS falso).
O Trade-off: Mesmo que não impeça todas as trapaças possíveis, ela aumenta o custo da trapaça. Atualmente, trapear requer apenas um editor de texto. Com este sistema, você teria que realmente executar o experimento de computador caro ou hackear o cérebro do computador.

O Caminho a Seguir

Os autores não estão dizendo que o K-Veritas é a resposta final. Eles o chamam de "ambiente de teste" (um protótipo). Eles propõem um plano de três etapas para a comunidade:

Voluntário: Permitir que pesquisadores o usem se quiserem obter um selo "Verificado".
Esperado: Torná-lo prática padrão, como o compartilhamento de código está se tornando padrão.
Obrigatório: Eventualmente, exigir para todos os artigos com resultados experimentais.

A Conclusão

A ciência é construída sobre confiança, mas confiança precisa de evidências. Este artigo argumenta que conferências de ciência da computação devem parar de pedir aos pesquisadores para "por favor, sejam honestos" e começar a exigir recibos digitais que provem que os números no artigo vieram de uma execução real e não alterada de computador. Trata-se de passar de "Confie em mim" para "Mostre-me o recibo".

Resumo Técnico: Conferências de Ciência da Computação Devem Exigir Resultados Experimentais Não Repudiáveis

Definição do Problema
O artigo identifica uma "lacuna de verificação" estrutural em conferências de ciência da computação, particularmente em aprendizado de máquina (ML). As medidas atuais de reprodutibilidade — como listas de verificação auto-relatadas (por exemplo, NeurIPS), avaliação opcional de artefatos, plataformas de registro controladas pelos autores (por exemplo, Weights & Biases) e pré-registro — falham em vincular resultados numéricos reportados à execução real do código que os produziu. Esses mecanismos verificam a intenção de divulgar ou a usabilidade do código, mas não conseguem responder à pergunta fundamental: "A execução de treinamento descrita neste artigo produziu realmente os resultados que este artigo relata?"

Os autores definem essa falha específica como não repúdio de experimentos. Tomando emprestado da literatura de segurança, definem-na como a propriedade pela qual um autor não pode, posteriormente, alterar, negar ou distorcer o registro do que sua computação realmente produziu. O sistema atual confia na confiança no auto-relato, deixando a comunidade vulnerável a fabricação em nível de texto, manipulação de logs e relato seletivo de execuções favoráveis.

Metodologia e Solução Proposta
Para abordar isso, os autores propõem um protocolo para gerar atestados à prova de adulteração e não repudiáveis de resultados experimentais. O núcleo de sua metodologia é um protocolo que deve satisfazer seis propriedades de segurança específicas:

Passividade: O observador não deve modificar a computação.
Cegueira de Dados: O observador nunca deve acessar o conjunto de dados $D$ , garantindo que dados proprietários permaneçam privados.
Vinculação à Execução: Métricas reportadas devem estar criptograficamente vinculadas à instância de execução específica, verificadas via telemetria de tempo de execução (uso de CPU/GPU, memória).
Evidência de Adulteração: Qualquer modificação no relatório (métricas, hiperparâmetros, carimbos de data e hora) deve invalidar a assinatura criptográfica.
Separação de Chave do Autor: A chave de assinatura deve ser mantida por um serviço de atestação independente, não pelo autor, impedindo que o autor gere atestados arbitrários.
Verificabilidade Independente: Qualquer terceira parte deve ser capaz de validar o atestado usando uma chave pública sem confiar no autor.

Para demonstrar a viabilidade desse problema, os autores construíram o K-Veritas, uma implementação de referência em Go. O K-Veritas funciona como um wrapper binário autônomo que os autores invocam via um prefixo de comando (por exemplo, kveritas run -- python train.py). Ele opera da seguinte forma:

Captura: Captura stdout/stderr de forma não bloqueante, analisa métricas e gera hashes de arquivos de origem antes e após a execução.
Telemetria: Um amostrador em segundo plano registra a utilização de hardware (tempo de CPU, memória, uso de GPU) em intervalos.
Selagem: Ao fechar a sessão, calcula um resumo canônico SHA-256 de toda a sessão (hashes de arquivos, fluxos stdout, métricas, amostras de hardware).
Assinatura: Envia apenas esse digest de 64 caracteres para um serviço remoto de atestação. O serviço, mantendo a chave privada, retorna uma assinatura RSA-PSS. O autor nunca vê a chave privada.
Saída: O sistema gera um relatório PDF assinado e um arquivo compactado assinado contendo o código de origem presente na execução.

Resultados e Demonstrações
O artigo apresenta duas formas principais de evidência:

Exercício da "Tabela Não Confiável": Os autores demonstram que duas tabelas de resultados — uma de uma execução real e outra gerada por um modelo de linguagem para ser plausível — são indistinguíveis para um revisor humano. Isso ilustra que a plausibilidade não é um substituto para a autenticidade.
Ambiente de Teste K-Veritas: Os autores executaram o K-Veritas em duas execuções de treinamento distintas: um LSTM Keras sintético e um RoBERTa-base ajustado finamente no SST-2. O sistema capturou com sucesso:
- Impressões digitais de hardware (modelos de GPU/CPU).
- Duração do treinamento e métricas finais (perda, precisão).
- Hashes de código de origem e stdout.
- Uma pontuação de "Consistência Hardware-Métrica (HMC)", que sinaliza anomalias (por exemplo, uma métrica relatada sem atividade de hardware correspondente).
- Assinaturas RSA-PSS válidas.

Os autores observam explicitamente que o K-Veritas é um ambiente de teste, não uma solução final. Ele previne com sucesso fabricação casual e moderada (edição de texto, manipulação de logs, relato seletivo ingênuo), mas reconhece não poder derrotar adversários privilegiados com acesso ao kernel ou firmware (por exemplo, falsificação de telemetria em nível de sistema operacional).

Contribuições Principais

Definição Conceitual: O artigo define formalmente a "não repúdio de experimentos" como uma classe distinta de problemas, separando-a de reprodutibilidade (pode ser reexecutada?) e replicabilidade (produz o mesmo resultado?).
Modelo de Ameaça: Descreve um modelo de ameaça abrangente, distinguindo entre ataques que protocolos apenas de software podem derrotar (fabricação, edição de logs) e aqueles que não podem (comprometimento de kernel/hardware).
Especificação de Protocolo: Define as propriedades de segurança necessárias para qualquer protocolo compatível, enfatizando a separação da chave de assinatura do autor.
Implementação: Fornece o K-Veritas como uma prova de conceito de que tal protocolo pode ser implementado sem exigir que os autores compartilhem dados sensíveis ou modifiquem sua lógica central de treinamento.

Significado e Alegações
O artigo argumenta que a não repúdio deve ser tratada como um requisito de primeira classe para conferências de ciência da computação, semelhante à proibição de revisões geradas por IA na ICML 2025. Os autores afirmam que, assim como a comunidade reconhece revisões fabricadas como uma ameaça que exige intervenção de políticas, resultados fabricados devem ser tratados com a mesma gravidade.

O significado do trabalho reside em deslocar o ônus da prova de "confie no autor" para "verifique a execução". Os autores propõem um caminho de adoção em três fases (Voluntário $\to$ Esperado $\to$ Obrigatório) ao longo de um horizonte de 3–8 anos. Eles enfatizam que, embora o sistema não seja perfeito contra adversários de nível estatal, ele muda fundamentalmente a economia da fabricação: movendo o custo de um simples editor de texto para a exigência de executar computação real ou comprometer um kernel.

O artigo conclui convocando uma organização independente e sem fins lucrativos para manter o padrão, garantindo que nenhuma entidade única controle a verificação da legitimidade científica. A estrutura é apresentada como generalizável além de ML para qualquer campo que dependa de pipelines computacionais para alegações empíricas.