💻 computer science

Beyond F1: A Study of LLM Reliability in Smart Contract Vulnerability Detection

Este estudo avalia 14 grandes modelos de linguagem na detecção de vulnerabilidades em contratos inteligentes, revelando que a seleção do modelo é mais crítica do que estratégias de prompting ou o aumento da computação em tempo de inferência, visto que modelos de fronteira maiores demonstram confiabilidade superior, enquanto modelos menores e técnicas de raciocínio estendido podem degradar o desempenho.

Autores originais: Durjoy Majumdar

Publicado 2026-08-25

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Durjoy Majumdar

Artigo original sob licença CC BY 4.0 (https://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

No mundo digital das finanças descentralizadas, o dinheiro se move através de programas de execução automática chamados contratos inteligentes. Estes são como máquinas de venda automática digitais que dispensam ativos automaticamente quando condições específicas são atendidas, operando sem gestores humanos ou bancos. Como esses programas rodam em uma blockchain, uma vez que são implantados, eles são efetivamente permanentes; se uma falha for encontrada após a máquina ser construída, muitas vezes é impossível corrigi-la. Essa imutabilidade torna a segurança crítica, pois até mesmo um erro minúsculo pode levar à perda de bilhões de dólares. Durante anos, pesquisadores confiaram em ferramentas automatizadas para escanear esses contratos em busca de erros, mas essas ferramentas frequentemente têm dificuldade em entender o contexto do código, gerando falsos alarmes ou ignorando perigos sutis. Recentemente, um novo tipo de inteligência artificial conhecido como modelo de linguagem de grande escala surgiu, capaz de ler e compreender código de forma muito semelhante a um programador humano. Isso levantou uma questão esperançosa: podem esses sistemas inteligentes substituir ou melhorar os controles de segurança tradicionais para encontrar vulnerabilidades antes que elas causem danos?

Um estudo recente buscou responder a isso submetendo quatorze modelos diferentes de inteligência artificial ao teste. Os pesquisadores reuniram cinquenta e quatro contratos inteligentes do mundo real, incluindo alguns conhecidos por possuírem falhas de segurança e outros que estavam perfeitamente limpos, para ver o quão bem os modelos conseguiam distinguir entre os dois. Eles não apenas pediram aos modelos para olharem o código; eles tentaram quatro maneiras diferentes de perguntar, variando de uma pergunta direta simples a instruções complexas e passo a passo que forçavam os modelos a refletir sobre sua análise. Eles também testaram se dar aos modelos mais tempo para "pensar" durante o processo melhorava seus resultados, um recurso que alguns modelos modernos oferecem para raciocinar sobre problemas de forma mais profunda. O objetivo era determinar se essas ferramentas poderosas poderiam encontrar bugs de forma confiável sem acusar erroneamente códigos seguros de serem perigosos.

Os resultados revelaram uma divisão acentuada de desempenho que desafia algumas suposições comuns sobre como esses modelos funcionam. O estudo descobriu que simplesmente dar a um modelo mais tempo para pensar ou pedir que ele siga um processo de raciocínio detalhado nem sempre o tornava melhor. Na verdade, para um dos modelos com melhor desempenho, habilitar este modo de pensamento extra o tornou pior, fazendo com que ele perdesse vulnerabilidades genuínas e reduzisse sua precisão geral. Isso sugere que mais esforço computacional não se traduz automaticamente em uma melhor análise de segurança. Em vez disso, o fator mais importante era simplesmente qual modelo era escolhido. Os melhores modelos, que são grandes e desenvolvidos comercialmente, provaram ser altamente confiáveis, identificando corretamente vulnerabilidades enquanto raramente cometiam erros em códigos seguros.

Em forte contraste, os modelos menores e de código aberto testados no estudo comportaram-se de forma muito diferente. Embora esses modelos menores fossem excelentes em detectar potenciais problemas, eles sofriam de uma falha crítica: eram incapazes de distinguir entre um contrato vulnerável e um seguro. Eles sinalizavam cada contrato limpo como perigoso, efetivamente gritando "lobo" a cada passo. Os pesquisadores cunharam um termo específico para essa tendência de alucinar ameaças onde não existem, chamando-a de "Taxa de Basilisco". Um modelo com uma taxa alta é inútil para a segurança porque sobrecarregaria os engenheiros com falsos alarmes. O estudo mostrou que os seis modelos com melhor desempenho tiveram um registro perfeito de nunca sinalizar código limpo, enquanto os três modelos menores sinalizaram todos os contratos limpos como vulneráveis.

A investigação também destacou um limite específico no tamanho desses modelos que parece determinar sua confiabilidade. Os modelos que tiveram bom desempenho geralmente possuíam um número maior de parâmetros internos, que podem ser pensados como a complexidade de sua base de conhecimento interna. O estudo sugere que existe um ponto de transição em torno de um tamanho específico, onde modelos abaixo desse limite tendem a alucinar constantemente, enquanto aqueles acima dele tornam-se precisos e confiáveis. Curiosamente, um modelo de código aberto grande conseguiu fazer a ponte para esse hiato, performando quase tão bem quanto os principais modelos comerciais, mas os menores permaneceram não confiáveis.

Em última análise, o estudo conclui que, para a tarefa específica de encontrar falhas de segurança em contratos inteligentes, a escolha do modelo de inteligência artificial importa muito mais do que como ele é instruído ou quanto tempo lhe é dado para pensar. Embora essas ferramentas avançadas mostrem grande promessa, elas não são uma solução mágica que funciona da mesma forma para todos os sistemas. A abordagem mais eficaz envolve selecionar um modelo que tenha sido comprovado como preciso e evitar aqueles que são propensos a ver problemas que não existem. Para o futuro das finanças digitais, isso significa que as equipes de segurança devem verificar cuidadosamente quais ferramentas de inteligência artificial utilizam, garantindo que dependam de sistemas que consigam distinguir entre uma ameaça real e um pedaço de código inofensivo.

Resumo Técnico: Além do F1: Um Estudo sobre a Confiabilidade de LLMs na Detecção de Vulnerabilidades em Smart Contracts

1. Declaração do Problema

Vulnerabilidades em smart contracts no setor de finanças descentralizadas (DeFi) resultaram em perdas de bilhões de dólares, com mais de US$ 1,2 bilhão perdidos apenas em 2024. Métodos tradicionais de detecção, como ferramentas de análise estática (ex: Slifer, Mythril), dependem de regras e heurísticas predefinidas. Embora eficazes para padrões conhecidos, eles frequentemente sofrem com altas taxas de falsos positivos e têm dificuldade com vulnerabilidades que exigem compreensão contextual.

Modelos de Linguagem de Grande Escala (LLMs) oferecem uma alternativa promissora para a análise de código, mas sua confiabilidade neste domínio específico permanece mal compreendida. Questões críticas persistem em relação a:

Se o aumento da computação em tempo de inferência (ex: via "pensamento estendido" ou modos de raciocínio) melhora consistentemente as capacidades de detecção.
Quais fatores (escala do modelo, arquitetura, estratégia de prompting) influenciam mais significativamente a confiabilidade.
Até que ponto os LLMs alucinam vulnerabilidades em códigos seguros, um risco que métricas padrão como o F1 score podem ocultar.

2. Metodologia

O estudo conduz uma avaliação sistemática de 14 LLMs de sete famílias diferentes em 54 smart contracts de Solidity.

Construção do Dataset

Composição: 54 contratos no total, sendo 24 do benchmark curado SmartBugs e 30 contratos escritos sob medida.
Cobertura de Vulnerabilidades: 44 contratos vulneráveis cobrindo classes como reentrância, erros aritméticos, violações de controle de acesso, negação de serviço (DoS), front-running e chamadas de baixo nível não verificadas.
Contratos Limpos: Foram incluídos 10 contratos propositalmente escritos e verificados como limpos para medir especificamente as taxas de falsos positivos.
Pré-processamento: Para evitar vazamento de informações, o dataset passou por uma sanitização rigorosa:
- Remoção de 3.456 linhas de comentários contendo dicas específicas de vulnerabilidade.
- Substituição de identificadores de contrato reveladores (ex: reentrancy_01) por IDs sequenciais opacos.
- Neutralização de nomes de classes (ex: mudar ReentrancyVuln1 para DepositVault).

Seleção de Modelos

Quatorze modelos foram selecionados para equilibrar acessibilidade (via APIs, interfaces de chat e Antigravity IDE) e capacidade. A seleção inclui:

Frontier/Closed-Source: Gemini (Flash, Pro, Thinking), ChatGPT 5.3, Grok (Fast, Expert), Claude (Sonnet 4.5, Opus 4.6), DeepSeek v3.2.
Open-Source (Pequeno/Médio): Llama 3.1 8B, Llama 4 Scout 17B, Qwen3 32B.
Modos de Raciocínio: Os modelos foram testados tanto com quanto sem as capacidades de "Thinking" ou "Extended Reasoning" habilitadas, onde disponíveis.

Estratégias de Prompting

Quatro estratégias distintas foram avaliadas:

Zero-shot: Solicitação direta de análise.
Few-shot: Três exemplos rotulados fornecidos antes do alvo.
Chain-of-Thought (CoT): Um protocolo de análise estruturado em seis etapas.
Auditor Role: Enquadramento do modelo como um "Auditor de Segurança Principal" para impor responsabilidade profissional.

Métricas de Avaliação

Além das métricas de classificação padrão (Precisão, Recall, F1, Acurácia), o estudo introduz a Taxa Basilisk:

Definição: $FP_{clean} / Total_{clean}$ .
Propósito: Mede a taxa de falsos positivos especificamente em contratos verificados como limpos. Uma taxa de 1.0 indica que o modelo alucina vulnerabilidades em cada contrato seguro, enquanto 0.0 indica segurança perfeita.
Configuração Experimental: Um design fatorial completo (14 modelos × 4 estratégias × 54 contratos) resultou em 3.015 respostas avaliadas após a exclusão de 9 falhas de API. Uma temperatura baixa (T=0.1) foi usada para forçar o determinismo.

3. Resultados Principais

Desempenho Geral de Detecção

Modelos Frontier: Seis modelos frontier alcançaram um F1 score > 0.95. Notavelmente, o Claude Opus 4.6 Thinking alcançou o maior F1 médio (0.9800), seguido pelo Gemini Pro (0.9797) e Claude Sonnet 4.5 Thinking (0.9796).
Troca Precisão-Recall: Os modelos frontier ocuparam o quadrante de alta precisão e alto recall. Seis modelos alcançaram precisão perfeita (1.000).
Modelos Open-Source Pequenos: Os três modelos pequenos (Llama 3.1 8B, Llama 4 Scout 17B, Qwen3 32B) alcançaram recall quase perfeito (≥0.988), mas sofreram com precisão extremamente baixa (~0.81). Eles classificaram quase todas as entradas como vulneráveis, falhando em distinguir entre código seguro e inseguro.

Computação em Tempo de Inferência (RQ1)

O estudo desafia a suposição de que "mais pensamento" equivale a "melhores resultados":

Resultados Mistos: Habilitar o "Extended Thinking" melhorou ligeiramente o DeepSeek v3.2 (F1 +0.014), mas degradou significamente o desempenho do ChatGPT 5.3.
Caso de Degradação: O ChatGPT 5.3 Thinking teve uma queda de 11,5% no F1 score (de 0.977 para 0.864) e uma queda no recall de 0.955 para 0.784. A análise sugeriu que o modelo analisou excessivamente, descartando vulnerabilidades genuínas como construções aceitáveis.
Conclusão: Aumentar a computação em tempo de inferência não melhora a detecção de forma confiável e pode ativamente degradá-la.

Impacto da Estratégia de Prompting

Influência Limitada: As estratégias de prompting tiveram um efeito marginal em comparação com a seleção do modelo. A melhor estratégia (Zero-shot, F1 0.938) superou a pior (Chain-of-Thought, F1 0.921) por apenas 0.017 pontos quando calculada a média de todos os modelos.
Dominância do Modelo: A diferença entre o melhor modelo (Claude Opus, F1 0.980) e o pior (Grok Fast, F1 0.859) foi de 0.121 pontos, reforçando que a seleção do modelo é o determinante primário da qualidade, não o prompt engineering.

Determinantes da Confiabilidade (RQ2)

O "Divisor Basilisk": Uma divisão binária clara surgiu em relação à alucinação.
- Zero Alucinação: Seis modelos frontier (incluindo Gemini Pro, Claude Sonnet/Opus, ChatGPT 5.3) alcançaram uma Taxa Basilisk de 0.000, o que significa que nunca sinalizaram um contrato limpo como vulnerável.
- Alucinação Universal: Todos os três modelos open-source pequenos (Llama 3.1, Llama 4 Scout, Qwen3) exibiram uma Taxa Basilisk de 1.000, sinalizando cada contrato limpo como vulnerável, independentemente da estratégia de prompting.
Limiar de Escala: Um gap de confiabilidade correlaciona-se fortemente com a escala do modelo. O estudo identifica um ponto de transição em torno de 37 bilhões de parâmetros ativos (exemplificado pelo DeepSeek v3.2). Modelos abaixo desta escala tendem a alucinar universalmente, enquanto aqueles acima (ou equivalentes closed-source) alcançam alta confiabilidade.
Classificação de Tipo de Vulnerabilidade: Embora a detecção binária tenha melhorado, a precisão da classificação de tipo permaneceu modesta (média de 60% para modelos frontier). Curiosamente, o prompting Zero-shot rendeu maior precisão de tipo (65.2%) do que prompts CoT estruturados, sugerindo que o prompting complexo pode restringir a flexibilidade de classificação.

4. Significância e Contribuições

O artigo oferece vários insights críticos para a implantação de LLMs na segurança de blockchain:

Introdução da Taxa Basilisk: O estudo propõe a Taxa Basilisk como uma métrica padrão necessária para aplicações de segurança. Argumenta-se que métricas agregadas como F1 podem ser enganosas; um modelo com um F1 decente (ex: Qwen3 32B com 0.895) é praticamente inutilizável se tiver uma Taxa Basilisk de 1.000, pois gera alarmes falsos para cada contrato seguro.
Reavaliação da Computação em Tempo de Inferência: Os resultados desafiam a suposição comum de que habilitar "modos de raciocínio" ou "pensamento estendido" melhora universalmente o desempenho. O estudo demonstra que, para certos modelos, esses modos podem induzir a uma análise excessiva e reduzir o recall.
Seleção de Modelo sobre Prompt Engineering: Os achados sugerem que, para auditoria de smart contracts, selecionar a arquitetura e a escala corretas do modelo é significativamente mais impactante do que otimizar estratégias de prompting.
Diretrizes Práticas de Implantação:
- Modelos frontier (ex: Gemini Pro, Claude Sonnet/Opus) são adequados para varreduras automatizadas pré-implantação (CI/CD) devido às suas taxas de falsos positivos zero em código limpo.
- Modelos open-source pequenos são considerados impraticáveis para esta tarefa específica devido à alucinação universal.
- Modelos open-source grandes (ex: DeepSeek v3.2) mostram promessa, preenchendo a lacuna entre modelos pequenos e frontier, particularmente ao usar modos de raciocínio.

O estudo conclui que, embora os LLMs tenham feito progressos significativos desde os baselines de 2025, sua confiabilidade não é garantida apenas pela escala ou pela adição de etapas de raciocínio. O benchmarking empírico rigoroso de modelos específicos é necessário antes da implantação em ambientes de segurança crítica.