Cronologia delle transazioni

Master della fonte EN · P09-L02 · 45 minuti stimati · needs_review

Una pagina di transazione può mostrare un trasferimento, la sua istruzione, un riepilogo decodificato e una variazione del saldo. Possono essere più viste di un unico evento. Sommare ogni riga gonfia l’attività, mentre ignorare lo stato di esecuzione può trasformare tentativi falliti in trasferimenti riusciti.

Questa lezione insegna un registro cronologico che separa identità dell’evento, successo, attività annidata e commissioni. Prepara l’analisi del finanziamento senza presumere che ogni riferimento a un indirizzo significhi pagamento.

Definire la copertura della cronologia

Scrivere rete, indirizzo considerato, account di token collegati, finestra richiesta e metodo di raccolta. Solana getSignaturesForAddress restituisce firme che citano l’indirizzo richiesto in accountKeys, dalla più recente, con parametri di paginazione [S09-SIGNATURES]. Una pagina restituita è un elenco di scoperta, non un registro completo dei trasferimenti.

Un indirizzo citato non deve necessariamente essere firmatario o destinatario. Le istruzioni possono citare programmi, account di dati e stato in sola lettura. Esaminare il ruolo del record prima di contare il coinvolgimento come azione. Interrogare l’indirizzo di un proprietario può anche non scoprire ogni operazione relativa ad account di token separati; esaminare la copertura prevista anziché dichiarare una cronologia completa.

Deduplicare le firme tra pagine sovrapposte, ma preservare istruzioni diverse nella stessa transazione. L’ordinamento deve rispettare l’ordine disponibile di slot/blocco e qualsiasi evidenza di ordine interno al contesto. L’ordine mostrato da un’interfaccia non è automaticamente l’esatto ordine di esecuzione.

Verificare il risultato prima di contare gli effetti

Recuperare metadati di esecuzione per i record scoperti. Solana getTransaction può restituire null al commitment richiesto e ha campi temporali o di metadati che possono essere nulli [S09-TRANSACTION]. Trattare il recupero mancante come irrisolto, non come evento fallito o inesistente.

Un record confermato/incluso può comunque contenere un’operazione fallita. Registrare il successo separatamente dalla finalità. Un importo inviato descrive l’intenzione; un effetto riuscito sul saldo descrive l’esecuzione. Per T2 fallita nei dati didattici, gli effetti del trasferimento di token sono esplicitamente zero mentre la commissione nativa fornita rimane addebitata.

Non universalizzare affermazioni semplificate di ripristino a ogni funzionalità della catena. L’esercizio esclude cambiamenti delle autorizzazioni e altri meccanismi diversi dai trasferimenti. La sua tabella dei risultati fornisce direttamente gli effetti pertinenti. Nell’analisi reale esaminare le effettive regole del protocollo e le differenze di stato.

Separare identità degli eventi e righe visualizzate

Scegliere una chiave dell’evento: rete, firma/hash della transazione e percorso dell’istruzione o indice del log, secondo il caso. Un’istruzione di trasferimento, il suo riepilogo decodificato e il delta di saldo corrispondente possono corroborare un evento. Non sono tre trasferimenti separati.

Un delta di saldo è un risultato netto. Se un account invia 10 e riceve 4 in una finestra, il delta è−6 mentre il deflusso lordo è 10. Il delta non cancella il trasferimento in entrata e sommare movimento lordo e delta netto conta due volte.

Le chiamate annidate richiedono una propria semantica. callTracer di Geth descrive frame di chiamata con ambito configurabile [S09-TRACES]. Una chiamata interna fa parte di una transazione principale, non è una transazione firmata separatamente. Alcuni frame portano valore nativo; altre chiamate portano zero ed eseguono codice. Non contare ogni chiamata come pagamento.

Distinguere chiamate, log e movimenti di token

Una ricevuta EVM fornisce collegamento alla transazione, stato e log [S09-RECEIPT]. Un log di evento di token e una chiamata con valore nativo sono record diversi. Il contratto del token che emette un log Transfer non è necessariamente il destinatario economico.

