Avoiding Collusion on EOS

I'll start off by saying I'm a new developer for EOS and I've been digging incredibly deep into the System Contract to get a full understanding of how it works. It has been a major part of the work I'm currently fulfilling.

Current System

Rotate between 21 different producers who receive weighted votes from users. The top 21 producers with the most votes will produce the blocks necessary for the network to function. A larger account will have a 'heavier' influence on the vote. Imagine the top 1% of the United States decided to vote with their money vs. the rest of the United States. The rest of the world besides the 1% wouldn't even matter.

How you get registered to vote on the EOS Main Net System:

Create an account.
The account is created in the system contract.
If the account has no funds staked it must stake funds before the account can vote.
Once the funds are staked the account can vote.
If you want a more effective vote, stake more funds.

Pros:

You get to help choose who is the most reliable and proficient producer.
Producers have incentive to be 'good' actors or get voted out.
You're required to 'STAKE' to get usable resources on the chain. Meaning you must vote in order to use the chain.
Enough money is involved that being a bad actor will only go on as long as other users allow it.

Cons:

Large holders have a larger impact on the chain.
New funds can be introduced into new accounts to help secure voting spots.
Collusion is incredibly easy to do if you secure a top position.
If 21/21 producers collude the entire network can be shut down.

The Pros and Cons are pretty brief but it summarizes how a lot of users feel about the current iteration of the main net.

A system should have been put in place to automatically replace disconnecting block producers in the protocol level of the system. This was not achieved on the main net launch.

Instead the producer schedule is updated whenever a schedule has not been set in a 60 second period. Potentially allowing for all 21 producers to shut off the network if strategically done.

On the protocol level the schedule is checked constantly for a producer schedule expiration.

A Random System

The major problem that I see is that the voting itself is causing 'good' competition. However, if this 'good' competition gets ahead of everyone else they can band together and pretty much just shut down the system. What do you do to fix this? Throw in additional random producers that ARE NOT using the voting system.

Here's an example of a system off the top of my head.

6x Producers with the HIGHEST VOTES.

3x Producers with the LOWEST VOTES.

3x Randomly Selected Producers Between.

1x Top Holding Producer that is neither a high or low vote.

1x Mid Holding Producer that is neither a high or low vote.

1x Low Holding Producer that is neither a high or low vote.

6x Other Means of Election.

You still get 21 producers. You get complete randomness. There are other opportunities to pursue a position on the EOS Chain and be rewarded.

Other Solutions May Include:

Rotation equally between all producers randomly.
Ensuring Voted in Producers don't account for 14 or 15 of the producers. Lower the amount of voted in producers to less than 14.
Public Repository of Projects that can be voted for that have general usefulness. Each account can only cast 1 vote. The repositories of projects with most usefulness get set in as producers. Highest rated but not top repositories are also voted in. Several 'new' projects get voted in for a short period of time to mimic randomness.

In those regards if you come up with better solutions by all means post about it. Knowledge is power.