Chain ID e identificador de red en Ethereum: por qué la dirección no basta

El identificador de cadena de Ethereum, o chain ID, aporta un contexto que una dirección por sí sola no ofrece. El valor devuelto por eth_chainId es el identificador configurado que se utiliza en la firma de transacciones con protección contra repetición de EIP-155. El identificador de red que devuelve net_version responde a una pregunta definida por separado. Conservar el nombre del método junto a su resultado evita confundir ambos identificadores.

Para interpretar estos datos conviene distinguir tres elementos: el texto de la dirección, el identificador comunicado y el contexto de red. Esta guía explica la diferencia mediante documentación y un ejemplo hipotético, y termina con una lista de comprobación que no requiere firmar con una cartera.

Chain ID y network ID responden a preguntas distintas

La documentación JSON-RPC de Ethereum define net_version como el método que devuelve el identificador de red actual en forma de cadena de texto. Al registrar una respuesta, conserva ese significado: es el identificador de red comunicado por el nodo que responde.

Por su parte, eth_chainId devuelve el identificador de cadena configurado, asociado a la firma de transacciones con protección contra repetición de EIP-155. Las definiciones asignan funciones diferentes a ambos campos. Antes de interpretar una cifra, por tanto, hay que saber qué método la ha proporcionado.

Comparar números no sustituye esa distinción. Aunque un ejemplo muestre valores numéricos coincidentes, mantén los campos separados. Sus funciones documentadas siguen siendo distintas; la coincidencia tampoco explica por qué se configuraron esos valores concretos.

Cómo leer el formato y el contexto de la respuesta

EIP-695 especifica que eth_chainId debe devolver un entero representado mediante una cadena hexadecimal. Por ejemplo, 0x1 representa el número uno. Al comparar valores registrados, distingue entre una diferencia de escritura y una diferencia en el entero representado.

La propuesta recomienda dar preferencia a eth_chainId frente a net_version para identificar la cadena con la que se está comunicando una aplicación. Esa recomendación depende de una implementación correcta. Citar la especificación no autentica un punto de acceso RPC concreto ni demuestra su seguridad.

La respuesta también tiene un contexto definido: el identificador debe corresponder a la información del bloque más reciente que conoce el cliente, su cabecera actual. Es un requisito de implementación, no una prueba de que cualquier respuesta individual lo cumpla.

Si ese bloque no especifica un identificador de cadena, EIP-695 indica que el cliente debe tratar la consulta como si el método no estuviera disponible y devolver un error adecuado. Conviene conservar esta condición al explicarlo: un fallo cualquiera no demuestra por sí solo que se haya producido precisamente ese supuesto. En un ejercicio de lectura, deja el error sin resolver antes que sustituirlo por un identificador supuesto.

Qué aporta el chain ID a la protección contra repetición

EIP-155 describe un esquema protegido que incluye el identificador de cadena en el cálculo del hash de una transacción. Sus condiciones de activación son que el número de bloque haya alcanzado el umbral establecido y que exista un identificador de cadena disponible. Aquí interesa entender su función, sin entrar en la construcción ni en la firma de transacciones.

La propuesta también mantiene el esquema de firma anterior, con valores v de 27 y 28, bajo sus reglas previas. Esta disposición de compatibilidad no permite afirmar cuál es la política de aceptación actual de todas las cadenas o de todos los clientes.

Además, EIP-155 anima a las futuras redes de prueba, cadenas de consorcio y cadenas alternativas de Ethereum que adopten la propuesta a elegir identificadores únicos. Esa recomendación no demuestra que todas las cadenas independientes la sigan.

De estas premisas se obtiene una deducción limitada: el esquema protegido incluye el chain ID, la propuesta conserva el esquema anterior y se recomienda utilizar valores distintos. Por tanto, la separación mediante el identificador de cadena depende de utilizar el esquema protegido con identificadores diferentes. Estas premisas no garantizan la misma protección para el esquema anterior, para cadenas que compartan identificador ni para cualquier clase de solicitud firmada.

Por qué el formato de una dirección no identifica la cadena

La documentación de cuentas de Ethereum describe la dirección de una cuenta de propiedad externa, o EOA, como un valor de 20 bytes representado por 40 caracteres hexadecimales, precedidos de 0x. Esto define su representación.

Por separado, la documentación de redes de Ethereum explica que pueden existir redes independientes que sigan el protocolo sin interactuar entre sí. A esas dos premisas se añade el método de identificación de cadena documentado en EIP-695.

La combinación permite una inferencia lógica: una dirección hipotética con ese formato no puede establecer por sí sola la identidad de la cadena. Su patrón de caracteres no permite elegir entre los distintos contextos de red independientes. Es una deducción a partir de las fuentes, no una afirmación citada directamente de la página sobre cuentas.

El alcance de esta conclusión es la identificación. No permite deducir saldos, despliegues de contratos, existencia de fondos, control mediante claves privadas ni posibilidades de recuperar activos en otras redes. Reconocer el formato de una dirección y establecer a qué cadena se refiere son preguntas separadas.

Ejemplo hipotético: una dirección repetida en dos fichas

Imagina dos fichas de documentación inventadas, A y B. Ambas muestran 0x1111111111111111111111111111111111111111. Supongamos que la ficha A registra una respuesta de eth_chainId igual a 0x65, mientras que la ficha B registra 0xca. Son datos ficticios para explicar el concepto; no describen puntos de acceso reales ni cuentas desplegadas.

El texto repetido aporta la misma representación de dirección en ambas fichas. Los identificadores estipulados aportan contextos de cadena diferentes. Según la deducción anterior, la dirección por sí sola no permite decidir a cuál de las dos cadenas se refiere el documento.

Ahora oculta los campos del identificador de cadena. La dirección conserva su aspecto, pero el ejercicio ha perdido el contexto explícito que permitía distinguir las fichas. Al recuperar esos campos, vuelve a quedar visible la diferencia. El ejemplo no asigna ningún saldo, no establece que exista un contrato ni afirma quién controla una cuenta.

Lista de comprobación de solo lectura

1. Define el contexto previsto. Anota a qué cadena se refiere el documento antes de interpretar una dirección.
2. Conserva el nombre del método. Registra una respuesta existente de eth_chainId como identificador de cadena y una de net_version como identificador de red.
3. Interpreta la notación hexadecimal. Compara los enteros representados, sin considerar que toda diferencia de escritura implica un valor distinto.
4. Mantén los límites de la respuesta. Recuerda el requisito relativo al bloque más reciente conocido por el cliente y deja sin resolver los errores cuya causa no esté establecida.
5. Delimita las conclusiones sobre repetición. Identifica el esquema protegido y la diferencia entre los chain ID antes de atribuirles esa separación.
6. Asigna al formato su función. Utilízalo para describir la representación de la dirección, manteniendo la identidad de cadena como una cuestión independiente.

Puedes aplicar esta lista a documentación o respuestas ya registradas. No requiere enviar transacciones ni firmar solicitudes con una cartera. Material educativo elaborado con asistencia de IA; el ejemplo hipotético ilustra las diferencias documentadas.

Lectura relacionada: Nodos y clientes de Ethereum: funciones, tipos y verificación.