Переворачиваем страницу.
Открываем следующую главу…
Псс… читайте так, как удобно вам.
Шрифты и темы — в разделе Оформление. Вашим глазам должно быть удобно.
Открываем следующую главу…
A numerical identifier included in supported blockchain signatures to distinguish the network on which an authorization is intended to work.
Проверяем поддержку чтения вслух в браузере…
Этот материал пока доступен на английском. Интерфейс использует выбранный вами язык.
Читать английский оригинал →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.