Simulazione delle transazioni: che cosa farà una transazione prima che tu la firmi

L'indirizzo è giusto. L'importo è giusto. Hai controllato entrambi. E la transazione continua a non essere quella che credi.

Non è un'ipotesi. È la forma ordinaria di quasi tutte le perdite in cripto che coinvolgono una persona attenta. Nessuno l'ha convinta a mandare denaro a uno sconosciuto. Ha approvato qualcosa le cui parti visibili erano tutte corrette e le cui conseguenze stavano interamente altrove: in un'autorizzazione di spesa su un token, in una chiamata a un contratto, in un carattere di un indirizzo visto cento volte.

La simulazione è il tentativo di colmare quel divario: mostrarti gli effetti di una transazione anziché il suo contenuto, prima che la tua firma la renda reale.

Il divario fra ciò che intendevi e ciò che stai firmando

Una transazione non è una frase. Sono byte.

Quando quei byte sono un semplice trasferimento, il divario fra ciò che dicono e ciò che fanno è piccolo: un indirizzo, un importo, una commissione. Quando sono una chiamata a un contratto, il divario può essere enorme. approve sembra un permesso. È un diritto permanente concesso a un altro indirizzo di muovere i tuoi token, e secondo lo standard ERC-20 nulla nella chiamata impone di limitarne l'entità o la durata. Una sola autorizzazione, firmata una volta, può essere svuotata mesi dopo.

L'interfaccia che stai guardando quando firmi deve tradurre quei byte in una frase. Quella traduzione è la superficie d'attacco. Se la produce chi vuole la tua firma, può dire qualunque cosa.

Una prova generale, non una promessa

Simulare significa eseguire la transazione contro lo stato attuale della catena senza trasmetterla, e registrare che cosa cambia.

In SSP Enterprise questo accade alla creazione di una proposta, prima che qualcuno firmi. La simulazione è costruita a partire da ciò che ha prodotto il builder della proposta — destinatari, importi, contratto del token e calldata che SSP stessa ha assemblato — mai da hex firmato grezzo consegnato da un client. Gira in sola lettura. Tre motori coprono le diverse famiglie di catene:

• Le catene EVM eseguono una chiamata in sola lettura contro un nodo e rileggono le variazioni di saldo risultanti e la chiamata decodificata.
• Le catene UTXO non hanno bisogno di alcun nodo. Ingressi e uscite sono già noti, quindi il prima-e-dopo è aritmetica sulle monete selezionate, e i destinatari vengono classificati come resto che torna a te o davvero esterni.
• Solana deserializza la transazione non firmata prodotta dal builder ed esegue il simulateTransaction della rete stessa, con la verifica delle firme disattivata, poi legge dal risultato i saldi in token del vault prima e dopo.

Ciò che torna è un'anteprima: quale era il saldo di ciascun asset prima, quale sarà dopo e — su EVM — che cosa sia davvero la chiamata, decodificata in un metodo e nei suoi argomenti.

Due cose che non è. Non è una garanzia: lo stato della catena si muove, e una simulazione eseguita al momento della proposta è una fotografia della catena com'era allora. E non è un blocco. Che è la metà più interessante del progetto, e ci torneremo.

Quattordici cose che vale la pena farti sapere

Un'anteprima che mostra solo numeri ti chiede comunque di individuare tu il problema. Perciò l'anteprima è accompagnata da avvisi, e ne esistono quattordici, su quattro livelli di gravità.

Autorizzazioni — la categoria che svuota il maggior numero di wallet. Un'autorizzazione illimitata o non delimitata è critica. Qualsiasi autorizzazione di spesa diversa da zero verso un indirizzo che non è nella tua lista di consentiti è alta. E autorizzare un account posseduto da una persona anziché un contratto è alta, perché non esiste praticamente alcuna ragione legittima per farlo: sono i contratti a spendere le autorizzazioni, non le persone.

Destinatari — viene segnalato un destinatario che non figura né nei contatti della tua organizzazione né nella whitelist del vault. Così come uno a cui il tuo vault non ha mai inviato prima. Nessuna delle due cose è sbagliata di per sé. Entrambe meritano una seconda lettura.

Rischio di contratto — un contratto di destinazione il cui sorgente non è verificato, uno distribuito negli ultimi sette giorni, valore nativo inviato a un contratto in generale, e qualsiasi indirizzo che un fornitore segnali come apertamente malevolo.

Esecuzione — la transazione che fallisce in simulazione, il che significa che fallirà on-chain sprecando la commissione. Oppure l'uscita simulata che non corrisponde agli importi dichiarati dalla proposta: il vault perde più, o meno, di quanto dice lo schermo.

Degrado — e, chiaramente etichettato, il caso in cui la simulazione non ha potuto girare. Un nodo irraggiungibile produce «non disponibile», non silenzio né un certificato di buona salute inventato.

La distinzione fra quelle gravità conta più del conteggio. Critica e alta parlano di una transazione che probabilmente non è ciò che sembra. Media e informativa parlano di una transazione insolita, cosa che le transazioni legittime ogni tanto sono.

Address poisoning: l'attacco che batte le persone attente

Un avviso merita una sezione a sé, perché prende di mira proprio l'abitudine che quasi tutti i consigli di sicurezza raccomandano.

