Wallet collegati e cluster

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

Un cluster può essere un insieme di osservazioni, un raggruppamento algoritmico o un’ipotesi di proprietà. Usare una parola per tutti e tre invita ad attribuzione non supportata. Finanziamento comune, tempi simili e uso della stessa applicazione possono essere relazioni autentiche senza provare un proprietario umano comune.

Questa lezione costruisce un grafo delle evidenze, confronta spiegazioni e tiene visibili gli archi incerti. Valuterai le ipotesi secondo supporto e verifiche mancanti anziché assegnare una confidenza numerica d’identità senza calibrazione.

Definire che cosa significa cluster qui

Iniziare con una regola esplicita di appartenenza. «Indirizzi che ricevono fondi nativi da HUB nella finestra W» definisce un insieme riproducibile finanziato dalla stessa fonte. «Indirizzi controllati da una persona» è un’ipotesi più forte che richiede evidenza indipendente di controllo.

Nominare l’insieme secondo la sua regola. Una coorte finanziata dalla stessa fonte può essere utile per ulteriori esami senza essere un cluster di proprietà. Se il metodo di raggruppamento di un fornitore non è divulgato, conservare l’output come affermazione del fornitore con meccanismo sconosciuto.

Il grafo deve separare nodi del registro e nodi di entità. Indirizzi, programmi e account di token sono oggetti ispezionabili. Un nodo umano o organizzativo necessita di supporto separato. Non crearlo soltanto per semplificare il diagramma.

Usare archi tipizzati con fonti

Ogni arco necessita di rete, fonte, destinazione, tipo, asset/importo se pertinenti, riferimento all’evento, contesto, risultato e copertura. «Collegato» è troppo vago. Trasferimento nativo, campo di autorità condiviso, derivazione da programma e stessa chiamata di applicazione rispondono ciascuno a una domanda diversa.

Le strutture dei risultati Solana distinguono istruzioni, firmatari e saldi [S09-STRUCTURES]. Forniscono campi di meccanismo per esaminare gli archi, non un’identità umana incorporata. Una ricerca di firme scopre soltanto attività che cita l’indirizzo nel proprio ambito [S09-SIGNATURES].

Per nodi mediati da programma, distinguere derivazione e proprietà. I PDA usano firma del programma anziché chiave privata [S09-PDA]. Un programma condiviso può elaborare molti utenti indipendenti, quindi derivare più indirizzi da un programma non fonde di per sé i beneficiari.

Separare osservazioni e ipotesi

Disegnare archi di movimenti forniti riusciti come linee continue. Disegnare collegamenti ipotizzati di controllo come linee tratteggiate con spiegazione. Un possibile arco indisponibile deve essere segnato sconosciuto, non disegnato come misurato.

Il finanziamento comune osservato supporta una relazione. Può essere compatibile con controllo comune, prelievi da custodia condivisa, distribuzione pubblica, stipendi o un altro servizio comune. Queste alternative non sono tutte provate; mostrano che l’osservazione non determina univocamente la proprietà.

Un trasferimento tra due membri può rafforzare una domanda sul coordinamento, ma comunque non identifica un controllore umano. Pagamento commerciale, rimborso o instradamento di servizio possono anche collegare indirizzi indipendenti. Verificare il meccanismo anziché contare frecce come voti d’identità.

Evitare inflazione di evidenze dipendenti

«Stesso minuto», «ravvicinati» e «stesso gruppo visibile» possono essere tre descrizioni di una caratteristica temporale. Non contarle come conferme indipendenti. Anche finanziamento comune e tempi dalla stessa fonte possono condividere una sola operazione sottostante.

Un’etichetta del fornitore e una dell’interfaccia copiata da quel fornitore sono dipendenti. Due visualizzazioni non raddoppiano l’evidenza d’identità. Un rapporto dovrebbe raggruppare tali affermazioni per fonte a monte.

Nessuna soglia fissa come «tre indizi significano stesso proprietario» è giustificata dai dati didattici. Un modello calibrato richiederebbe obiettivo definito, verità di riferimento rappresentativa e analisi degli errori. La lezione usa invece stati qualitativi espliciti e richieste di evidenza falsificabili.

Confrontare equamente spiegazioni concorrenti

Scrivere che cosa prevede ogni spiegazione e che cosa la distinguerebbe. Il controllo comune potrebbe prevedere evidenza di autorizzazione condivisa o gestione coordinata, ma la sola attività pubblica condivisa non è esclusiva. Un’ipotesi di distribuzione di servizio potrebbe prevedere molti destinatari con comportamenti successivi diversi, ma un grafo parziale non può stabilire quella popolazione più ampia.

Cercare evidenze che potrebbero indebolire l’interpretazione preferita, non soltanto esempi compatibili. Evidenza contraria mancante in un’esportazione incompleta non è conferma. Se nessun record fornito discrimina le ipotesi, riportarle irrisolte.

Una conclusione valida può essere «i dati didattici supportano una coorte finanziata dalla stessa fonte; la proprietà umana è insufficientemente evidenziata». È un risultato di analisi, non un fallimento del compito. Dice precisamente al revisore dove l’indagine potrebbe avanzare.

Preservare limiti del grafo e delle quantità

