💻 computer science

Assessing Vulnerability in Smart Contracts: The Role of Code Complexity Metrics in Security Analysis

Questa ricerca dimostra che, sebbene le singole metriche di complessità del software mostrino una bassa correlazione con vulnerabilità specifiche nei contratti intelligenti in Solidity, la loro analisi collettiva distingue efficacemente tra codice sicuro e vulnerabile, con i contratti vulnerabili che esibiscono costantemente punteggi di complessità media più elevati.

Autori originali: Masoud Jamshidiyan Tehrani

Pubblicato 2026-01-26

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Masoud Jamshidiyan Tehrani

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina un Smart Contract come un distributore automatico che si auto-esegue, costruito su una blockchain. Una volta inseriti i soldi e premuto un tasto, ti restituisce uno snack automaticamente. Non puoi tornare indietro per cambiare gli ingranaggi interni della macchina in seguito; è "immutabile". Se c'è un difetto negli ingranaggi, un hacker può rubare tutto il denaro all'interno e non c'è modo di ripararlo senza costruire una macchina completamente nuova.

Questo articolo parla del tentativo di trovare questi ingranaggi rotti prima che la macchina venga distribuita. I ricercatori si sono posti una domanda semplice: "Possiamo capire se un distributore automatico è probabilmente rotto solo guardando quanto sono complicati i suoi progetti?"

Ecco la ripartizione delle loro scoperte utilizzando analogie quotidiane:

1. L'idea centrale: La complessità è un "segnale d'allarme"

I ricercatori hanno esaminato 21 modi diversi per misurare quanto sia "disordinoso" o "complicato" un pezzo di codice. Considera queste metriche come strumenti che misurano cose quali:

SLOC (Righe di Codice Sorgente): Quante pagine ha il manuale di istruzioni?
Nesting (Annidamento): Quanti strati di scatole "se succede questo, allora fai quello" ci sono l'una dentro l'altra? (Come una matrioska).
Coupling (Accoppiamento): Di quante altre macchine ha bisogno questa macchina per comunicare al fine di funzionare?

La scoperta: Hanno scoperto che progetti disordinati di solito significano macchine rotte.
Quando hanno esaminato i contratti che erano stati hackerati (vulnerabili), i loro progetti erano quasi sempre più complessi, lunghi e aggrovigliati rispetto ai progetti dei contratti sicuri.

2. Il problema della "Palla di Cristallo" (Metriche Individuali)

I ricercatori hanno cercato di vedere se una specifica misurazione potesse predire un hack.

Analogia: Immagina di cercare di indovinare se un'auto farà un incidente solo guardando il numero di portabicchieri.
Risultato: Non ha funzionato bene. Nessuna singola metrica (come contare solo le righe di codice) era una "palla di cristallo" perfetta. Se avessi guardato solo il numero di righe, non avresti potuto dire con certezza: "Questo è sicuramente destinato a essere hackerato". Il collegamento c'era, ma era debole.

3. Il successo del "Lavoro di Squadra" (Metriche Combinate)

Tuttavia, quando hanno guardato a tutte le misurazioni insieme, il quadro è diventato molto chiaro.

Analogia: Non puoi capire se una zuppa è salata assaggiando solo il salvasapore, ma se assaggi l'intera ciotola, sai esattamente quanto è salata.
Risultato: Sebbene una metrica non fosse sufficiente, la combinazione di metriche è stata molto efficace nel distinguere tra contratti sicuri e pericolosi. I contratti "vulnerabili" avevano costantemente punteggi più alti in tutto il campo (più righe di codice, annidamento più profondo, più connessioni) rispetto a quelli sicuri.

4. Le sorprendenti eccezioni

Ci sono state tre cose che sono andate contro la regola "più complessità = più pericolo":

Commenti (CLOC): I contratti sicuri avevano più commenti (note scritte dal programmatore per spiegare il codice). I contratti vulnerabili ne avevano meno.
- Conclusione: Scrivere note sul tuo progetto sembra aiutare a mantenere sicura la tua macchina.
Discendenti (NOD): I contratti sicuri avevano più "discendenti" (versioni o contratti figli). Quelli vulnerabili ne avevano meno.
Parametri: I contratti vulnerabili avevano in realtà leggermente meno input/parametri in media.

5. Cosa significa per gli sviluppatori