Su Solana i metadati del risultato distinguono istruzioni, istruzioni interne, commissioni e saldi [S09-STRUCTURES]. Un’istruzione interna può identificare un meccanismo dentro un’operazione principale. Un riepilogo della stessa istruzione dovrebbe usare lo stesso riferimento all’evento.

Una chiamata di contratto con un log di trasferimento di token può essere un movimento economico di token più una relazione di chiamata, anziché due movimenti di token. Preservare entrambe le osservazioni in tabelle tipizzate, poi scegliere l’unità di conteggio appropriata alla domanda.

Tenere separate le commissioni

Le commissioni usano l’asset nativo della rete e hanno un pagatore specifico. Non sono trasferimenti del token considerato. La documentazione Solana descrive un meccanismo di commissione nativa delle transazioni [S09-FEES]. Non presumere che ogni indirizzo visibile abbia pagato la commissione o che ogni tentativo fallito fosse gratuito.

I totali delle commissioni devono contare una volta per risultato di transazione fornito, non una volta per istruzione o riga di riepilogo. Convertire le unità grezze della commissione usando la precisione nativa se i dati reali la forniscono. Questo esercizio fornisce unità fittizie di commissione normalizzate e nessuna conversione di prezzo.

Riconciliare separatamente movimento di token e costi nativi. Un delta di token può essere corretto mentre il saldo nativo ha ulteriori effetti di rent, depositi o fenomeni non collegati. I dati didattici escludono esplicitamente tali effetti; i record reali richiedono un’ulteriore riconciliazione.

Costruire una tabella cronologica delimitata

Usare colonne per riferimento all’evento, ruolo dell’oggetto, risultato, asset, direzione, importo lordo, pagatore della commissione e incertezza. Mantenere un elenco separato dei record irrisolti. Non eliminare record mancanti soltanto per far sembrare completo il conteggio visibile dei successi.

Il conteggio delle transazioni riuscite di trasferimento di token differisce dal conteggio degli eventi di trasferimento di token. Una transazione può avere più eventi. Dichiarare quale statistica si riporta. Un tentativo fallito può appartenere al conteggio dei tentativi pur contribuendo zero al movimento riuscito.

La descrizione finale deve nominare finestra di osservazione e copertura fornita. La cronologia insegna che cosa è avvenuto nei record disponibili, non perché un attore lo abbia scelto. Un trasferimento riuscito non è prova di affiliazione né segnale di prezzo.

• Risultato di esecuzione: successo/fallimento dell’operazione esaminata.
• Riferimento all’evento: transazione più percorso di istruzione/log.
• Frame di chiamata: esecuzione annidata dentro una transazione.
• Flusso lordo: somma dei movimenti direzionali.
• Delta netto: saldo finale meno iniziale.
• Pagatore della commissione: account che sostiene il costo nativo fornito.

ILLUSTRATIVE — FIX-P09-02. SIM-SOL-A / W / MINT-T. Effetti completi soltanto per T1–T3, ordine sintetico S1,S2,S3. Le commissioni native sono normalizzate e pagate da W. Nessun altro effetto nella finestra. Saldo iniziale di token 100.

L’esempio separato SIM-EVM-A E1 riesce con W-E→ROUTER di livello principale valore0; ROUTER→C-E annidato valore nativo2 e un log Transfer di token per7 unità da W-E a C-E. I dati didattici stipulano asset/effetti distinti e copertura completa delle chiamate. Nessun valore di commissione è fornito per E1.

OBSERVED nei dati didattici: Le tre viste di T1 descrivono un trasferimento di10 token; T2 fallisce; T3 riceve 4. E1 contiene una chiamata a valore zero, un movimento di 2 unità native e un log di 7 token.

INFERRED: Deflusso riuscito del token considerato 10, afflusso 4, netto−6; saldo finale 94. Le commissioni native T1–T3 ammontano a 0.04.

UNKNOWN: Cronologia precedente, operatori umani, commissioni E1 e motivi.

INSUFFICIENT EVIDENCE: H2/H3 non possono aggiungere20 token trasferiti ulteriori. Il tentativo di T2 non può contare come deflusso riuscito di 20 token. La chiamata annidata di E1 non è una seconda transazione firmata indipendentemente.

