Understand if-how Parsec solves this problem, please explain/describe Parsec

[g.u.y]

Hi @pierrechevalier83 !

Here are some common sense questions on Parsec and its use, your clarifications would be greatly appreciated.

First for context, what is MaidSafe’s purpose with using Parsec to provide consensus in network events, meaning establishing a common consensus among voters on which members dropped in and dropped out respectively, just curious

• why is this an important problem to solve, and
• what is this answer used for.

I’d like to use Parsec for ordering in a distributed but common acyclical dependency graph that is being built over time.

What’s happening in my model is that each of voters Alice, Bob, Carol, Dave randomly over time come up with "conditioned vertex"es that do fit into the dependency graph according to their view of the graph, and that they would like to have inserted into the dependency graph so that ALL the four of them will have exactly the same graph.

The condition vertices are such that sometimes the addition of one such conditioned vertex is not compatible with the addition of another one. Also alternatively, there can be a specific order that they need to be included in to satisfy inclusion criteria.

It’s not certain that at the time one of the four of the voters comes up with a suggested conditioned vertex to add to the graph, that neither of the other three of them has not unbeknownst to the first one, ALSO come up with a suggested conditioned vertex to add to the graph, and this produces a consensus problem, namely:

How to asynchronously, trustlessly qualify conditioned vertex contributions so that the four of the voters will reach ONE SINGLE consensus of exactly which vertices to add right now, leading all of the voters to remain with ONE common shared equal version of the consensus graph.

A consensus algorithm like Parsec is needed to solve this, also Parsec’s absence of leader appointment as well as absence of dependency on wall clock time should be very useful here.

Would you agree that Parsec is suited to solve this above described problem?

Also, is Parsec good at voting for an order (that satisfies the dependency order - alternatively just come to consensus of one vertex at a time and this way through adding one “DAG layer” at a time the graph extension work with dependencies honored will be performed over more rounds)?

Please let me know your comments for understanding how to map my problem onto Parsec, also do you think the Rust implementation should be a useful for solving this problem.

Watching the PARSEC Graphs: Visualising ABFT Consensus - YouTube video, I see an example of Parsec used to vote on, and in that case all four voters voted for th 9kKpZ option - the vote is illustrated in the turqouise box, and then the red boxes show this same vote in {}:s.

Is this to illustrate that there is a voting for a SET of options - you could call that a “block” - that is being qualified?

When watching Parsec’s workings for instance at PARSEC Graphs: Visualising ABFT Consensus - YouTube and when reading the whitepaper, I remain unclear about the role of

• “Estimate” aka est
• “bin_values” aka bin
• “AUX” aka aux
• “Decided value” aka dec
• “Block”

in the voting process.

Would you mind MOTIVATING WHY you introduced these four, and in layman terms describing their function/role?

There is a claim that Parsec has “optimal complexity”, what do you mean by this.

IF Parsec would break down, for instance due to too many failing nodes, how does the breakdown look like, e.g. how can the consensus outcome be tricked in case of for instance 2 failing voters in a 5 node configuration.

To sum up, after having read all your documentation I don’t see clearly how Parsec maps to my consensus problem, and I hope I can ask you directly here for me to be able to comperhent and visualize the problem.

Thanks!
Guy

[dirvine]

Pierre has a new job, he may be busy, this is a lot of questions and validation of a design. So a big ask. I will try and help though.

@g.u.y

First for context, what is MaidSafe’s purpose with using Parsec to provide consensus in network events,

The network requires a consistent agreed membership of voters. The easy approach is strictly ordered consensus.

@g.u.y

Would you agree that Parsec is suited to solve this above described problem?

PARSEC will let you know the supermajority agree on X whatever X is. In your case it is a vertices. That is all good. You could also detect nodes voting for the wrong vertix as malice.

@g.u.y

Please let me know your comments for understanding how to map my problem onto Parsec, also do you think the Rust implementation should be a useful for solving this problem.

I think that is the anser above, it is what PARSEC will do.

@g.u.y

Is this to illustrate that there is a voting for a SET of options - you could call that a “block” - that is being qualified?

Not going back over the vid, but yes PARSEC can handle blocks as well as plain votes. So a vote is a single nodes “thing” a block is where you have a majority of nodes all having the same “thing” agreed.

