What happens when a fork/network split occurs on the Stellar network?

Question

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?

I'm not sure whether the consensus algorithm has been significantly changed from Ripple to Stellar, but if it hasn't, your question is answered here: What is the exact consensus protocol Ripple uses? — Murch, Apr 11 '15 at 16:15
@Murch I think it did. I recall hearing about how Stellar has a proof of how their network won't fork. edit, here: https://www.stellar.org/papers/stellar-consensus-protocol.pdf — Nick ODell, Apr 11 '15 at 16:55

score 4 · Accepted Answer · answered Apr 11 '15 at 22:42

4

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

answered Apr 11 '15 at 22:42

user3188445

291
2
4

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. – David Schwartz Apr 12 '15 at 01: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. – user3188445 Apr 13 '15 at 04: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.) – David Schwartz Apr 13 '15 at 05: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. – user3188445 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. – David Schwartz Apr 13 '15 at 17:06
Indeed, that must be the misunderstanding. I don't understand what "forward progress" is in a consensus system. I think maybe you are talking about an optimization where some of the data structures have been precomputed before the ledger heals, but this is an optimization that should occur at a different level of abstraction from the consensus protocol. Stellar would probably heal things with one single ledger containing a lot of transactions. That doesn't necessarily seem any better or worse than how I think you are describing Ripple, unless it complicates the correctness proof. – user3188445 Apr 14 '15 at 03:07
Certainly there's going to be some upper limit to the number of transactions per second you can make forward progress on. If you make no forward progress on either side while split, a split means lost capacity. If you make forward progress on both sides of a split, all you have to do is decide which one "wins" when you rejoin and you can settle thousands of transactions. That way, the time spent split is not lost settlement capacity. This is just a choice -- it's not required by Bewer. – David Schwartz Apr 14 '15 at 17:08
(By "forward progress" I mean determining the possible results of transactions. By "settle" I mean determining the results that people can rely on.) – David Schwartz Apr 14 '15 at 17:27
Well, in Stellar the consensus protocol can be amortized over an arbitrary number of transactions, so consensus itself is not on the critical path for transaction throughput, just settlement latency. After a partition heals, the other half will have to verify all the transactions anyway, so it's unclear how much precomputation can help things. But this is really a separate issue from the consensus protocol--I suspect either Ripple or Stellar's consensus protocol could be used with or without precomputation. – user3188445 Apr 14 '15 at 18:21

score 1 · Answer 2 · answered Apr 28 '15 at 10:52

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.

What happens when a fork/network split occurs on the Stellar network?

2 Answers2