All nodes connecting to a given Swarm network should use the same blockchain networkID

[diegomasini]

Nodes with the Swap feature enabled could point to incompatible blockchain backends (e.g. a node could point to Rinkeby while another points to Ropsten).
From a security point of view allowing this behavior is a bad idea, it could lead to potential attacks (e.g. nodes could impersonate other nodes). We need a way for nodes to verify the blockchain network id used by a Swarm network when connecting to it. Some possible options are:

1. Verify whether the Ethereum networkID is the same as the BZZ networkID at boot up.
2. When connecting to a peer, check that the peer's communicated contractAddress is a valid chequebook.

Additionally, a networkID field should be added to the cheque signature and let the smart contract verify it to be absolutely certain that a signature a node releases for a given network (e.g. Ropsten) can't be used on mainnet.

To simplify configuration for users a mapping from BZZ networkIDs to blockchain networkIDs can be created.

@ralph-pichler comments for option (1): checking for the backend url could not be enough. The proper way to do it is to run the net_version RPC call against the backend. This is already done in Swarm when detecting which ENS address to use (see detectEnsAddr in swarm.go). We'll have to do it in a similar way with the Swap backend url (both to ensure that both nodes are connected with the same network but also to discover the contract factory address in the future).

[ralph-pichler]

Just to be clear, option 2 is not optional, this has to happen for other reasons also. Option 1 is too strict, there is no need that the Ethereum id equals the Bzz one, just that nodes talk about the same Ethereum id (but it is ok to have nodes on bzz network 5 talk about contracts on eth network 3 (ropsten)).

Regarding putting it into the cheque signature we have the problem that right now we cannot detect network ID on the contract side (although this might only be a temporary issue as I think the next hardfork will bring a CHAINID opcode). Alternatively if we have a factory in place the chain id could be stored there as well.

Another related point is what to do with our own chequebook address. e.g. what happens if I connect to rinkeby and start swarm and the chequebook gets deployed, and then I restart swarm connected to ropsten. We don't store the chequebook address for now but once we do we'll have to save the network id with it.

[diegomasini]

You are right @ralph-pichler, the match doesn't need to be strict, it is enough to define the valid mappings between BZZ networkIDs to blockchain networkIDs in the Swarm node.

[diegomasini]

This was discussed in the incentives channel and I think it is a good idea to have it documented here, comments and corrections to what is described here are welcome.

On bootup Swarm nodes should be allowed to connect to any accounting backend (blockchain) provided that it MUST (for now) only accept connections or requests from peers using the same accounting backend. No mapping between BZZ and accounting backends (blockchain network IDs) are needed beforehand.

Example:

I bootup a new Swarm node with BZZ id 5 and configure it against Ropsten, since this node is joining Ropsten for the first time it deploys the Swap chequebook smart contract. From now on this node will only allow connections / requests from peers using Ropsten as accounting backend. This means that we need for nodes to announce the accounting backend ID + Swap contract address (accounting_network:checkbook_addresss) which in this example would be: ropsten:chequebook_address.

Going one step further with this idea: a node receiving a request from a peer doing accounting with a different accounting backend could deploy a new Swap chequebook if it is already connected to such accounting backend (or if it can connect to it) and then start working with this peer. Otherwise, it could just reject the request, or it could propose to use a different accounting backend to the peer and let it apply this same logic to define what to do.

To support multicurrency in Swarm we should make the Swarm client capable of registering / recovering previously used accounting backend IDs + swap chequebook addresses. So mapping actually happens at Swap chequebook address level. The node should check the announced accounting_network:chequebook_address from their peers and only operate with those for which it has a matching accounting_network:chequebook_address. All this logic should be encapsulated in the payment processors.

The accounting information for the different accounting_network:chequebook_address combinations could be stored in separated data stores.

[ralph-pichler]

#1913 addresses some of this.