@g.u.y

There is a claim that Parsec has “optimal complexity”, what do you mean by this.

Only as complex as it needs to be.

@g.u.y

IF Parsec would break down, for instance due to too many failing nodes, how does the breakdown look like,

There would be no agreement, so stalled or no liveliness

Ohhps missed this one

@g.u.y

When watching Parsec’s workings for instance at https://youtu.be/kkafYeHKzIk?t=253 and when reading the whitepaper, I remain unclear about the role of

I am not sure what is unclear and without coming up with new descriptions or a new paper I cannot help, it’s just lack of time, but if there is specifics you don’t understand then I can try and help.

[g.u.y]

Hi @dirvine thanks for responding! Let’s jump into specifics:

@dirvine

g.u.y:

When watching Parsec’s workings for instance at https://youtu.be/kkafYeHKzIk?t=253 and when reading the whitepaper, I remain unclear about the role of

I am not sure what is unclear and without coming up with new descriptions or a new paper I cannot help, it’s just lack of time, but if there is specifics you don’t understand then I can try and help.

This post intends to describe the specifics that I don’t understand. Also there is pretty much zero Parsec protocol discussion outside the whitepaper and RFC, so I understand that these questions are necessary to bring Parsec’s workings to light.

Looking forward very much to understand it soon. First response to your points, and then a list of central Parsec specifics that I need help to understand:

@dirvine

g.u.y:

First for context, what is MaidSafe’s purpose with using Parsec to provide consensus in network events,

The network requires a consistent agreed membership of voters. The easy approach is strictly ordered consensus.

If you have the time, can you give some examples of what the membership of voters is then used for.

Anyhow sure I understand that it is or can be useful among participants to have a common view of which the members are.

@dirvine

g.u.y:

Would you agree that Parsec is suited to solve this above described problem?

PARSEC will let you know the supermajority agree on X whatever X is. In your case it is a vertices. That is all good. You could also detect nodes voting for the wrong vertix as malice.

Great news! Thank you.

Briefly how do I detect a malicious node, I ask this both because you bring it up now and because I didn’t see it mentioned in the other documents. (Not aware if your Rust implementation reports malicious nodes.)

@dirvine

g.u.y:

Is this to illustrate that there is a voting for a SET of options - you could call that a “block” - that is being qualified?

Not going back over the vid, but yes PARSEC can handle blocks as well as plain votes. So a vote is a single nodes “thing” a block is where you have a majority of nodes all having the same “thing” agreed.

Aha great. (The RFC kind-of interchangably talks about both possibilities, mostly it talks in terms of a network event (= a plan vote) but there’s also definitions of blocks there, even while not much elaborated on.)

Please help me understand, Parsec will NOT help REORDER the plain votes (= vertices) within the block (= set of vertices) right -

Instead, for Parsec to vote about order of vertices within a block, then, (one or more) voters would need to come up with EVERY ORDER COMBINATION THAT CAN BE VOTED ON, SEPARATELY, and then Parsec will do the voting to choose WHICH of those combinations will be the chosen one, right?

HOW does a voter pass more concurrent votes in the protocol, or can one voter only vote for one “thing” (here: one block which means one order combination), at once, so to explore more combinations than there are voters during one single vote, you’d need more voting rounds / more Parsec executions?

@dirvine

g.u.y:

IF Parsec would break down, for instance due to too many failing nodes, how does the breakdown look like,

There would be no agreement, so stalled or no liveliness

(Repeating same question as above) can this be detected, for instance with a supermajority of sincere nodes, is there a maximum number of Parsec rounds, so that reaching above a certain threshold proves the presence of one/more malicious nodes?

Which are the detection points/criteria that show or indicate a malicious node.

Central Parsec specifics that I need help to understand:

These questions are formulated from watching GossipGraph .

