A proposal for chain-id's, to help avoid using the wrong network

[cbeck88]

Rendered Proposal

[jgreat]

I think making the networks aware of who they are in a human readable way is a good way to reduces client and operational support burden.

Clear errors like "Service network_id doesn't match expected network_id" would be really helpful.

[voloshyn]

I like the idea:

1. the overhead on the SDKs will be minimal;
2. we don't have to come up with and maintain separate data testssets for separate networks;
3. does not require token range reservation, so if someone wants to mint a token in hexspeak like 0xABADCAFEDEADBEEF they can;
   If network-id is a header field, adding it to Fog seems simple enough too, I think it makes sense to add it from the get-go.

[eranrund]

This seems reasonable to me. I do think the network id should make it into the enclave. We don't have to worry about releasing a new enclave immediately but there's no reason to not include this in a future release.
I also think we should add it to fog - I haven't seen a convincing argument why only part of the network services (e.g. consensus) should have this but not others (e.g. fog). It's not a particularly complicated change, and it is backwards-compatible for clients.

Thanks for writing this!

[cbeck88]

Yeah I was trying to just control the scope of the change, but in POC work it seems like it's pretty easy to add it to fog also. I will update the proposal.

I think a second step should be that:

• network id makes it into the enclave
• network id is part of the transaction and under the signature, and checked by the enclave
• James proposed (offline) that network id is in the block header. this will give mobilecoind and fog-ingest visibility into it
• James also thinks we should call it "chain id" and we shouldn't have two separate ids if there's no good reason.

Right now I'm just trying to do the network-id part because it can ship without an enclave upgrade

[eranrund]

I like those suggestions, I think the MCIP should cover the whole desirable change, we can implement at whatever pace we like.

[cbeck88]

sorry guys, this wasn't supposed to merge yet, we were supposed to wait for final comment period, but i fat-fingered it

Please, let's move any further comments here:

#51