Hello!
I’m proposing a flexible governance embedded that will fulfill all of our current necessities and even beyond.
The governance embedded contract will be able to:
- Create sporks to upgrade the network codebase
- Change network parameters that were previously only accessible to admins
We are basically solving 2 problems at once with my proposed architecture for the embedded contract.
The process goes as follows:
One must spend 1 ZNN in order to make a governance proposal. This anti-spam mechanism is also implemented for ZTS creation or AZ proposals.
Once the account-block is sent to the governance embeded, the Pillars can start voting on the proposal.
The threshold to pass this proposal is 51% of registered Pillars. I’ve chosen a bigger threshold because network governance needs wider Pillar participation and support to implement changes that will impact everyone.
Point 1 is pretty self-explainatory: instead of the current hardcoded spork address to create a spork block and active the spork, we’ll be able to activate network upgrades if the proposal has enough votes and passes.
Point 2 is more interesting: we will be able to change network parameters that were reserved only for centralized admins like adding new networks in the bridge or modifying params in the liquidity contract.
I’ve managed to make a working implementation and I’ll release the source-code zoon.
In technical terms, a proposal is a custom account block that will be sent from the governance embedded to the other embedded contracts. We will add permission for the governance to all embedded contracts so for example, not only the bridge administrator could call “SetNetwork” but also the governance.
4 Likes
Thank you for initiating this initiative zir. A governance module is much needed in order to move NoM forward. That said, I’m a bit concerned that we may struggle to reach the 51% pass rate in most cases, especially since some Pillars either don’t vote at all (with less than a 10% voting rate) or have been offline for a long time (not producing momentums). Could we consider adding additional rules for the pass rate? With a 51% threshold, achieving quorum could be challenging.
Also as @georgezgeorgez mentioned, for HyperQube_z’s (hq_z) first Work Package (WP), we’re aiming to stimulate as much open collaboration as possible and involve the community. I’d like to invite you to join us in developing the specs for hq_z before implementing it on mainnet. This work will of course, be incentivized.
Great work @sumoshi21! A much needed upgrade to NoM.
I think the threshold is simple and fair. 51% consensus is really important for network wide upgrades. AZ quorum has a lower threshold because it doesn’t impact the network as a whole, just the AZ treasury. Plus it’s only limited to 5k ZNN 50K QSR so little “damage” can be caused.
We can’t go with lower values for this threshold and also we can’t get higher either. 51% is the sweet spot for security and participation.
51% of pillars, it will be stuck for waiting pillar to reach quorum vote.
51% of active (creating momentum) pillars or
even 51% of active pillar that more than 33% vote rate is good imo
Hmm… I just checked the numbers and 31/95 pillars have <10% voting rate. 7 of these pillars are offline, 51% quorum could work. Especially if the goal is upgrading the network.
For the issue of 50% + 1: If you can’t count on them to vote, then you can’t count on them to upgrade the node, and then we’ve got bigger problems.
There’s no need to overthink it. The embedded contracts that will be governable need to define dedicated functions accessible only to the governance module. It’s not mean to govern the ungovernable and over complicate it. If we’ll want to govern certain aspects of the network, new embeddeds will need to be deployed for those specific needs and we can now achieve it by vote.
I like the idea of type 1 and type 2. For now, type 1 is just creating and activating a spork. Others would be type2. Type1 should be at least the majority required for consensus which 66% + 1 for NoM. Type2 like adding networks to the bridge could remain 50% + 1.
I don’t think we need to implement the logic in order to send ZNN or QSR, we just don’t need it now, there is no functionality for it, just create an accelerator proposal insead of a type1/2 that would transfer. Handling ZTS transfers is purely beyond the scope of a governance embedded contract.
I also don’t think we need a dynamic quorum for now. One pillar, one vote for all the remaining time. If pillars don’t vote, there is no interest in the proposed change. Why should the quorum lower?
We might need to increase the period from one month for type1.
1 Like