Non è la prima volta che si parla di utilizzare gli LLM come GPT4 o Claude per rilevare errori e vulnerabilità negli smart contract. Anzi, di fatto è stato quasi un tormentone nel corso degli ultimi tempi con vari esperti, incluso il sottoscritto, che si divertivano a postare screenshot delle risposte di ChatGPT a domande sulla sicurezza di questo o quello snippet di codice solidity.

Forse spinti dall’ancestrale paura di venire rimpiazzati dalla macchina ci siamo mossi in maniera preventiva per mostrare che la macchina in realtà faceva dei gran pasticci e che noi esperti non saremmo rimasti senza lavoro.

Posto che anche dare in pasto ad un LLM un contratto e chiedergli se è sicuro sembra un’approccio piuttosto naif, una cosa che abbiamo imparato dall’uso degli LLM è che le domande vanno poste in modo corretto e in modo completo per rimuovere ambiguità e incomprensioni. Ma questo è un altro discorso

In questo caso però voglio presentarvi un articolo scientifico scritto a quattro mani dai ricercatori dell’Imperial College London e UCL che in effetti cerca di dare una stima quantitativa al precendente “lo vedete che fa solo dei pasticci”.

La referenza bibliografica completa è

David, Isaac, et al. "Do you still need a manual smart contract audit?." arXiv preprint arXiv:2306.12338 (2023).

Ed è scaricabile da https://arxiv.org/abs/2306.12338

L'articolo esplora la fattibilità di utilizzare i Large Language Models (LLMs) per condurre audit di sicurezza sui smart contract.

Esperimento su smart contract vulnerabili e noti

La ricerca si concentra sull'ottimizzazione dell'ingegneria dei prompt per un'analisi di sicurezza e valuta le prestazioni e l'accuratezza degli LLMs utilizzando un set di dati di riferimento composto da 52 smart contract di finanza decentralizzata (DeFi) che sono stati precedentemente compromessi (Pagina 1).

I risultati mostrano che, quando applicati a contratti vulnerabili, sia i modelli GPT-4 che Claude identificano correttamente il tipo di vulnerabilità nel 40% dei casi. Tuttavia, questi modelli mostrano anche un alto tasso di falsi positivi, che richiede un coinvolgimento continuo da parte degli auditor manuali. Nonostante ciò, gli LLMs testati superano un modello casuale del 20% in termini di punteggio F1. Francamente mi pare che siamo abbastanza lontani da una seppur minima utilità, o per lo meno andrebbe capito se il dover verificare i falsi positivi alla fine è un costo superiore ad un audit completamente manuale.

Esperimento su smart contract ignoti e realizzati ad hoc

Giustamente non contenti del risultato i ricercatori fanno anche un’altra considerazione, ovvero che il test è stato condotto con esempi noti di smart contract affetti da vulnerabilità e pubblicati in veri servizi di DeFi, quindi probabilmente gli stessi modelii Claude e GPT potrebbero già includere nel loro training set informazioni relative a questi specifici hack. Per ovviare a questo problema allora conducono un secondo esperimento in cui vengono creati ad hoc 5 nuovi smart contract ognuno dei quali contiene 2 (oppure 15 in una variante dell’esperimento) vulnerabilità aggiunte dai ricercatori stessi.

GPT-4 e Claude sono stati in grado di rilevare 6 su 10 vulnerabilità (vulnerabilità totali in tutti i contratti). Per i contratti con 15 vulnerabilità, GPT-4 ha avuto prestazioni leggermente migliori e ha potuto identificare 46 delle possibili 75 vulnerabilità (61,3%) in tutti e 5 i contratti, mentre Claude ha identificato 43

In tutti i contratti, tranne LPManager, sono state identificate delle vulnerabilità. Claude è stato in grado di identificare il numero di vulnerabilità corrispondenti alla realtà nella maggior parte dei contratti, tranne FaucetToken, in cui non è stata rilevata alcuna vulnerabilità

L'articolo conclude che la ricerca costituisce un passo fondamentale verso la ridefinizione del panorama dell'audit degli smart contract ma in realtà questi risultati indicano che, nonostante i modelli di linguaggio possano identificare alcune vulnerabilità, non sono ancora in grado di sostituire completamente gli auditor umani.