Aller au contenu
Financial Context Wiki

Chain ID

Guide fondé sur la vérification des chain ID EVM, domaines anti-rejeu EIP-155 des transactions legacy, transactions typées, CHAINID, contrôles wallet et RPC, domaines EIP-712 et identifiants non EVM.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Dans l’écosystème EVM, la chain ID est un entier configuré servant de paramètre de domaine anti-rejeu. EIP-155 la lie aux signatures protégées des transactions legacy ; les formats typés, comme le type 2, l’encodent dans leur payload signé ; CHAINID l’expose pendant l’exécution EVM ; eth_chainId la renvoie par JSON-RPC. Ces interfaces sont liées, mais ne constituent pas un certificat universel d’identité.

La valeur n’est ni garantie unique au niveau mondial ni permanente. Des réseaux privés et forks conflictuels peuvent la réutiliser, un RPC peut mentir et une même adresse peut contenir un code et un état différents selon la chaîne. EIP-712 comporte un champ chain ID facultatif, tandis que les messages bruts et systèmes non EVM suivent d’autres règles. Il faut donc connaître le schéma de signature, l’endpoint, le genesis ou checkpoint et le domaine applicatif exacts.

Fonctionnement

  1. Identifiez d’abord l’écosystème et la sémantique : entier EIP-155 EVM, domaine EIP-712, référence CAIP-2 avec namespace, chain ID textuelle Cosmos, genesis hash Solana ou autre schéma. Ne comparez jamais un nombre non qualifié entre écosystèmes.
  2. Fixez un instantané fiable : URL RPC, chain ID attendue en décimal et hexadécimal, genesis ou checkpoint finalisé, bloc de tête, configuration client, codeHash des contrats clés et date de la source. Nom et icône du réseau dans le wallet sont des métadonnées non fiables.
  3. Interrogez eth_chainId pour signer sur EVM et analysez la quantité hexadécimale JSON-RPC sans perte de précision. Comparez l’entier normalisé à la configuration et à l’état du provider ; ne remplacez pas par net_version ; refusez tout écart avant de signer.
  4. Reconstituez le domaine exact. Distinguez transactions legacy non protégées, legacy EIP-155 et enveloppes typées ; pour EIP-712, vérifiez champs du domaine, verifyingContract, nonce et deadline ; pour intents relayés ou smart accounts, inspectez le hash interne du protocole.
  5. Vérifiez sur la chaîne active destinataire, valeur, calldata, adresse du token, code ou implémentation proxy, nonce, frais et état simulé. La chain ID sépare un domaine, mais n’authentifie aucun de ces objets.
  6. Traitez chainChanged d’EIP-1193, changements de compte et déconnexions comme des frontières strictes. Supprimez cotation, allowance, nonce, simulation et requête de signature en cache, relisez chaîne et cible et ne diffusez que la transaction brute vérifiée vers l’endpoint fixé.
  7. Rapprochez sur la chaîne prévue bytes signés et hash, acceptation RPC, statut du reçu, numéro et hash de bloc, consommation du nonce, changements d’état et finalité. Surveillez forks, changements d’ID, confusion L1/L2 et dérive du provider ; arrêtez-vous face à toute différence inexpliquée.

Exemples détaillés

  • Contrôle RPC hexadécimal et décimal. Base a la chain ID décimale 8453, renvoyée par eth_chainId sous la forme 0x2105 : 2 * 4096 + 1 * 256 + 0 * 16 + 5 = 8453. Ethereum mainnet vaut 1 = 0x1 et Arbitrum One 42161 = 0xa4b1. Si le wallet attend 8453 mais reçoit 0x1, il doit abandonner avant signature.
  • v d’une transaction legacy protégée. Pour EIP-155, v = 35 + 2 * chainId + yParity. Avec l’ID 1, les valeurs sont 37 ou 38 ; avec l’ID 61, 157 ou 158. Inversement, floor((37 - 35) / 2) = 1. Ce calcul ne vaut ni pour y-parity des transactions typées ni pour les signatures legacy non protégées avec 27 ou 28.
  • Transaction typée et rejet sur la mauvaise chaîne. Un payload de type 2 lie chain_id=8453. Avec 21,000 gas, base fee 20 gwei, priority fee maximal 2 gwei et fee maximal 30 gwei, le prix effectif est min(30, 20 + 2) = 22 gwei et les frais 21,000 * 22 gwei = 0.000462 ETH. Une chaîne appliquant correctement l’ID 1 rejette le payload pour écart de domaine sans consommation de gas on-chain ; il peut encore échouer pour une autre raison sur l’ID 8453.
  • Identifiants doubles et non EVM. Cosmos EVM peut utiliser l’ID texte Cosmos SDK local-1 et l’ID entier EVM indépendant 262144 = 0x40000. La signature native Cosmos utilise texte, numéro de compte et sequence ; la signature EVM utilise l’entier. Solana utilise genesis hash et recent blockhash ou durable nonce, non un entier EIP-155.

Risques

  • Mauvais endpoint RPC ou mauvaise chaîne active.
  • RPC malveillant sur l’ID, l’état ou la diffusion.
  • Confusion hexadécimal/décimal.
  • Perte de précision numérique.
  • net_version pris pour eth_chainId.
  • Événement chainChanged ou course de bascule manqués.
  • Réutilisation de nonces, cotations, approvals ou simulations.
  • Unicité mondiale sans collision supposée.
  • Signature sur réseaux privés ou forks avec le même ID.
  • Comportement après fork non défini.
  • Transaction legacy non protégée acceptée.
  • Formule legacy v appliquée ailleurs.
  • Domaine supposé dans message brut ou personal_sign.
  • Chain ID EIP-712 omise ou mal encodée.
  • verifyingContract, nonce, deadline ou objectif omis.
  • Adresse identique sans comparaison du code et de l’état.
  • Confusion des domaines L1, L2, origine et destination.
  • Domaine interne d’intent, permit ou smart account ignoré.
  • Métadonnées, explorer ou icône pris pour authentification.
  • Sémantique EVM transposée à un autre protocole.

Idées reçues

  • La chain ID est un numéro officiel mondial, unique et permanent.
  • Une chain ID correcte authentifie RPC, réseau et contrats.
  • Toute signature Ethereum lie automatiquement la chain ID.
  • Des ID différents empêchent le rejeu de tout message signé.
  • Toute blockchain utilise un entier de type EIP-155.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...