Verifica esatta di contratto e mint

EN fonte principale · P08-L01 · 45 minuti stimati · needs_review

Ogni calcolo successivo dipende dall’analisi dell’asset inteso. Un audit corretto dei permessi del contratto sbagliato è comunque un’indagine fallita. Nomi, simboli e icone aiutano la navigazione ma non possono essere chiavi primarie. Questa lezione estende il riconoscimento del mint esatto a un record d’identità riproducibile che distingue il ruolo dell’account e la logica che lo governa.

Farai corrispondere un obiettivo dichiarato ai record forniti, identificherai prove mancanti dell’implementazione e scriverai un risultato ripetibile da un altro analista. Non firmerai, approverai o acquisterai nulla.

Costruire la tupla d’identità

Iniziare con rete, indirizzo esatto e tipo di oggetto. Distinguere mainnet da ambienti di test e diverse blockchain EVM. Una sola stringa a forma di indirizzo è incompleta. Un URL di explorer può selezionare una rete diversa anche quando l’indirizzo visualizzato sembra familiare. Preservare la rete richiesta quando una ricerca restituisce un sosia più popolare.

Scrivere l’identificatore completo anziché un prefisso abbreviato. Nell’esame reale convalidare la codifica e confrontare i byte decodificati dell’indirizzo con uno strumento affidabile. Maiuscole/minuscole del checksum EVM e convenzioni base58 Solana richiedono gestioni diverse. Il materiale usa etichette invalide perché nessuno possa transare accidentalmente con esse; i confronti sono confronti educativi di stringhe.

Chiedere quale oggetto denomina l’identificatore. Un mint Solana è distinto da un account token che contiene unità e dal Token Program che contiene la logica delle istruzioni [S08-TOKENS]. Un’implementazione EVM dietro un proxy non è automaticamente l’indirizzo dei saldi rivolto all’utente. Descrivere il ruolo prima di usare valori.

Separare esistenza, logica e affiliazione

Una fonte che restituisce un account è prova di un oggetto a un contesto, non prova che un marchio lo approvi. La verifica del codice sorgente di un explorer riguarda la corrispondenza tra sorgente e codice distribuito; non certifica affiliazione ufficiale o completezza dell’audit. Queste domande richiedono record separati [S08-CODE]. Etherscan distingue corrispondenze esatte e simili; una corrispondenza simile può lasciare differenze di costruttore o inizializzazione. Esaminare il tipo dichiarato di corrispondenza anziché trattare ogni badge come lo stesso risultato.

Usare esiti distinti: oggetto esatto corrispondente, implementazione irrisolta e affiliazione senza riscontro. Una corrispondenza positiva d’identità non risolve le altre due. Se è fornita corrispondenza del codice, preservare compilatore, configurazione e ambito di distribuzione anziché parafrasarli come «sicuro».

ERC-20 descrive un’interfaccia; nome e simbolo sono metadati opzionali e la compatibilità non certifica un progetto [S08-ERC20]. Ricevere il simbolo atteso non può quindi risolvere l’affiliazione. Un’implementazione può esporre metodi familiari includendo controlli aggiuntivi non descritti dall’interfaccia di base.

Tracciare il limite della logica

Per un mint Solana registrare il Token Program proprietario del suo account dati. Non confondere il campo proprietario del programma di base con il campo proprietario dell’account token usato per le detenzioni. Un mint con estensioni richiede decodifica consapevole delle estensioni. Un parser di base che ignora stato aggiuntivo non può stabilire che non esista comportamento aggiuntivo.

Per un proxy, l’indirizzo del token richiesto può restare stabile mentre cambia la logica delegata. ERC-1967 descrive collegamenti a implementazione o beacon e uno slot amministratore opzionale [S08-PROXY]. La distribuzione effettiva determina l’applicabilità; slot standard vuoti non stabiliscono che ogni possibile meccanismo di aggiornamento sia assente.

Tenere insieme indirizzo del proxy, implementazione e contesto. Codice a un contesto e stato a un altro creano un record misto. Se il collegamento non è disponibile, identificare l’oggetto rivolto all’utente indicando come incompleta la risoluzione della logica. Non riempire mai quella lacuna con qualsiasi contratto che un’interfaccia etichetta «implementazione».

Preservare la provenienza del recupero

Registrare fonte, tempo di recupero, contesto di blocco o slot dove restituito, livello di conferma/finalità e ipotesi del decodificatore. Un timeout significa dati non disponibili. Una risposta della rete sbagliata è mancata corrispondenza, non assenza sulla rete intesa. Non ritentare silenziosamente su una blockchain diversa e combinare quei valori.

Due interfacce possono condividere un indicizzatore. L’accordo è utile ma non è automaticamente due osservazioni indipendenti. Registrare la fonte sottostante se visibile; altrimenti dichiarare sconosciuta l’indipendenza. Un record grezzo e la sua decodifica sono più riproducibili di un’immagine ritagliata senza identificatore esatto.

Separare obiettivi dichiarati e riscontrati. Una schermata che dichiara un indirizzo ufficiale è una dichiarazione. Farla corrispondere dimostra soltanto che hai esaminato l’oggetto nominato. L’affiliazione richiede fonti dell’emittente adeguatamente autenticate con contesto di acquisizione, e nemmeno un’affiliazione riscontrata dimostra sicurezza.

Usare una regola di arresto

Fermare conclusioni dipendenti dall’identità quando la tupla non corrisponde o il ruolo dell’oggetto è irrisolto. Puoi comunque documentare la lacuna; non puoi associare offerta o permessi di un altro asset all’obiettivo. Una corrispondenza generica di ricerca non è un sostituto.

