Quando colleghi un wallet a una dApp e confermi uno swap, un deposito o un’operazione di staking, non stai necessariamente inviando ether a un indirizzo come se fosse un normale pagamento. Nella maggior parte dei casi stai inviando una chiamata a uno smart contract: una richiesta codificata che indica quale funzione eseguire e quali dati fornire.
Capire questo meccanismo aiuta a leggere meglio una transazione, a interpretare ciò che mostra un wallet e a riconoscere alcune richieste anomale. Non serve diventare sviluppatori Solidity, ma è utile conoscere la differenza tra indirizzo destinatario, funzione, parametri, dati della chiamata e stato del contratto.
Che cos’è una chiamata a uno smart contract
Una transazione Ethereum contiene alcuni elementi fondamentali: l’indirizzo del mittente, l’indirizzo del destinatario, il valore eventualmente inviato in ether, il limite di gas e un campo di dati. Quando il destinatario è uno smart contract, il campo dati può contenere le istruzioni necessarie per invocare una funzione.
In forma semplificata, una chiamata può essere rappresentata così:
- destinatario: l’indirizzo del contratto;
- value: l’eventuale quantità di ether trasferita insieme alla chiamata;
- calldata: la sequenza di dati che identifica la funzione e i suoi argomenti;
- gas: la risorsa massima che la transazione può consumare;
- firma: la prova che il mittente autorizza l’invio della transazione.
Il contratto riceve la richiesta, interpreta i dati, esegue il proprio bytecode e può modificare lo stato della blockchain. Può, per esempio, aggiornare il saldo interno di un token, registrare un deposito, trasferire asset o emettere eventi visibili agli strumenti di esplorazione.
Il fatto che una chiamata sia diretta a un contratto non significa però che l’operazione sia sicura. Il contratto può contenere errori, avere privilegi amministrativi, interagire con altri contratti o ricevere autorizzazioni che consentono di movimentare token in un secondo momento.
ABI e function selector: come il contratto interpreta i dati
Per invocare correttamente una funzione occorre conoscere la sua interfaccia. Questa descrizione è chiamata ABI, acronimo di Application Binary Interface. L’ABI indica i nomi delle funzioni, il tipo degli argomenti, il loro ordine e il tipo dei valori restituiti.
Una funzione Solidity può essere immaginata, per esempio, in questa forma:
transfer(address destinatario, uint256 quantita)
Il contratto non riceve la stringa leggibile con il nome della funzione. La richiesta viene codificata in esadecimale. Il primo elemento è il function selector, un identificatore di quattro byte derivato dalla firma della funzione, cioè dal nome e dai tipi degli argomenti. Dopo il selector vengono codificati i parametri.
In termini concettuali:
- i primi quattro byte indicano quale funzione si vuole chiamare;
- la parte successiva contiene gli argomenti codificati secondo le regole ABI;
- il contratto interpreta la sequenza e decide quale porzione del bytecode eseguire.
Il selector non è una password e non dimostra che il contratto sia legittimo. È soltanto un identificatore tecnico. Funzioni diverse possono inoltre generare situazioni di ambiguità o collisioni rare a causa della lunghezza limitata del selector: per questo un’interfaccia leggibile e verificata è più utile del solo dato esadecimale.
Che cos’è la calldata
La calldata è il campo dati della transazione. In una chiamata a un contratto contiene normalmente il function selector e gli argomenti ABI-encoded. È un’area di dati temporanea e di sola lettura per l’esecuzione della funzione: il contratto può leggerla, ma non modificarla come farebbe con una variabile di stato.
Gli argomenti semplici, come numeri interi, indirizzi e valori booleani, vengono codificati in parole di lunghezza standard. Gli argomenti dinamici, come stringhe, array e bytes di lunghezza variabile, richiedono invece offset e aree dati aggiuntive. Questo spiega perché una chiamata apparentemente semplice può contenere una lunga sequenza esadecimale.
Un esempio pratico è una funzione di swap. La calldata potrebbe includere:
- l’identificatore della funzione di scambio;
- l’indirizzo del token da vendere;
- l’indirizzo del token da ricevere;
- la quantità minima accettabile in uscita;
- un destinatario;
- una scadenza o altri parametri di controllo.
Il significato preciso dipende dall’ABI del contratto. La stessa sequenza di byte non dovrebbe essere interpretata senza sapere a quale contratto è stata inviata e quale interfaccia utilizza.
Storage, memory e calldata: dove finiscono i dati
Durante l’esecuzione, Ethereum distingue diverse aree di dati. La differenza principale riguarda durata, costo e possibilità di modifica.
- Storage: è lo spazio permanente dello smart contract. Qui possono essere conservati saldi, proprietà, configurazioni e altre variabili che devono rimanere disponibili dopo la fine della transazione. Modificare lo storage richiede risorse e può incidere sensibilmente sul gas.
- Memory: è uno spazio temporaneo utilizzato durante l’esecuzione. Viene impiegato per elaborare dati intermedi e non conserva il proprio contenuto dopo la conclusione della chiamata.
- Calldata: contiene i dati ricevuti dall’esterno. È temporanea e normalmente viene letta senza essere copiata in altre aree, quando la logica del contratto lo consente.
Questa distinzione è importante perché un parametro inserito in una transazione non diventa automaticamente una registrazione permanente sulla blockchain. Diventa parte dello storico della transazione, ma viene salvato nello stato permanente solo se il contratto decide di utilizzarlo per aggiornare il proprio storage.
Per esempio, inviare un importo a una funzione di deposito può modificare il saldo interno del contratto. Inviare lo stesso importo a una funzione che non lo gestisce correttamente può invece causare un errore o produrre un risultato diverso da quello atteso.
Chiamate di lettura e transazioni che modificano lo stato
Non tutte le interazioni con un contratto richiedono una transazione firmata. Le funzioni che leggono dati senza modificarli possono essere eseguite come call tramite un nodo Ethereum. In questo caso non viene pubblicata una transazione, non si paga una commissione on-chain e non si modifica lo stato.
Un wallet o un’applicazione può usare una chiamata di lettura per verificare il saldo di un token, controllare una quota o recuperare una configurazione. Anche se il nodo simula l’esecuzione e può calcolare un risultato, la lettura non equivale a un aggiornamento della blockchain.
Una funzione che modifica lo stato richiede invece una transazione firmata. Deve essere inclusa in un blocco e può consumare gas. Se l’esecuzione termina con un revert, lo stato viene normalmente riportato alla situazione precedente, ma il gas utilizzato per tentare l’esecuzione non viene necessariamente recuperato.
Questa differenza spiega perché una dApp può mostrare prima una simulazione e poi chiedere una firma: la simulazione serve a stimare il possibile esito, mentre la transazione reale deve essere autorizzata dal wallet e registrata dalla rete. Una simulazione non elimina tutti i rischi, perché lo stato del contratto può cambiare prima dell’inclusione nel blocco.
Il ruolo del valore inviato e dei token
Ether e token ERC-20 non vengono trasferiti nello stesso modo. Quando una transazione include un valore nativo, il campo value indica quanti ether vengono inviati al destinatario. Un contratto deve essere progettato per ricevere e gestire quel valore.
Un token ERC-20, invece, è normalmente registrato nello storage del proprio smart contract. Il trasferimento modifica le registrazioni dei saldi nel contratto del token. Se una dApp deve spendere token per conto dell’utente, può essere necessaria un’autorizzazione preventiva, come un’allowance. L’autorizzazione e il successivo trasferimento sono operazioni distinte, anche se l’interfaccia della dApp può presentarle come parti di un unico flusso.
Per questo bisogna distinguere sempre:
- l’asset che si sta inviando;
- il contratto a cui è diretta la transazione;
- la funzione invocata;
- le autorizzazioni già concesse ad altri contratti;
- il destinatario finale previsto dalla logica dell’operazione.
Come leggere una chiamata su un block explorer
Un block explorer può mostrare la funzione decodificata se conosce l’ABI del contratto. In alternativa può visualizzare soltanto input data esadecimali. Le sezioni più utili da controllare sono:
- To: l’indirizzo che riceve la transazione; può essere un contratto oppure un normale account;
- Input data: la calldata inviata;
- method: il nome della funzione, quando la decodifica è disponibile;
- parameters: gli argomenti interpretati dall’ABI;
- logs ed eventi: le registrazioni emesse durante l’esecuzione;
- status: indica se l’esecuzione è terminata correttamente oppure con revert.
La decodifica automatica è utile, ma non deve essere considerata una garanzia. Occorre verificare che il contratto visualizzato sia quello corretto, che l’indirizzo appartenga alla rete utilizzata e che i parametri abbiano senso per l’operazione. Un sito può mostrare un nome familiare per un contratto diverso, oppure un’interfaccia può nascondere dettagli importanti della chiamata.
Errori e rischi da evitare
Uno degli errori più comuni è guardare soltanto l’importo mostrato dal wallet. Una richiesta può avere valore zero in ether e contenere comunque una funzione capace di modificare autorizzazioni o trasferire token già approvati.
È rischioso anche confondere il contratto chiamato con il destinatario economico dell’operazione. In un protocollo complesso, il contratto principale può inoltrare la richiesta ad altri contratti tramite chiamate interne. La presenza di un indirizzo noto nell’interfaccia non è sufficiente per capire tutto il percorso dei fondi.
Prima di firmare una transazione è prudente controllare la rete, l’indirizzo del contratto, il tipo di azione richiesta, gli asset coinvolti e l’eventuale modifica di allowance o autorizzazioni. Bisogna inoltre prestare attenzione a richieste di firma che non mostrano chiaramente la funzione, a contratti non verificati e a dApp raggiunte tramite link inattesi.
Un revert non significa necessariamente che i fondi siano stati trasferiti altrove: spesso indica che la condizione richiesta dal contratto non è stata soddisfatta. Tuttavia la transazione può aver eseguito chiamate precedenti prima del revert solo se la logica e il contesto lo consentono? In Ethereum, un revert dell’intera chiamata propagato correttamente annulla gli aggiornamenti di stato della transazione, ma i costi di esecuzione già sostenuti restano una possibilità concreta. Le regole dipendono dalla struttura delle chiamate e dalla gestione degli errori del contratto.
Perché conoscere la calldata è utile
La calldata è il ponte tra l’interfaccia di una dApp e il codice eseguito sulla blockchain. Comprenderne la struttura permette di andare oltre pulsanti come “Conferma” o “Approva” e di verificare che la richiesta tecnica corrisponda all’azione desiderata.
Non è necessario decodificare manualmente ogni campo esadecimale. È più importante sapere che una transazione non è definita soltanto da importo e indirizzo, ma anche dalla funzione invocata, dai parametri, dalle autorizzazioni e dalle modifiche di stato che il contratto può effettuare. Questa consapevolezza rende più leggibili wallet, block explorer e avvisi di sicurezza, senza trasformare una decodifica automatica in una garanzia di affidabilità.
