How does the Stellar Network prevent an actor with small quorum intersection from halting the network

Question

I am thinking through some of the edge cases of adversaries attempting to compromise the Stellar Network.

Let's say an adversary creates four consensus bearing Stellar-core nodes and runs all four of them, he makes all nodes list each other in each other's quorum sets.

Each of these four compromised validators also have a single normal non-compromised validator in their quorum sets for a total of 5 validators in the quorum set with a threshold of let's say 80%.

What would happen to the network, if these four nodes proposed different transaction sets to the ledger compared to the rest of the network ( and their one uncompromised peer )?

In this scenario, these nodes are receiving the messages from the rest of the network, and rejecting that transaction set and ledger in favor of the one being proposed by the compromised group.

Some of the questions I am pondering are as follows:

1) What if bridge servers start to listen and relay transactions to one of the comprised servers?

2) Do both networks operate independently

3) How would a client find the proper horizon servers on the uncompromised network?

4) Would this halt the network?

Answer 1

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 validator only includes the compromised nodes in its quorum set). For each round of consensus, other nodes in the network would mark the non-compromised validator as compromised (because of its mismatched result) which would contribute to a tolerated fault that their quorum set has hopefully accounted for.

The 4 remaining compromised validators do not matter since they will logically all roll up to the one non-compromised validator since its the only one that is trusted by a node in the main network. As node admins slowly realize that there is one compromised node in their quorum set they will remove that node from their own quorum set. This would apply similarly to a compromised node that is trusted directly by a node that is part of the main network.

Answers to specific questions:

1. Bridge Server is for Anchors. Your own bridge server should only connect to a node that you trust. If you are running a bridge server you need to also be running your own horizon and stellar-core node; this is part of the bridge server setup. In this case your bridge server should connect to your own horizon instance. Your quorum set for stellar-core will handle the non-compromised but faulty node appropriately as described above if that faulty node is included in your quorum set.
2. Assuming that the nodes in the compromised network include nodes from the main network in their quorum sets, enough to give the nodes in the main network a majority, then they will both be on the same network. The false data being proposed by the compromised nodes would effectively just be ignored. If the nodes on the compromised network do not include enough nodes from the main network to give the main network a majority then the compromised nodes will effectively be on a separate network and it will not affect the main network.
3. Horizon servers should be hosted in an intranet, with Stellar-Core serving as a communication layer to the internet. This means that only private clients will be able to connect to the internally hosted horizon server. Public horizon instances hosted by SDF is an exception and is a public service and it is not something that applications should depend on.
4. As described above, it would not halt the network.