Vérification exacte du contrat et du mint

Source maître EN · P08-L01 · 45 minutes estimées · needs_review

Chaque calcul ultérieur dépend de l’analyse de l’actif voulu. Un audit correct des permissions du mauvais contrat reste une investigation échouée. Noms, symboles et icônes facilitent la navigation mais ne peuvent servir de clés primaires. Cette leçon étend la reconnaissance exacte du mint à un relevé d’identité reproductible distinguant le rôle du compte et la logique qui le régit.

Vous ferez correspondre une cible déclarée aux enregistrements fournis, identifierez les preuves d’implémentation manquantes et écrirez un résultat qu’un autre analyste peut reproduire. Vous ne signerez, n’approuverez ni n’achèterez rien.

Construire le tuple d’identité

Commencer par le réseau, l’adresse exacte et le type d’objet. Distinguer le réseau principal des environnements de test et les différentes chaînes EVM. Une chaîne ressemblant à une adresse est incomplète à elle seule. Une URL d’explorateur peut sélectionner un autre réseau même si l’adresse affichée semble familière. Préserver le réseau demandé lorsqu’une recherche renvoie un sosie plus populaire.

Écrire l’identifiant complet plutôt qu’un préfixe abrégé. Lors d’une inspection réelle, valider l’encodage et comparer les octets d’adresse décodés avec un outil fiable. La casse de somme de contrôle EVM et les conventions base58 de Solana exigent des traitements différents. Le jeu utilise des libellés invalides afin qu’aucun apprenant ne puisse accidentellement effectuer une transaction avec eux ; ses comparaisons sont des comparaisons pédagogiques de chaînes.

Demander quel objet l’identifiant nomme. Un mint Solana est distinct d’un compte de jetons détenant des unités et du Token Program contenant la logique des instructions [S08-TOKENS]. Une implémentation EVM derrière un proxy n’est pas automatiquement l’adresse de solde utilisée par l’utilisateur. Décrire le rôle avant d’utiliser les valeurs.

Distinguer existence, logique et affiliation

Une source renvoyant un compte prouve un objet dans un contexte, pas qu’une marque le soutient. La vérification du code source d’un explorateur concerne la correspondance entre source et code déployé ; elle ne certifie ni affiliation officielle ni exhaustivité d’audit. Ces questions exigent des enregistrements distincts [S08-CODE]. Etherscan distingue les correspondances exactes des similaires ; une correspondance similaire peut laisser des différences de constructeur ou d’initialisation. Inspecter le type déclaré de correspondance au lieu de traiter tous les badges comme le même constat.

Utiliser des résultats distincts : objet exact correspondant, implémentation non résolue et affiliation non corroborée. Une correspondance d’identité positive ne résout pas les deux autres. Si une correspondance de code est fournie, préserver le compilateur, la configuration et le périmètre de déploiement au lieu de la paraphraser par « sûr ».

ERC-20 décrit une interface ; nom et symbole sont des métadonnées facultatives, et la compatibilité ne certifie pas un projet [S08-ERC20]. Recevoir le symbole attendu ne peut donc régler l’affiliation. Une implémentation peut exposer des méthodes familières tout en incluant des contrôles supplémentaires non décrits par l’interface de base.

Retracer la limite de logique

Pour un mint Solana, consigner le Token Program propriétaire de son compte de données. Ne pas confondre le champ de programme propriétaire de base avec le champ propriétaire du compte de jetons utilisé pour les avoirs. Un mint avec extensions exige un décodage tenant compte des extensions. Un analyseur de base ignorant l’état supplémentaire ne peut établir qu’aucun comportement supplémentaire n’existe.

Pour un proxy, l’adresse de jeton demandée peut rester stable tandis que la logique déléguée change. ERC-1967 décrit le lien d’implémentation ou de beacon et un emplacement facultatif d’administrateur [S08-PROXY]. Le déploiement réel détermine l’applicabilité ; des emplacements standard vides n’établissent pas que tout mécanisme possible de mise à niveau est absent.

Garder ensemble adresse du proxy, implémentation et contexte. Du code dans un contexte et un état dans un autre créent un relevé mélangé. Si le lien est indisponible, identifier l’objet utilisé par l’utilisateur tout en marquant la résolution de logique incomplète. Ne jamais remplir cette lacune avec le contrat qu’une interface étiquette « implémentation ».

Préserver la provenance de récupération

Consigner source, heure de récupération, contexte de bloc ou slot lorsqu’il est renvoyé, niveau d’engagement/finalité et hypothèses du décodeur. Un délai d’attente dépassé signifie des données indisponibles. Une réponse du mauvais réseau est une discordance, pas une absence sur le réseau voulu. Ne pas réessayer silencieusement sur une autre chaîne et combiner ces valeurs.

Deux interfaces peuvent partager un indexeur. Leur accord est utile mais ne représente pas automatiquement deux observations indépendantes. Consigner la source sous-jacente si elle est visible ; sinon indiquer que l’indépendance est inconnue. Un enregistrement brut et son décodage sont plus reproductibles qu’une image recadrée sans l’identifiant exact.

Distinguer cibles déclarées et corroborées. Une capture affirmant une adresse officielle est une déclaration. Y correspondre prouve seulement que vous avez inspecté l’objet qu’elle nomme. L’affiliation exige des sources d’émetteur correctement authentifiées avec contexte de capture, et même une affiliation corroborée ne prouve pas la sécurité.

Utiliser une règle d’arrêt

Arrêter les conclusions dépendant de l’identité lorsque le tuple ne correspond pas ou que le rôle de l’objet n’est pas résolu. Vous pouvez toujours documenter la lacune ; vous ne pouvez attribuer l’offre ou les permissions d’un autre actif à la cible. Une correspondance générique de résultat de recherche n’est pas un substitut.

