semux-core
semux-core copied to clipboard
semuxproject
On-chain Governance
There was a debate on the tokenconomics of Semux and people haven't seem to reach a consensus on the future block reward as only 55% of validators upgraded their nodes to v1.4.0. Voting based on-chain governance that enables validators to dynamically change consensus rules like block reward can be a solution to this situation.
TODOs
- [ ] Figure out which parameters shoud/can be changed dynamically
- [ ] Implement new transaction types for on-chain governance
- [ ] Initiate a fork that enables on-chain governance
Hmm, is it 55% right now because some validators are not aware of v1.4.0? Or has everyone made a decision already. How do we know if validators did not upgrade to v1.4 because they are slow to change VS they do not want to support future block reward update?
@victorx716 I have no idea. This proposal is meant to reduce the risk that Semux consensus might be suspended if validators can't reach a consensus on rule change like #39 regardless it's because validators are not aware of the upgrade or they just don't like it.
@cryptokat Ah okay I understand what you mean now. I think it is a great proposal, and will be good for Semux in the future.
This is a great proposal and we were discussing this many times in Discord.
@victorx716 I think there is no drama about 1.4.0 release, validators have been warned that the deadline for this update is Dec 2019 (block 2,000,000). And the thing is that very likely we will have other mandatory upgrades before that date, ie the bloody VM activation and others, so there is no rush for validators with the 1.4.0
Pretty sure the validators not upgrading not as defiance to decision, but because we made a point to not mark it as a release with any need to spend time to upgrade as there's no real reason to anytime between now and November...
For instance, I personally am waiting for 1.5 to update mine since this release contains no real reason to hurry and update... Let's not confuse motives
From an implementation perspective, we need to think about how balance can be turned into voting power.
I don't believe this would work out to 'fair' voting power, given that more than half of the validators are pool operators with very little stake in the game. Adding voting power to how network runs without adding native delegated votes for votes seems a bit awkward. It would allow someone with 34k sem to be able to (via introducing 0% pools) veto power against any change.