Aggiungere riepiloghi e delta ai trasferimenti; equiparare inclusione e successo; trattare ogni riferimento a un indirizzo come azione; mescolare commissioni native e importi di token; escludere record indisponibili da un’affermazione sulla copertura.

Costruire un registro deduplicato dei token per T1–T3. Calcolare flusso lordo e netto, saldo finale e commissioni. Classificare chiamata e movimenti degli asset di E1 senza un totale tra asset diversi.

• Registrare scoperta e copertura della cronologia.
• Verificare il risultato di esecuzione separatamente dalla finalità.
• Identificare eventi tramite transazione e percorso.
• Riconciliare flusso lordo e saldo netto.
• Contare le commissioni una volta e preservare pagatore/asset.
• Tenere distinti chiamate, log e attribuzione umana.

Ricostruire la cronologia è contabilità degli eventi, non conteggio di righe. Movimenti riusciti, tentativi falliti e commissioni rispondono a domande diverse.

Più viste possono descrivere un trasferimento. Le chiamate annidate non sono transazioni firmate separatamente. I record mancanti rimangono irrisolti anziché assenti.

Cronologia T1–T3 con H1/H2/H3 raggruppati in un evento, T2 fallita con commissione ancora fornita, T3 entrata4. Mostrare flusso10/4/netto−6/saldo finale 94 e un pannello separato della commissione 0.04. Separare l’albero di chiamate E1 dalle righe degli importi di token/unità native.

Contabilità illustrativa degli eventi; righe e chiamate annidate non sono transazioni indipendenti.

Usare SVG/HTML deterministico o grafici con unità, riferimenti alle evidenze e alternative testuali. Blu navy/nero con tocchi sobri di ciano, blu elettrico e viola; nessuna schermata decorativa o inventata di explorer. A 390px impilare le annotazioni; verificare 768px, desktop e RTL arabo quando le risorse saranno implementate. Mantenere gli identificatori LTR e inalterate le direzioni fattuali del tempo, degli archi e degli assi. Usare soltanto il marchio ufficiale BlockAssay fornito. Entrambi i record visivi rimangono specifiche.

WALLET_INTELLIGENCE corrisponde all’ispezione in sola lettura di record di indirizzi pubblici, relazioni e provenienza. Verificare rete supportata, identificatori esatti, campi e copertura prima di qualsiasi integrazione a runtime; qui non si dichiara alcuna capacità di un fornitore in tempo reale. Usare l’esercizio offline incorporato se dati o accesso a pagamento non sono disponibili. Non sono richiesti connessione del wallet, credenziali, chiave privata, firma o operazione di mercato reale. I dati mancanti rimangono sconosciuti. Progressi Academy, stato di creatore, pagamenti e segnalazioni non alterano mai le evidenze Radar.

• Solana getSignaturesForAddress — Cronologia delle firme che citano l’indirizzo, ordine dal più recente e paginazione. Verificato il 2026-09-30.
• Solana getTransaction — Ricerca delle transazioni, commitment e campi dati/tempo che possono essere nulli. Verificato il 2026-09-30.
• Strutture JSON del RPC Solana — Metadati del risultato, commissione, istruzioni e saldi come viste distinte. Verificato il 2026-09-30.
• Commissioni Solana — Meccanismo della commissione nativa delle transazioni; non un movimento di token né un modello universale dei costi. Verificato il 2026-09-30.
• Tracciatori integrati di Geth — Ambito della traccia dei frame di chiamata e configurazione specifica del tracciatore. Verificato il 2026-09-30.
• API di esecuzione Ethereum eth_getTransactionReceipt — Stato della ricevuta, collegamento alla transazione e log. Verificato il 2026-09-30.

Tutti i record di esempio sono dati didattici originali ILLUSTRATIVE, non misurazioni storiche o in tempo reale della catena. La documentazione spiega i meccanismi, non gli importi o le etichette inventati. La cronologia sintetica è esplicitamente delimitata; observedAt=null è intenzionale. OBSERVED in un esercizio indica un record dei dati forniti. Riesaminare documentazione e decodifica distribuita prima della pubblicazione. Le etichette dei fornitori non stabiliscono identità; controllo degli indirizzi e attribuzione umana richiedono evidenze distinte.

P09-L03 dopo l’esercizio svolto e la revisione delle domande.