This post is exploring what happens if nodes decide to relocate extremely close to other nodes, and how close they may be able to get. This may have implications for the security and economic design of the network.
Vaults are relocated to any name that’s within a specified target section (see routing::RelocateDetails).
From the keypair generation topic the expected rate of key generation is about 30K keys per second.
After one day a vault will have generated 2.6 billion possible new names. For a network with a million sections this vault would have about two thousand valid names for every section of the network.
So the vault can choose which name to use. How close do they want to be to existing vaults; maybe as far away from the other vaults as possible, or maybe as close to another as possible.
How does the operator choose one name from their thousand (or more) possible names?
The chart below gives an indication of the topic. A set of 10 random nodes (blue vertical lines) are in a section. The 20 red triangles indicate possible names my node has generated and could relocate to.
On the right-hand-side is a large gap in names, so I might pick a new name near the middle of that gap. This would have some certain effects for which chunks I be given and whether splits happen, etc.
On the left-hand-side are two existing nodes very close together, and I could have a name also very close to those two nodes. This would add a third node right on top of those two already very close nodes. Another slightly different effect on the section happens for chunk distribution, splits etc.
This chart is showing the effect of only twice as many names as nodes - the relocating node can choose within quite a wide variation of strategic analysis. In reality there will be thousands of names to pick from, so I could relocate my node virtually anywhere on the chart to suit my best benefit relative to the other node locations.
Let’s look at an extreme example to give an idea of where this can get funky.
The green lines are chunks. Perhaps a little too even for reality but this illustrates the point most clearly. The few blue nodes at the far right end of the chart are responsible for the majority of green chunks. The nodes in the middle of the dense blue clump of nodes are responsible only for a few green chunks.
If I pick a relocation name in the middle of the clump, I’d end up responsible for very few chunks.
If I picked a relocation name in the big gap, I’d end up responsible for a lot of chunks.
So the choice of relocation can (maybe) affect how many chunks I’d be storing (at least until a node near to my one moves).
This is interesting since it may be a way to use the side effect of relocation to also be a way to decide the vault size the operator would prefer, perhaps not precisely but to a degree.
The effects of various name choosing strategies are not obviously good or obviously bad, but maybe you can infer and extrapolate better than me on this topic. I’d be keen to hear your thoughts.
Size
There’s some degree of control over how many chunks a vault would have due to the density of other vaults around the relocated name.
Earning
Depending on how rewards work, it may be that vaults try to clump around particularly popular chunks, competing for it.
Network Health
A node is intended to be relocated to a specific section (or maybe a specific part of a section) depending which sections are the least healthy and most need the node.
However if the vault chooses to join the ‘most healthy’ part of the section rather than the ‘least healthy’ part of the section for relocation this may reduce the effectiveness of network health via relocating.
It may be possible to fix this by relocating to a specific xorname interval rather than a specific section.
Decentralisation
If clumping of nodes happens it may lead to large variation in vault size and capabilities, which may impact vault viability especially for smaller operators.
It may seem pointless to try to clump but it may be used by large operators to aid their other (non-clumped) nodes. I’m not sure of the possible magnitude of the effect of clumping or the potential for compounding the effect over time.
Accidents
It may be that a poorly coded vault sorts all new names and chooses the first available one, which would accidentally cause clumping at the very start of the section namespace.
Splitting
If clumping happens in only one part of the section it affects the intended split mechanic which is supposed to retain a fairly even balance of nodes and data on the network.
Optimisation
If a node can generate 1 billion keys per day (for example) which covers 30 bits of prefix then it makes relocating within a network of 20 bits prefix extremely trivial (possibly dangerous) and relocating within a network of 40 bits prefix extremely difficult. It seems odd that such an essential mechanic (ie the network structure) is dictated by such an arbitrary aspect (rate of key generation). This need for a ‘goldilocks’ network size based on the average rate of key generation seems a bit dubious to me.
I think it’s dangerous to allow nodes to pick their own name within a section. Perhaps it’s better to have a narrower target for relocation than the whole section?
I would also revisit using hierarchical deterministic names (as suggested a while ago in this dev forum topic Secure Random Relocation) as another option. Maybe there’s some flexibility allowed when choosing the next derived key, but not ‘total flexibility’ like the current brute force keypair/name solution.
It’s not that I can say the naming thing is dangerous because specifically X or Y or Z will happen, but it seems potentially dangerous because it allow various emergent behaviours that are not based on some underlying intended fairness but rather based on a side effect.
There doesn’t seem to be any immediate blazing red flags but since it touches on so many aspects of the security and economics of the network it seemed at least worth exploring a bit and seeing if anyone has other thoughts about this.