Un constat concis pourrait dire : « Le réseau/l’adresse demandés correspondent à un mint dans S0 fourni. Son inventaire d’extensions et son affiliation à l’émetteur ne sont pas fournis. » Cela préserve un constat positif et ses limites. Un relevé complet doit aussi indiquer quelles preuves supplémentaires permettraient l’étape suivante.

Un réviseur indépendant doit pouvoir partir de votre tuple sans deviner quel onglet de réseau ou quelle adresse tronquée vous avez sélectionné. La vérification en lecture seule protège ce processus : aucune approbation de portefeuille n’est nécessaire pour établir l’identité d’un objet, et aucun exercice n’exige d’identifiants de connexion.

• Tuple d’identité : réseau, adresse complète et rôle de l’objet.
• Mint : compte Solana représentant un jeton.
• Compte de jetons : compte distinct détenant des unités pour un mint.
• Implémentation : logique utilisée par un contrat délégué.
• Provenance : source et contexte étayant un enregistrement.
• Affiliation : relation affirmée avec un émetteur ou une marque.

ILLUSTRATIVE — FIX-P08-01. S0 est fictif, pas un bloc réel. La déclaration D1 demande SIM-SOL-A / MINT-ALPHA comme mint ; l’attribution à l’émetteur n’est pas authentifiée.

I1 contient les champs de base mais aucun inventaire d’extensions. I5 a un lien mais aucune correspondance source/compilation.

OBSERVED dans le jeu : I1 correspond au tuple de D1 ; I3 référence son mint mais a un rôle différent.

INFERRED: I1 est le bon enregistrement de départ pour une inspection de base. I5/I6 décrivent un lien de proxy fourni distinct.

UNKNOWN: Affiliation, état d’extension omis et correspondance code/compilation de I5.

INSUFFICIENT EVIDENCE: Des symboles égaux ne peuvent faire de I2/I4 la cible. I6 portant la logique ne peut remplacer I5 utilisé par l’utilisateur.

Faire correspondre uniquement les symboles, oublier le réseau, substituer un compte de détention à un mint, analyser les soldes d’implémentation et appeler la visibilité de la source un certificat de sécurité.

Choisir la correspondance de D1 ; rejeter I2–I4 avec des raisons individuelles. Écrire une note d’identité distincte de I5. Lister trois lacunes de preuves avant un examen complet du comportement de I1.

• Préserver réseau et identifiant complet.
• Vérifier le rôle et le lien programme/logique.
• Faire correspondre les contextes avant de combiner les preuves.
• Distinguer affiliation et examen du code.
• Arrêter lorsque les entrées dépendant de l’identité ne correspondent pas.

La vérification d’identité produit un relevé d’objet circonscrit. Le bon réseau et le bon rôle sont des préalables aux mesures ultérieures.

Un symbole est un libellé. Mints, comptes de détenteurs et implémentations sont des objets différents. Les preuves manquantes de lien ou d’affiliation restent visibles.

Comparer D1 à I1–I4 en annotant les différences de réseau/adresse/rôle. Placer I5→I6 dans un panneau distinct de logique S0 ; marquer la correspondance de compilation inconnue. Éviter les badges de sécurité.

Correspondance d’identité illustrative ; aucune corroboration d’émetteur.

Utiliser du SVG/HTML déterministe ou des graphiques avec alternatives textuelles, bleu marine foncé/noir et accents mesurés cyan, bleu électrique et violet. Étiqueter chaque quantité et incertitude. À 390px, empiler les panneaux ; la vérification 768px/ordinateur et RTL arabe reste un travail futur sur les actifs. Garder les identifiants LTR et les axes factuels/sens des arêtes inchangés. Utiliser uniquement la marque officielle BlockAssay fournie si une identité de marque est ajoutée. Les deux enregistrements sont des spécifications, pas des actifs livrés.

Utiliser RADAR pour l’objectif pédagogique circonscrit de la leçon uniquement si la prise en charge du réseau, l’identité exacte, les champs et la provenance sont vérifiés. Ce contenu n’affirme aucun point de terminaison d’exécution ni capacité de fournisseur. Utiliser le jeu hors ligne intégré sans accès payant. Les données manquantes restent inconnues ; aucune connexion de portefeuille, signature de transaction, lancement de jeton ou transaction en direct n’est requis. Les progrès Academy, paiements et recommandations ne changent jamais les preuves Radar. Un Passeport diagnostique préserve observations et limites, pas une prévision de prix ni un certificat de sécurité.

• Onglet de code de contrat Etherscan — Libellés de correspondance exacte contre similaire du bytecode et informations distinctes de compilateur/constructeur/audit. Vérifié le 2026-09-30.
• Actifs Solana — Identité mint/compte/programme et décimales ; distinguer les champs de propriété de compte. Vérifié le 2026-09-30.
• Norme de jeton ERC-20 — Interface standard ; nom, symbole et décimales facultatifs ; aucune certification de privilèges ou d’identité. Vérifié le 2026-09-30.
• Emplacements de stockage de proxy ERC-1967 — Emplacements d’implémentation, beacon et administrateur facultatif ; inspection propre au mécanisme. Vérifié le 2026-09-30.

La documentation étaye les mécanismes, pas les valeurs fictives du jeu. Tous les exemples et enregistrements d’exercice sont du matériel original ILLUSTRATIVE, figé dans ce fichier. S0/S1 sont des libellés synthétiques de contexte ; observedAt est null car aucune mesure de registre en direct ou historique n’a été collectée. Réexaminer la documentation et le comportement réellement déployé avant toute publication ou intégration.

P08-L02 après l’exercice corrigé et l’examen du quiz.