• Re workings of ROUND and STEP:

  Zooming out, the “Parsec state machine” is based fundamentally on a process driven by a COUNTER, which is specifically the “round” and “step” values, right?

  So each node will keep counting “step” up to 2, after which it will bump “round” and start “step” over from zero, correct, or?

  Or is “step” increased only during certain protocol phases?

  To understand how the “round” and “step” slots for other voters are handled:

  The D_9 gossip event makes me a bit clueless, because the step slot for c there is 1 (ONE), while at that phase Carol is producing gossip event C_6 which is still at step zero, so Carol has clearly NOT bumped its own step or round slot and gossiped it to anyone, meanwhile Dave already counts Carol as being at step 1.

  Why? So the round-step is not only about that a voter bumps ITS OWN round & step slots and then gossiping those to other voters for them to adopt it in to their round & step slot arrays, but something more - can you describe?

  Also just for clarity, B_17 shows round 0 step 2, then B_18 doesn’t disclose its round and step but B_18 gossips to D_19 which shows Bob as having round 1 step 0, meaning there was a bump. Did this bump happen in the transition B_17 to B_18?

• Re a VOTER VOTE for MORE THINGS CONCURRENTLY:

  (Repeat of question above), can one voter (i.e. Alice/Bob/Carol/Dave) vote for more things at once, or not?

  I ask because in gossip_graph.dot.svg, all of the EST, BIN, AUX, DEC, contain a BOOLEAN, ONLY (in the case of est, plus the combined “true,false” “anybool” value).

  That would suggest that the voting machine only relates to judgement of “a given voter’s [one single] vote” -

  E.g., in Bob’s voting machine state b_0, …, b_4, …, b_6 etc., at least the ETC value, regards Bob’s view of the validity of Alice’s [one single] vote, Bob’s view of Bob’s [one single] vote, Bob’s view of Carol’s [one single] vote, Bob’s view of Dave’s [one single] vote.

  Is this so?

  What was the motivation for allowing one voter to pass only one vote concurrently, protocol simplicity?

  Does this mean that if one likes to use Parsec for ONE voter to vote on MORE options in the same round, one would need to spawn more ‘virtual voters’ within one and the same real voter, so say Bob wants to vote for both A, B, C, D and E at the same time, for him to do this he’d need to function as five voters - BobA, BobB, BobC, BobD, BobE, one for each vote he likes to pursue - is this so?

• What’s in and outside of the “binary value gossip”:

  Are actually all of EST, BIN, AUX AND DEC all parts of the “binary value gossip” protocol, or is binary value gossip something that kicks in at a given protocol phase, if so what do you call the pre-BV gossip phase, also is there any POST-BV gossip phase?

• What’s a metavote, as in, what is its function:

  Please describe in layman terms. If I get it right, it appears that when you run the protocol, there is a point in its execution where (a) gossip event(s) naturally will constitute a meta vote.

  I would wildguess that a metavote is somehow one voter (e.g. Carol) somehow voting for another voter’s (e.g. Bob’s) vote, and then as the voters send metavotes to each other, there will be a proof buildup of which voter’s vote (= suggested vertex) won.

  A lot of the metavoting talk in the documents regards to EST which I don’t understand, understanding EST will likely help:

• What’s the EST[imate] value and what is it initialized to:

  I’ll ask this question about “what it is” before asking “what the point with it is”.

  Within a gossip event (b_4 etc.), we see that EST is defined as an array with one slot per voter.

  Each slot has either of the values “TRUE”, “FALSE”, or “TRUE,FALSE” - and,

  while gossip_graph.dot.svg does NOT SHOW IT, there is also a “NONE”/NULL/not-set value, isn’t it?

  I presume that on initialization at A/B/C/D_0 (bottom of gossip_graph.dot.svg), each voter has their EST slots for all the other voters, set to NONE. Is this correct?

  However also on initialization, A/B/C/D_0 has its EST slot for itself, set to … what? Its own vote on itself, that it wants its vote to win ?? or what.

• What’s the point of the EST[imate] value:

  Please explain the role of the EST value in the protocol, why is it there, conceptually what is it for.

  I could get an impression that EST is an accumulator of the different voters’ expectations of the vote outcome, but not sure:

  If B_4 has the EST slot for Alice set to TRUE, does this mean that Bob at B_4 EXPECTS that Alice will exclusively? inclusively? win the vote and become the consensus choice for this Parsec execution / this Parsec round?

• What’s the point of the BIN[ary_values] value:

  It appears to me that BIN is somehow just a qualified EST, but I don’t get it.

  What is BIN for? What does it tell? How does it participate in the voting?

