Tl;dr: Stellar’s protocol (SCP) uses a decentralized state propagation where each node commits to a value if every node it deems trustworthy agrees while Ripple uses a supermajority vote (80%) among all validating nodes. Stellar achieves better decentralization than Ripple.
A pretty old, but still relevant discussion on the bitcoin stack exchange
I'll take a try to explain in simpler terms. But first I assume you understand that Quorum Slices are to help a Stellar node do the validation.
Stellar is all about trust (validators). After all, when you have to trust somebody, you'd trust the reputated nodes, rather than a random stranger node on the internet.
You can imagine Quorum as a list of ...
The way the SCP protocol works, you include your quorum slices in your vote messages. So following your example, nodes would say the following:
A says. "I vote to accept statement a so long as B accepts it, too."
B says, "I vote to accept statement a so long as C accepts it, too."
C says, "I vote to accept statement a so long as A accepts it, too."
So now ...
From my recent blog post:
Everybody knows that Stellar Network is a blockchain-powered platform, right? However, it's architecture is completely distinctive from, let's say, Bitcoin or Ethereum. There is no mining, no PoW or PoS algorithms, it resembles rather a database with a simplified API than Bitcoin sequence of blocks. So why is it listed on the ...
If you look at the stellar-core codebase, under the HerderSCPDriver's validateValueHelper function, there is this code snippet:
// Check closeTime (not too old)
if (b.closeTime <= lastCloseTime)
// Check closeTime (not too far in future)
uint64_t timeNow = mApp.timeNow();
The Stellar Consensus Protocol is a form of Byzantine agreement protocol.
It is said to be Sybil-proof. It is discussed in page 3 of the
Stellar Consensus Protocol official paper
And I really can't explain better than the people who implemented it in this use case.
slot is simply a ledger number in Stellar implementation.
Once previous ledger closed nodes start by proposing candidates for the next "slot" and then vote on it.
Some relevant info can be found here
key implementation details
The Herder considers a ledger number to be a "slot" in the SCP protocol, and transaction set hashes (along with ...
You can read the network configuration section in the admin guide.
Here is the relevant snippet:
For a new value to be adopted, the same level of consensus between nodes needs to be reached as for transaction sets.
What that means is that the mechanism (consensus) to get the network to agree to a change is the same one than for deciding which transaction ...
As a practical matter, SCP's asymptotic security follows from the fact that it depends only on digital signatures (and hash functions) for security, and that these can be tuned to resist arbitrarily powerful attackers.
For example, you consider an attack in which every grain of sand on earth is a supercomputer attempting to break SCP a billion times per ...
Yes, you are right that a full validator configures and writes to an archive. But basic validator can also have a history archive.
Apart from all other differences mentioned in the documentation, main difference between Full and Basic validator is that, full validator maintaines full history archive and publishes it for anyone to view. Its publicly ...
The tricky part is that the timer for the nomination rounds of the SCP protocol starts five seconds after the previous slot's nomination protocol has ended. If you want to have an arbitrary delay between slots while waiting for a transaction, you may want to trigger the start of nomination from something other than the previous round. However, the only ...
Yes, all nodes maintain the exact same ledger as a replicated state machine on top of the Stellar Consensus Protocol (SCP). It is a serious configuration error to have two disjoint quorums--such a configuration will cause serious problems for the network if the two quorums agree on different sets of transactions for a ledger. At that point people will have ...
I think you are conflating the ballot and the candidate value chosen by the ballot. The candidate value (which includes a set of transactions) is selected using a nomination protocol that typically randomly chooses one node's candidate value based on the node's importance in the system. However, it's possible there are multiple candidate values nominated, ...
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 ...
You're mixing up two completely different concepts here. One is about transaction finality, and the other is about resistance to sybil attacks.
POW has probabilistic finality, since there's always the potential of a longer chain reverting your transaction.
SCP has deterministic finality -- when a transaction is included in a ledger update, that's it. No ...
tl;dr: the rest of the network can still reach consensus and it will not halt the network.
In your case, there is only one non-compromised validator. Any node outside the set of compromised nodes that include the non-compromised validator in their own quorum set will get a non-matching result from just that one node (assuming that the non-compromised ...
Each node defines which other ones it trusts for the quorum.
The layers are a good example for a model how to organise whom to trust.
But on the technical side there are just node addresses and thresholds defined.
When you want to add a new node to your "layer", you would need to add it to the QUORUM_SET in Core config.
I found method which returns the expected ledger closing time,
First thing to see is that the PoW algo isn't what gives BitCoin immutability; the PoW algo is throttling the speed at which new blocks can be found based on current conditions of the machines on the network. In fact, the oldest blocks on the chain are the easiest to manipulate because the hardware put to the task was so much more inferior to the hardware ...
I'd consider it a decentralized permissioned blockchain. There is no central authority to receive permission from, but the system is based on proliferated trust so you need to get trusted by someone who is already trusted in order for your validation opinions to have any merit.
It says Can't have FAILURE_SAFETY=0 unless you also set UNSAFE_QUORUM=true. I guess you might have set somewhere FAILURE_SAFETY=0.
In the example config, it says
A value of 0 is only allowed if UNSAFE_QUORUM is set
Therefore, your log showed Got an exception: SCP unsafe. To fix this, you have to declare UNSAFE_QUORUM=true.
As you have 3 nodes, n=3 &...
If you run a stellar-core instance, it is possible to query the quorum set for any validator via an http request on port 11626:
Here is the endpoint your would use:
And here is a description from the docs on the Stellar website:
returns information about the quorum for node NODE_ID (this node by
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 ...
A and B cannot sync up with SCP. This is an invalid configuration. B is misconfigured, so should just dump its state and restart with better quorum slices.
SCP only guarantees agreement when there is quorum intersection. (This is one of the reasons stellar-core makes it hard to assign <= 66% threshold. In your example, B would have had to add the ...
I believe there are implementations either complete or in progress, but am not sure if any have been publicly released. If you want to implement SCP, I strongly recommend starting with the protocol specification draft rather than the whitepaper. Many of the people following the draft hang out on the IRTF Decentralized Internet Infrastructure list, so that ...
As per my understanding, the flow should be like this:
Confirm prepare(b)/Vote commit(b)
A couple things.
First, the way quorum sets are configured are always done in the context of a validator.
A validator will never “vote” for something it doesn’t agree with so when you have things like “AB+CD” in the context of A it just means that C and D’s votes won’t matter for A (unless B somehow depends on them).
Second, you need a property called “...
There is https://www.stellar.org/stories/adventures-in-galactic-consensus-chapter-1/, which is a quite nice, as they say, graphic novel.
For people who like to think of themselves as very serious, there's this writeup: https://medium.com/a-stellar-journey/on-worldwide-consensus-359e9eb3e949, which also does the job of explaning the protocol basics.