Chain ID Ethereum et identifiant réseau : les différences

Le chain ID d’Ethereum apporte un contexte que la seule chaîne de caractères d’une adresse ne fournit pas. L’identifiant renvoyé par eth_chainId correspond à la valeur configurée pour la signature des transactions protégées contre le rejeu selon EIP-155. L’identifiant réseau renvoyé par net_version répond à une question définie séparément. Associer chaque résultat au nom de sa méthode évite de confondre ces deux identifiants.

Pour lire correctement ces informations, distinguez trois éléments : le texte de l’adresse, l’identifiant indiqué et le contexte réseau concerné. Les explications suivantes s’appuient sur la documentation et sur un exemple hypothétique. Une liste de vérification permet ensuite d’appliquer ces distinctions à des données déjà disponibles, sans signer de demande dans un portefeuille.

Chain ID et identifiant réseau : deux rôles distincts

La documentation JSON-RPC d’Ethereum définit net_version comme une méthode qui renvoie l’identifiant du réseau actuel sous forme de chaîne de caractères. Lorsque vous consignez ce résultat, gardez cette signification : il s’agit de l’identifiant réseau déclaré par le nœud qui répond.

De son côté, eth_chainId renvoie le chain ID actuellement configuré, utilisé pour la signature des transactions protégées contre le rejeu selon EIP-155. Les deux méthodes ont donc des rôles documentés différents. Avant d’interpréter un nombre, il faut savoir quelle méthode l’a fourni.

Une comparaison numérique ne remplace pas ces définitions. Même si deux résultats enregistrés représentent le même nombre, conservez deux champs distincts. Cette égalité ne suffit pas à expliquer pourquoi ces valeurs ont été configurées, ni à rendre les deux méthodes interchangeables.

Lire la notation et le contexte de la réponse

EIP-695 précise que le résultat de eth_chainId représente un entier sous forme de chaîne hexadécimale. Par exemple, 0x1 représente l’entier un. Dans une comparaison de résultats enregistrés, distinguez une différence d’écriture d’une différence entre les nombres représentés.

La proposition recommande de privilégier eth_chainId plutôt que net_version pour identifier la chaîne avec laquelle on communique. Cette recommandation suppose une mise en œuvre correcte. Citer la spécification n’authentifie pas un point d’accès particulier et ne suffit pas à établir sa sécurité.

La réponse possède également un contexte précis : le chain ID renvoyé doit correspondre aux informations du dernier bloc connu du client. Il s’agit d’une exigence de la spécification, pas d’une preuve qu’une réponse donnée la respecte effectivement.

EIP-695 prévoit une erreur de type « méthode non prise en charge » lorsque ce dernier bloc connu ne précise aucun chain ID. Cette condition doit rester attachée à l’explication. L’échec quelconque d’une demande n’établit pas, à lui seul, que cette condition s’est produite. Pour analyser un relevé, mieux vaut laisser une erreur inexpliquée que lui substituer un identifiant supposé.

La portée du chain ID dans la protection contre le rejeu

EIP-155 décrit un schéma de hachage des transactions qui intègre le chain ID pour la protection contre le rejeu. Les conditions indiquées sont que le numéro du bloc ait atteint le seuil d’activation prévu et qu’un chain ID soit disponible. L’élément à retenir ici est la place de cet identifiant dans le schéma, sans entrer dans la construction ou la signature d’une transaction.

La proposition conserve aussi le schéma de signature antérieur utilisant les valeurs v égales à 27 et 28, selon ses règles précédentes. Cette disposition de compatibilité ne permet pas de conclure à la politique d’acceptation actuelle de chaque chaîne ou de chaque client.

EIP-155 encourage les futurs réseaux de test, chaînes de consortium et chaînes alternatives à Ethereum qui l’adoptent à choisir des chain ID uniques. Une recommandation de ce type ne prouve pas que toutes les chaînes indépendantes utilisent effectivement des valeurs distinctes.

Ces éléments permettent une déduction limitée : le schéma protégé intègre le chain ID, le schéma antérieur reste prévu dans la proposition et les adoptants sont encouragés à choisir des valeurs uniques. La séparation fondée sur le chain ID suppose donc l’utilisation du schéma protégé avec des identifiants différents. Ces prémisses n’établissent pas la même protection pour l’ancien schéma, pour des chaînes partageant un identifiant ou pour toute catégorie de demande signée.

Pourquoi le format d’une adresse ne suffit pas

La documentation sur les comptes Ethereum décrit l’adresse d’un compte externe, ou EOA, comme une valeur de 20 octets représentée par 40 caractères hexadécimaux, précédés de 0x. Cette description porte sur la représentation de l’adresse.

Par ailleurs, la documentation sur les réseaux Ethereum explique que des réseaux indépendants peuvent respecter le protocole sans interagir entre eux. EIP-695 documente séparément la méthode d’identification de la chaîne présentée plus haut.

En combinant ces prémisses, on obtient une déduction logique : une adresse hypothétique respectant ce format ne peut pas, à elle seule, établir l’identité de la chaîne. Son apparence ne sélectionne aucun contexte parmi ces réseaux indépendants. Cette conclusion découle du rapprochement des sources ; elle n’est pas une affirmation directement citée de la page sur les comptes.

Sa portée reste limitée à l’identification. Elle n’établit rien sur les soldes, le déploiement de contrats, la présence de fonds, le contrôle par une clé privée ou les possibilités de récupération d’actifs sur différents réseaux.

Exemple hypothétique : une adresse sur deux fiches

Imaginons deux fiches documentaires fictives, A et B. Toutes deux affichent 0x1111111111111111111111111111111111111111. Pour cet exercice, la fiche A indique un résultat eth_chainId de 0x65, tandis que la fiche B indique 0xca. Ces données sont inventées à des fins pédagogiques : elles ne décrivent ni des points d’accès réels ni des comptes dont l’existence serait établie.

Le texte répété fournit la même représentation d’adresse sur les deux fiches. Les résultats de chain ID posés dans l’exemple fournissent, eux, des contextes de chaîne différents. Selon la déduction précédente, l’adresse seule ne permet pas de décider quelle chaîne est visée.

Masquez maintenant les champs de chain ID. L’adresse conserve son format visible, mais l’exercice a retiré l’indication explicite du contexte de chaîne. Réafficher ces champs rend la distinction lisible. Rien dans cet exemple n’attribue un solde, n’établit un déploiement de contrat ou ne désigne la personne qui contrôlerait un compte.

Liste de vérification en lecture seule

Nommez le contexte visé. Notez la chaîne concernée par l’explication avant d’interpréter une adresse.
Conservez les noms des méthodes. Étiquetez un résultat existant de eth_chainId comme chain ID, et un résultat de net_version comme identifiant réseau.
Lisez correctement l’hexadécimal. Comparez les entiers représentés, sans considérer toute différence de texte comme une différence de valeur.
Gardez les limites de la réponse. Retenez l’exigence relative au dernier bloc connu du client et laissez les erreurs inexpliquées en suspens.
Délimitez les conclusions sur le rejeu. Identifiez le schéma protégé et des chain ID différents avant de conclure à la séparation fondée sur cet identifiant.
Respectez le rôle du format d’adresse. Utilisez-le pour décrire la représentation, tout en traitant l’identité de la chaîne comme une question distincte.

Cette liste s’applique à la documentation ou à des réponses déjà enregistrées. Elle ne nécessite ni envoi de transaction ni signature dans un portefeuille.

Article pédagogique préparé avec l’aide de l’intelligence artificielle. L’exemple hypothétique sert à illustrer les distinctions documentées.