Lo sforzo di Solana per modernizzare la verifica delle firme delle transazioni ha incontrato un intoppo inaspettato, giunto da una fonte insolita: un agente di ricerca AI autonomo attivo sotto l'alias @hackhackai sulla blockchain Solana. L'agente ha identificato una potenziale vulnerabilità in SIMD-0376, la proposta pensata per riformare il modo in cui la rete gestisce la verifica delle firme delle transazioni.

Secondo le rilevazioni dell'agente, la vulnerabilità—se non affrontata—potrebbe consentire la firma all'indirizzo zero, uno scenario che dovrebbe essere impossibile con le regole attuali, mettendo a rischio 433 account di metadati.

Cosa propone SIMD-0376

Solana attualmente verifica le firme Ed25519 utilizzando la libreria ed25519-dalek. SIMD-0376 la sostituirebbe con lo standard di verifica EdDSA cofattorizzato ZIP-215, un'implementazione diversa della stessa curva crittografica sottostante—uno standard nato come proposal di miglioramento di Zcash.

La verifica delle firme viene eseguita su ogni transazione elaborata dalla rete, ed è per questo che i guadagni di efficienza a questo livello si moltiplicano sull'intero throughput di Solana. Il vantaggio pratico del passaggio è concreto: la proposta mira ad abilitare l'elaborazione batch delle firme, che potrebbe ridurre di circa il 40% i costi computazionali dei validatori quando gestiscono grandi volumi di firme.

David Rubin di Syndica ha presentato la proposta il 6 ottobre 2025. Dopo successive rifiniture, è stata approvata nel repository dei Solana Improvement Documents il 28 gennaio 2026.

Il problema dell'indirizzo zero

La vulnerabilità riguarda uno specifico caso limite introdotto dallo standard ZIP-215: la possibilità di firmare con, o per, l'indirizzo zero. Secondo le normali regole Ed25519, una firma del genere verrebbe respinta senza appello. Con la logica di verifica più permissiva di ZIP-215, potrebbe non esserlo.

L'indirizzo zero non è un caso limite qualunque. Funziona come identità null—un indirizzo composto da soli zero per il quale in pratica non esiste alcuna chiave privata—ed è per questo che le regole attuali considerano nulla in partenza qualsiasi firma ad esso relativa, e perché una firma verificabile all'indirizzo zero minerebbe un'assunzione di base dei sistemi basati su account come quello di Solanan
Questa permissività è intenzionale. ZIP-215 è stato progettato per accettare una gamma più ampia di rappresentazioni valide delle firme, il che rende più semplice l'elaborazione batch. Il compromesso è che rilassa anche alcuni controlli ai limiti che in precedenza fungevano da barriere di sicurezza implicite.

Il risultato, secondo le rilevazioni di @hackhackai, è che 433 account di metadati collegati all'ecosistema Solana potrebbero essere esposti a operazioni di firma che non dovrebbero mai essere possibili. Hackhackai si descrive come un agente di ricerca focalizzato sull'AI, creato specificamente per isolare vulnerabilità nei protocolli Solana.

Perché il tempismo conta

La proposta è stata presentata a ottobre 2025 e approvata a gennaio 2026, eppure la vulnerabilità dell'indirizzo zero è emersa senza una copertura significativa da parte delle principali testate di crypto nei mesi successivi. Questo vuoto è anche uno scorcio di come si svolge oggi la ricerca sui protocolli: un agente autonomo attivo on-chain può portare alla luce un problema a livello di proposta molto prima della copertura mainstream o delle risposte ufficiali.

Gli account di metadati segnalati nelle rilevazioni non sono wallet generici di utenti. Nell'architettura di Solana, gli account di metadati in genere archiviano dati a livello di programma, configurazioni di token o attributi NFT. Nello scenario peggiore, un'anomalia di firma che coinvolga questi account potrebbe consentire modifiche non autorizzate allo stato dei programmi o ai record di proprietà degli asset, a seconda di come i singoli programmi gestiscono le istruzioni firmate in arrivo.

Per gli sviluppatori che costruiscono su Solana—in particolare quelli i cui programmi interagiscono con gli account di metadati—la domanda pratica è se la loro logica di validazione delle istruzioni presuppone l'attuale comportamento di rigetto di Ed25519 o se verifica esplicitamente gli input con indirizzo zero. I programmi scritti prima che SIMD-0376 fosse proposto non avrebbero motivo di includere quest'ultima verifica, poiché non è mai stata necessaria.

Al momento della stesura, né gli autori della proposta né la Solana Foundation hanno commentato pubblicamente la vulnerabilità. Qualsiasi revisione al testo SIMD, una risposta formale dai suoi autori o dagli ingegneri core di Solana, o nuove linee guida per i programmi che interagiscono con gli account di metadati sarebbero i prossimi segnali concreti su come verrà risolto questo compromesso tra efficienza batch e verifica rigorosa.