user25028: 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?

user85: 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.

user24989: 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

25028: <p>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.</p>

<p>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?</p>
 85: <p>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.</p>

<p>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.</p>

<p>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.</p>
 24989: <p>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.</p>

<p>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.</p>

<p>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: <a href="http://www.cs.luc.edu/~pld/353/gilbert_lynch_brewer_proof.pdf" rel="nofollow">http://www.cs.luc.edu/~pld/353/gilbert_lynch_brewer_proof.pdf</a></p>
