In Tests 11, 14 and its integration version, how does a node learn that its proposal has been rejected so that it knows to retry? My understanding was that it just does not reach PROMISE (or PROPOSE) majority before the paxosRetry timeout, therefore it makes another attempt with a new ID (and, since TLC majority has been observed in the meantime, a higher block number).
However, in these tests, paxosRetry is set to 1000 seconds, which means it does not fire during the test. What am I missing?
Hi, I had kind of the same issue. I assumed that when we reach a consensus in a Paxos box (receiving a TLC message), the proposer can just stop waiting for promise or accept .
I hope that the approach is correct and that can help you!
Hi Stratos,
Thanks for your question. What Bastien said makes sense (thanks, Bastien!). To summarize: say that node A proposes value v1 for block 5, but some time after sending out this proposal, A observes consensus on block 5 for a different value v2. Then node A learned the consensus value v2 for block 5 and can move to block 6.
To add to Bastien's answer: node A still wants to propose value v1, despite his value not being agreed on for block 5. A could directly propose value v2 for block 6. However, if some value in the blockchain conflicts with v2, e.g., v1 or some other value contains a different file name for the same metahash that v2 contains, A's proposal will be rejected. How does A learn about it? Because every node is a proposer, learner, and acceptor, A's proposer could first ask A's learner whether v2, the value to be proposed, conflicts with any of the values already in the blockchain. If it conflicts, A shouldn't propose v2 because it'll trivially be rejected by the other acceptors (and should be rejected by A's acceptor as well).
Does this make sense? If not, please write back.
Cristina
Perfect, yes! Thanks, both Bastien and Cristina!
Follow the pulses of EPFL on social networks
© 2023 EPFL, all rights reserved