Say some country decides to somehow block all outgoing Stellar connections for 30 minutes. With a voting based consensus that Stellar has chains in both networks progress with a similar speed. After the network split is over there will be two Stellar networks with a diverged history.

How would such an outcome be resolved/avoided with the new consensus changes? Is there some way to determine which network state is correct after the split? Can the smaller split network know that it's split and pause accepting transactions?


Assuming people chose adequate quorum slices and the system has quorum intersection (which is how the system is intended to be used), then with Stellar's new consensus protocol, at least one of the two partitions would be unable to settle transactions for the duration of the network outage.

Stellar does allow for redundancy, in that validators can have multiple slices. For example, a slice might consist of any 5 out of 7 validators spread across countries. In that case, if the partitioned country has only 1 or 2 validators, the rest of the world can continue to make progress.

This kind of scenario is actually unavoidable. You have to chose at most two out of Consistency, Availability, and Partition tolerance. This is sometimes known as "Brewer's theorem" because Eric Brewer conjectured it and Seth Gilbert and Nancy Lynch subsequently proved it. See: http://www.cs.luc.edu/~pld/353/gilbert_lynch_brewer_proof.pdf

  • This does seem avoidable though. You could allow both sides to make forward progress during the split, as Ripple does, and resolve which side was "authentic" afterwards. By not making forward progress during the split, you accumulate a massive backlog of valid transactions during the split. This seems to be more disruptive than needed. Apr 12 '15 at 1:32
  • Well Brewer's theorem is unavoidable. You are advocating availability and partition tolerance over consistency, vs. stellar prioritizing consistency and partition tolerance over availability. Sounds like ripple and stellar just make different trade-offs. Apr 13 '15 at 4:04
  • Not exactly. I am saying that Stellar sacrifices availability here for no apparent reason. There is no apparent corresponding benefit in either consistency or partition tolerance. The consequences might be significant, depending on what fraction of transactions are voluntarily abandoned if delayed. If that's high, it doesn't matter. If that's low, a partition could lead to a persistent backlog. (My gut instinct is that it probably is fairly high. Most transactions, if they take too long, will likely just be abandoned. So it may not make much difference.) Apr 13 '15 at 5:05
  • Not sure I see your point. Do you disbelieve Brewer's conjecture? Assuming quorum intersection of good nodes, Stellar's algorithm has been mathematically proven to offer consistency (or "safety"), regardless of any network partitions. So it's consistency and partition tolerance are as good as one could hope for. These guarantees come at the cost of availability, in the sense that at least one of the partitions cannot settle transactions without agreement from the rest of the world, but by Brewer this is inevitable, not for no apparent reason. Apr 13 '15 at 15:31
  • I think I see where you're misunderstanding me. You have two choices when you are partitioned. You can make forward progress on neither side. Or you can make forward progress on both sides but only later know which side you're going to keep (and throw the other side away). True, you can't settle transactions on both sides, but that doesn't mean you have to make no forward progress at all. Sellar chooses to make forward progress on neither side just because it can't settle on either side. This is not required by Brewer, it's just a choice. Apr 13 '15 at 17:06

I think your question is based on the flawed premise that this is a problem. While the network is split, at most one side has sufficient validators to fully-validated ledgers, even though both sides are making forward progress. It's also possible that neither side will have a super-majority, and thus while both sides will make forward progress, neither side will fully-validated any ledgers.

Once the two sides rejoin, one chain or the other will acquire a super-majority due to avalanche of the validators as the network rejoins. This is better than not making forward progress during the split because network transaction capacity isn't lost.

During rejoin, a large number of otherwise-expensive checks are not needed. There's no need to execute transactions twice (once to decide how to vote on them and then again to determine their actual results). There's no need to retry transactions (since you know the order they executed in). And so on. All you have to do is build each ledger in the final accept process, which you need to do anyway because you need to update your databases, push transaction results to clients, and so on.

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.