Remove the proposer bonus lottery

Parameter change proposal to set baseproposerreward & bonusproposerreward params to ZERO to remove the undesireable centralization incentive it creates.\n\nThere is a detailed writeup on the Osmosis Commonwealth why we should pass this proposal : https://commonwealth.im/osmosis/proposal/discussion/1688-remove-the-proposer-bonus-lottery\n\n****REPRINTED BELOW****\nCurrently 1-5% of epoch rewards go to the validator (and their delegators) who proposed the epoch block. The exact percentage depends on details of how many validators were counted as online at the epoch block. This is an unfair system for a number of reasons, and introduces a force to centralize stake amongst the validators who already have the most stake. This is because:\n\n1. (In theory) The chance of a validator being the proposer is proportional to their stake, which means you have the same expected return, but lower variance with larger validators. This gives an incentive to delegate to the largest validators. (There is a similar effect in POW mining systems like Bitcoin, which leads to pools)\n2. In practice, the chance of a validator being the epoch proposer is 0 if they are not in the top 66% (by stake) of fastest validators. Only the validators who finish computing the block first will be potential proposers for it. This also contributes to centralization, as the largest validators can most afford to maximize their speed.\n3. The proposer selection algorithm is not based on secure randomness, it isn’t even random at all. It is in fact highly manipulable. There are known strategies validator operators could use to attempt to propose a specific block. Actual usage of these strategies could be considered byzantine behavior, and could lead to further network instability around the epoch time.\n\nThis centralization effect is harmful to the long term success of the network – we want the stake distribution to become much less top heavy. Stake distribution has been decentralizing nicely as time has gone in the network, but it would be ideal to further accelerate this decentralization. And whats critical to that, is at minimum, lowering the incentive for the stake to centralize at the top. We are nowhere near the end state yet for stake distribution!\n\n--Short Term Suggestion--\n\nCreate a parameter change proposal to set the proposer bonus to 0%. This would then go into affect immediately after the proposal passes.\n\n--Long Term Suggestion--\n\nThis is definitely a conversation that needs to be designed together over time!\nTalking with @UnityChaos & @dogemos, we thought it’d be cool to re-introduce this proposer bonus lottery, but have it only be applicable to the bottom {say} 50 validators. Also have the total pot of the reward not be 5%, but instead be around {say} 1% of the reward. This would help incentivize decentralization of the network, and also retain the (accidentally introduced) lottery effect that so many folks like! (Since delegating to smaller validators would be higher EV!)\n\nIt is possible that higher stake validators sybil themselves into multiple lower stake validators. The hope is that the pot here is sufficiently low, that this won’t be worth the reputational hit that the sybilling validator would take. (And would also cause community uproar, justifying a governance proposal to slash them) There is still a fear that the big validator makes multiple sybils anonymously, this is quite plausible if its all their own funds. Noticeability only really comes in when its from validators gathering delegations from users, or are trying to build a common brand.\n\nThe blocker for re-introducing this epoch reward lottery this is we need a secure on-chain randomness source. (In addition to design work to ensure sybilling incentivizes are sufficiently low) This can be added as a follow-on to the threshold decryption work that is being worked on. The threshold decryption work eliminates most of the known forms of MEV learned about from Ethereum, such as front-running, sandwitching, stealing arbs, etc. – making them unable to applied on Osmosis once its done. It turns out that the technical primitive underlying this is very well suited for making a secure on-chain randomness source.