This weekend I have added 2 small modifications:
-
I have implemented my idea to replace relocation to the neighbouring weakest section by a 2 steps relocation: first to a distant random section and then to the weakest neighbour of this section. This idea was expressed in this post.
-
Second one is not an improvement but a simplification: I have used the random() function to compute, well … the random section. But in reality vaults cannot use this function because the result will be different between each vault. The randomness must be computed from a common data, typically the hash of an agreed state.
For example, current routing code relocates a joining node to the hash of its name concatenated with the ids of its 2 closest nodes. I don’t think that this algorithm will be kept, but I don’t need to know what the new algorithm will be. The important characteristic for the simulation is that it is a random address, how it will be computed in the real network doesn’t matter.
The same is true for the age of the node to relocate: In @bart code It was computed from the hash of the event, but when we look at @madadam repo, it has been changed to another thing. I make the same argument here: we don’t need to know the final implementation, we only need to compute a random age.
So, I have replaced this usage of hash function by the random function again. Then the hash has been completely removed, because it was not being used anywhere else.
Results are very similar but are slightly less stable (very slightly). I observed two instances with 3 distinct prefix lengths (for example at iteration 310000):
| Prefix len | Count | Average | Min | Max | Standard dev |
|---|---|---|---|---|---|
| 12 | 1 | 17.00 | 17 | 17 | None |
| 13 | 247 | 21.62 | 11 | 25 | 3.35 |
| 14 | 15886 | 12.43 | 8 | 16 | 1.20 |
| All | 16134 | 12.57 | 8 | 25 | 1.69 |
Also, there is sometimes a merge that happens during a stable period with a power of 2 number of sections (for example at iterations 390000, 400000, 410000):
| Prefix len | Count | Average | Min | Max | Standard dev |
|---|---|---|---|---|---|
| 14 | 16384 | 15.38 | 10 | 20 | 1.11 |
| All | 16384 | 15.38 | 10 | 20 | 1.11 |
| Prefix len | Count | Average | Min | Max | Standard dev |
|---|---|---|---|---|---|
| 13 | 1 | 19.00 | 19 | 19 | None |
| 14 | 16382 | 15.77 | 12 | 20 | 1.16 |
| All | 16383 | 15.77 | 12 | 20 | 1.16 |
| Prefix len | Count | Average | Min | Max | Standard dev |
|---|---|---|---|---|---|
| 14 | 16384 | 16.16 | 12 | 21 | 1.18 |
| All | 16384 | 16.16 | 12 | 21 | 1.18 |
Intuitively, I would have thought that relocating nodes at distance is more secure, but these results are not proving this. Though the difference is tenuous: one section over 16000 and I don’t show the curves because they are indistinguishable from previous ones.
Maybe I should add a parameter to allow comparison with more tests. Something like RelocationScope with 2 values (Local and Distant).