Anatomia del wallet

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

Una pagina di wallet può riunire in un’unica schermata un indirizzo, diversi account di token, chiamate a contratti ed etichette dei fornitori. Questa comodità non li rende un unico oggetto del registro o una sola persona. Prima di leggere la cronologia, definire che cosa rappresenta effettivamente la pagina.

Mapperai i ruoli degli account e riconcilierai le disponibilità fornite senza attribuire identità. È la competenza iniziale del programma: ogni successiva affermazione su finanziamento, età e relazioni dipende dalla scelta della corretta unità di osservazione.

Separare l’interfaccia dall’oggetto

Un’applicazione di wallet è un’interfaccia, mentre un account è un oggetto del registro; la documentazione Ethereum esplicita questa distinzione [S09-ETHACCOUNTS]. Un’interfaccia può mostrare più account e reti. Un account può essere accessibile tramite più interfacce. Nessuna delle due relazioni identifica una persona unica.

Usare rete e indirizzo completo come identificatore iniziale. Un’etichetta abbreviata non può stabilire uguaglianza. Lo stesso testo visualizzato su catene diverse non è un oggetto contabile condiviso. Il raggruppamento «wallet» di un fornitore può includere relazioni dedotte; esaminarne la definizione prima di trattarlo come totale di un proprietario.

Nel lavoro reale validare la codifica dell’indirizzo e registrare la rete selezionata. L’esercizio usa deliberatamente etichette invalide, quindi i confronti sono soltanto didattici e nessuna transazione può avere come destinazione questi identificatori.

Identificare il ruolo dell’account

Gli account Solana memorizzano stato agli indirizzi e hanno un campo del programma proprietario [S09-ACCOUNTS]. Quel campo non è un’identità umana. Un account di token registra separatamente mint e autorità proprietaria [S09-TOKENS]. Non interpretare la proprietà di base del Token Program come se quel programma fosse il beneficiario di ogni saldo di token.

Un’autorità può possedere più account di token per un mint. Aggregare soltanto mint esatto, contesto corrispondente e campi di autorità supportati. Un saldo nativo e uno di token hanno unità diverse. Non sommarli mai come un unico asset né convertirli in dollari senza un’esplicita fonte di valutazione.

Registrare se un indirizzo designa un programma, un account di token, un mint o un altro account di stato. Lo stesso grafo di relazioni può contenere tutti questi tipi di nodo. Un grafo con cinque nodi non mostra cinque wallet, tantomeno cinque persone.

Comprendere l’attività controllata da programma

Gli indirizzi Solana derivati da programma (PDA) derivano da un ID di programma e da seed e non hanno chiave privata; il programma derivante può firmare per essi tramite il meccanismo di runtime [S09-PDA]. La sola derivazione non afferma che un account sia già allocato a quell’indirizzo. Verificare sia la relazione dell’indirizzo sia lo stato pertinente dell’account.

La firma del programma e quella umana non devono essere fuse in un solo campo. Un’autorità mediata da programma può servire molti utenti. Le regole della sua applicazione determinano quali richieste la fanno agire; un’etichetta PDA non può stabilire un singolo utente o controllo illimitato.

Sulle reti EVM distinguere controllo ordinario tramite chiave, logica dei contratti e meccanismi di delega supportati. Un account di proprietà esterna (EOA) è controllato da una chiave privata; la delega supportata può determinare il codice che esegue. EIP-7702 consente la delega del codice per EOA sulle reti che la supportano [S09-DELEGATION]. La sola presenza di codice, quindi, non è una regola universale «questo non può essere un EOA». Esaminare regole di rete e stato dell’account nel contesto richiesto.

Un account con codice può eseguire istruzioni senza provare quale persona ne benefici. Un contratto multisig può rappresentare più account firmatari, ma contarli non prova persone indipendenti. Tenere separati meccanismo di controllo e attribuzione umana.

Costruire una mappa dei ruoli prima della proprietà

Usare tipo di nodo, identificatore esatto, rete, contesto e riferimento all’evidenza. Usare archi come proprietario dell’account di token, riferimento al mint, derivazione da programma e delega del codice. Questi archi hanno significati specifici. Un arco generico «collegato a» nasconde perché i nodi siano connessi.

Non trasformare ogni arco in proprietà comune. Il riferimento al mint collega tutti i detentori di un asset senza renderli un unico controllore. La derivazione da programma collega un indirizzo a un meccanismo, non necessariamente all’inventario personale dell’operatore del programma.

Le etichette dei fornitori appartengono a un’annotazione separata con provenienza e stato di verifica. «Servizio di custodia» potrebbe essere una pista utile, ma editore, data di aggiornamento e fondamento dell’etichetta devono essere esaminati. Registrarla come affermazione del fornitore finché non sia sufficientemente corroborata.

Riconciliare le disponibilità fornite

I dati didattici forniscono un insieme esaustivo di account di token per l’autorità W e un mint considerato a S0. Tale completezza è un’ipotesi dell’esercizio, non una capacità dichiarata di Wallet Intelligence. Sommare i due saldi validi soltanto dopo aver confermato proprietario e mint.

