Vitalik Buterin afferma che l'hacking guidato dall'AI non condannerà la cybersecurity, puntando alla verifica formale
Punti chiave
- •Vitalik Buterin ha proposto la verifica formale—la dimostrazione matematica che il software soddisfa requisiti di sicurezza definiti—come risposta all'hacking guidato dall'AI, invece di affidarsi alla scoperta delle vulnerabilità.
- •In un post sul blog del 18 maggio condiviso su X, ha sostenuto che l'AI potrebbe rendere pratica su larga scala la verifica dell'intero programma, estendendo la copertura a database, rete e livelli di caching.
- •Ha affermato che la sicurezza deve essere definita con precisione prima di poter essere dimostrata, con definizioni che potrebbero superare 1.000 righe di codice per coprire questioni come la falsificazione dei messaggi, i messaggi riprodotti e le chiavi trapelate.
- •La verifica formale è storicamente stata confinata a campi critici per la sicurezza come l'aviazione e il software medico, perché lo sforzo richiesto l'ha mantenuta rara nello sviluppo generico.
- •Buterin ha collegato l'approccio alla roadmap di Ethereum, identificando i protocolli a scambio di messaggi, le sandbox, gli SNARK e la crittografia completamente oomorfica come aree che necessitano di garanzie più solide nel lavoro su scalabilità e privacy.

Il co-fondatore di Ethereum Vitalik Buterin afferma che l'ascesa dell'hacking guidato dall'AI non rende la cybersecurity una battaglia impossibile da vincere, puntando invece alla verifica formale come modo per dimostrare la sicurezza del software. Piuttosto che dipendere dalla scoperta delle vulnerabilità, sostiene, gli sviluppatori possono dimostrare matematicamente che i programmi soddisfano requisiti di sicurezza definiti.
In un post sul blog del 18 maggio, che ha condiviso su X, Buterin ha sostenuto che l'AI potrebbe rendere tale verifica pratica su larga scala, un approccio che, secondo lui, è più rilevante per i sistemi critici, inclusi la crittografia, i protocolli di messaggistica e il software blockchain.
La sicurezza deve essere definita prima di poter essere dimostrata
Buterin ha detto che dimostrare la sicurezza di un programma richiede innanzitutto di definire cosa significhi effettivamente sicurezza. Ha citato come esempio l'app di messaggistica crittografata Signal, osservando che la sola crittografia non copre ogni problema di sicurezza. Una definizione completa potrebbe dover tenere conto della falsificazione dei messaggi, dei fallimenti di consegna, dei messaggi riprodotti, dei dispositivi compromessi e delle chiavi trapelate.
L'hardware aggiunge ulteriori complicazioni. I segnali fisici possono far trapelare informazioni, mentre dettagli come le dimensioni dei messaggi, l'identità del mittente e la tempistica possono essere rivelatori di per sé. Insieme, queste considerazioni possono spingere le definizioni di sicurezza oltre 1.000 righe di codice. Ciò nonostante, Buterin ha sostenuto che le definizioni rimangono un bersaglio più ristretto per la verifica rispetto all'implementazione sottostante.
La verifica formale mira all'intero programma
La verifica formale non è un'idea nuova: è da tempo applicata in campi critici per la sicurezza come l'aviazione e il software medico, dove il costo di un fallimento è elevato, ma lo sforzo richiesto l'ha mantenuta rara nello sviluppo generico. Storicamente, gli sviluppatori hanno verificato solo le sezioni che essi stessi avevano identificato come critiche per la sicurezza, principalmente perché la verifica richiedeva uno sforzo considerevole. Buterin ha sostenuto che l'AI potrebbe cambiare questa equazione, rendendo la verifica dell'intero programma più pratica ed estendendo la copertura a database, rete, livelli di caching e altri componenti.
Ha presentato l'obiettivo come distinto dal modello tradizionale in cui i difensori gareggiano per scoprire le vulnerabilità prima degli attaccanti. Secondo il suo approccio, il software diventa più resiliente dimstrando che soddisfa i requisiti di sicurezza. Le definizioni possono anche essere combinate quando gruppi diversi stabiliscono requisiti separati, ha detto, e laddove due definizioni non possano coesistere, gli sviluppatori possono isolare il conflitto di design sottostante. Ha tuttavia riconosciuto che alcune interfacce utente restano più difficili da gestire.
Complesse esigenze di verifica per il software di Ethereum
Buterin ha identificato i protocolli a scambio di messaggi, le sandbox, gli SNARK — dimostrazioni crittografiche compatte che un calcolo è stato eseguito correttamente — e la crittografia completamente oomorfica, che consente di eseguire calcoli direttamente sui dati crittografati, come aree in cui la distinzione tra definizioni e implementazioni può essere rilevante. Ha collegato l'approccio direttamente alla direzione di sviluppo di Ethereum, affermando che le blockchain necessitano di una sicurezza software più solida, in particolare nei sistemi che perseguono scalabilità e privacy.
Il contesto sottolinea ciò che è in gioco: il software blockchain è open-source e le reti che supporta detengono direttamente gli asset, quindi lo stesso codice è in piena vista sia degli attaccanti che dei difensori — condizioni in cui le garanzie che non dipendono da chi trova prima una vulnerabilità assumono un peso particolare.
Il suo argomento si concentra sulla verifica matematica piuttosto che sulla sola scoperta delle vulnerabilità. La verifica, ha detto, deve estendersi oltre le sezioni di codice selezionate: la definizione richiede un lavoro accurato, mentre l'implementazione rimane soggetta a controllo formale. L'AI, a suo avviso, potrebbe sostenere la scala di quel processo, coprendo database, rete, caching e altri componenti. La domanda da seguire è se gli strumenti assistiti dall'AI possano portare la verifica dell'intero programma nella pratica ordinaria su scala di produzione, incluse le interfacce utente che ha indicato come i casi più difficili.