Some exploration of the ageing process…
Purpose
The purpose of ageing is to “ensure that nodes are relocated and therefore dilute their impact on the network across the address range” so “that an attacker or large participant in the network has an amount of work that must be carried out that is prohibitively expensive” (rfc-0045 node ageing).
I would paraphrase this as ‘balancing inclusiveness vs restrictions’.
There was an issue with the recently proposed ageing mechanism (ie the first post in this topic) that “made the network accept barely any new peers” (2017-12-14 update).
This post explores one potential cause and solution for the issue.
Cause
The simulation below indicates the issue is “it’s too difficult to age” rather than “too many nodes are disallowed”; the disallowing is a symptom, not a cause.
The ‘problem’ must be looked at from the perspective of ‘a prohibitively expensive amount of work’ required to ‘impact the network’. Extreme difficulty in ageing is counterproductive. Even though it makes it expensive to impact the network it also makes it expensive to participate in the first place. Ageing protections must not come at the cost of inclusiveness.
Making it expensive to join the network goes against the ‘everyone’ part of ‘Secure Access For Everyone’.
The aim of ageing is to make it expensive to impact the network without making it expensive to participate in the network. Maybe this is not the aim? Or not possible to achieve? Anyway, that’s a different discussion perhaps. Let’s look at the ageing mechanism.
Simulation
One of the major changes from the rfc and the new proposal is that originally the oldest possible vault would be aged, but now the youngest possible vault is aged.
The following tables show the difference between a preference toward younger vs older vaults.
A simulation of these two different preferences is shown below. It involves creating a network of 100K vaults (500K joins interleaved with 400K departures).
YOUNGEST PREFERRED
age vaults
1 29712
2 67461
3 2827
100000 total vaults
6186 total sections
OLDEST PREFERRED
age vaults
1 4274
2 16337
3 38242
4 21057
5 10171
6 4759
7 2677
8 1366
9 691
10 287
11 113
12 22
13 3
14 1
100000 total vaults
1607 total sections
Caveats
Youngest-preferred never hits the disallow rule, since there is never a Complete Section formed.
For oldest-preferred it was necessary to remove the disallow rule because the simulation got stuck at a single Complete Section which disallowed every new vault. I think the disallow rule needs tweaking or removing.
I suspect if the youngest-preferred eventually forms a Complete Section the disallow rule would also need to be tweaked or removed.
Thoughts
The rfc calls for an “exponentially increasing period between such relocations” which youngest-preferred does not achieve (but oldest-preferred does).
Youngest-preferred means an old vault can only age if its section has both a) no younger vaults and b) it ‘matches’ the hash of the network event. This is an almost-impossible condition to meet for old vaults (>3) because young vaults continue to accumulate in the section. It’s much harder than exponentially difficult.
Oldest-preferred seems to better match the intended difficulty of ageing and leads to an ‘expected’ age distribution. Ageing is exponentially more difficult as vaults get older, but is still common for younger vaults to age (ie exponentially easier the younger the vault is).
The key concept being affected by the younger-preferred mechanism is ‘difficulty’. Old (>3) vaults are nearly-impossible to age, rather than merely exponentially difficult to age.
I think perhaps most important is to keep the intended purpose in mind. Simulations show the intuitive approach to ‘age youngest first’ does not achieve the intended purpose. I’m not saying oldest-preferred is necessarily the best solution, but it does seem to me that youngest-preferred does not function as intended because it’s far too hard to become an adult.
Other possible things to try (but I think would not replace the older-preferred mechanism) are
-
age all vaults in the section that match the network event rather than just one, but still only relocate one vault to avoid massive churn.
-
tweak the disallow algorithm to have a gradually-stricter-rate-of-disallowing rather than a strict wall. This allows more chances for relocations and thus more chances for ageing.
It’s complex. But it always comes back to balancing inclusiveness vs restrictions. I think the simulations show youngest-preferred fails to achieve this balance, but oldest-preferred does a good job.
Just something to mull over during the holiday season… looking forward to seeing what comes from maidsafe in the new year.
