I have been studying PARSEC these days (white paper, forum, medium, youtube, etc), trying to understand it, but I am not sure I got it right - it is kind of a dense reading.
Correct me if I am wrong, but the way PARSEC works is: each node flips a coin, and the results are used to generate a random number (the communication is all done using Gossip). This number goes through a hash to be even more random. Then, it is used to create a ranking according to its distance and each node ID. The closest the node is to this number, the higher rank it gets in the command chain. In this way, being random, it is not possible to malicious nodes to pick their favourite node to be the Byzantine General and they will all agree on just one general (or a ranked chain of them).
Did I get it right? Is this the purpose of PARSEC? To pick a random general?
I also got from other replies that PARSEC won’t replace the close group consensus, but improve it by providing a way of creating order in the events, which is possible once we have the gossip graphs. But why is the order so important here? To create a chain of events? Can anyone give me an example of why is the order so important?
So, what’s the purpose of PARSEC? To choose a random general? Or to order events?
2 requests to append data to an AD come in (approximately) together. Due to lag times some vaults see one of the requests as being first and the other nodes see the other as being first. Order is important since you don’t want 1/2 of the vaults deciding on one request to do first and the rest of the vaults deciding on the doing the other request first. Later on there would be inconsistent data/versions depending on which vault supplied the contents of the AD.
Then there is the question of rejecting a node from being a part of the section. Some events maybe in the progress of happing involving that node. So knowing the order of things will ensure that some nodes don’t think the node being rejected was still valid even though the other nodes do not.
More accurately agree order of events and secure that order in a graph. We also take this and can create chains (ordered lists signed by quorum), to allow us to have linear representation of a graph of order (the parsec gossip graph).
I think it is because that defines the reality at any particular point - for example what the rank of a node is, whether a node is in one section or another etc. So agreeing on order, is agreeing on state, because order is change from one state to a new state. To agree the new state it is necessary to agree the order of events, because that determines the next state.
Something like that!
I like your description of PARSEC (in the OP) , can someone confirm it is accurate?
I would say this is partially accurate but it focuses on a detail of Parsec while omitting the bigger picture.
There is a coin flip mechanism, but that can be seen as a bit of a detail of the binary consensus.
If I wanted to describe Parsec succinctly, I would say that the key idea is reducing general consensus to binary consensus by agreeing which node will decide the next arbitrary payload.
Of course, if you decide that Alice (for instance) is that node, you must make sure that all honest nodes will be able to see Alice’s proposal so they all agree on the same value.
For that reason, you define observers: events that strongly see events created by a supermajority of nodes that are interesting (i.e. worthy of reaching consensus on). Each observer will virtually vote yes for any node for which they strongly see an interesting event this node created. This yes/no virtual vote is a binary value; so we can reach consensus on it with a binary value protocol.
Once you start speaking of the binary consensus protocol, you have a coin in there that serves as a bit of a tie-breaker if all nodes aren’t proposing the same binary values. That coin can be a “common coin” or a “concrete coin”. In current Parsec, it’s a concrete coin. The general idea here is to generate a random looking value that everyone will generate identically and that malicious nodes can’t predict before honest nodes are aware of that value. Detail: the difference between a common coin and a concrete coin is that a common coin will always be common but a concrete coin will only be common more than a fixed percentage of the times a coin is flipped.
About its purpose, like you said; it’s reaching consensus on an order of event. That’s the purpose of any consensus protocol. We need it primarily to maintain a consistent agreement on who’s supposed to have which role in the network at any instant. Note that this is all asynchronous so the definition of “instant” is only given a node’s local view on things. So basically, something like: I want to send a message across the network. Who do I send it to? If the answer is “the closest elder to the destination that you know”; you have to know who’s an elder at this time (from your point of view) and that must be something that also make sense to all other nodes you’ll interact with. It can also be used for other stuff, but in general, maintaining the topology of the network is the main aim imo.
One thing that still not clear to me is how this will work with the current close group consensus mechanism.
For example, in the current voting system, Alice’s proposal will also be seen by all the honest nodes. Right?
Just to make sure we are on the same page, and correct me if I’m wrong, that’s how the current consensus mechanism works:
The group needs to decide if they approve or reject an action (e.g. safecoin ownership transfer);
The nodes of the group vote to approve/reject it (it can be rejected if, in the example, the safecoin doesn’t belong to whom is asking for the transfer);
The votes are weighted according to their age;
If approved by the majority of the votes, it goes to a special node, the manager (the oldest node), which will give the final word (approve or reject it);
The way I understand it, in a network level, the voting happens almost in an sync way. Using the safecoin transfer as example, the manager gets the request from the client, ask the nodes if they approve or reject it, waits them all to answer, sums the votes and does the decision. If approved, using its veto power, it double-checks if the transaction is valid.
The above mechanism is the way SAFE reaches consensus (even with malicious nodes) and it is based on proof-of-resource, which seems pretty solid to me. Will this mechanism be changed with PARSEC? How?
Will PARSEC be used to randomly choose the manager? Will it be used to change the weights of the votes? Will it be used just as a way to coordinate the voting communication? Will it be used just to sort which transactions should be voted first?
The actual consensus is based in accumulator. The node closest to the XOR position of the data is in charge of accumulating the group vote. The “age” don’t exist.
In this post there is an explanation of the current consensus
Oh, I see now. I don’t know from where I got the idea that we had a weighted voting system. I was pretty sure there was some kind of “ranking system”. But anyway, last time I studied the network was years ago.
So, I suppose that, in the consensus context, the “node aging” is only being used to decide who can/can’t vote, right?
Great post. Thanks for sharing. It cleared a lot of questions I had.
So, the “accumulator” is a node in the group that is chosen to manage the voting process. It receives the event and it is responsible to collect and sum the votes. Once the voting process is done, it sends the results to all nodes in its section, to be validated. This “accumulator” is the closest node to the payload. Got it.
I also understand now some of the problems that PARSEC solves: for example, what if the accumulator is malicious and it doesn’t send the computed votes to all nodes in the section? It can choose just few other malicious nodes in order to get a bogus approval. One solution is the swarm mechanism, but it requires to send a lot of messages to guarantee that everybody gets the results. Gossip (a multicast protocol) fixes this problem without overloading the network with tons of messages. Another problem was if a node is added during this process. There is no malice here but in this situation the event can be wrongly rejected or delayed because this new node will affect the total expected votes. PARSEC also fixes this problem because it sets an order to the events.
Questions:
Is the accumulator still being chosen according to the XOR distance (the closest one)? Or PARSEC will now pick a random node to be the accumulator?
Are these ordered events going to be saved as datachains? Does PARSEC changes the datachains in any way?
The other post says that the votes, after being collected by the accumulator, go to the entire section to be checked. Can the section reject a decision made by the group? Is there a 2nd voting (1st voting = close group, 2nd voting = section)? If so, is PARSEC going to be used to coordinate this voting too?
Right, although to point out that in the current consensus the node ageing is not implemented. In the future only the elders, of a section, will have the power to vote in the consensus.
Parsec is leaderless and doesn’t need accumulator nodes.
Yes. What Parsec allows is simplify the implementation of datachains.
Parsec has meant rethinking questions as the relationships between a section and theirs groups, their sizes, who votes what and under what circumstances.
Half of the Devs, in routing, have been working on this questions these past few months. I suppose they will soon show us their conclusions.
