At one side, there is increased complexity, which means fresh bugs.
On other side it looks like this complexity is needed…
7 Likes
One thing I absolutely trust this team for is to find the minimum required complexity.
Another great update by the way!
14 Likes
There’s a few competing constraints we were working within here that force our hand.
- If an honest elder accepts a node into a section, it must be certain all other honest elders will eventually do the same
- 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).
- dishonest nodes or elders should not have the ability to prioritize some requests over others.
- 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?
14 Likes
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.
18 Likes
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.
15 Likes
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.
6 Likes
But how does the section verify that the elder has noticed the incorrect ranks but chosen not to act?
1 Like
Good question! I’ll defer to the experts on that one, but for adults there’s a comparison between the suspicious node and its nearest neighbours. If an adult consistently fails to give up a chunk or does so later than its neighbours it gets demoted. Not implemented yet though, as far as I know.
2 Likes
He will fail liveness checks and be killed. A non-voting elder is useless to us.
9 Likes
Yes upon reviewing my comment it would grow without bound as more requests to join arrive and each of the 7 elders is proposing their own join requests for that member. Wouldn’t it be good to cap the active amount of requests for any elder at any time at some number. So that if there are 7 elders * buffer_limit (e.g. 10 requests) so you got 70 - buffer limit of requests at every elder eventually.
7 elders, each takes 10 join requests (could be completely unique or similar as other elders).
That would make 70 potential unique join requests but each elder only has to confirm the ones he received which is 70 - 10 = 60.
Any further requests for joining to an elder when cap is reached would return a message to try again later. The backlog of those requests is then resolved in time until there is room again in the buffer capacity?
5 Likes
Thx 4 the update Maidsafe Devs
Hihi your close to becoming a Maidsafe Dev @happybeing 
for your PR
Playground sn v0.53.0, sn_cli v0.44.0
Was nice to play around with and great that it didn’t really break
Superfly went super fast
I’ll try to node join next time 
Keep hacking super ants
15 Likes
@maidsafe have you had any internal testnets with more than two sections recently? Any observations from there?
1 Like
@DeusNexus some notes
- If you start capping the pending join requests buffer per elder, you open up the possibility of different elders seeing different buffers.
- Elders act based on what they can see, if they are seeing different join requests, they’ll act differently (i.e. accept different nodes)
- If we can synchronize the views of all elders, then all elders can act together and accept the same join request.
- So the problem now becomes:
"how do we synchronize the views of the elders"
Or, in your example, how do we get enough elders to see enough join requests that they can agree on which of the competing join request should go in.
Keep in mind that not all elders are honest, so they may for example:
- refuse to share their buffers
- selectively send their buffers to some of their peers and not others,
- lie and send different join requests to different peers.
More generally, you can rely on dishonest elders to do the worst possible thing at the worst possible time. Despite this, we need the synchronization algorithm to always terminate with honest elders in agreement.
Some concrete critiques on this: I agree that if an elder did see 70 join requests, the elder can be confident that it can make a decision about which join request to select. But, if we can’t trust all elders to share their buffers with everyone (suppose an elder is unplugged part way through synchronizing), then what would the termination condition be for an elder to stop waiting and make a decision based on what it’s seen so far? Can it be certain that all other honest elders will make the same decision?
9 Likes
@davidrusu Maybe you need to go to a 2 stage selection. The first is to build a (short) list all elders see. second is to select. Need to be fast on the (short) list build and this then means any elder with completely different list can be updated with the (short) list to work with.
Maybe the (short) list is a list of the join requests that most elders see. Each elder sends the other elders a list, each elder builds the (short) list from the most common join requests in the (upto) 7 lists.
5 Likes
@neo yes! this is essentially what we’re doing in sn-membeship: step 1: agree on which join requests we will consider (short list), then step 2: is a deterministic selection from the short-list.
step 1 is where the complexity lies, getting agreement amongst the (potentially byzantine) elders is non-trivial to say the least 
Since theres interest, let me quickly break down the phases of sn-membership:
- elders propose a reconfig (reconfigs are either joins or leaves) by broadcasting the proposal vote to all elders
- when an elder receives a vote, they check if they’ve voted already, if not, and they agree with the vote ballot (i.e. they agree that there is room for another node), they will adopt the ballot and broadcast their vote to the elders.
- when an elder notices that we’ve reached a split vote (i.e. say 1/2 the elders voted one way, the others voted another). it will broadcast out a new
mergevote containing all of the competing proposals. - when an elder notices that a super-majority of elders voted the same way and their last vote was not a super-majority ballot, then they broadcast out a new
super-majorityballot that contains all of the votes proving a super-majority has been reached. - once an elder notices a super-majority of these super-majority ballots (super-majority over super-majority), then they can be certain that a super-majority of elders are looking at the same proposals (our short list) and the algorithm terminates
Note: split votes can happen multiple times, eventually the competing proposals are merged into one common view.
15 Likes
Thank you for the heavy work team MaidSafe! I add the translations in the first post 
Privacy. Security. Freedom
5 Likes