14

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?

17

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.

  • Can you elaborate how this works on a granular level? I appreciate the response, but I'm not any closer to understanding how it works when signing, why the hash would be different, etc. – AlwaysQuestioning Jan 26 '18 at 13:22
  • I've added some further details (essentially copied from the EIP-155 page). :-) – Richard Horrocks Jan 26 '18 at 14:41
  • You say "It's required for the chain to operate in general", but how does a transaction at the end of the chain know about the variables such as chainID at the genesis block? – AlwaysQuestioning Jan 27 '18 at 16:54
  • A client can't operate without knowing which network (i.e. the combination of networkID and chainID) it's operating on. To boot into a network a client's genesis information must match the rest of the network. Note there's technically no "genesis block". It's really just a state definition in a JSON file, one field of which is the chainID. (The first block was block 0, and it was just a normal block, like all subsequent blocks, with the exception that I think it was crafted by hand, and not mined.) – Richard Horrocks Jan 27 '18 at 17:09
  • The client therefore has the genesis information, in its genesis.json, which it can refer back to when it needs it. (On boot it'll likely read the genesis state from disk into a set of in-memory variables. I haven't looked at the codepath to confirm though.) – Richard Horrocks Jan 27 '18 at 17:11
2

- How is it different than networkID?

It is not. chainID is a different name but refers to the same thing.

- 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 )

{
  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: []
}

- 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

  • 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? – AlwaysQuestioning Jan 26 '18 at 2:54
  • My knowledge on this topic is not good enough to answer that. I can only tell you that no matter the chainID, geth uses the entire genesis file to check if two peers are using the same chain. – Florian Castelain Jan 26 '18 at 3:01
  • Can you elaborate on the distinction between the genesis file and the first block? How does the blockchain use this information if it's not stored in the first block? – AlwaysQuestioning Jan 27 '18 at 7:20
  • Geth just check the genesis.json and compare it to the one of the person trying to connect, that's it. Moreover, the genesis file is a description of the chain at the very beginning. The first block is just a block that uses this description, then it goes on. – Florian Castelain Jan 28 '18 at 3:04
  • Yes but what if the genesis file says something like "Fork at block 20000", which it does. How does that take place if it's just read at the beginning? Doesn't it need to be read all the time? – AlwaysQuestioning Jan 28 '18 at 3:21
2

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.

1

Despite the fact that this question has accepted answer, 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 node receives Status message from its peer, it compares network identifier in the message with 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.

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

Network ID is not included into blocks, neither it is 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.

  1. 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 reply attack, i.e. from the situation when transaction that meant to be executed on one chain was actually executed on another chain as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.