Pasando la página.
Preparando el siguiente capítulo…
Psst… haz tuya la lectura.
Las fuentes y los temas están en Apariencia. Tus ojos también deciden.
Preparando el siguiente capítulo…
A numerical identifier included in supported blockchain signatures to distinguish the network on which an authorization is intended to work.
Comprobando la lectura en voz alta de este navegador…
Esta lectura está disponible actualmente en inglés. La interfaz usa el idioma que has elegido.
Leer el original en inglés →Two Ethereum-compatible networks can use identical address formats and transaction structures. Without an additional distinction, a valid signature on one network may also be usable on another. EIP-155 introduced chain-aware signing for Ethereum transactions by including a chain identifier in the signed data. Ethereum mainnet uses identifier 1. This is separate from an account address: the same private key can derive the same address on several networks while controlling different balances on each.
Suppose a wallet prepares a transfer on network A but its interface is accidentally connected to network B. Checking the chain ID before signing can reveal the mismatch. A correctly implemented chain-bound signature for A should not authorize the corresponding transaction on B when B uses a different identifier. The network, destination, asset contract, and amount still need checking; the identifier is only one component of the instruction a user approves.
A chain ID is an identifier, not a certificate that a network is legitimate or economically secure. Private networks can reuse identifiers, old transaction formats may lack the same protections, and off-chain messages have their own signing rules. EIP-712 provides a chainId field for application signing domains, but applications must implement their intended validation. A familiar network name in a wallet is therefore not sufficient evidence that the RPC endpoint or requested signature is trustworthy.