Update January 20, 2022

I believe the elder count is fixed at 7!


Thanks so much to the entire Maidsafe team for all of your hard work! :racehorse:


My understanding is that when the section gets to its size limit, a supermajority of the seven elders vote for a split. Then the oldest seven adults are promoted to elders based on node age, with some kind of sorting hat if there’s a clash. Then records are exchanged as in Elder Handover mentioned in the OP. After that the split happens depending on name, so seven of the nodes that are closest in XOR terms split off to form a new section taking the closest 50% of the adults with them. I guess some sort of data redistribution would have to happen too to ensure redundancy, but I don’t know if that would be pre- or post-split, and keeping similarly named nodes together should minimise that.


Yeah, that’s what I figured. I suspect/suggest/hypothesize that a continuous elder increase over time from 7 to 14 as the section grows, rather than a step change right when the split is decided, may have some benefits. Everything would be setup and already working properly with abundant resources as one big section, the split is quick and painless after that. Think mitosis.


That could make the voting process / supermajority considerations very complex though. I think you worked out before 7 is a magic number (in a good way).


its been discussed for reasons of supermajority plus malice control that 7 elders is the sweet spot

(I will post here the thread that explains that)


Not really that complicated. Here’s a super-majority lookup table:

5 of 7
6 of 8
6 of 9
7 of 10
8 of 11
8 of 12
9 of 13
10 of 14

Also, the magic number depends on various trade-offs. Although 7 looks good, so do others in the range from 7 to 14.


But you’d probably have to change the voting algorithm with each node you add, and would any advantage be that great? The elders don’t store primary data (just a planned cache). All they do is make decisions, and the elder handover ought to be pretty quick and easy, certainly quicker than any data redistribution among adults. What would be gained by increasing their number incrementally as the section grows?


Stability? Security? It’s a hypothesis :wink:

Rather than ask a group of 7 adults to immediately switch roles and become elders, you bring one in at a time. This allows the current set of elders to vet an initiate.


Thank you, @happybeing. That is really appreciated.

I’m full of admiration for everybody involved in the project and capable of handling the complex mathematics of it. You make me feel small, but also proud to be even a tiny member of the group contributing to the common good.


I can feel the maidsafe’s fire!


Isn’t it possible to float these join requests around with a timestamp, then signatures are collected and the one that has the lowest timestamp and super majority of signatures is allowed in. After that pending requests have to be terminated by broadcasting the final joining request along with the already collected signatures of super majority to clear it out of the memory?


At one side, there is increased complexity, which means fresh bugs.
On other side it looks like this complexity is needed…


One thing I absolutely trust this team for is to find the minimum required complexity.

Another great update by the way!


There’s a few competing constraints we were working within here that force our hand.

  1. If an honest elder accepts a node into a section, it must be certain all other honest elders will eventually do the same
  2. The protocol must eventually terminate and a decision reached. (for example sn-membership will always terminates within O(log n) rounds where n is number of elders).
  3. dishonest nodes or elders should not have the ability to prioritize some requests over others.
  4. avoid buffers that can grow boundlessly (don’t create new Denial-Of-Service attack vectors)

It’s hard to analyze your idea solely on what you’ve written, but what stands out is potentially a unbounded buffer with your pending requests? and perhaps the ability for dishonest elders to fudge timestamps to give their friends priority? It’s also not quite clear how 1. would be satisfied, it’s possible that only a subset of elders may receive a join request?


We searched widely for solutions that did not depend on consensus. There were papers that claimed to manage membership without consensus, but on deeper reading, the algorithm was not guaranteed to terminate in real world (not theoretical) settings!

I suspect in a protected network, consensus is required to manage membership. If we can find a simpler way, we’d certainly adopt it.


Texas sized 10-4 here. Been here for the whole ride and have access to every paper. Reason I’m still here is the quality of the people and that SAFE is asking the correct questions… and that I know that if you had an easier way there would be no hesitation to throw out a ton of work to implement it. Facta non verba and hope that you are all well.


If an elder notices that the current elders are not the seven oldest nodes, then it sparks a vote on promoting the oldest adult(s) and demoting the youngest elders to make way.

What if an elder chooses not to spark a vote? Is there a punishment? Because I’m wondering what the elder gains from this.

I guess another elder will soon spot it and so long as 2/3 of the elders are honest the split will happen, and any elders that consistently misbehave like that will be ejected.


But how does the section verify that the elder has noticed the incorrect ranks but chosen not to act?

1 Like