• What’s the point of the AUX value:

  Is it even used?? I see in gossip_graph.dot.svg that AUX magically suddenly magically gets set at D_5 and C_5 and also A_4 and A_5. Bob builds up his AUX a bit slower, at B_4 it’s empty and he has filled it up at first by B_17.

  What does this illustrate, what’s the function.

• What’s the point of the DEC[ided] value:

  Same here, what’s it used for - is this the OUTPUT RESULT of the whole consensus process?

  If so, what does it describe?

  B_6 is the first gossip event that has any DEC content at all. Also I notice that DEC slots are either NONE or TRUE.

  What’s going on?

• How is completion of Parsec achieved:

  First, do you define TERMINATION as the point of success of Parsec, where the voters reached consensus?

  Is there any situation where >=1 voters could stay in the Parsec loop, NOT complete, while some other voters found that voting finished and ended.

  How is this synchronization achived.

This was exhaustive, can’t wait for your and/or @pierrechevalier83 / @jean-philippe / @bart 's thoughts. I’m yet at a point where I can’t visually see for myself how Parsec works, trust to get there soon.

Thanks again,
Guy

[dirvine]

@g.u.y

If you have the time, can you give some examples of what the membership of voters is then used for.

Only those in the valid group have their vote counted. So not any old node, but a node agreed valid by PARSEC consensus.

@g.u.y

Briefly how do I detect a malicious node,

Things like vote on opossing things etc. It is down to your use case and design. Also things such as knowing the node missed a vote it should have sent you etc.

@g.u.y

Not aware if your Rust implementation reports malicious nodes

There is some work there, you can see that in github.

@g.u.y

Parsec will NOT help REORDER the plain votes (= vertices) within the block (= set of vertices) right -

PARSEC Will give agreement only on a single order as witnessed by the supermajority. So only a single order can exist.

@g.u.y

HOW does a voter pass more concurrent votes in the protocol,

A voter can vote on as much as it wishes, sending gossip events. So not strictly concurrrent, but no need to wait on consensus of last vote if that is what you mean.

@g.u.y

(Repeating same question as above) can this be detected, for instance with a supermajority of sincere nodes, is there a maximum number of Parsec rounds, so that reaching above a certain threshold proves the presence of one/more malicious nodes?

You can detect (with some difficulty) an unresponsive node as it will not be in the graph for a period. My opinion is this is essential for permissionless networks.

@g.u.y

Central Parsec specifics that I need help to understand:

These are more in code, I have not worked in the code, but please do thoroughly play around with the code/tests and examples there. Otherwise you will need to stop one of the devs working on launch and I cannot authorise that time right now as we are at a critical and extremely busy time.

When you are very familiar with the code then your questions will be very much more direct and easy to answer. Sorry for the push back, perhaps others can help, but I cannot take the guys of the project at this moment and Pierre has only just started a new job so will be understandably busy. We will help where we can though, but I hope you understand this level of very long discussion comes at a cost to us.

[g.u.y]

Hi David,

Thanks for responding!

@dirvine

These are more in code, I have not worked in the code, but please do thoroughly play around with the code/tests and examples there. Otherwise you will need to stop one of the devs working on launch and I cannot authorise that time right now as we are at a critical and extremely busy time.

When you are very familiar with the code then your questions will be very much more direct and easy to answer. Sorry for the push back, perhaps others can help, but I cannot take the guys of the project at this moment and Pierre has only just started a new job so will be understandably busy. We will help where we can though, but I hope you understand this level of very long discussion comes at a cost to us.

Wait there is something that is still incredibly unclear, could you or @bart clarify:

I watched the videos up to 5:17 in this video https://youtu.be/oitDwgSBMDk?t=317 , this is the point where understandability evaporates in an instant:

What on earth do these four balls show?

At 9:59 https://youtu.be/oitDwgSBMDk?t=599 and 11:37 https://youtu.be/oitDwgSBMDk?t=697 there have been two further buildups of complexity.

This appears to be supposed to reflect the EST → BIN → AUX → DEC game.

Could you please take 10 minutes to explain, what is est, bin, aux, dec - why are they there, what is their role in producing consensus.

Currently these make no sense at all to me, even after having spent three work days on carefully reading all of your documents. Your attempt at explanation would be greatly appreciated.

[dirvine]

@g.u.y

What on earth do these four balls show?

