Rischi dei contratti intelligenti: codice, oracoli, governance e chiavi di aggiornamento

Un cruscotto può far sembrare che il rischio dei contratti intelligenti dipenda da un unico evento. In realtà, la definizione di diritti e invarianti, la verifica del sistema distribuito e la risposta e governance sono cambiamenti di stato distinti, gestiti da partecipanti diversi. È in questi passaggi nascosti che entrano in gioco tempo, costi e rischi.

Il rischio dei contratti intelligenti è la possibilità che il codice, le dipendenze o la governance producano un risultato finanziario diverso da quello atteso dagli utenti. La superficie di attacco comprende la logica aziendale, il controllo degli accessi, l’aritmetica e la contabilità, gli oracoli, i token, la componibilità, le interfacce front-end, le chiavi private, gli aggiornamenti e le promesse giuridiche relative al codice.

Una verifica è una prova derivante da un esame definito, non una garanzia. È possibile distribuire codice sorgente corretto con parametri diversi, aggiornarlo in seguito o farlo interagire con un oracolo manipolato. Il codice immutabile riduce il rischio di modifiche solo se anche il comportamento immutabile e le relative dipendenze sono sicuri.

Per inquadrare il rischio dei contratti intelligenti nella trattazione più ampia di Securities.io, confronta il modello di riferimento dello stack DeFi, le società di verifica dei contratti intelligenti e la sicurezza dei contratti intelligenti e l’IA. Nel loro insieme, queste guide mostrano come la stessa questione relativa all’infrastruttura degli asset digitali cambi al variare dell’emittente, dell’asset, del diritto dell’investitore o dell’infrastruttura operativa.

Dalla definizione di diritti e invarianti alla risposta e governance: la catena dei rischi dei contratti intelligenti

La fase di definizione dei diritti e degli invarianti stabilisce di definire saldi, autorità, limiti e condizioni che devono sempre essere rispettati. Il risultato diventa quindi un input per l’implementazione e i test, che prevedono l’uso di componenti verificati e di test unitari, d’integrazione, basati su proprietà e avversariali. Questo passaggio è il primo punto in cui verificare il rischio dei contratti intelligenti: chi riceve il risultato deve poter distinguere un cambiamento di stato completato da un messaggio, una stima o un dato provvisorio. La stessa verifica si applica a ogni passaggio successivo, finché la fase di risposta e governance non produce un risultato che possa essere riconciliato in modo indipendente.

Leggi il diagramma a ritroso, partendo dalla fase di risposta e governance. Lo stato finale dovrebbe ricondurre alla specifica, al codice sorgente distribuito e al bytecode, ai test e alle verifiche, ai parametri e ai ruoli amministrativi, alla mappa degli oracoli e delle dipendenze, agli eventi monitorati, alla risposta agli incidenti e all’allocazione delle perdite; da lì, all’autorità esercitata nella fase di gestione e monitoraggio, all’esposizione generata dalla verifica del sistema distribuito e agli input accettati nella definizione dei diritti e degli invarianti. Se questa catena si interrompe, un bug nel controllo degli accessi può sembrare una transazione completata, anche quando un chiamante non autorizzato ottiene l’autorità di coniare, prelevare, sospendere o aggiornare. Questa ricostruzione a ritroso mantiene l’analisi concentrata sull’invariante finanziaria promessa e su ogni dipendenza dal codice, dai dati e dalla governance che può modificarla, anziché sull’etichetta del fornitore o sullo stato dell’interfaccia.

Chi controlla i dati fondamentali nel rischio dei contratti intelligenti?

Lo sviluppatore del protocollo e il revisore occupano posizioni diverse nella catena operativa. Lo sviluppatore del protocollo progetta e implementa la logica economica e tecnica, mentre il revisore esamina una versione circoscritta e comunica i risultati. Le rispettive documentazioni — specifiche, codice, test, commit, dipendenze e distribuzione; ambito, metodi, ipotesi, gravità, correzioni e rischio residuo — dovrebbero concordare sullo stesso evento, senza essere copie di un unico database di un fornitore. Gli oracoli o i protocolli esterni, la governance e i titolari delle chiavi, nonché gli utenti o gli integratori, apportano decisioni o prove distinte; considerarne intercambiabili le funzioni nasconde dove entrano in gioco discrezionalità, liquidità o responsabilità legale.

