Quando un’operazione Ethereum interagisce con uno smart contract, la schermata principale di Etherscan può non raccontare tutta la storia. Una singola transazione visibile nella blockchain può infatti attivare una serie di chiamate interne: trasferimenti di ETH, esecuzioni tra contratti, rimborsi, pagamenti a un destinatario o creazione di un nuovo contratto.
Etherscan mostra spesso queste operazioni nella sezione Internal Txns della pagina di un indirizzo o nella scheda di una transazione. Il nome può creare confusione: non si tratta di transazioni indipendenti inviate direttamente da un wallet e non hanno un proprio hash di transazione sulla blockchain. Sono piuttosto chiamate e trasferimenti generati durante l’esecuzione della transazione principale.
Capire questa distinzione è utile quando un saldo cambia senza che il trasferimento sia evidente nella cronologia standard, quando si riceve ETH da un protocollo, quando si interagisce con un bridge o quando si vuole ricostruire con maggiore precisione ciò che è accaduto dentro uno smart contract.
Che cosa sono davvero le transazioni interne
Una transazione Ethereum tradizionale è un’operazione firmata e trasmessa alla rete. Contiene, tra gli altri elementi, un mittente, un destinatario, un eventuale valore in ETH, dati di chiamata, nonce e parametri relativi al gas. Viene inclusa in un blocco e identificata da un transaction hash.
Durante la sua esecuzione, il destinatario può essere uno smart contract. Il contratto, a sua volta, può chiamare altri contratti o inviare ETH a uno o più indirizzi. Queste operazioni successive sono chiamate comunemente internal transactions, ma il termine più preciso è spesso internal calls o traces.
La chiamata interna non viene firmata separatamente da un utente, non ha un nonce indipendente e non occupa una propria posizione nella mempool. È parte dell’esecuzione della transazione principale. Per questo motivo, per collegarla alla blockchain bisogna partire dal transaction hash della transazione esterna che l’ha generata.
Un esempio semplice è il prelievo da un contratto. Il wallet invia una transazione al contratto di un protocollo. La transazione principale può avere come destinatario il contratto e come valore zero, ma durante l’esecuzione il contratto trasferisce ETH al wallet. Quel trasferimento può comparire tra le transazioni interne, anche se non esiste una seconda transazione firmata dal contratto nel senso tradizionale.
Dove trovare le Internal Txns su Etherscan
Il punto di partenza può essere la pagina di un indirizzo oppure quella di una transazione.
- Pagina dell’indirizzo: incollando un indirizzo nella barra di ricerca si possono consultare le schede relative alle transazioni, ai trasferimenti di token e, quando disponibili, alle transazioni interne.
- Pagina della transazione: aprendo un transaction hash, Etherscan mostra i dati principali dell’operazione. Le chiamate interne possono essere rappresentate nella sezione dedicata ai trasferimenti o nei dettagli dell’esecuzione.
- Scheda dei trasferimenti di valore: alcuni trasferimenti di ETH sono evidenziati con una vista più leggibile, utile per capire chi ha inviato e chi ha ricevuto il valore.
La grafica può cambiare nel tempo e alcune informazioni possono essere organizzate in schede diverse. Il principio, però, resta lo stesso: occorre distinguere la transazione principale dai movimenti che si sono verificati durante la sua esecuzione.
Se una voce non appare, non significa necessariamente che l’operazione non sia avvenuta. La disponibilità delle tracce dipende dall’indicizzazione del servizio e dal tipo di chiamata. Per analisi tecniche particolarmente approfondite possono essere necessari un explorer alternativo o gli strumenti di tracing di un nodo Ethereum.
Come leggere i campi principali
La sezione delle transazioni interne presenta normalmente alcuni campi ricorrenti. Il loro significato va interpretato insieme al transaction hash di riferimento.
- Parent transaction: è la transazione esterna che ha avviato l’esecuzione. È il collegamento fondamentale per ricostruire il contesto.
- From: indica l’indirizzo che ha effettuato la chiamata interna secondo quella specifica fase dell’esecuzione. Non coincide necessariamente con l’utente che ha firmato la transazione principale.
- To: è il destinatario della chiamata o del trasferimento. Può essere un wallet, un contratto o un indirizzo creato durante l’esecuzione.
- Value: rappresenta l’eventuale quantità di ETH trasferita in quella chiamata. Un valore pari a zero non significa che la chiamata sia irrilevante: potrebbe aver modificato lo stato o mosso token tramite funzioni del contratto.
- Type: descrive la natura della chiamata, per esempio call, delegate call, static call, contract creation o self-destruct, quando questa informazione è disponibile.
- Trace action e trace result: nelle viste più tecniche possono indicare l’azione eseguita e il risultato restituito, compresi eventuali indirizzi creati.
- Status: segnala se l’esecuzione associata è riuscita o è stata annullata. In caso di revert della transazione principale, anche gli effetti interni normalmente vengono annullati.
È importante non leggere il campo From come se fosse sempre il proprietario economico dei fondi. Uno smart contract può effettuare una chiamata per conto della logica prevista dal protocollo, mentre il wallet dell’utente resta il soggetto che ha originato l’operazione esterna.
Internal transaction, evento e trasferimento di token: non sono la stessa cosa
Uno degli errori più comuni consiste nel mettere sullo stesso piano tre elementi diversi: chiamate interne, eventi e trasferimenti di token.
Una transazione interna è una traccia dell’esecuzione: può rappresentare un trasferimento di ETH o una chiamata tra contratti. Un evento è invece un log emesso da uno smart contract tramite un’istruzione prevista dal linguaggio e dall’ABI. Gli eventi vengono registrati nei receipt della transazione e possono essere indicizzati per facilitare la ricerca.
Un trasferimento di token ERC-20, per esempio, viene normalmente rappresentato dall’evento Transfer del contratto del token. Non è necessariamente un trasferimento di ETH e non deve essere cercato soltanto nella sezione Internal Txns. La scheda Token Transfers è spesso il punto più utile per seguire questi movimenti.
Lo stesso episodio può quindi produrre più rappresentazioni: una transazione esterna verso un protocollo, una chiamata interna tra contratti, uno o più eventi e un trasferimento di token. Nessuna di queste viste, da sola, è sempre sufficiente per capire l’intera operazione.
Un metodo pratico per ricostruire un’operazione
Quando si vuole analizzare un movimento apparentemente inspiegabile, è utile procedere con ordine.
- 1. Parti dal transaction hash: verifica che la transazione sia inclusa in un blocco e controlla il suo stato generale.
- 2. Identifica il mittente e il destinatario esterni: chiediti quale wallet ha firmato l’operazione e quale indirizzo ha ricevuto la chiamata.
- 3. Controlla il valore in ETH: un valore nullo nella transazione principale non esclude che ETH sia stato trasferito durante l’esecuzione.
- 4. Apri le tracce interne: ricostruisci la sequenza di chiamate e osserva quali indirizzi hanno inviato o ricevuto ETH.
- 5. Esamina i Token Transfers: verifica se sono stati trasferiti token e quali contratti hanno emesso gli eventi.
- 6. Leggi gli eventi e i dati della chiamata: quando disponibili, aiutano a distinguere swap, deposito, prelievo, mint, burn o altre funzioni.
- 7. Confronta gli effetti finali: controlla se i cambiamenti osservati nei saldi sono coerenti con l’operazione. Il saldo nativo e i saldi dei token vanno analizzati separatamente.
Questo metodo è particolarmente utile per gli swap. La transazione esterna può essere inviata a un router, il router può chiamare un pool, il pool può trasferire un token all’utente e ricevere l’altro token. Nella cronologia apparirà un solo transaction hash, ma l’esecuzione conterrà più passaggi.
Limiti e rischi di interpretazione
Le transazioni interne non sono una prova automatica di chi possieda economicamente i fondi. Un contratto può custodire asset per conto di molti utenti e trasferirli in base alle regole del protocollo. Osservare un movimento verso un indirizzo non basta, da solo, per stabilire la titolarità.
Un altro limite riguarda le operazioni annullate. Se una transazione termina con revert, le modifiche di stato e i trasferimenti prodotti durante l’esecuzione vengono normalmente ripristinati. Tuttavia, il gas utilizzato per tentare l’esecuzione può non essere recuperato. Per questo una traccia mostrata nei dettagli tecnici non va interpretata automaticamente come un trasferimento definitivo.
Occorre inoltre distinguere ETH e token. Il campo Value delle transazioni interne riguarda il valore nativo della rete, mentre un trasferimento ERC-20, ERC-721 o ERC-1155 dipende dalla logica del relativo smart contract e dai suoi eventi. Confondere questi livelli può portare a concludere erroneamente che siano stati trasferiti ETH quando, in realtà, si è mosso un token.
Infine, un explorer è uno strumento di indicizzazione e presentazione. È molto utile per l’analisi quotidiana, ma non sostituisce la verifica del codice del contratto, della documentazione del protocollo o dei dati prodotti direttamente da un nodo quando servono prove tecniche complete.
La checklist prima di considerare chiusa l’analisi
- Hai verificato il transaction hash corretto e la rete corretta?
- Hai distinto la transazione esterna dalle chiamate interne?
- Hai controllato sia il valore nativo sia i trasferimenti di token?
- Hai verificato lo stato finale dell’operazione e l’eventuale revert?
- Hai identificato se gli indirizzi coinvolti sono wallet, contratti o indirizzi creati durante l’esecuzione?
- Hai letto gli eventi senza considerarli automaticamente equivalenti a trasferimenti di ETH?
- Hai evitato di dedurre la proprietà economica soltanto dall’indirizzo mostrato nei campi From e To?
Le Internal Transactions di Etherscan diventano molto più comprensibili quando vengono trattate come una traccia dell’esecuzione, non come una seconda cronologia indipendente. Il transaction hash resta il punto di riferimento; le chiamate interne, gli eventi e i trasferimenti di token sono livelli diversi che, letti insieme, permettono di ricostruire ciò che uno smart contract ha effettivamente fatto.