These are votes, as Pierre says (yes you forced me to watch that video, I cannot spend more time) the colours represent the nodes view of something (alice’s event) being true or false using green == true, orange == false.

If the event is interesting (seen from supermajority of routes).

That’s EST (estimate of the value). BIN is the agreement they need to make (binary consensus is easier than full consensus)

As a node gets new estimates (seen by more than 1/3) received from any others (getting more concrete) if it sees 2/3 the value is concrete.

If a node sees true and false as valid by convention we accept true.

AUX is the Auxiliary value (first value that forms part of the set of BIN values)

DEC (Decision) is the common coin component (we started with concrete coin) basically a common non deterministic coin flip (or binary value)

I hope that helps, the vid and paper does have all of this as well though.

[Cryptoskeptic]

Man, I’ve been an avid follower for over 2 years and don’t understand a bloody thing of a technical term described anywhere on the forum.
But I have great faith in the Dev team to deliver a mind blowing network.

One question, are you trying to understand Parsec to develop on the network or attempt to hack it?

You are probably aware Parsec has been submitted for academic approval. I can’t wait for that feedback either. Unlikely I will understand a word of that either

[pierrechevalier83]

I’ll give a go at explaining the estimates, bin values, aux values and decided values.

Before I start, I’d like to precise that these concepts come from the “ABA” paper (about binary Byzantine consensus). All of these values are just details of how we get binary consensus. For context, the estimates can be seen as representing a node’s opinion on whether a given node’s voice should be considered for a certain meta-election. That opinion is yes or true if this node’s observer strongly sees an interesting event from that node. It is false otherwise. As many meta-elections run in parallel as there are participants.

For the context of binary consensus, you can forget all of the above. An estimate is simply a binary value that is proposed by a node. The point of binary consensus is to reach agreement on one decided value. That decided value must be the same for all participants and have been proposed (there was an initial estimate with that value) by at least a honest node.

This is done in a few steps. If you want to follow along by looking at the diagrams, bottom left quadrant is initial estimate (true: green, false: orange). Bottom right quadrant is second estimate, if any. Top left quadrant is first “bin value” (also named auxiliary value). Top right quadrant is second “bin value” if any.

So starting from the initial estimates, we want to make our way to decided values. It is done as follows:
If I see >= 1/3 of estimates that are different from my initial estimate, I add them to my own set of estimates. This is because it proves that this estimate has been proposed by at least one honest node since there is at most <1/3 malicious nodes. This happens in a1 (bottom right quadrant), for instance as it sees 2 false estimates, its estimates are true (from a0) and false (from being able to infer that at least one honest node proposed false).

When I see more than 2/3 concording estimates, that makes them one of my bin values. For instance, a1 now sees 3 concording estimates for false, so false gets added to it’s set of bin values (top left quadrant). If both values true and false become bin values at the same time, true goes first by convention.

The first bin value (top left quadrant) is called an auxiliary value. At this point, we know that an auxiliary value was proposed by a honest node and will eventually be seen by all honest node as >= 1/3 of honest nodes have seen it (since > 2/3 of the nodes have seen it).

The only thing we are missing to make a binary decision is commonality. Some nodes could have an auxiliary value that is true and some could have one that is false. They could be split in any kind of fashion. We did gain that we filtered out any value proposed incorrect value; but if we started with a tie (honest nodes have differing estimates), we could still be in a tie situation.

This is where the common coin magic happens: we proceed as follow (this is different from the video. It is simpler to explain if you trust me that a common coin can be created). I flip common coon. If I strongly see a supermajority of concording auxiliary values that are in agreement with the common coin and where that value is present in my set of bin values, I decide for that value. I know that no other honest node will strongly see another auxiliary value and it must have been proposed by a honest node.
If I strongly see a supermajority of concording auxiliary values, but they don’t agree with the common coin, I pick the common that value as my next estimate (but can’t decide yet as it wouldn’t be guaranteed to be common) and go for another round from estimates upward. Once a node decides, their estimates etc. are fixed forever.

There are 3 possible cases:

• No supermajority of concording auxiliary values: all honest nodes will pick the common coin as initial estimate from next round and the other value won’t be in anyone’s bin values as there is less than 1/3 of it. Common decision will be reached in the next round.
• Supermajority of auxiliary values agrees with coin. Some nodes may decide. Everyone else will pick the common coin as next estimate. Since it agrees, decision will be reached on the next round as all honest nodes start with the same estimate.
• Supermajority of auxiliary values disagree with coin. No node will decide. Further rounds may start in a tie situation and end in a tie situation. This branch has less than 50/50 chance of being hit for any round, so we will eventually hit one of the other branches and decide.

And this is how we get to agree on one binary value that

• Must have been proposed by a honest node
• Must be common
• So that every node will eventually decide,
  a.k.a binary consensus.

[JPL]

Have you had your breakfast yet @pierrechevalier83?

[pierrechevalier83]

Hehe random question . Not yet

[JPL]

You’ve done more before breakfast than I do in an average morning!

[pierrechevalier83]

It’s more than I do in an average morning too, don’t worry . I felt this needed a bit of a detailed answer to help the OP, but not so many free timeslots as I’m settling into my new job.

[happybeing]

I’m sure we all really appreciate your taking time to answer these Pierre, i certainly do and I take my hat off to you for doing so. Just makes me even sadder about you leaving! But by all means continue, maybe you can never truly leave

Good luck with the new job, I hope we’ll get to learn what you get up to there too. Where will you be based, if you don’t mind saying?

[g.u.y]

Hi @pierrechevalier83 ,

Thank you very much for your extensive response.

I believe what you mean will become clear, apparent and self-evident very very soon, and for me to reach there I have one very fundamental question,

and to phrase the question clearly to you, I’ll correlate my question with the usecase:

Usecase for context:

The black parts of the illustration, is the DAG I like to hold a vote on.

What I like the Parsec nodes Alice, Bob, Carol and Dave to vote about, is specifically, which of the green, blue, red and yellow conditioned vertices to add to the DAG.

The condition in this case is that the parent vertex exists, and this applies in this case to the blue vertex only - that one can only be added, if the green parent has also been added.

Now to the…

Question:
You explained what estimate is, with these words:

the estimates can be seen as representing a node’s opinion on whether a given node’s voice should be considered for a certain meta-election.
…
An estimate is simply a binary value that is proposed by a node.

This still left me with this fundamental question:

HOW does the DATUM I like to vote for (in this case, the green, blue, red and yellow vertex above), CORRELATE with the EST value?

Say that Alice likes to vote for GREEN only, Bob likes to vote for BLUE only (= invalid !! he’s byzantine :o ), Carol likes to vote for both green, blue, and red, and Dave likes to vote for red and yellow.

I’m fine with that the consensus would take only some of the valid votes, i.e. ANY, EITHER or ALL of Alice’s, Carol’s and Dave’s but of course not invalid Bob’s.

The only important thing is that they will reach consensus.

Please explain what EST for A[lice], B[ob], C[arol], D[ave] should be to represent the above vote, e.g. in the first GossipEvent that they send each other.

Also:

• Please define “interesting”, it’s neither in whitepaper nor RFC nor anywhere
• I don’t master the term metavote yet - what is a metavote and where does it happen (may become clear as you explain the term interesting)

Thanks!
Guy

[g.u.y]

@Cryptoskeptic

One question, are you trying to understand Parsec

Right now just trying to bridge the documentation gap, thanks! Very grateful to Pierre, David and others for explaining here on the forum.

[g.u.y]

(PS @pierrechevalier83 about rfcs/gossip_graph.dot.svg at master · maidsafe/rfcs · GitHub , when having watched this one previously, I thought all of A_0 to A_2, B_0 to B_3, C_0 to C_3 and D_0 to D_3 had EST values attached to them but for some obscure reason had been redacted away in the SVG .

Now I’m starting to realize that instead, EST is calculated by the respective Parsec participant at the time it has reached an “observer” GossipEvent , which is in turn defined relative to the word “interesting”, which I believe you will clarify the meaning of soon - this should mean Parsec will become very much clearer with your next response.)

[dirvine]

@g.u.y

which is in turn defined relative to the word “interesting”, which I believe you

An event seen by >2/3 of nodes. So take an event and look back across the graph at who “seen it”.

[mav]

Great to see technical questions and detailed investigation. I’ve tried to answer some questions but there’s a lot of detail in this topic so haven’t touched everything. I’m glad to see you digging in and helping work toward a simple and clear explanation of PARSEC.

