What is a chainID in Ethereum, how is it different than NetworkID, and how is it used?

Question

Here it's described in Ethereum's go implementation.

type ChainConfig struct {
    ChainId *big.Int `json:"chainId"` // Chain id identifies the current chain and is used for replay protection

A few questions:

1. How is it different than networkID?
2. Is chainID and networkID needed in every block or just the genesis block?
3. Can you give a specific example of what it means when it says chainID is used "for replay protection"?

EDIT: Still unanswered:

What would happen in the situation that you set networkID to one of the mainnet networkIDs, but change the other config variables to whatever you want? Why does it matter what you set for networkID if you're running a local chain?

Answer 1

How is it different than networkID?

ChainID was introduced in EIP-155 to prevent replay attacks between the main ETH and ETC chains, which both have a networkID of 1.

It's basically just an additional way to tell chains apart. Subsequent to EIP-155, ETH has a chainID of 1, while ETC has a chainID of 61 (even though they still have the same networkID of 1).

Is chainID and networkID needed in every block or just the genesis block?

It's required for the chain to operate in general - e.g. it's required when signing transactions, meaning transactions signed on the ETH network end up with a different hash than those signed on ETC. Before EIP-155, signed transactions on each network would look the same, and could be replayed.

Edit:

A specific example of how chainId is used.

As per the EIP-155 page, the v value of a transaction's signature is dependent on the value of chainID.

If block.number >= FORK_BLKNUM and v = CHAIN_ID * 2 + 35 or v = CHAIN_ID * 2 + 36, then when computing the hash of a transaction for purposes of signing or recovering, instead of hashing only the first six elements (i.e. nonce, gasprice, startgas, to, value, data), hash nine elements, with v replaced by CHAIN_ID, r = 0 and s = 0. The currently existing signature scheme using v = 27 and v = 28 remains valid and continues to operate under the same rules as it does now.

There is a detailed example of how this is applied on the EIP-155 page.

Answer 2

Despite the fact that this question has an accepted answer, the original question does not seem to be answered, so I will add my two cents.

1. How is it different than networkID?

Network identifier (networkID) protects a node from connecting to the nodes that are synchronizing with other networks. When connection between two nodes is established, these nodes exchange Status messages that, among other things, contain network identifiers of the sending nodes. According to the documentation, Status message “should be sent just after the connection is established and prior to any other eth protocol messages”. When a node receives Status message from its peer, it compares the network identifier in the message with the node's own network identifier and terminates connections in case of mismatch.

Chain identifier (chainID) introduced in EIP-155 protects transaction included into one chain from being included into another chain. Basically, chain identifier is an integer number being used in the processes of signing transactions and verifying transaction signatures. If different chain identifiers are used for signing and verifying the transaction, then transaction verification will fail.

2. Is chainID and networkID needed in every block or just the genesis block?

Network ID is not included into blocks, nor is it used when signing transactions or mining blocks. It is just an attribute of Ethereum Wire protocol that prevents nodes of different chains to connect to each other. Chain ID is not included into blocks, but is used during transaction signing and verification processes, effectively protecting transaction aiming one chain to appear on another chain.

3. Can you give a specific example of what it means when it says chainID is used "for replay protection"?

If two chains use different chain identifiers for verifying transactions, or if one chain implemented EIP-155 and the other chain didn't implement it, such two chains will never both accept the same transaction. This effectively protects from replay attack, i.e. from the situation when a transaction meant to be executed on one chain was actually executed on another chain as well.

Answer 3

- How is it different than networkID?

networkId is for node communication and chainId is used for target chain identification in signature - ETC and ETH chainId is different and networkId is same

- Is chainID and networkID needed in every block or just the genesis block?

This is only in the genesis file, not in blocks. Here is the description of the very first block of the mainnet (yeah, I'm currently syncing in fast mode :D )

> eth.getBlock(0)
{
  difficulty: 17179869184,
  extraData: "0x11bbe8db4e347b4e8c937c1c8370e4b5ed33adb3db69cbdb7a38e1e50b1b82fa",
  gasLimit: 5000,
  gasUsed: 0,
  hash: "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3",
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  miner: "0x0000000000000000000000000000000000000000",
  mixHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  nonce: "0x0000000000000042",
  number: 0,
  parentHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 540,
  stateRoot: "0xd7f8974fb5ac78d9ac099b9ad5018bedc2ce0a72dad1827a1709da30580f0544",
  timestamp: 0,
  totalDifficulty: 17179869184,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles: []
}

> web3.eth.chainId()
"0x5b7d"

- Can you give a specific example of what it means when it says chainID is used "for replay protection"?

You may find your answer here

Answer 4

What would happen in the situation that you set networkID to one of the mainnet networkIDs, but change the other config variables to whatever you want? Why does it matter what you set for networkID if you're running a local chain?

In order to have a truly local chain, you must set --bootnodes to point to one of your nodes. To which bootnode(s) a node connects determines which peers it sees. Then the network id determines with which peers (out of those it sees) it connects.

So if you set --bootnodes to one of your nodes, you can set the network id to whatever you want -- you are now separate from the public Ethereum network.

If you don't set --bootnodes to one of your nodes:

In this case you don't really have a fully local chain -- you are connected to all the peers on the public Ethereum network that use the same network id as you.

You are not clear what you mean by "other config variables". If you mean chain id or genesis block content, your node will then still connect to peers on the same bootnodes with the same network id, but the hash of the genesis block (and all subsequent blocks) won't match, and the node will feel rather lonely... it will have difficulty finding a peer with which it can exchange blockchain data.