Un’interruzione del servizio che coinvolga la governance e i titolari delle chiavi è una prova concreta di responsabilità nel rischio degli smart contract. Questi soggetti possono modificare i parametri, mettere in pausa il sistema, aggiornarlo o trasferire asset. La domanda è se lo sviluppatore del protocollo e il revisore siano ancora in grado di ricostruire la situazione sulla base dei ruoli, del quorum, del blocco temporale, delle votazioni, della custodia delle chiavi e della cronologia degli eventi. I contratti possono assegnare i compiti, ma la parte responsabile della promessa fatta al cliente, dell’asset o dell’obbligo non può sostituire le prove con una clausola di esternalizzazione. Una progettazione resiliente indica quale documentazione usare come riferimento alternativo e chi è autorizzato a risolvere eventuali discrepanze.

Come cambia concretamente lo stato del rischio degli smart contract

1. Specificare diritti e invarianti: definire lo stato iniziale del rischio degli smart contract

Definire saldi, autorità, limiti e condizioni che devono essere sempre rispettati. In questa fase del rischio degli smart contract, si stabiliscono le condizioni su cui possono fare affidamento l’implementazione e il test. Lo sviluppatore del protocollo ha un ruolo centrale, perché progetta e implementa la logica economica e tecnica. La documentazione di lavoro dovrebbe conservare specifiche, codice, test, commit, dipendenze e distribuzione.

Il problema che non si riesce a individuare in questa fase è un bug nel controllo degli accessi: un chiamante non autorizzato ottiene il potere di creare token, effettuare prelievi, mettere in pausa il sistema o aggiornarlo. Per verificare questa fase, acquisire il risultato usando lo stesso momento, ambito e condizioni applicabili, quindi modificare un’ipotesi prima dell’implementazione e del test. Nel caso del rischio degli smart contract, un passaggio di consegne difendibile specifica chi ha approvato il risultato, quale documentazione è cambiata, che cosa resta reversibile e chi si farà carico della perdita se il partecipante successivo non accetta le prove.

2. Implementare e testare: individuare la regola decisionale nel rischio degli smart contract

Utilizzare componenti sottoposti a revisione e test unitari, di integrazione, basati sulle proprietà e avversariali. In questa fase del rischio degli smart contract, si verificano le condizioni su cui può fare affidamento la revisione del sistema distribuito. Il revisore ha un ruolo centrale, perché esamina una versione circoscritta e comunica i risultati. La documentazione di lavoro dovrebbe conservare ambito, metodi, ipotesi, gravità, correzioni e rischio residuo.

Il problema che non si riesce a individuare in questa fase è uno sfruttamento delle vulnerabilità contabili: arrotondamenti, rientranza, determinazione del prezzo delle quote o ordine degli aggiornamenti dello stato generano valore dal nulla. Per verificare questa fase, ricalcolare il risultato usando lo stesso momento, ambito e condizioni applicabili, quindi modificare un’ipotesi prima della revisione del sistema distribuito. Nel caso del rischio degli smart contract, un passaggio di consegne difendibile specifica chi ha approvato il risultato, quale documentazione è cambiata, che cosa resta reversibile e chi si farà carico della perdita se il partecipante successivo non accetta le prove.

3. Verificare il sistema distribuito: valutare il trasferimento del rischio negli smart contract

Verificare il codice sorgente, il bytecode, i parametri, le dipendenze, le chiavi e i controlli operativi. In questa fase del rischio degli smart contract, si ridefiniscono le condizioni su cui possono fare affidamento l’esercizio e il monitoraggio. Gli oracoli o i protocolli esterni hanno un ruolo centrale, perché forniscono prezzi, messaggi, token o liquidità. La documentazione di lavoro dovrebbe conservare fonti, aggiornamenti, resistenza alla manipolazione, amministratori e incidenti.

Il problema che non si riesce a individuare in questa fase è la manipolazione degli oracoli: un prezzo temporaneo o poco liquido determina prestiti, scambi o liquidazioni. Per verificare questa fase, sottoporre il risultato a prove di stress usando lo stesso momento, ambito e condizioni applicabili, quindi modificare un’ipotesi prima dell’esercizio e del monitoraggio. Nel caso del rischio degli smart contract, un passaggio di consegne difendibile specifica chi ha approvato il risultato, quale documentazione è cambiata, che cosa resta reversibile e chi si farà carico della perdita se il partecipante successivo non accetta le prove.

4. Gestire e monitorare: riconciliare la documentazione ufficiale relativa al rischio degli smart contract

