Vérification du réseau et de l’explorateur

Version source EN · P02-L06 · 30 minutes estimées · needs_review

Étude en lecture seule. Aucune connexion de portefeuille, aucun argent réel, aucune phrase de récupération, clé privée, signature ou transaction de marché en direct. La durée est une estimation éditoriale ; les éléments visuels sont des spécifications, pas des composants déployés.

Une adresse ou une transaction d’apparence techniquement valide peut être interrogée sur le mauvais réseau. Le titre d’une page remplace mal un contexte réseau sourcé.

Partir d’un contexte indépendant

Les réseaux Ethereum ont des identifiants propres à chaque réseau [NET]. Solana propose une requête d’empreinte du bloc de genèse [GENESIS]. Ces éléments aident à distinguer les contextes, mais la réponse provient toujours d’un point d’accès. Un service malveillant ou mal configuré peut retourner une chaîne plausible. Consignez comment le point d’accès a été choisi, pas seulement le nom qu’il s’attribue.

Faire correspondre le tuple complet

Une clé de recherche comprend le réseau, l’identifiant exact de l’actif ou de la transaction et le contexte d’observation. Pour un token, gardez le contrat ou le mint distinct du compte qui le détient. Une adresse réutilisée sur plusieurs réseaux EVM n’implique pas un code, un solde ou une activité communs.

Le domaine et la marque d’un explorateur indiquent la provenance du fournisseur, pas une preuve que le réseau est correct. Recoupez avec une documentation ou une configuration établies indépendamment. Une publicité de recherche ou un lien non sollicité n’est pas une origine fiable simplement parce que le site affiche un nom de chaîne familier.

Comparer des enregistrements de même périmètre

Lorsque deux sources divergent, demandez si elles ont interrogé le même réseau, identifiant et bloc ou niveau de confirmation. Des instants d’observation différents peuvent expliquer une différence sans prouver qu’une source est malveillante. Deux pages utilisant les mêmes données en amont ne constituent pas nécessairement des observations indépendantes.

Un identifiant de chaîne résolu est une preuve utile, mais n’authentifie pas chaque enregistrement retourné [RPC]. Gardez distincts les niveaux de vérification : réseau visé, identifiant retourné, contexte des données et confiance dans le fournisseur.

Ne pas conclure en présence de divergences non résolues

Ne faites pas la moyenne de réponses réseau incompatibles et ne choisissez pas celle dont l’interface est plus agréable. Conservez chaque réponse et marquez la conclusion sur l’état visé comme non résolue. L’action suivante est un contrôle ciblé de provenance, pas un transfert réel pour tester quel service a raison. Tous les identifiants de l’exercice sont des étiquettes d’entraînement invalides.

Classification des états de preuve

OBSERVED dans l’exercice : les champs d’identifiant et de genèse attendus et retournés, ainsi que le titre incohérent de E2. INFERRED : E2 entre en conflit avec le contexte visé stipulé. UNKNOWN : l’authenticité indépendante des points d’accès et la propriété des services. INSUFFICIENT EVIDENCE : un identifiant concordant authentifie chaque enregistrement retourné ou une divergence établit une intention malveillante.

• Identifiant de chaîne : valeur du contexte réseau.
• Empreinte de genèse : identifiant de l’état de genèse d’un réseau, interprété selon ses règles.
• Provenance du point d’accès : origine et sélection d’un service.
• Recoupement : comparaison avec des preuves établies séparément.

ILLUSTRATIVE. La configuration d’entraînement fiable attend l’identifiant101 de NET-A et GENESIS-A. Le point d’accès E1 retourne101/GENESIS-A. E2 retourne202/GENESIS-B tandis que son titre indique NET-A. Les deux affichent ACCOUNT-X. La propriété indépendante des services n’est pas établie.

Tableau de comparaison mint/réseau : attendu101/A, E1 concordant, E2 conflit202/B ; colonne distincte d’authenticité UNKNOWN. Texte alternatif : E1 concorde mais n’est pas authentifié ; le titre de E2 ne résout pas sa divergence.

La concordance ou le conflit entre les identifiants fournis.

L’authenticité des points d’accès, l’intégrité des enregistrements, des soldes égaux entre chaînes ou une intention malveillante.

• Faire confiance au titre d’une page plutôt qu’aux identifiants.
• Traiter des adresses identiques comme un état identique.
• Transformer une divergence en accusation.

Rédigez un tableau comparatif. Quel résultat contredit le contexte visé ? La concordance de E1 prouve-t-elle son authenticité ? Que faut-il garder UNKNOWN ?

Présenter un court tableau des éléments de preuve et le raisonnement, uniquement à partir du matériel fourni. Répartition suggérée : étude 12 min, inspection/calcul 8 min, correction/quiz 10 min.

• Réseau visé.
• Identifiants retournés.
• Origine de la source.
• Même contexte d’observation.
• Consigner les divergences.

Une adresse ou une transaction d’apparence techniquement valide peut être interrogée sur le mauvais réseau. Le titre d’une page remplace mal un contexte réseau sourcé. Le matériel fourni permet de constater la concordance ou le conflit entre les identifiants fournis. Il n’établit ni l’authenticité des points d’accès, ni l’intégrité des enregistrements, ni des soldes égaux entre chaînes, ni une intention malveillante.

• Recouper les identifiants du réseau et la provenance des sources.
• Séparer la concordance des identifiants de l’authenticité du point d’accès.
• Conserver les conflits sans en deviner la résolution.

P02-L07 après examen de cet exercice et de ses prérequis.

NONE. Le catalogue de référence n’exige aucun accès au produit pour cette leçon. Utiliser le matériel figé/hors ligne.

• [NET] Réseaux Ethereum — Réseaux distincts et identifiants de chaîne propres à chaque réseau. Vérifié 2026-10-01.
• [GENESIS] Solana getGenesisHash — Identifiant de genèse réseau retourné par un point d’accès ; ne constitue pas une authentification de ce point d’accès. Vérifié 2026-10-01.
• [RPC] Ethereum JSON-RPC — Statut du reçu, contexte du bloc et résultats d’API dans le périmètre du réseau. Vérifié 2026-10-01.

Les valeurs synthétiques sont des données d’entrée d’exercice créées par l’auteur. Les valeurs historiques éventuelles doivent utiliser le jeu de données lié et sa provenance plus restreinte. L’inspection des sources ne constitue pas une acceptation éditoriale indépendante.