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.
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.
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.
First, I want to thank @sumoshi21 for taking the initiative to draft an implementation for the governance module. This has been long overdue and is a crucial step for the future of our network.
I appreciate how quickly Sumoshi integrated feedback and made changes. However, George’s insights present a compelling argument against the current approach, which we should carefully consider.
It’s encouraging to see @aliencoder and @georgezgeorgez, along with other network developers, joining the discussion. I’d love to hear from even more voices, as this change deserves thorough review and due process.
While I recognize different preferences for pace, I tend to favor caution with significant changes like this. If speed had been a priority, I would have recommended drafting the implementation a year ago, during the initial discussions. We had the time, so there’s no need to rush now.
At this point, I support testing the governance module in a live production environment, such as hyperqube_z. It seems it will be live soon, and I can’t think of a better way to stress-test it.
On this note, I’d also like to see other developers receive compensation for their work on the Governance Module AZ—especially contributors like George, who have invested substantial time and thought and will be involved in testing the module. It would reflect well on our network if this effort is a collective achievement by a majority of our developers.
I read coins post and wasnt sure what to make of it but after letting it sit for a minute I am aligned. Maybe this is our chance to turn AZ from a spray and pray (not saying this is… but many are) to a process that gets the attention it deserves. Not saying anything everyone here doesnt know but governance is a unique animal and can have disproportionate impact compared to most of what goes through here.
I would be in favor of having a twitter spaces discussion (or similar) with sumoshi, alien, and george (since they are all actively working on this topic) plus other devs / pillars / community members.
I dont want us to slow down or get to a point where there are so many stage gates to funding that people are not motivated to build, but I think some of the things we are discussing deserve more than a few responses in a forum every day or two.
I can make time Friday / this weekend if we were to actually do this - not that I am key to this discussion, but I would like to practice what I preach
As I said, even if China cuts the connection to the Internet and 50% e.g. of pillars can’t connect, having a quorum that decreases over time means that all proposals will be accepted, even proposals that are a joke, or the community and pillars disagree with, in case of pillar inactivity. An analogy for the accelerator contract means that all proposals will be accepted (and funds released) with a few yes votes on the long term if other pillars don’t vote. And we have a solution for that edge case of blackout, as george said, hard fork or the spork address.
On the implementation side, these are the methods that the governance contract will be able to call: Spork:
CreateSporkMethod
ActivateSporkMethod
Bridge:
* SetNetworkMethod
RemoveNetworkMethod
SetNetworkMetadataMethod
SetTokenPairMethod
RemoveTokenPairMethod
HaltMethod
UnhaltMethod
EmergencyMethod
ChangeTssEcdsaPubKeyMethod
ChangeAdministratorMethod
SetAllowKeyGenMethod
SetOrchestratorInfoMethod
SetBridgeMetadataMethod
RevokeUnwrapRequestMethod
NominateGuardiansMethod
Liquidity:
* FundMethod
BurnZnnMethod
SetTokenTupleMethod
SetIsHalted
UnlockLiquidityStakeEntries
SetAdditionalReward
ChangeAdministratorLiquidity
NominateGuardiansLiquidity
EmergencyLiquidity
Type1 proposals are the ones that have the destination the spork contract, the voting period is 45 days and the threshold is 66%.
Type2 proposals are all other one, the voting period is 30 days and the threshold is 50%.
We could discuss these variables.
The cost of creating a proposal is 1 ZNN. Personally I would increase it to 5 ZNN, even if the price goes up and the proposal is accepted, one could get them back from the accelerator if he really needs them. I saw there is also some spam with 1 ZNN for accelerator projects and we need to make it as easy as possible for pillars to vote only on serious proposals, not scroll on all.
I believe this is a good version for V1, if we decide in the future that we should add dynamic quorum or any other functionality, one should implement it, test it, audit it and could propose it and see if pillars agree and vote. Otherwise, we will just spend another year discussing once in a while on the forum about impact, possibilities and nothing will be practically achieved.
I totally agree that testing and auditing each other’s code should not be done for free. We should encourage that and speed up the acceptance or denial of PR.
Dynamic quorum is a trojan horse for the Gov module. It introduces potential weaknesses and vulnerabilities that can be exploited by malicious actors. I’m agaist it because in the case of a network partition the CAP theorem states that the consensus will always favor consistency. It’s the same trade-off between safety and liveness. The consensus must always favor safety over liveness (better stop the chain than making progress with incorrect state transitions).
As part of this AZ would you be willing to prepare a ZIP - Zenon Improvement Proposal and test the deployment on Hyperqube before pushing to mainnet?
The governance module is core to the inner workings of NoM. I look at all the testing that @vilkris@georgezgeorgez and @CryptoFish do for protocol level work and it’s extensive: months of testing. DP has been in design and testing for what seems like a year.
I think it’s really important that we test this work extensively before bringing it to mainnet. Hyperqube seems like a good place to test it. Also, we can iterate quickly on hyperqube if we find an issue. Pillars will be active and many devs are looking at this work.
Also if we test on Hyperqube I think we will engage with more devs, more will look at the code, and we will have a public testing process that pillars can see and monitor.
