“The randomness and the blind election of keys assignment to all eligible validator is a bad idea since protocol has no sure way to say the node will be running smoothly to help the network.”
In what way NOW does the network know that a validator will be running smoothly other than it has x amount of keys and x amount of stake??
It has happened many times and is indeed part of the protocol that a poorly performing node will be booted from election. this happened many times with Kucoin to the tune of 40+ keys and the network handled it fine.
Indeed this was cited by Harmony as justification for moving towards decentralisation and having the community run more nodes than Harmony… Has this changed?
Right now we have a node with 29 keys about to get knocked out… This is most likely due to poor management the protocol has be proven to be able to handle this.
I do propose getting rid of key bidding and allowing automatic assignment… Using a round robin will spread keys out which will minimise the risk and make the action of ‘spinning up more nodes’ less viable because it would make no difference.
It could be that some sort of extra requirement is to be considered for random assignment such as uptime or being synced to a certain range. Information that is known and served by Harmony RPC’s
Maybe a hybrid solution of keys per shard per node and THEN randomly assign based upon that… combined with the above uptime / syncing.
Example:
4 keys per node per shard
IF uptime > 90% AND db is synced to within 100 blocks
THEN allow that node to be assigned
The focus maybe should be, as you noted, geared more towards infrastructure rather than stake.