Monitorare il valore, le anomalie, gli oracoli, le azioni privilegiate e le modifiche alle dipendenze. In questa fase del rischio degli smart contract, si riconciliano le condizioni su cui possono fare affidamento la risposta agli incidenti e la governance. La governance e i titolari delle chiavi hanno un ruolo centrale, perché possono modificare i parametri, mettere in pausa il sistema, aggiornarlo o trasferire asset. La documentazione di lavoro dovrebbe conservare ruoli, quorum, blocco temporale, votazioni, custodia delle chiavi e cronologia degli eventi.

Il problema che non si riesce a individuare in questa fase è un guasto di una dipendenza: un token, un bridge, un pool o una blockchain si comporta diversamente da quanto previsto. Per verificare questa fase, confrontare il risultato usando lo stesso momento, ambito e condizioni applicabili, quindi modificare un’ipotesi prima della risposta agli incidenti e della governance. Nel caso del rischio degli smart contract, un passaggio di consegne difendibile specifica chi ha approvato il risultato, quale documentazione è cambiata, che cosa resta reversibile e chi si farà carico della perdita se il partecipante successivo non accetta le prove.

5. Rispondere e governare: verificare l’esito finale del rischio degli smart contract

Sospendere, aggiornare, compensare, migrare o accettare l’immutabilità nell’ambito dell’autorità dichiarata. In questa parte del rischio degli smart contract, il passaggio definisce le condizioni su cui può basarsi l’esito registrato. L’utente o l’integratore ha un ruolo centrale, perché accetta l’esposizione al codice e alle dipendenze. La documentazione di lavoro dovrebbe conservare l’indirizzo, la versione, le autorizzazioni, la simulazione della transazione, i limiti e le modalità di uscita.

Il rischio di non contestare in questa fase è l’abuso della chiave di emergenza: un meccanismo di recupero diventa la via d’attacco o non è disponibile durante una crisi. Per verificare questa fase, dimostra il risultato usando gli stessi tempi, ambito e condizioni applicabili, poi modifica una delle ipotesi prima di registrare l’esito. Nel caso del rischio degli smart contract, un passaggio di consegne difendibile indica chi lo ha approvato, quale documentazione è stata modificata, che cosa resta reversibile e chi si fa carico della perdita se il partecipante successivo rifiuta le prove.

Tre stati spesso confusi nel rischio degli smart contract

Il rischio del codice significa che l’implementazione viola gli invarianti previsti o gestisce in modo errato un caso limite; il rischio degli oracoli e della composizione, invece, si verifica quando il codice locale è corretto ma dipende da un prezzo, un messaggio, il comportamento di un token o uno stato esterno errati. Il rischio di governance e aggiornamento aggiunge una terza condizione: dopo la revisione, gli attori privilegiati possono modificare il comportamento, i parametri o gli asset. Le distinzioni sono importanti perché due utenti possono vedere una conferma simile pur avendo diritti diversi, affrontando tempistiche diverse o dipendendo da istituzioni diverse. Nel rischio degli smart contract, un confronto utile indica, per ciascuno stato, quale documentazione fa fede e chi si fa carico delle perdite.

Confronta il rischio del codice, il rischio degli oracoli e della composizione e il rischio di governance e aggiornamento usando un’unica base di misurazione: importo, tempo, liquidità assorbita, reversibilità, pretesa giuridica e perdita residua. Nel rischio degli smart contract, un’etichetta più rapida non indica automaticamente uno stato più definitivo, così come un rendimento dichiarato più regolare non implica automaticamente un rischio economico minore. Usare un unico criterio di misurazione evita di scambiare le differenze di tempistica o di contabilizzazione per miglioramenti effettivi.

Costi, incentivi ed effetti sul bilancio del rischio degli smart contract

La spesa per la sicurezza dovrebbe essere proporzionata al valore massimo e all’irreversibilità, non al prezzo del token o alla visibilità del marketing. Audit, metodi formali, monitoraggio e programmi di ricompensa per la segnalazione di vulnerabilità sono livelli complementari con coperture diverse.

La componibilità genera valore di rete perché i contratti possono riutilizzare liquidità e servizi. Crea però anche dipendenze correlate: il malfunzionamento di un solo oracolo o token può propagarsi attraverso molti protocolli prima che la governance reagisca.

