Il paradosso sulla sicurezza degli smart contract nell'era dell'AI

Il paradosso

Uno smart contract, per essere tale nel senso forte — autonomo, decentralizzato, resistente alla censura, senza accessi privilegiati — deve essere immutabile. Per essere sicuro deve poter essere corretto. I due requisiti sono in tensione.

Nessun sistema software non banale è sicuro al 100%. Non lo è il kernel Linux, non lo è OpenBSD nonostante decenni di reputazione granitica, non lo è alcun contratto Solidity per quanto auditato. La sicurezza assoluta è un asintoto.

Una formulazione utile è la seguente:

Un qualunque componente software, dato un tempo sufficientemente lungo, presenterà un bug — in modo diretto, manifestandosi come malfunzionamento, oppure in modo indiretto, emergendo da un'ispezione del codice.

È una formulazione più forte del consueto "no software is bug-free" perché aggiunge la dimensione temporale e il doppio canale di emersione. Un bug che non si è mai manifestato come malfunzionamento — e che magari non si manifesterà mai durante la vita del sistema — diventa comunque un problema nel momento in cui un'ispezione lo rivela. Il rischio non dorme finché non viene guardato. Più cresce la complessità, più si accorcia il tempo perché uno dei due canali si attivi.

Nel software tradizionale la non-perfezione è gestibile: si patcha. Nello smart contract veramente autonomo quel canale non può esistere per costruzione. Qualsiasi architettura di upgrade — proxy pattern, admin keys, governance multisig, timelock — introduce un punto di accesso privilegiato. E un punto di accesso privilegiato è l'opposto della decentralizzazione promessa.

Da qui il dilemma:

• •Immutabile: davvero decentralizzato, ma l'unica quasi-garanzia di assenza di bug è la banalità del codice.
• •Aggiornabile: più sicuro nel lungo periodo, ma reintroduce una superficie di trust centralizzata che svuota il termine "smart contract".

Le terze vie pure non esistono. Esistono punti intermedi sull'asse del compromesso, mascherati da soluzioni eleganti: governance on-chain, timelock, multisig fra fondazioni "indipendenti". Sono mitigazioni, non risoluzioni.

L'asimmetria

Una vulnerabilità latente e una vulnerabilità nota sono lo stesso bug, ma due rischi diversi. Per anni un componente può funzionare in produzione senza anomalie. Il giorno dopo la disclosure, lo stesso codice — invariato — diventa inaccettabile. Non perché sia cambiato, ma perché è cambiato ciò che si sa su di esso.

L'epistemologia precede la patch. On-chain, dove la patch spesso non è un'opzione, questa asimmetria pesa più che altrove.

Perché ora

Per molto tempo si è convissuto con il paradosso. Il secondo canale — l'ispezione — era manuale, lento, bottlenecked sull'expertise di pochi. Il primo (il malfunzionamento) era statisticamente raro per contratti ben fatti. Si poteva sperare di sopravvivere senza sorprese.

Quell'epoca sta finendo. I frontier model trovano autonomamente bug rimasti latenti per decenni. Il caso più citato è Claude Mythos, in programma con un gruppo di partner selezionati (AWS, Apple, Google, Microsoft, Linux Foundation, altri): in poche settimane, migliaia di zero-day, molte critiche, in OS, browser e componenti fondamentali.

Tra i risultati documentati: 27 anni in OpenBSD, 16 in FFmpeg, una RCE 17-anni in FreeBSD/NFS (CVE-2026-4747) sfruttabile da attaccante non autenticato. Mozilla ha rilasciato Firefox 150 con 271 fix.

E non è solo il modello frontier: ricerche indipendenti mostrano otto modelli su otto capaci di rilevare l'exploit di punta su FreeBSD, incluso uno con 3,6B parametri attivi. Il genio è uscito dalla lampada.

Mythos non crea le vulnerabilità: accelera il secondo canale, comprimendo in settimane ciò che richiedeva anni.

Cosa cambia on-chain

Quando uno strumento legge un codebase, ragiona sulle invarianti, costruisce exploit funzionanti, la probabilità che una vulnerabilità latente diventi nota nell'arco di vita del contratto si avvicina a uno. Da quel momento il contratto immutabile è inaffidabile, anche se non è mai stato sfruttato.

Punto spesso sottovalutato: un contratto immutabile vulnerabile non si aggiorna. Si abbandona. Fork, migrazione della liquidità, deprecazione. E — paradosso nel paradosso — la migrazione richiede un coordinamento centralizzato che il sistema in teoria voleva evitare.

Per i contratti aggiornabili non va meglio: significa usare in fretta il meccanismo di upgrade che già rappresentava il compromesso, sotto pressione, con asset reali in gioco.

Cosa cambia per chi progetta

Gli smart contract non sono una cattiva idea. Meritano però un realismo che il marketing raramente concede: decentralizzazione totale e sicurezza nel lungo periodo sono obiettivi parzialmente incompatibili, e ogni progetto serio dovrebbe esplicitare dove si colloca sul compromesso.

Per chi lavora in compliance, advisory, o disegna sistemi:

• •L'immutabilità non è una virtù assoluta. È una scelta che porta con sé un debito tecnico permanente.
• •Le strategie di deprecazione e migrazione vanno nel disegno iniziale: non è un "se", è un "quando".
• •Il calendario delle patch on-chain si sta comprimendo per ragioni strutturali. La governance va adeguata di conseguenza.
• •Agli stakeholder va dichiarato il punto di equilibrio scelto, anziché nasconderlo dietro etichette.

Il software cattivo di ieri era cattivo anche prima dei modelli capaci di trovarne i bug. Solo che non lo si sapeva. On-chain, dove la patch non è un'opzione, la differenza tra "non si sapeva" e "si sa" è la differenza tra un sistema che vale qualcosa e un sistema da spegnere.

È il momento di smettere di vendere decentralizzazione totale e sicurezza assoluta come se fossero gratuite entrambe.