Controparti

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

Un wallet può chiamare un router, inviare token a un indirizzo di custodia e ricevere un trasferimento non richiesto. Un grafo può mostrare tutti e tre come controparti, benché rappresentino relazioni diverse. Descriverli come partner o affiliati inventa un significato che il registro non fornisce.

Questa lezione costruisce una tabella tipizzata delle controparti e un registro separato delle etichette dei fornitori. Distinguerai interazioni tecniche, movimenti riusciti e affermazioni non verificate sulle entità.

Definire una controparte per tipo di evento

Per un trasferimento diretto di valore, fonte e destinazione decodificate sono i punti terminali del movimento. Per una chiamata di contratto, l’indirizzo chiamato è un punto terminale di esecuzione. Per un log di token, contratto emittente e campi from/to hanno ruoli diversi. Specificare quale relazione si misura.

Un elenco di controparti senza regola non può essere confrontato in modo riproducibile. «Destinatari unici dei trasferimenti» differisce da «tutti i contratti chiamati». Una transazione può contenere entrambe le categorie. Non combinarle in un conteggio chiamandolo numero di relazioni commerciali.

Identità dell’asset e rete rimangono necessarie. Un trasferimento di TOKEN-A e uno di TOKEN-B sono quantità separate anche con lo stesso destinatario. Una chiamata a valore zero può stabilire interazione di esecuzione senza stabilire pagamento nativo.

Leggere attentamente l’esecuzione annidata

callTracer di Geth rappresenta frame di chiamata e può essere configurato per includere soltanto la chiamata principale [S09-TRACES]. Una configurazione incompleta della traccia può omettere interazioni annidate. Registrare se la fonte copra la profondità pertinente anziché presumere che il destinatario principale sia l’unico punto terminale di esecuzione.

Un router può delegare o instradare attività attraverso altri contratti. L’account chiamato dall’utente può non essere quello che riceve un eventuale movimento di token. Un grafo di interazioni dovrebbe conservare entrambi gli archi con tipi distinti anziché fingere che siano duplicati o relazioni economiche equivalenti.

I log delle ricevute Ethereum portano collegamento alla transazione e informazioni sugli eventi [S09-RECEIPT]. Decodificare un evento richiede emittente e semantica corretti. Un contratto che emette un evento Transfer di token non è per questo acquirente, destinatario o affiliato di ogni indirizzo nominato nell’evento.

Distinguere coinvolgimento e relazione volontaria

Su Solana una ricerca di firme trova transazioni che citano un indirizzo in accountKeys [S09-SIGNATURES]. La sola citazione non significa che l’indirizzo abbia autorizzato la transazione. Esaminare firmatari, istruzioni ed effetti prima di assegnare un ruolo attivo.

Un trasferimento in entrata può essere non richiesto. La sola ricezione non prova consenso, appartenenza o partnership. Anche interazioni dirette ripetute possono essere compatibili con l’uso ordinario di un servizio pubblico anziché affiliazione.

Un trasferimento mediato da contratto può coinvolgere un delegato o una politica dell’applicazione. Non concludere che il detentore visibile abbia firmato personalmente ogni movimento. I metadati del risultato separano ruoli degli account e viste di esecuzione [S09-STRUCTURES]; l’intenzione umana richiede ulteriori evidenze.

Memorizzare le etichette come affermazioni delle fonti

Un’etichetta del fornitore dovrebbe avere editore, indirizzo/rete esatti, contesto di acquisizione/aggiornamento, formulazione, fondamento e stato di verifica. Se quei campi sono assenti, dirlo. «Exchange-X» visualizzato accanto a un indirizzo non è un’identità di entità stabilita indipendentemente.

Due interfacce che usano lo stesso flusso di etichette sottostante non forniscono due conferme indipendenti. L’accordo tra etichette può motivare un’indagine mentre la dipendenza rimane esplicita. Se le fonti sono in conflitto, conservare entrambe le etichette e il conflitto.

Un meccanismo verificato di deposito presso un servizio, quando effettivamente stabilito, comunque non identificherebbe l’utente beneficiario dell’account né proverebbe che un trasferimento sia una vendita. Affiliazione tecnica, custodia del servizio e identità personale sono domande separate.

Contare l’unità prevista

Usare chiavi uniche di eventi riusciti per contare movimenti. Usare indirizzi terminali unici per contare destinatari in un asset/finestra dichiarati. Invii ripetuti a un indirizzo contano come più eventi ma un destinatario unico.

Escludere tentativi falliti dai totali di flusso riuscito conservandoli in una tabella dei tentativi. Non cancellarli dall’indagine. Se il risultato è indisponibile, mantenerlo irrisolto; né successo né fallimento possono essere dedotti da una bella riga dell’interfaccia.

Per un rapporto basato sulla direzione, distinguere archi in entrata e in uscita. Ricevere da un contratto non equivale a chiamarlo. Un percorso di andata e ritorno non prova proprietà o finalità di rimborso senza evidenza del meccanismo.