Un terzo account con lo stesso mint sotto un’autorità derivata da programma non appartiene alle disponibilità di W soltanto perché compare nella stessa schermata dell’applicazione. Una disponibilità di un mint diverso non può entrare nel totale considerato. Le unità native rimangono separate.

Se i record reali sono parziali, riportare il totale dei saldi restituiti e il limite di copertura. Non promuoverlo tacitamente a «tutte le disponibilità». Una query fallita è evidenza indisponibile, non inventario zero. Un importo zero fornito è una misurazione nel suo ambito dichiarato.

Esporre costruttivamente i limiti

Una buona conclusione sull’anatomia può dire «W è l’autorità fornita per T1/T2 che detengono MINT-A; P1 è un’autorità separata mediata da programma. Il controllo umano è sconosciuto». Risponde alla domanda sull’account senza risolvere una domanda d’identità non supportata.

La successiva richiesta di evidenze deve corrispondere alla lacuna: enumerazione completa proprietario/mint per disponibilità mancanti, record di derivazione/stato per classificare un PDA e autorizzazione dell’applicazione per controllo mediato. Chiedere il nome di una persona non sostituisce queste verifiche tecniche.

Nessun ruolo di account produce un segnale BUY/SELL. Avere un contratto, PDA o account di token indica come sono organizzate le osservazioni. Non stabilisce legittimità, intenzione o comportamento futuro del mercato.

• Indirizzo: identificatore nell’ambito di una rete.
• Account: oggetto di stato a un indirizzo.
• Interfaccia wallet: applicazione che mostra account o vi interagisce.
• Autorità proprietaria: campo che governa uno specifico account di token.
• PDA: indirizzo derivato da programma con firma tramite runtime.
• Delega: relazione di esecuzione dell’account, non affiliazione personale.

ILLUSTRATIVE — FIX-P09-01. SIM-SOL-A al contesto fittizio S0; saldi già normalizzati. Autorità considerata W, mint considerato MINT-A. T1/T2 sono stipulati esaustivi per W/MINT-A.

A 7 è un esempio su rete separata. Non sono forniti record d’identità, valutazione, soglia di firma o autorizzazione dell’applicazione.

OBSERVED nei dati didattici: W è autorità proprietaria di T1/T2; P1 è un’autorità distinta derivata da programma per T4. Il fornitore pubblica A 8.

INFERRED: Le disponibilità MINT-A fornite di W ammontano a 200 token. Le sue 2 unità native e MINT-B50 sono quantità separate.

UNKNOWN: Identità umana dietro W/P1/E1, regole di controllo dell’applicazione e proprietà beneficiaria.

INSUFFICIENT EVIDENCE: A 8 non può stabilire l’identità di Alice. Il mint condiviso non può fondere W e P1. La delega del codice non stabilisce affiliazione con l’editore di LOGIC-D.

Trattare una UI di wallet come una persona; confondere proprietario del programma di base e autorità proprietaria del token; sommare unità diverse; fondere detentori dello stesso mint; applicare una classificazione obsoleta codice/assenza di codice senza contesto di rete.

Disegnare una mappa tipizzata dei ruoli da A 1–A 7. Calcolare le disponibilità considerate di W. Classificare A 8 e spiegare perché T4 debba restare fuori dal totale di W. Identificare due verifiche mancanti per l’attività controllata da programma.

• Selezionare rete esatta e unità di osservazione.
• Tipizzare ogni nodo e relazione.
• Tenere separati saldi nativi e dei mint.
• Aggregare soltanto campi di proprietario supportati.
• Distinguere controllo da programma, chiave e delega.
• Conservare le etichette come affermazioni finché corroborate.

L’anatomia del wallet è una mappa di oggetti del registro e meccanismi di controllo. Stabilisce che cosa esaminare senza equiparare indirizzi e persone.

Un’interfaccia non è un account o una persona. Le relazioni tipizzate impediscono aggregazioni false. Etichette dei fornitori e comportamento del codice non provano identità.

Disegnare nodi tipizzati W,T1,T2,T3,P1,T4 e mint con archi etichettati di autorità/mint/derivazione. Evidenziare soltanto il totale considerato200. Isolare unità native e MINT-B e separare la delega EVM. Inserire A 8 nell’annotazione dell’etichetta non verificata.

Anatomia illustrativa degli account; i nodi del grafo non sono persone.

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.

• Account Solana — Stato indirizzato e campo del programma proprietario. Verificato il 2026-09-30.
• Asset Solana — Distinzioni tra mint, account di token e autorità proprietaria. 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.
• Account Ethereum — Distinzione account/interfaccia e tipi di account. Verificato il 2026-09-30.
• EIP-7702: impostazione del codice per EOA — Delega del codice degli EOA; la sola presenza di codice non è una regola universale di classificazione degli EOA. 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-L02 dopo l’esercizio svolto e la revisione delle domande.