La possibilità di aggiornare i contratti consente di correggere i difetti e adattarsi, ma gli utenti pagano un premio per il rischio di governance. Blocchi temporali, diversificazione delle firme multiple, ruoli circoscritti, limiti e registri degli eventi trasparenti possono ridurre tale premio senza fingere che gli amministratori non esistano.

Dove si manifesta il rischio degli smart contract e che cosa verificare per prima cosa

• Bug nel controllo degli accessi: un chiamante non autorizzato ottiene i privilegi di conio, prelievo, sospensione o aggiornamento. Interrompere; specificare diritti e invarianti, mentre lo sviluppatore del protocollo mantiene i propri normali obblighi, poi verificare se il rischio del codice conserva il significato descritto sopra.
• Exploit contabile: arrotondamenti, rientranza, determinazione del prezzo delle quote o ordine degli stati creano valore dal nulla. Interrompere; implementare e testare, mentre il revisore mantiene i propri normali obblighi, poi verificare se il rischio degli oracoli e della composizione conserva il significato descritto sopra.
• Manipolazione dell’oracolo: un prezzo temporaneo o illiquido determina prestiti, scambi o liquidazioni. Interrompere; verificare il sistema distribuito, mentre l’oracolo o il protocollo esterno mantiene i propri normali obblighi, poi verificare se il rischio di governance e aggiornamento conserva il significato descritto sopra.
• Guasto di una dipendenza: un token, un bridge, un pool o una blockchain si comporta diversamente da quanto previsto. Interrompi la fase di esercizio e monitoraggio mentre la governance e i titolari delle chiavi continuano a essere soggetti ai loro normali obblighi, quindi verifica se il rischio legato al codice conserva il significato descritto sopra.
• Abuso delle chiavi di emergenza: un meccanismo di ripristino diventa la via d’attacco oppure non è disponibile durante una crisi. Interrompi la fase di risposta e governance mentre l’utente o l’integratore continua a essere soggetto ai suoi normali obblighi, quindi verifica se il rischio legato agli oracoli e alla composizione conserva il significato descritto sopra.

Una prova di stress efficace sul rischio degli smart contract combina una vulnerabilità nel controllo degli accessi con la manipolazione di un oracolo, invece di esaminarle separatamente. Blocca o ritarda la verifica del sistema distribuito, rendi indisponibili la governance e i titolari delle chiavi e chiedi all’utente o all’integratore di ricostruire l’esito a partire dall’indirizzo, dalla versione, dalle autorizzazioni concesse, dalla simulazione della transazione, dai limiti e dalle modalità di uscita. Il progetto supera la prova solo se la fase di risposta e governance conduce a un unico esito comprensibile, tutela i diritti connessi ai rischi legati agli oracoli e alla composizione e stabilisce come ripartire eventuali perdite secondo regole definite prima dell’interruzione.

Esempio pratico: seguire un evento di rischio degli smart contract dall’inizio alla fine

Un contratto di prestito è sottoposto a verifica, ma il prezzo della garanzia proviene da un unico pool con scarsa liquidità. Un aggressore altera temporaneamente il prezzo del pool, prende in prestito più del valore effettivo della garanzia e si ritira prima che l’oracolo corregga il prezzo. Il codice del contratto di prestito ha funzionato esattamente come previsto; il sistema è fallito perché le ipotesi sulla fiducia nell’oracolo e sulla liquidità non erano sicure. Una verifica solida modellerebbe l’intero grafo delle dipendenze e limiterebbe l’esposizione alle garanzie il cui prezzo può essere manipolato.

È possibile confutare l’esempio modificando l’ipotesi definita durante l’implementazione e i test oppure rimuovendo le prove fornite dall’oracolo o dal protocollo esterno. Segui il cambiamento attraverso la verifica del sistema distribuito, l’esercizio e il monitoraggio, quindi la risposta e la governance; non passare direttamente dall’input al risultato principale. Se non è possibile riprodurre il nuovo esito del rischio degli smart contract sulla base della specifica, del codice sorgente e del bytecode distribuiti, dei test e delle verifiche, dei parametri e dei ruoli amministrativi, della mappa degli oracoli e delle dipendenze, degli eventi monitorati, della risposta agli incidenti e dell’allocazione delle perdite, il processo dipende da una valutazione o da una registrazione non documentata.

Perché il rischio degli smart contract è importante oggi

