Nominate --> Prepare --> Commit --> Externalize question

Question

Ok, so I am trying to grok how, if at all, state moves through this setup.

Let's say a stellar node receives a transaction from a client that it wants to propose to the network. The node then sends an SCP nominate message with the transaction to its neighbors (a set of whom represent a quorum slice for the sending node). Let's do this with just two nodes for now. I think what happens is as follows:

• Node 1 sends SCP nominate with Tx1 state: Vote

  Node 2 receives SCP nominate with Tx1 state: Vote and replies to Node 1 with state: Accept

  Node 1 receives SCP nominate with Tx1 state: Accept and replies to Node 2 with state: Accept

This concludes nominate (the final state of Nominate being "prepared"). Then we do commit.

• Node 1 sends SCP Commit with Tx1 state: Vote

  Node 2 receives SCP Commit with Tx1 state: Vote and replies to Node 1 with state: Accept

  Node 1 receives SCP Commit with Tx1 state: Accept and replies to Node 2 with state: Accept

This concludes commit (the final state is that the transaction is written to the ledger/disk for all tx's in the ballot). Then we do externalize.

• Node 1 sends SCP Externalize with Tx1 state: Vote

  Node 2 receives SCP Externalize with Tx1 state: Vote and replies to Node 1 with state: Accept

  Node 1 receives SCP Externalize with Tx1 state: Accept and replies to Node 2 with state: Accept

Is this correct? Can someone also clarify for me what externalize does that commit does not do?

If this is the case, is it possible that, assuming I disable the ability for nodes to change quorum slices mid-vote, after I have completed the 'prepare' state, I now have a set of nodes that represent quorum and I can just use a simpler algorithm like practical byzantine fault tolerance to federate the transactions?

It feels like the stellar algorithm is a 3-phase commit 3x and I'm not sure why we have to do the full 3-phase commit 3x if we completed it once (that is to say I don't know that doing 3PC again for the commit and externalization steps actually helps prevent byzantine faults in a cheaper way than PBFT).

Answer 1

First, note that the values in stellar are actually sets of transactions, or actually triples with a set of transactions, a timestamp, and a list of upgrades. Second, it's a little hard to follow your example because you didn't specify what the quorum slices were, so I'm going to answer your higher-level questions.

Can someone also clarify for me what externalize does that commit does not do?

The SCPExternalize message is not strictly necessary. However, it is useful when nodes have fallen behind and need to catch up. Say you were offline for a week and want to catch up, but in that week some nodes have died and nodes changed their quorum slices. So while you have a live quorum today, you don't have a quorum from a week ago. The SCPExternalize lets you prune your quorum search when looking at week-old messages, so if a quorum slice and blocking set from today has sent you SCPExternalize from last week's ledger at the same ballot number, that's good enough, you don't need to track down commit/externalize messages from other members of the quorum slices.

I can just use a simpler algorithm like practical byzantine fault tolerance to federate the transactions?

You might be able to, but would at the very least sacrifice some liveness, because whatever quorum you happen to select could suffer node failures partway through the protocol. SCP is crafted in such a way that it won't get stuck so long as there is a quorum of intact nodes.

I'm not sure why we have to do the full 3-phase commit 3x if we completed it once

Let me answer this in a kind of imprecise way, but intended to convey the right intuition.

1. You have to do it once for nomination, because unlike in a centralized setting, you can't just round-robin through a set of "primary" nodes. In SCP, not everyone agrees on the set of nodes that exists.
2. You have to do it a second time to actually get a quorum, so as to guarantee there is only one possible value for a slot.
3. You have to do it a third time because unlike a centralized BFT protocol, SCP cannot reason "backwards" about safety. In other words, there are many points in PBFT where the protocol says "f+1 nodes told me this, so either it's true or I have no hope of maintaining safety." In SCP, if a blocking set tells you something is true, then either it's true or you have no hope of maintaining liveness, but you might still be able to guarantee safety. To guarantee safety, you must first-hand verify a quorum. That's why you need a second confirmation vote essentially to confirm that the first vote succeeded.