Saltar al contenido
Financial Context Wiki

Chain ID

Guía basada en la verificación sobre los chain ID de EVM, los dominios anti-replay de EIP-155 para transacciones legacy, las transacciones tipadas, CHAINID, las comprobaciones de wallet y RPC, los dominios EIP-712 y los identificadores de redes no EVM.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

En el ecosistema EVM, un chain ID es un entero configurado que se utiliza como parámetro del dominio anti-replay. EIP-155 lo incorpora a las firmas protegidas de transacciones legacy; los formatos tipados, como el tipo 2, lo codifican en su propio payload firmado; CHAINID lo expone durante la ejecución de EVM; y eth_chainId lo comunica mediante JSON-RPC. Son interfaces relacionadas, no un certificado universal de identidad.

No se garantiza que el valor sea único en todo el mundo ni permanente. Las redes privadas y los forks controvertidos pueden reutilizarlo, un RPC puede mentir y una misma dirección puede contener código y estado diferentes en distintas cadenas. EIP-712 incluye un campo opcional de chain ID en el dominio, mientras que los mensajes sin estructura y los sistemas no EVM aplican reglas distintas de replay e identidad de red. Por ello deben conocerse el esquema exacto de firma, el endpoint, el genesis o checkpoint y el dominio de la aplicación.

Cómo funciona

  1. Identifique primero el ecosistema y la semántica del identificador: entero EIP-155 de EVM, dominio EIP-712, referencia con namespace CAIP-2, chain ID textual de Cosmos, genesis hash de Solana u otro esquema. Nunca compare un número sin calificar entre ecosistemas.
  2. Fije una instantánea fiable de la red: URL RPC, chain ID esperado en decimal y hexadecimal, genesis o checkpoint finalizado, bloque de cabecera, configuración del cliente, codeHash de contratos clave y fecha de la fuente. El nombre y el icono de red de una wallet son metadatos no fiables.
  3. Consulte eth_chainId para firmar en EVM y analice la cantidad hexadecimal de JSON-RPC sin perder precisión. Compare el entero normalizado con la configuración esperada y el estado del proveedor de la wallet; no sustituya net_version y rechace cualquier discrepancia antes de construir una firma.
  4. Reconstruya el dominio exacto de firma. Distinga transacciones legacy sin protección, codificación legacy protegida por EIP-155 y envelopes tipados; en EIP-712 verifique los campos de dominio, verifyingContract, nonce y deadline; en intents retransmitidos o de smart accounts inspeccione el hash interno del protocolo.
  5. Verifique el destino de ejecución en la cadena activa: destinatario, valor, calldata, dirección del token, código del contrato o implementación del proxy, nonce de la cuenta, comisiones y estado simulado. El chain ID separa un dominio, pero no prueba que ninguno de esos objetos sea auténtico.
  6. Trate chainChanged de EIP-1193, los cambios de cuenta y las desconexiones como límites estrictos de estado. Descarte cotizaciones, allowances, nonces, simulaciones y solicitudes de firma almacenados; vuelva a leer cadena y destino; transmita solo la transacción bruta revisada al endpoint fijado.
  7. Concilie la transacción en la cadena prevista: bytes firmados y hash, aceptación del RPC, estado del recibo, número y hash del bloque, consumo del nonce, cambios de estado y finalidad requerida. Vigile forks, cambios de ID, confusión de dominios L1/L2 y desviaciones del proveedor; ante diferencias inexplicadas, deténgase.

Ejemplos desarrollados

  • Control RPC hexadecimal y decimal. Base tiene chain ID decimal 8453, representado por eth_chainId como 0x2105: 2 * 4096 + 1 * 256 + 0 * 16 + 5 = 8453. Ethereum mainnet es 1 = 0x1 y Arbitrum One 42161 = 0xa4b1. Si una wallet espera 8453 pero recibe 0x1, debe abortar antes de firmar en vez de confiar en el nombre de red mostrado.
  • v de una transacción legacy protegida. Para transacciones legacy EIP-155, v = 35 + 2 * chainId + yParity. Con chain ID 1, los valores son 37 o 38; con chain ID 61, 157 o 158. A la inversa, floor((37 - 35) / 2) = 1. Esta aritmética no se aplica al campo y-parity de transacciones tipadas ni a firmas legacy sin protección que usan 27 o 28.
  • Transacción tipada y rechazo por cadena incorrecta. Un payload de tipo 2 vincula chain_id=8453. Con 21,000 gas, base fee de 20 gwei, prioridad máxima de 2 gwei y fee máximo de 30 gwei, el precio efectivo es min(30, 20 + 2) = 22 gwei y la comisión 21,000 * 22 gwei = 0.000462 ETH. Una cadena que aplique correctamente ID 1 rechaza el payload firmado por discrepancia del dominio, por lo que ese rechazo no consume gas on-chain allí; en ID 8453 la transacción aún puede fallar por otros motivos.
  • Identificadores duales y no EVM. Un despliegue Cosmos EVM puede usar el ID textual de Cosmos SDK local-1 y el ID entero EVM independiente 262144 = 0x40000. La firma nativa de Cosmos usa el texto junto con número de cuenta y sequence; la firma de transacciones EVM usa el dominio entero. Solana expone en cambio un genesis hash y utiliza un recent blockhash o durable nonce en los mensajes, no un entero EIP-155.

Riesgos

  • Conectarse al endpoint RPC o cadena activa de wallet equivocados.
  • Confiar en un RPC malicioso que miente sobre ID, estado o transmisión.
  • Confundir representaciones hexadecimal y decimal.
  • Perder precisión al analizar un chain ID grande con un tipo numérico inseguro.
  • Usar net_version como si siempre coincidiera con eth_chainId.
  • No detectar chainChanged de EIP-1193 o una carrera al cambiar de red.
  • Reutilizar nonces, cotizaciones, approvals o simulaciones tras el cambio.
  • Suponer que los chain ID están registrados globalmente y no colisionan.
  • Firmar entre redes privadas o forks que reutilizan el mismo ID.
  • No definir qué ocurre si un fork cambia o conserva el ID.
  • Aceptar una transacción legacy sin dominio EIP-155.
  • Aplicar la fórmula legacy de v a transacciones tipadas u otras firmas.
  • Suponer que un mensaje bruto o una solicitud personal_sign incluye dominio de cadena.
  • Omitir o codificar mal el chain ID en un dominio EIP-712.
  • Omitir verifyingContract, nonce de aplicación, deadline o propósito.
  • Confiar en direcciones idénticas sin comparar código y estado.
  • Confundir dominios L1, L2, origen del bridge y destino.
  • Ignorar el dominio interno de un intent, permit u operación de smart account.
  • Tratar metadatos de wallet-add, etiquetas de explorer o iconos como autenticación.
  • Trasladar la semántica EVM a Cosmos, Solana, Bitcoin u otro protocolo.

Errores comunes

  • Un chain ID es un número oficial, mundialmente único y permanente.
  • Un chain ID correcto prueba que el RPC, la red y los contratos son auténticos.
  • Toda firma de Ethereum incorpora automáticamente el chain ID.
  • Diferentes chain ID impiden el replay de todo mensaje e intent firmado.
  • Toda blockchain utiliza un chain ID entero al estilo EIP-155.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...