1

What can happen if two proposals are issued with the same ProposalId? It shouldn't create any problem if they have the same value. But what about different values? I can work out a scenario where it risks liveness at the time of failure, but would it create any problem for the protocol's safety?

narengi
  • 1,345
  • 3
  • 17
  • 38

2 Answers2

1

It's a nice idea because it would ease an annoying design requirement for a practical system: designing a scheme to ensure proposers have different, yet increasing round numbers.

It doesn't work, unfortunately.

Let's define PaxosPrime to be a variation of Paxos where different proposers are allowed to have the same round numbers. We show through contradiction that PaxosPrime is not a consensus algorithm.

Proof sketch: Assume PaxosPrime is a consensus algorithm. Let's consider where each acceptor has a different value, but with the same round (w.l.o.g we'll pick 3). Each will also have promised at 3. We then have a pair of proposers interact in the system.

A1    | A2    | A3
v   p | v   p | v   p  
------+-------+------
x@3 3 | y@3 3 | z@3 3
  1. P1 prepares for round 4 (i.e. Phase 1.A) and receives all three values x@3, y@3, and z@3. There is no provision in Paxos for tie-breaking, so we'll have it choose x.
  2. P2 also prepares for round 4 and receives y@3 and z@3 from A2 and A3, respectively. We'll have it choose y.
  3. P1 sends accepts for x@4 (i.e. Phase 2.A) and the acceptors all process it. At this point all the acceptors have value v@4 and promises for 4. The system has consensus on the value x.
  4. P2 sends accepts for round y@4 and the acceptors A2 and A3 successfully process it. A majority of the acceptors now have value y@4; The system has consensus on the value y.

Here is the trace from the acceptors' point of view:

A1    | A2    | A3
v   p | v   p | v   p  
------+-------+------
x@3 3 | y@3 3 | z@3 3  # Start
x@3 4 | y@3 4 | z@3 4  # Process P1's propose command
x@3 4 | x@3 4 | x@3 4  # Process P1's accept command
x@3 4 | y@3 4 | y@3 4  # Process P2's accept command

The system first had consensus on the value x then consensus on the value y. This is a contradiction on the definition of consensus; thus PaxosPrime is not a consensus algorithm.

∎

Michael Deardeuff
  • 10,386
  • 5
  • 51
  • 74
  • So it violates safety, thanks for the great answer. Here's another idea based on your example: The Acceptors have three different values simply because at least one Acceptor has promised (Phase 1B) to more than one proposer in round 3 (otherwise more than one proposer couldn't have reached the 2nd phase). Paxos allows that. What if we don't allow it? We can easily enforce it by keeping the unique ProposerID (e.g. its IP) with each Promised round in an Acceptor ... (pls continue to the next comment) – narengi Nov 19 '20 at 15:39
  • ... This way, an Acceptor gives its Promise in each round only to *one particular* proposer (and rejecting the others), therefore not allowing more than one proposer to reach the 2nd phase for that round. This consequently eliminates the possibility that Acceptors have different values for the same round. – narengi Nov 19 '20 at 15:40
  • Okay, but what if we only promise prepare numbers that are strictly greater than the highest prepare number seen so far? Then, it would be impossible to get multiple majority promises for the same prepare value but from different proposers. How would you prove it then? – Joshua Anderson Oct 28 '21 at 18:39
0

The Synod algorithm technically does not require the proposal numbers to be unique among all processes. And the monotonically increasing requirement is only an optimization. We could technically choose a random proposal number, and still have a correct algorithm.

The algorithm starts off with a proposer sending a prepare(proposal number) to all acceptors. It can then only uses that proposal number in a proposal if a majority of acceptors haven't seen a proposal number as high as or higher than that yet and successfully send back a promise which can only happen once per proposal number. After this stage, if the proposer is able to continue, then that proposal number is effectively unique. So the algorithm already enforces the uniqueness of proposal numbers that are actually used in a proposal.

Joshua Anderson
  • 97
  • 4