As has been pointed out in other venues.
-
The 20% “cap” was originally implemented as a security measure, not as a business model, limitation to governance, nor as a tool for decentralization of voting power (outside the security case that was considered). It was specifically meant to help prevent a specific situation within the first few minutes of staking reopening. It was proposed to leave it in place after the reopening of staking since it does help no one validator from halting the chain (it takes >= 1/3 total voting power not being consensus to halt the chain, and > 2/3 consensus to sign blocks as accepted in consensus voting).
-
A person can just open (or potentially buy) multiple validators to get around any caps in terms of voting power.
-
Proof Of Stake is predicated on the principle that those who have the most to lose in the system (ie. those with the largest stake) have the least reason to sabotage their own stake.
-
It removes freedom of choice in the business model side of Proof Of Stake (ie. validators partner with those who delegate stake - it is their delegators that actually provide the majority of stake in most cases, and so it is their delegators that are securing the network in coordination with the validators hardware - it is a partnership). Forcing either delegators into selection choices that are not as helpful for them (so they just will not delegate at all), or taking away the business competition of validators to appeal on the basis of value to the delegators and network overall is harmful in the mid to long term to network stability.
-
It also messes with Proof of Stake, which is also has a security component as well (in broad terms, and stated here and here (validators - end) and here in specific terms to this network).
-
If it is governance that people are wanting to limit the power of validators in, remember that the delegators are actually the ones with the power to vote (validators are a proxy vote if their delegators do not vote, in order to keep important proposals, particularly for network security and/or the protocol, from stalling due to lack of delegate voting participation - the validator vote only counts if the delegator does not vote [even if the validator votes before the delegator - the system adjusts the vote to follow a delegator’s vote(s)]). The issue is not with validators having too much authority - those validators have been given that voting power and responsibility to vote on behalf of delegators when they do not vote (based upon the validators distinctives, actions to protect the network, and voting patters as a validator - ie. they align in partnership with their delegators). For a review of how governance was designed to work, see here, here, and here - for more info on the underlying cosmos-sdk gov module:
- And if you want a more stream of conscience outline of why each area of governance is designed to work the way it is, as a simplified version of parliamentary procedure:
Conclusion:
If people really want to flatten consensus voting power to evenly distribute voting power to prevent network halting, and make it more difficult (in some ways) to create short and long range attacks, or censorship (halting) attacks on consensus voting for blocks, then their is a simple solution. Adjust the custom tendermint/ignite layer to split all consensus voting power for consensus voting (as in this process) to be exactly equal among the whole active set (each validator maintains the same percentage of voting power for consensus). However, have the custom tendermint/ignite layer still keeps track of what the consensus voting power would have been based upon stake in the system for all other aspects such as rewards, governance, etc.
- https://tendermint.com/static/docs/tendermint.pdf
- https://v1.cosmos.network/resources/whitepaper#tendermint-consensus
- There are also mitigations currently to each type of attack either built into the system (in the evidence module), or that are suggestive (which it appears the Terra v1 documents also tend to outline as well).
The caution with this is that it can also open the door to subtle new attack vectors as well. But, it may well be worth having some independent sessions with some in the Cosmos ecosystem for technical discussion (to see if they can see any further subtleties), if not then prototyping this type of idea, and testing it out in a testnet situation, and open testing to the broader cosmos community (since they may be interested to at least test and contribute) rather than what is being proposed (in my humble opinion).