Ir para o conteúdo

Chain ID

Guia orientado à verificação sobre chain IDs EVM, domínios antirreplay EIP-155 de transações legacy, transações tipadas, CHAINID, verificações de wallet e RPC, domínios EIP-712 e identificadores de redes não EVM.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

No ecossistema EVM, chain ID é um inteiro configurado usado como parâmetro de domínio antirreplay. A EIP-155 o vincula às assinaturas protegidas de transações legacy; formatos tipados, como o tipo 2, o codificam no próprio payload assinado; CHAINID o expõe durante a execução EVM; e eth_chainId o informa via JSON-RPC. São interfaces relacionadas, não um certificado universal de identidade.

O valor não é garantidamente único no mundo nem permanente. Redes privadas e forks controversos podem reutilizá-lo, um RPC pode mentir e o mesmo endereço pode conter código e estado diferentes em chains distintas. A EIP-712 inclui um campo opcional de chain ID no domínio, enquanto mensagens brutas e sistemas não EVM usam outras regras de replay e identidade. O uso correto exige o esquema exato de assinatura, endpoint, genesis ou checkpoint e domínio da aplicação.

Como funciona

  1. Identifique primeiro o ecossistema e a semântica: inteiro EIP-155 EVM, domínio EIP-712, referência com namespace CAIP-2, chain ID textual Cosmos, genesis hash Solana ou outro esquema. Nunca compare entre ecossistemas um número sem qualificação.
  2. Fixe um snapshot confiável: URL RPC, chain ID esperado em decimal e hexadecimal, genesis ou checkpoint finalizado, bloco de cabeçalho, configuração do cliente, codeHash de contratos essenciais e data da fonte. Nome e ícone de rede da wallet são metadados não confiáveis.
  3. Consulte eth_chainId para assinatura EVM e analise a quantidade hexadecimal JSON-RPC sem perda de precisão. Compare o inteiro normalizado com a configuração esperada e o estado do provider da wallet; não substitua por net_version; rejeite divergências antes de construir a assinatura.
  4. Reconstrua o domínio exato. Distinga transações legacy desprotegidas, codificação legacy protegida EIP-155 e envelopes tipados; em EIP-712 verifique campos do domínio, verifyingContract, nonce e deadline; em intents retransmitidos ou de smart accounts examine o hash interno do protocolo.
  5. Verifique o alvo na chain ativa: destinatário, valor, calldata, endereço do token, código ou implementação do proxy, nonce da conta, taxas e estado simulado. Chain ID separa o domínio, mas não prova autenticidade desses objetos.
  6. Trate chainChanged da EIP-1193, mudanças de conta e desconexões como fronteiras rígidas. Descarte cotação, allowance, nonce, simulação e pedidos de assinatura em cache, releia chain e alvo e transmita apenas a transação bruta revisada ao endpoint fixado.
  7. Concilie na chain pretendida: bytes assinados e hash, aceitação RPC, status do recibo, número e hash do bloco, consumo de nonce, mudanças de estado e finalidade exigida. Monitore forks, mudanças de ID, confusão L1/L2 e desvio do provider; falhe de forma fechada diante de diferenças inexplicadas.

Exemplos resolvidos

  • Gate RPC hexadecimal e decimal. Base tem chain ID decimal 8453, representado por eth_chainId como 0x2105: 2 * 4096 + 1 * 256 + 0 * 16 + 5 = 8453. Ethereum mainnet é 1 = 0x1 e Arbitrum One 42161 = 0xa4b1. Se a wallet espera 8453 e recebe 0x1, deve abortar antes de assinar em vez de confiar no nome exibido.
  • v de transação legacy protegida. Para transações legacy EIP-155, v = 35 + 2 * chainId + yParity. Com chain ID 1, os valores são 37 ou 38; com chain ID 61, 157 ou 158. Inversamente, floor((37 - 35) / 2) = 1. A aritmética não vale para y-parity de transações tipadas nem para assinaturas legacy desprotegidas com 27 ou 28.
  • Transação tipada e rejeição na chain errada. Um payload tipo 2 vincula chain_id=8453. Com 21,000 gas, base fee de 20 gwei, prioridade máxima de 2 gwei e taxa máxima de 30 gwei, o preço efetivo é min(30, 20 + 2) = 22 gwei e a taxa 21,000 * 22 gwei = 0.000462 ETH. Uma chain que aplique corretamente ID 1 rejeita o payload assinado por divergência de domínio; essa rejeição não consome gas on-chain ali. A transação ainda pode falhar por outros motivos no ID 8453.
  • Identificadores duais e não EVM. Uma implantação Cosmos EVM pode usar ID textual Cosmos SDK local-1 e ID inteiro EVM independente 262144 = 0x40000. A assinatura Cosmos-native usa a string com número da conta e sequence; a assinatura EVM usa o domínio inteiro. Solana expõe um genesis hash e usa recent blockhash ou durable nonce, não inteiro EIP-155.

Riscos

  • Conectar ao RPC ou à chain ativa errados.
  • Confiar em RPC malicioso sobre ID, estado ou broadcast.
  • Confundir hexadecimal e decimal.
  • Perder precisão com tipo numérico inseguro.
  • Usar net_version como equivalente a eth_chainId.
  • Perder chainChanged ou corrida de troca.
  • Reutilizar nonces, cotações, approvals ou simulações.
  • Supor registro global sem colisões.
  • Assinar em redes privadas ou forks com o mesmo ID.
  • Não definir comportamento de ID após fork.
  • Aceitar transação legacy sem domínio EIP-155.
  • Aplicar fórmula v legacy a outras assinaturas.
  • Supor domínio em mensagem bruta ou personal_sign.
  • Omitir ou codificar errado chain ID EIP-712.
  • Omitir verifyingContract, nonce, deadline ou finalidade.
  • Confiar em endereço idêntico sem comparar código e estado.
  • Confundir domínios L1, L2, origem e destino.
  • Ignorar domínio interno de intent, permit ou smart account.
  • Tratar metadados, explorer ou ícone como autenticação.
  • Transplantar semântica EVM para outro protocolo.

Erros comuns

  • Chain ID é registro oficial global, único e permanente.
  • Chain ID correto prova RPC, rede e contratos.
  • Toda assinatura Ethereum inclui chain ID.
  • IDs diferentes impedem replay de toda mensagem.
  • Toda blockchain usa inteiro EIP-155.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...