L'articolo conclude che la complessità non è la causa dell'hack (come un virus), ma è un segnale di avvertimento molto forte.

L'analogia: Se vedi una casa con un groviglio di cavi, tubi esposti e una pianta confusa, non sai con certezza se prenderà fuoco, ma sai che è molto più probabile che accada rispetto a una casa con cablaggi ordinati e organizzati.
Il consiglio: Gli sviluppatori dovrebbero cercare di mantenere il loro codice semplice. Se un contratto sta diventando troppo complicato, è un segnale per fermarsi e controllare eventuali falle di sicurezza. Inoltre, scrivete più commenti; i dati suggeriscono che un codice ben documentato è più sicuro.

Riassunto

L'articolo dimostra che la complessità è un forte indicatore di rischio nei smart contract. Non puoi affidarti a un solo numero per predire un hack, ma se guardi il "disordine" complessivo del codice, puoi individuare i contratti pericolosi molto meglio rispetto a se ignorassi interamente la complessità. È uno strumento per aiutare auditor e sviluppatori a dare priorità ai contratti che necessitano di un'ispezione più attenta.

Sintesi Tecnica: Valutazione della Vulnerabilità nei Contratti Intelligenti tramite Metriche di Complessità del Codice

Problematica
I contratti intelligenti (smart contract) distribuiti su piattaforme blockchain come Ethereum sono immutabili e spesso gestiscono transazioni finanziarie di alto valore, rendendo fondamentale l'assicurazione della sicurezza. Sebbene la blockchain sottostante sia sicura, i contratti intelligenti stessi possono essere vulnerabili ad exploit derivanti da negligenza del programmatore o errori di codifica. Gli strumenti tradizionali di analisi statica spesso si affidano al pattern matching per rilevare tipi specifici di vulnerabilità. Tuttavia, esiste la necessità di comprendere se le proprietà strutturali del codice, ovvero la complessità del software, possano servire come indicatori complementari per identificare aree vulnerabili. Gli autori postulano che il codice che differisce dalle pratiche consolidate (ovvero una maggiore complessità) possa esporre maggiormente a difetti di sicurezza, tuttavia la relazione specifica tra le metriche di complessità e le vulnerabilità dei contratti intelligenti in Solidity rimane un problema aperto che richiede una validazione empirica.

Metodologia
Lo studio impiega un approccio quantitativo ed empirico per analizzare la relazione tra 21 distinte metriche di complessità del software e la presenza di vulnerabilità nei contratti intelligi in Solidity.

Dataset: La ricerca utilizza un dataset derivato da Liu et al., composto da 16.239 contratti individuali (258 vulnerabili, 15.981 neutri) estratti da Etherscan. I contratti vulnerabili sono stati etichettati sulla base di otto tipi specifici di vulnerabilità: Integer Underflow/Overflow, Dangerous Ether Strict Equality, Reentrancy, Timestamp Dependency, Block Number Dependency, Dangerous Delegatecall, Ether Frozen e Unchecked External Call.
Estrazione delle Metriche: Lo strumento di analisi statica Solmet è stato utilizzato per estrarre 21 metriche di complessità per ogni contratto. Queste includono metriche di dimensione (SLOC, LLOC, CLOC), metriche strutturali (NF, WMC, NOS), metriche di annidamento (NL, NLE), metriche di ereditarietà (DIT, NOA, NOD), metriche di accoppiamento (CBO, NOI, NA) e le medie di tali metriche.
Analisi Statistica:
- Analisi di Correlazione: Il coefficiente di correlazione di rango di Spearman è stato utilizzato per valutare le relazioni monotone e per identificare ridondanze tra le metriche stesse.
- Confronto tra Gruppi: Il test di Mann-Whitney U è stato impiegato per determinare se la distribuzione dei valori delle metriche differisse significativamente tra i contratti vulnerabili e quelli neutri.
- Dimensione dell'Effetto: Il Delta di Cliff ( $\delta$ ) è stato calcolato per quantificare l'entità della differenza tra i due gruppi.
- Intervalli di Confidenza: Utilizzati per confrontare la tendenza centrale (medie) delle metriche tra i gruppi vulnerabili e neutri.

Contributi Chiave
Il documento affronta quattro domande di ricerca specifiche (RQ) per valutare l'utilità delle metriche di complessità:

