Network IDs and swap

[holisticode]

The bzz network ID identifies a specific swarm network.

Swap-enabled nodes though can only interact with nodes which run on the same backend. Thus, the network IDs should be specified (e.g. RSK vs ethereum networks).

cc @Eknir @ralph-pichler

[Eknir]

The main problem, for now, is that swap-enabled nodes can only run on bzzNetworkID 5, which means that nodes that are swap-enabled, but with a different backend might try to connect with each other, which will obviously fail. To prevent this situation, I propose to create the requirement of a seperate bzz network id per blockchain backend id. We can enforce this by providing a mapping that stipulates which blockchain backend id is allowed per bzz network id.

For example: bzzNetworkID 5 = backendNetworkID 3 (ropsten), bzzNetworkID 6 = backendNetworkID 31 (RSKTest).

The exact mapping is completely arbitrarily. We could opt for a relationship bzzNetworkID == backendNetworkID, but to enforce this, we need to change the networkID of our running swap-enabled network (from 5 to 3) and our non-swap-enabled network (from 4 to, say, 99).

[Eknir]

[USER-STORY]:

Rationale Currently, Swap may only be enabled on when BZZ Network ID == 5. This works OK, when we assume that all nodes run on the same Ethereum network ID. Obviously, this is not the case, causing nodes on the same BZZ Network ID to be not connected with each other. This convolutes the log (Error cannot connect), but it also makes the idea of one BZZ Network, as a set of nodes which are all connected, erroneous. Furthermore, if we clearly document which BZZ Network idea maps to which EVM Network ID, the user needs one less input parameter when starting Swarm.

Story: As a user of Swarm, I can connect to different BZZ Network IDs, such that I connect to Swarm with a different blockchain

Acceptance Criteria

1. A user boots up Swarm with BZZ Network ID 103, and it connects to EVM Network ID 3 (exact mapping may be different) && BZZ Network ID 104 => EVM Network ID 4

[mortelli]

even though this is most likely a temporary solution: should this be implemented as a function, or as a hard-coded mapping?

meaning: with a bzz network ID as an input, should we calculate the expected blockchain ID as an output and compare it to the given one? (runtime)

or: with a bzz network ID as an input, should we find the correspondent blockchain ID in a hard-coded mapping? (compile time)

@janos

[mortelli]

or, alternatively—depending on how the acceptance criteria is interpreted—the user only specifies the BZZ network ID, and the blockchain ID is determined based on that, i.e. the user does not specify it

[Eknir]

or, alternatively—depending on how the acceptance criteria is interpreted—the user only specifies the BZZ network ID, and the blockchain ID is determined based on that, i.e. the user does not specify it

I think this is the best option, as it is more user-friendly and it leaves fewer possibilities for mistakes from the user.

[Eknir]

And, I would create a hard-coded mapping (compile-time), but IMO, there is not a very big difference between the two in this implementation.

[mortelli]

And, I would create a hard-coded mapping (compile-time), but IMO, there is not a very big difference between the two in this implementation.

hard-coded alternative

pros

a hard-coded compile-time correspondence allows for any arbitrary mapping. i.e. ID 3 can go to ID 103, but if—for whatever reason—ID 104 is not available for ID 4, we can hard-code it to anything we want instead. in this way, it is more flexible.

cons

we have to change the code and create new binaries every time we wish to add a new match between IDs.

function alternative

pros

in principile, no new binaries need to be generated. you can throw an ID at it and it will spit another one back, based on the function as it is.

cons

there can be less flexibility for special cases. if one ID mapping does not follow the rule, the function must indeed be updated, so the previous advantage would be lost. it also can result in unexpected or undesired mappings.

---

I think this is the best option, as it is more user-friendly and it leaves fewer possibilities for mistakes from the user.

it means removing a flag (which is not bad by itself) but it can mean obscurity for the user as well. if they don't know the mappings, they might end up connecting to a blockchain that they do not wish to connect to.

[santicomp2014]

Maybe we should consider from the network perspective. How often are backends created/changed, normally they are test/main nets that are longlived.

So from one swarm version to the other, there is plenty of time to get a new backends integrated into code.

This would require an update of the binary, it would be less flexible but more controlled on our side.

TLDR: It should be baked into compile-time, if these networks are changing all the time, then I would prefer the function alternative.