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!

2 Answers 2

  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.

  • 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? Commented Jul 24, 2018 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. Commented Jul 25, 2018 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
    Commented Sep 25, 2018 at 15:32
  • @user3188445 Thanks, I think I get it now.
    – PiersyP
    Commented Sep 26, 2018 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. Commented Sep 27, 2018 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


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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