L'address poisoning funziona così. Un attaccante manda al tuo vault una transazione minuscola o di valore nullo da un indirizzo costruito apposta per condividere i primi sei e gli ultimi quattro caratteri di un indirizzo con cui già operi. Non viene rubato nulla. Non viene nemmeno davvero fatto nulla. La transazione esiste perché l'indirizzo sosia compaia nella tua cronologia.

Più tardi — giorni dopo, quando paghi di nuovo la stessa controparte — copi l'indirizzo dalla tua cronologia delle transazioni, come fanno le persone attente invece di riscriverlo. Lo controlli come controllano le persone attente: i primi caratteri, gli ultimi caratteri. Entrambi coincidono. Il mezzo no, e il mezzo è dove va il denaro.

SSP confronta ogni destinatario di una proposta con gli indirizzi che il tuo vault già conosce, usando esattamente il confronto fra prefisso e suffisso che compie l'occhio umano, e solleva un avviso critico che nomina l'indirizzo imitato. Lo stesso controllo gira nella direzione opposta sulla cronologia in entrata, così un indirizzo avvelenato viene marcato quando arriva e non solo quando stai per usarlo.

Il motivo per conoscere questo attacco anche se non userai mai SSP: l'abitudine di verifica che ferma ogni altro attacco sugli indirizzi è proprio quella che questo attacco è costruito per sconfiggere. Confronta indirizzi interi, o non confrontare nulla.

Perché gli avvisi si calcolano sul server — e comunque non bloccano nulla

L'insieme degli avvisi è deciso lato server, usando i contatti della tua organizzazione e la whitelist del vault come fonte di verità. È deliberato: se fosse un client a decidere che cosa conta come consentito, un client compromesso potrebbe decidere in silenzio che lo è tutto.

Eppure nulla di ciò può fermare una transazione. La simulazione non condiziona mai la firma né la trasmissione. Un fornitore che va in errore, va in timeout o non raggiunge un nodo restituisce «non disponibile», e la proposta resta pienamente firmabile. L'intero sottosistema è isolato dai guasti perché un crash nell'anteprima non possa mai lasciare una proposta incagliata.

Suonerà come una scelta strana, quindi conviene enunciare il ragionamento con chiarezza. Un'anteprima che può bloccare è un'anteprima che può essere fatta bloccare: abbattendo un nodo, producendo un falso critico, in una qualsiasi delle mille maniere in cui il software va storto. Fondi che non possono muoversi perché un servizio consultivo è malandato sono fondi che hai in parte perso. È la soglia del multisig a proteggere il denaro; la simulazione sta lì per informare gli esseri umani che tengono le chiavi. Che cosa ferma davvero una transazione è la versione lunga di questo argomento.

Quando il server e il tuo dispositivo non concordano

Tutto quanto sopra è la lettura del server. Il tuo dispositivo fa la sua.

Quando SSP Wallet ti mostra una proposta da firmare, decodifica i byte per conto proprio e mostra ciò che lui ha trovato, non il riepilogo del server. Poi confronta i due. Se la chiamata decodificata dal server implica un insieme di destinatari diverso da quello che il dispositivo ha derivato, il dispositivo solleva un proprio avviso critico di discordanza e retrocede visivamente l'anteprima del server.

La decodifica del dispositivo è quella che fa fede. Il controllo è deliberatamente conservativo: una simulazione del server assente o in attesa è un degrado, non una contraddizione, e non viene segnalata come tale. Inoltre si applica solo alle catene EVM, dove il server produce una chiamata decodificata; sulle catene UTXO non c'è nulla con cui confrontarsi, e la decodifica propria del dispositivo semplicemente regge da sola.

Questa è la proprietà da portarsi via, qualunque wallet tu usi. Un secondo parere vale qualcosa solo se viene da un luogo che non poteva essere compromesso dallo stesso atto che ha compromesso il primo. Due riepiloghi dallo stesso server sono un riepilogo solo.

Leggere una striscia di rischio senza imparare a ignorarla

Gli avvisi funzionano finché non diventano carta da parati. Poche abitudini li mantengono utili.

Leggi prima la gravità, poi il dettaglio. Critica e alta meritano di fermarsi. Un avviso medio o informativo su un primo pagamento a un nuovo fornitore è il sistema che funziona correttamente, non un motivo di allarme.

Tratta qualsiasi avviso di autorizzazione come uno stop totale. I trasferimenti muovono ciò che dicono di muovere. Le autorizzazioni concedono un diritto che sopravvive alla transazione. Se non intendevi concedere un permesso permanente, la risposta è no.

Credi al dispositivo più che allo schermo. Se i due discordano, il telefono che hai in mano è quello che gira su hardware che un attaccante avrebbe dovuto compromettere separatamente.

Non leggere «non disponibile» come «va tutto bene». Significa che nessuno ha controllato. È un motivo per guardare tu con più attenzione, specialmente su un pagamento grande o insolito.

Tutto qui riguarda l'istante prima di una firma. Per ciò che accade dopo — chi può firmare, quanti ne servono e quali operazioni richiedono di nuovo entrambi i dispositivi — parti da configurare il tuo primo vault aziendale e le azioni critiche e la rifirma. E per gli schemi d'attacco attorno ai quali questi avvisi sono modellati, gli attacchi di phishing rivolti agli utenti cripto coprono la metà umana del problema.