Say we have four nodes in a section: A, B, C and D, and say that E is trying to join. The four nodes need to vote for E to join in order for that to actually happen. Let’s say that A sees that it voted first, and then it received votes from B, C and D. B first received a vote from D, then it voted itself, then it saw votes from C and A; etc. Everybody can see a different order of the votes - what we want is to have a way for all of them to agree on one shared order, which we call “consensus ordering”.
It’s not that important in this simple example, actually - but there are situations, usually having to do with splits and merges, in which such a shared order would be very helpful.
Not yet. Our current algorithms are attempting to ensure only that merges and splits are ordered with respect to other events (nodes joining/leaving), but don’t really give us any proper guarantees even about that. We are working on a much more robust solution.
It has to, about some things - especially about merges. But this is a step above the consensus inside a group/section, and having such a consensus first will be a huge help towards achieving inter-section consensus.
Algorithms for finite state machine replication are usually exactly the algorithms solving the consensus problem. Most of them don’t have the properties we need, unfortunately (they are either leader-based, or do not cater to the situations with malicious nodes). We specifically require a leaderless, Byzantine fault tolerant (which is another way of saying “resilient against malicious actors”) algorithm - which narrows the scope a lot, and the algorithms that remain all have some other drawbacks. We do have a few promising ideas, though, and that’s what our efforts are focused on recently.