Dichiarare che cosa rafforzerebbe l’affermazione

Per un ruolo tecnico richiedere operazioni decodificate, codice/interfaccia binaria dell’applicazione (ABI) corretti, copertura della traccia e saldi coerenti. Per un’identità del fornitore, chiedere fondamento dell’etichettatura e corroborazione indipendente. Per affiliazione, specificare quali evidenze organizzative o autenticate sarebbero necessarie.

Non cercare identità personali soltanto perché un indirizzo pubblico è interessante. Mantenere la domanda proporzionata all’obiettivo didattico. Questo esercizio non contiene persone reali o indirizzi utilizzabili e non richiede indagini di attribuzione oltre ai record forniti.

Una conclusione delimitata come «W ha effettuato due invii riusciti TOKEN-A a X; X è etichettato Exchange-X da un flusso condiviso, qui non verificato» è informativa. Non implica vendita, partnership o proprietario comune.

Mantenere limiti causali e finanziari

L’interazione non stabilisce affiliazione. Un grande trasferimento a un servizio etichettato non stabilisce un’operazione di mercato. Un grafico che si muove dopo non stabilisce che il trasferimento l’abbia causato. Queste conclusioni successive richiedono evidenze separate e non possono essere ricavate dal conteggio delle controparti.

Lo scopo della lezione è un vocabolario accurato delle relazioni. Più archi non sono necessariamente evidenza più forte di una relazione umana. Talvolta diverse righe espongono soltanto più meccanismi interni di una transazione pubblica.

• Punto terminale di esecuzione: indirizzo chiamato durante l’esecuzione.
• Punto terminale di movimento: fonte o destinazione di un trasferimento decodificato di asset.
• Emittente: contratto che produce un log di evento.
• Destinatario unico: destinazione distinta secondo una regola dichiarata.
• Affermazione del fornitore: etichetta pubblicata in attesa di valutazione dell’ambito/provenienza.
• Affiliazione: relazione organizzativa che necessita di evidenza indipendente.

ILLUSTRATIVE — FIX-P09-04. SIM-EVM-A, W, ordine sintetico T1–T4. Importi TOKEN-A normalizzati. Tutti i risultati elencati sono forniti, non misurati.

Non sono forniti record di vendita, affiliazione organizzativa o evidenza di controllo umano. Le etichette hanno acquisizione sintetica T5; non esiste timestamp reale.

OBSERVED nei dati didattici: W chiama ROUTER; sono fornite interazione annidata POOL e due invii TOKEN-A a X. L1/L2 condividono una fonte di etichetta; L3 è in conflitto.

INFERRED: Totale TOKEN-A riuscito in uscita 15, con un destinatario riuscito unico X in questa finestra/regola. C6 aggiunge un destinatario tentato Y, non flusso riuscito.

UNKNOWN: Entità dietro X, consenso alla ricezione per C5, motivi e proprietari beneficiari.

INSUFFICIENT EVIDENCE: Interazioni ROUTER/POOL non provano affiliazione. L1/L2 non sono prova indipendente d’identità; L3 non risolve il conflitto. La ricezione di X non stabilisce vendita.

Contare l’emittente come destinatario; trattare chiamate al router come partnership; fondere punti terminali annidati e diretti senza tipi; adottare etichette copiate come conferma indipendente; interpretare ricezione non richiesta come appartenenza volontaria.

Produrre una tabella tipizzata delle relazioni e una statistica TOKEN-A riuscita in uscita. Separare affermazioni di etichette di entità e record del registro. Riscrivere «W ha venduto15 al suo affiliato Exchange-X e ricevuto un pagamento da un partner».

• Definire regole di relazione e conteggio.
• Separare chiamante, punto terminale annidato, emittente e destinatario.
• Verificare risultato e copertura della traccia.
• Registrare etichette con dipendenze dalle fonti.
• Preservare possibilità di ricezione non richiesta/intenzione sconosciuta.
• Evitare conclusioni di affiliazione, vendita e identità senza evidenze.

L’analisi delle controparti descrive interazioni specifiche. Partecipazione tecnica ed entità etichettate non stabiliscono automaticamente relazioni economiche o organizzative.

Interazione non è affiliazione. Destinatari ripetuti differiscono da eventi ripetuti. Le etichette dei fornitori sono affermazioni con provenienza e conflitti.

Usare stili distinti di archi di chiamata e trasferimento con ID dei record; emittente TOKEN-A separato. Segnare C6 fallita, consenso C5 sconosciuto. Mostrare etichette X nel registro delle fonti con parentesi di flusso condiviso L1/L2 e conflitto L3, senza contrassegno d’identità.

Tipi illustrativi di controparti; l’interazione non prova affiliazione.

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.

• 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.
• Solana getSignaturesForAddress — Cronologia delle firme che citano l’indirizzo, ordine dal più recente e paginazione. 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.

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-L05 dopo l’esercizio svolto e la revisione delle domande.