Un risultato conciso potrebbe dire: «La rete/indirizzo richiesta si risolve in un mint in S0 fornito. Il suo inventario di estensioni e l’affiliazione all’emittente non sono forniti». Questo preserva un risultato positivo e i suoi limiti. Un record completo dovrebbe anche dichiarare quali prove aggiuntive consentirebbero il passaggio successivo.

Un revisore indipendente dovrebbe poter partire dalla tupla senza indovinare quale scheda di rete o indirizzo troncato hai selezionato. La verifica in sola lettura protegge questo flusso di lavoro: non serve approvazione del wallet per stabilire l’identità di un oggetto e nessun esercizio richiede credenziali.

• Tupla d’identità: rete, indirizzo completo e ruolo dell’oggetto.
• Mint: account Solana che rappresenta un token.
• Account token: account separato che contiene unità per un mint.
• Implementazione: logica usata da un contratto delegato.
• Provenienza: fonte e contesto che sostengono un record.
• Affiliazione: relazione dichiarata con un emittente o marchio.

ILLUSTRATIVE — FIX-P08-01. S0 è fittizio, non un blocco reale. La dichiarazione D1 richiede SIM-SOL-A / MINT-ALPHA come mint; l’attribuzione all’emittente non è autenticata.

I1 contiene campi di base ma nessun inventario di estensioni. I5 ha un collegamento ma nessuna corrispondenza sorgente/build.

OBSERVED nel materiale: I1 corrisponde alla tupla di D1; I3 si riferisce al suo mint ma ha un ruolo diverso.

INFERRED: I1 è il record iniziale corretto per l’esame di base. I5/I6 descrivono un collegamento proxy separato fornito.

UNKNOWN: Affiliazione, stato omesso delle estensioni e corrispondenza codice/build di I5.

INSUFFICIENT EVIDENCE: Simboli uguali non possono rendere I2/I4 l’obiettivo. I6 che contiene logica non può sostituire I5 rivolto all’utente.

Far corrispondere soltanto simboli, dimenticare la rete, sostituire un account di detenzione a un mint, analizzare saldi dell’implementazione e chiamare la visibilità del sorgente un certificato di sicurezza.

Scegliere la corrispondenza D1; rifiutare I2–I4 con motivi individuali. Scrivere una nota d’identità separata per I5. Elencare tre lacune probatorie prima di una revisione completa del comportamento di I1.

• Preservare rete e identificatore completo.
• Verificare ruolo e collegamento programma/logica.
• Far corrispondere i contesti prima di combinare prove.
• Separare affiliazione e revisione del codice.
• Fermarsi quando dati dipendenti dall’identità non corrispondono.

La verifica d’identità produce un record circoscritto dell’oggetto. Rete e ruolo corretti sono prerequisiti per misurazioni successive.

Un simbolo è un’etichetta. Mint, account di detentori e implementazioni sono oggetti diversi. Prove mancanti di collegamento o affiliazione restano visibili.

Confrontare D1 con I1–I4, annotando differenze di rete/indirizzo/ruolo. Mettere I5→I6 in un pannello separato della logica S0; indicare sconosciuta la corrispondenza del build. Evitare badge di sicurezza.

Corrispondenza illustrativa d’identità; nessun riscontro dell’emittente.

Usare SVG/HTML deterministici o grafici con alternative testuali, blu navy scuro/nero e accenti sobri ciano, blu elettrico e viola. Etichettare ogni quantità e incertezza. A 390px impilare i pannelli; verifica a 768px/desktop e RTL arabo restano lavoro futuro sulle risorse. Tenere gli identificatori in LTR e invariati assi fattuali/direzioni degli archi. Usare soltanto il marchio ufficiale BlockAssay fornito se viene aggiunto il marchio. Entrambi i record sono specifiche, non risorse consegnate.

Usare RADAR per lo scopo educativo circoscritto della lezione soltanto se sono verificati supporto della rete, identità esatta, campi e provenienza. Questo contenuto non afferma alcun endpoint runtime o capacità del fornitore. Usare il materiale offline incorporato senza accesso a pagamento. I dati mancanti restano sconosciuti; non sono necessari collegamento a wallet, firma di transazioni, lancio di token o operazioni dal vivo. Progressi nell’Academy, pagamenti e referral non cambiano mai le prove di Radar. Un Diagnostic Passport preserva osservazioni e limiti, non una previsione di prezzo o un certificato di sicurezza.

• Scheda del codice del contratto Etherscan — Etichette di corrispondenza esatta rispetto a simile del bytecode e informazioni separate di compilatore/costruttore/audit. Verificato 2026-09-30.
• Asset Solana — Identità di mint/account/programma e decimali; distinguere campi di proprietà degli account. Verificato 2026-09-30.
• Standard di token ERC-20 — Interfaccia standard; nome, simbolo e decimali opzionali; non certificazione di privilegi o identità. Verificato 2026-09-30.
• Slot di memoria dei proxy ERC-1967 — Slot di implementazione, beacon e amministratore opzionale; esame specifico del meccanismo. Verificato 2026-09-30.

La documentazione sostiene meccanismi, non valori dei dataset fittizi. Tutti gli esempi e i record degli esercizi sono materiale originale ILLUSTRATIVE, fissato in questo file. S0/S1 sono etichette di contesto sintetiche; observedAt è null perché non è stata raccolta alcuna misurazione di un registro dal vivo o storico. Riesaminare documentazione e comportamento effettivamente distribuito prima di qualsiasi pubblicazione o integrazione.

P08-L02 dopo l’esercizio svolto e la revisione del quiz.