I recently have studied the Stellar Consensus Protocol (SCP) based on the internet draft here: https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/.

I have several questions as follows.

  1. In the last paragraph of Section 3.6, a node leaves the PREPARE phase and proceeds to the COMMIT phase when there is some ballot "b" for which the node confirms "prepare(b)" and accepts "commit b". However, SCPPrepare message does not (conceptually) convey "accept commit b", while it is conveyed in SCPCommit message, as far as I understand. Is this correct? It seems a bit odd because the PREPARE phase ends with the aid of SCPCommit message.

  2. Regarding the conceptually iterated federated voting over the nomination, ballot, and externalize phases. Please check the following (where x = value and b = ballot), and let me know if I have any misunderstandings.

input "x"
--------------------------- the NOMINATION phase starts
vote "x"
accept "x"
confirm "x"
--------------------------- the PREPARE phase starts
vote "prepare(b)"
accept "prepare(b)"
confirm "prepare(b)"
vote "commit(b)"
accept "commit(b)"
--------------------------- the COMMIT phase starts
confirm "commit(b)"
--------------------------- the EXTERNALIZE phase starts
output "b.value"

  1. I cannot fully understand why we need to keep track of the preparedPrime (i.e., p') in the SCPPrepare message. Could you briefly describe an example which motivates the use of p'?

Thanks very much for your time and help!

  1. The SCPPrepare message conveys "vote commit ballot ". However, it does not convey "accept commit c" for any c, because if it accepts any commit message then it immediately proceeds to the COMMIT phase and issues SCPCommit instead of SCPPrepare messages. Of course, a node in the PREPARE phase could accept "commit c" for some ballot c after getting SCPCommit messages from a blocking set. The latest draft says this about that situation:

    A node leaves the PREPARE phase and proceeds to the COMMIT phase when
    there is some ballot "b" for which the node confirms "prepare(b)" and
    accepts "commit b".  (If nodes never changed quorum slice mid-
    protocol, it would suffice to accept "commit b".  Also waiting to
    confirm "prepare(b)" makes it easier to recover from liveness
    failures by removing Byzantine faulty nodes from quorum slices.)
  2. The sequence looks basically okay, but certain things happen concurrently, or at least without intervening protocol messages. For example, "confirm prepare(b)" and "vote commit b" are actually the same message (though the act of the first one happening is what allows the second). Similarly, "accept commit b" happens concurrently with the transition to the COMMIT phase, and "confirm commit b" and "output b.value" both happen concurrently with the transition to the EXTERNALIZE phase.

  3. Conceptually, you need to keep track of every single ballot you've ever accepted as aborted. The reason is that if some other node voted "commit b" for some ballot b that was later aborted, that node will be stuck until a blocking set asserts that they have all accepted "abort b." Keeping track of an arbitrary set of accepted aborted ballots could be cumbersome. Fortunately, the prepared predicate is designed in such a way that keeping track of all accepted aborted ballots only requires remembering the top two such ballots with different values. In other words, say the top two you accepted are prepare(<10,x>) and prepare(<7,y>), where x != y. This means you have accepted every ballot under <7,y> as aborted, and every ballot between <7,y> and <10,x> as aborted except those with value x.

| improve this answer | |
  • Thanks. One following question regarding the use of the prepared prime. How do we use the prepared prime in assessing quorum threshold and blocking threshold? – Donghwan Shin Jul 24 '18 at 6:11
  • @DonghwanShin You consider all ballots under preparedPrime to be accepted aborted for whoever sent the preparedPrime. That means if there is some ballot that is less than preparedPrime in some messages and less than and compatible with prepared in others, then if the set of messages is blocking you, too, can accept the ballot as prepared. And if the set comes from a quorum, then you can confirm the ballot prepared and vote to commit it. – user3188445 Jul 25 '18 at 8:41
  • @DonghwanShin, I think you mean "That means if there is some ballot that is greater than preparedPrime in some messages and less than and compatible with prepared in others" – PiersyP Sep 25 '18 at 15:32
  • @user3188445 Thanks, I think I get it now. – PiersyP Sep 26 '18 at 15:34
  • No, I meant what I wrote. The point is that if it's less than preparedPrime, then you don't care what the value is, you know the sender has accepted it as aborted. If it's between preparedPrime and prepared, then the sender only accepted it aborted if it is incompatible with prepared. – user3188445 Sep 27 '18 at 1:28

As per my understanding, the flow should be like this:

            Vote x
            Accept x
            Confirm x
            Vote prepare(b)
            Accept prepare(b)
            Confirm prepare(b)/Vote commit(b)
            Accept commit(b)
            Confirms commit(b)
            Outputs b.value

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.