@g.u.y

why is this an important problem to solve [ie establishing a common consensus among voters on which members dropped in and dropped out]

The membership of nodes is critical for security of SAFE network. Knowning which nodes have joined or where they should relocate to or from is essential for

• correctly measuring the age of nodes, which determines
• the correct assignment of responsibility to nodes for consensus which determines
• the state of the network and data on it and
• security by distributing consensus decisions evenly rather than only to potentially malicious nodes

More generally, ordering of events in a distributed asyncronous byzantine network is important for many reasons, eg in bitcoin the ordering of blocks determines which transactions are valid or invalid. Similarly in SAFE network, the order of events (not necessarily node membership) might be important for applying mutations to data in the correct order, or detecting multiple simultaneous mutations and deciding how to proceed, or mutating a shared state such as pricing values or rewards or storage capacity in a consistent way for all nodes.

@g.u.y

what is this answer used for.

Currently PARSEC is used to order the joining and departure of nodes into and out of sections of the network. It’s also used to determine membership when sections split or merge. Specifically it’s used to ensure all nodes see the same history regardless of when they ‘hear’ about events, which may arrive at each node in a different order due to the asyncronous and distributed nature of gossip and node membership.

The membership is important because it determines which nodes store or don’t store specific chunks of data and ensures the correct degree of redundancy etc.

@g.u.y

how do I detect a malicious node
…
Which are the detection points/criteria that show or indicate a malicious node.

See RFC-0050 Malice In PARSEC and maidsafe/parsec/src/observation.rs - enum Malice.

---

There’s a lot of questions about the meanings of words, and even though I’m sure you must have seen it I’ll link it anyway - have a look at RFC-0049 PARSEC Definitions. It’s difficult to go through and reword most of the definitions which seems to be what you’re asking for…

One thing I would suggest is to add print statements to the parsec examples since this will allow you to explore the algorithm as deep or as shallow as you need to get the exact understanding you want.

[g.u.y]

Hi @mav , thank you for following up.

I read your response carefully, thank you.

Of “Parsec examples”, there is only one example, basic.rs , right.

Regarding your point “a lot of questions about the meanings of words”, this is not correct, rather I ask about central words’ contextual meanings in order to understand the process they describe. I did read both RFC and whitepaper. I think I’m making good progress to understand the algo currently. Also should dig into the reference implementation.

I’m surprised the reference implementation is 15,000 lines of code, maybe that’s a lot for an optimal-complexity consensus algorithm - perhaps there’s noncritical code in there, will see.

A brief practical special case follow question @mav @pierrechevalier83 ,

Parsec/ABA in its normal mode is creating consensus between votes passed by all/a supermajority of voters, and this is done in four rounds x 2-3 steps per round, this x network latency means ~~1-1.5 seconds to reach consensus.

I am in a place where sometimes, all going on is that only ONE node will pass a vote, and the other nodes will simply accept that one vote.

Can I recycle Parsec’s GossipEvent, networking and DAG logics for this purpose, and somehow include such one-node-only-passes-one-vote-only situations - here, one round x ~2-3 steps should be needed, so reaching consensus in this special case should take ~0.15-0.45sec.

Either node would obviously be free to respond to that one vote, “you know what, I have a vote too” - at which point you’d probably “upgrade” to Parsec with its bigger number of rounds & steps immediately.

So something like two-phase commit:

Adam → Bob, Carol, David: “I have a vote X and I’m not aware of any vote right now from any of you. Do you accept my vote?”

Bob, Carol, David → Adam, Bob, Carol, David “Looks good, thanks. Everyone commit?”

Adam, Bob, Carol, David → Adam, Bob, Carol, David “Commited.”

alternatively

Bob/Carol/David → Adam, Bob, Carol, David “I have a vote too, upgrade to normal Parsec thanks.”

Your off-hand thought on how to incorporate this special case would be much appreciated.

[g.u.y]

Um, maybe for that special case maybe you could even downgrade the nodes to one leader - by a normal Parsec vote for GossipEvent “let’s downgrade to P as leader” - and that leader is given a timeout, so the other nodes will defer any valid votes to the leader to take care of it, as long as they see that he responds within T seconds, and if not time to revert to normal Parsec.