ChainId is an identifier introduced by EIP-155 to distinguish different EVM chains. As shown in the figure below, the main function is to prevent a transaction from being repeatedly submitted on different chains after signing. Initially, it was mainly to prevent Ethereum transactions from being replayed on the Ethereum Classic network or Ethereum Classic transactions from being replayed on the Ethereum network. On the Ethereum network, it was activated from block 2675000 through the Spurious Dragon hard fork upgrade.

What impact has the introduction of ChainId brought?

NetworkId is mainly used to identify the current blockchain network at the network layer. Two nodes with inconsistent NetworkId cannot establish a connection.

NetworkId cannot be specified through the configuration file. It can be specified through the parameter --networkid. So when we start our own private chain node, we need to remember to add this parameter. If this parameter is not added and the network type is not specified, the default NetworkId value is consistent with the Ethereum main network.

No.

From the above introduction, it can be clearly seen that the two are not very closely related.

Almost all articles on the Internet that mention building an Ethereum private chain emphasize that the NetworkId needs to be the same as the ChainId value in the genesis file. In fact it's not necessary.

As shown in the picture below, many EVM chains already running on the main network have different ChainIds and NetworkIds. For example, Ethereum Classic's ChainId is 61, but its NetworkId is 1, the same as the Ethereum mainnet.

The reason why many articles emphasize that ChainId and NetworkId should be consistent may be because for a certain period of time, some development tools such as MetaMask will use NetworkId as ChainId. However, now MetaMask has supported custom ChainId, and Ethereum has also added the "eth_chainId" RPC API. I believe that the misuse of both will become less and less.