RQ1 (Interdipendenza delle Metriche): Lo studio identifica una significativa ridondanza tra alcune metriche. Ad esempio, SLOC è fortemente correlato con NOI, NOS, WMC e NF. Allo stesso modo, le metriche di annidamento (NL, NLE) e le loro medie mostrano un'alta correlazione, suggerendo che non tutte le 21 metriche forniscono informazioni uniche per il rilevamento delle vulnerabilità.
RQ2 (Correlazione Metrica-Vulnerabilità): L'analisi rivela che, sebbene tutte le 21 metriche mostrino una correlazione statisticamente significativa ( $p < 0,05$ ) con la presenza di vulnerabilità, la forza di queste correlazioni è generalmente debole (coefficienti per lo più inferiori a 0,3). Ciò contrasta con le scoperte nei linguaggi di programmazione tradizionali dove le correlazioni sono spesso più forti. Di conseguenza, nessuna singola metrica funge da forte predittore da sola.
RQ3 (Potere Discriminante): Nonostante le deboli correlazioni individuali, il test di Mann-Whitney U conferma che tutte le metriche possono distinguere statisticamente tra codici vulnerabili e neutri ( $p < 0,05$ ). La maggior parte delle metriche mostra una grande dimensione dell'effetto (ad es., SLOC, LLOC, NF, WMC, NL, NOS, CBO, NA, NOI), indicando che le distribuzioni di queste metriche sono praticamente diverse tra i due gruppi.
RQ4 (Direzionalità della Differenza): Lo studio rileva che i contratti vulnerabili presentano generalmente punteggi di complessità media più elevati rispetto ai contratti neutri per la maggior parte delle metriche. Tuttavia, vi sono tre eccezioni degne di nota in cui i contratti vulnerabili hanno valori inferiori:
- CLOC (Linee di Commento): I contratti neutri hanno più commenti, suggerendo che la documentazione possa mitigare la vulnerabilità.
- NOD (Numero di Discendenti): I contratti vulnerabili hanno meno discendenti.
- Avg. NUMPAR (Media dei Parametri): I contratti vulnerabili hanno mediamente meno parametri.

Risultati e Significato
Il documento conclude che le metriche di complessità sono indicatori piuttosto che cause dirette di vulnerabilità. Il significato primario dei risultati risiede nei seguenti punti:

Utilità Collettiva: Sebbene le singole metriche abbiano un debole potere predittivo, lo studio dimostra che, quando analizzate collettivamente, le metriche di complessità possiedono forti capacità discriminanti. Ciò supporta il loro uso come caratteristiche complementari negli strumenti di rilevamento automatico delle vulnerabilità.
Gestione della Ridondanza: L'identificazione di metriche altamente correlate (ad es., SLOC vs. WMC vs. NF) suggerisce che i modelli di predizione della vulnerabilità possono essere ottimizzati selezionando un sottoinsieme non ridondante di caratteristiche, migliorando l'efficienza senza sacrificare l'accuratezza.
Sfumatura Contestuale: I risultati evidenziano caratteristiche uniche di Solidity rispetto al software tradizionale. Ad esempio, la relazione inversa con la densità di commenti (CLOC) suggerisce che, nel contesto degli smart contract, la mancanza di documentazione è un marker specifico di rischio.
Applicazione Pratica: Gli autori propongono che queste metriche possano essere integrate negli strumenti di analisi statica esistenti per dare priorità agli sforzi di audit. I contratti con punteggi di complessità elevati possono essere segnalati per una revisione manuale più approfondita, e gli sviluppatori possono utilizzare questi insight per aderire alle best practice, come minimizzare l'annidamento, ridurre l'accoppiamento e garantire una documentazione adeguata.

Gli autori mantengono una posizione modesta, sottolineando che le relazioni osservate sono associazioni statistiche. Essi riconoscono che l'alta complessità spesso correla con un dominio di problema più ampio (ad es., i protocolli DeFi complessi richiedono naturalmente più codice), il che potrebbe essere il driver sottostante per l'aumento del rischio di vulnerabilità, piuttosto che le metriche di complessità stesse essere l'unico meccanismo causale. Il lavoro futuro suggerito include la stratificazione specifica per dominio e l'esplorazione delle metriche di complessità cognitiva.