Un trasferimento dentro una coorte sposta inventario tra nodi senza aggiungere nuovo finanziamento esterno. Sommare tutti gli archi misura movimento lordo, non afflusso esterno o saldi detenuti. Riconciliare entro un confine dichiarato.

Se HUB invia 10 a ciascuno di tre membri e uno successivamente invia 2 a un altro, il finanziamento esterno della coorte è 30. Il volume lordo degli archi di trasferimento, incluso quello interno, è 32. L’inventario della coorte rimane30 nel modello chiuso senza commissioni. Queste statistiche hanno nomi diversi e non sono sostituibili.

Non fondere viste duplicate di un evento. Mantenere i riferimenti agli eventi di P09-L02. Un arco di chiamata non ha quantità senza un effetto distinto di valore fornito. Le chiamate dell’applicazione in questo esercizio non portano importo nativo aggiuntivo.

Riportare relazioni senza attribuzione pubblica d’identità

Tenere etichette dei fornitori, ipotesi di controllo e trasferimenti osservati in sezioni diverse. Usare sempre identificatori neutrali. Stato commerciale, ricchezza apparente e popolarità non possono innalzare uno stato probatorio.

Nessun grafo autorizza un segnale di trading o un’accusa pubblica. Non identificare una persona reale da percorsi di finanziamento e non dedurre intenzioni da attività che sembra coordinata. L’obiettivo didattico è un grafo verificabile con alternative, copertura e verifiche successive.

• Coorte: insieme selezionato tramite una regola di osservazione divulgata.
• Ipotesi di proprietà: controllo condiviso proposto che necessita di evidenze separate.
• Arco tipizzato: relazione con meccanismo esplicito.
• Indizio dipendente: evidenza che descrive la stessa osservazione sottostante.
• Afflusso esterno: movimento che attraversa verso l’interno il confine scelto.
• Evidenza discriminante: record che distingue spiegazioni concorrenti.

ILLUSTRATIVE — FIX-P09-06. SIM-CHAIN-A, T1–T5 sintetici. I saldi nativi iniziano0 per W1/W2/W3. Effetti nativi elencati completi; commissioni e altri effetti sono0. Regola della coorte: riceve 10 da HUB durante T1–T3.

T1–T5 stabiliscono soltanto ordine sintetico, non secondi reali. Non sono fornite firme che provino autorità condivisa, provenienza autenticata degli stipendi o identità umana. H1=controllore comune; H2=servizio condiviso/distributore pubblico con destinatari indipendenti.

OBSERVED nei dati didattici: W1/W2/W3 condividono la fonte immediata di finanziamento; W1/W2 interagiscono anche con APP; avviene un movimento interno di2 unità.

INFERRED: Tutti e tre soddisfano la regola di finanziamento dalla stessa fonte. Afflusso esterno 30, flusso interno2 e saldo finale della coorte 30 secondo le ipotesi del modello.

UNKNOWN: Proprietà umana, affiliazione agli stipendi, insieme più ampio di destinatari HUB e semantica di autorizzazione APP.

INSUFFICIENT EVIDENCE: Né H1 né H2 è stabilita univocamente. Finanziamento uguale e ordine sintetico ravvicinato non possono provare controllo comune; L1 non può autenticare identità del servizio stipendi.

Rinominare un insieme finanziato dalla stessa fonte come un proprietario; contare descrizioni temporali come indizi indipendenti; disegnare continui archi ipotizzati; aggiungere movimento interno al finanziamento esterno; adottare un’etichetta di servizio per risolvere un’ipotesi.

Costruire il grafo tipizzato e calcolare saldi finali dei membri, afflusso esterno e volume lordo degli archi nativi. Confrontare H1/H2 usando supporto fornito e una verifica successiva per ciascuna. Dichiarare se un cluster di proprietà umana possa essere riportato come provato.

• Pubblicare una regola di appartenenza.
• Tipizzare ogni arco e indicarne la fonte.
• Separare relazioni misurate e ipotesi di controllo.
• Raggruppare indizi dipendenti per meccanismo.
• Riconciliare flussi attraverso il confine e interni.
• Verificare alternative e preservare attribuzione irrisolta.

Un grafo utile di cluster può stabilire relazioni lasciando irrisolta la proprietà. Verificare ipotesi richiede evidenze che distinguano le spiegazioni.

Finanziamento comune non è proprietà comune. Diverse etichette temporali possono essere un indizio. Il movimento interno cambia allocazione, non finanziamento esterno della coorte.

Grafo HUB→W1/W2/W3 quantità10 e W1→W2 quantità2; archi di chiamata APP distinti e valore0. Archi osservati continui, possibilità H1/H2 di controllo/servizio tratteggiate. Mostrare finali8/12/10, esterno30 e lordo 32 con etichette separate; L1 non verificata.

Coorte illustrativa finanziata dalla stessa fonte; proprietà irrisolta.

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.

• Strutture JSON del RPC Solana — Metadati del risultato, commissione, istruzioni e saldi come viste distinte. 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.
• Indirizzi Solana derivati da programma — Indirizzi derivati da programma e firma del programma; nessuna chiave privata del PDA. 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-L07 dopo l’esercizio svolto e la revisione delle domande.