La verifica formale, il monitoraggio continuo, i programmi di ricompensa per la segnalazione di vulnerabilità, l’isolamento modulare e una migliore simulazione nei portafogli digitali stanno aumentando la sicurezza degli smart contract. Al tempo stesso, i proxy aggiornabili e le dipendenze tra blockchain ampliano i rischi di governance. L’informativa più utile indica il codice distribuito, i poteri privilegiati, il percorso seguito dall’oracolo, i limiti di valore e il piano di ripartizione delle perdite, usando un linguaggio che gli utenti possano verificare.

La lezione fondamentale sul rischio degli smart contract è che definire diritti e invarianti e rispondere e governare non sono la stessa cosa. Le decisioni intermedie determinano l’invariante finanziario promesso e tutte le dipendenze dal codice, dai dati e dalla governance che possono modificarlo, mentre lo sviluppatore del protocollo e l’utente o l’integratore possono avere accesso a parti diverse della documentazione. L’automazione è utile quando rende più semplice verificare queste decisioni; è pericolosa quando le riduce a un unico stato che nasconde l’abuso delle chiavi di emergenza.

Le prove a sostegno dell’analisi del rischio degli smart contract

Le principali fonti a sostegno dell’analisi del rischio degli smart contract sono il Quadro per la sicurezza informatica del NIST, il BIS: Rischi per la stabilità finanziaria della DeFi e il Rapporto sulla DeFi del Comitato consultivo tecnologico della CFTC. Considerateli come livelli complementari: regole e definizioni, struttura istituzionale o di mercato e prove operative necessarie per verificare un’affermazione concreta. Nessuna di queste fonti va considerata un sostituto dei documenti sui prodotti, dei rendiconti o delle registrazioni delle transazioni descritti sopra.

Domande da porsi prima di fare affidamento sulle valutazioni del rischio degli smart contract

• Lo sviluppatore del protocollo può dimostrare, prima dell’implementazione e dei test, quali siano la specifica, il codice, i test, i commit, le dipendenze e la distribuzione?
• Quale registrazione fa fede se il revisore e la governance e i titolari delle chiavi non sono d’accordo?
• Chi finanzia o assorbe l’esposizione generata durante la verifica del sistema distribuito?
• In che cosa si distinguono, sul piano giuridico ed economico, i rischi legati agli oracoli e alla composizione dai rischi legati al codice?
• Come farebbe il sistema a rilevare un exploit contabile prima della fase di risposta e governance?
• Che cosa accade se l’oracolo o il protocollo esterno non sono disponibili o se le prove che forniscono non sono aggiornate?
• Un revisore indipendente può ricondurre l’esito alla specifica, al codice sorgente e al bytecode distribuiti, ai test e alle verifiche, ai parametri e ai ruoli amministrativi, alla mappa degli oracoli e delle dipendenze, agli eventi monitorati, alla risposta agli incidenti e all’allocazione delle perdite?

Quando si parla di rischio degli smart contract, sostituite espressioni come «se ne occupa la piattaforma» con account, contratti, date e orari, regole di approvazione ed entità responsabili chiaramente identificati. Una risposta completa dovrebbe consentire a chi effettua la verifica di risalire dalla fase di risposta e governance a quella in cui si definiscono diritti e invarianti, individuare il responsabile di ciascuna registrazione e calcolare chi sostiene le perdite prima che si verifichi un’eccezione.

Il principio fondamentale alla base del rischio degli smart contract

Il rischio degli smart contract si comprende meglio quando l’analisi segue l’invariante finanziario promesso e tutte le dipendenze di codice, dati e governance che possono modificarlo nelle cinque fasi operative, e verifica il risultato confrontandolo con le specifiche, il codice sorgente distribuito e il bytecode, i test e gli audit, i parametri e i ruoli amministrativi, la mappa degli oracoli e delle dipendenze, gli eventi monitorati, la risposta agli incidenti e l’allocazione delle perdite. Il flusso spiega che cosa cambia; la tabella dei partecipanti identifica chi può autorizzare il cambiamento; il confronto tra i tre stati impedisce di confondere affermazioni non comparabili; e la mappa dei guasti mostra dove la fiducia dovrebbe diminuire. Questa combinazione distingue un miglioramento reale dagli attriti o dai rischi trasferiti a un livello meno visibile.

Fonti primarie sul rischio degli smart contract

• Quadro per la sicurezza informatica del NIST
• BIS: rischi per la stabilità finanziaria della DeFi
• Rapporto sulla DeFi del Comitato consultivo per la tecnologia della CFTC