Open jaekwon opened 7 months ago
jaekwon
commented
7 months ago All comments and suggestions welcome.
Who's interested in thumbs up: helping with this process smiley face: helping with code and familiar with the sdk/gaia rocket: want to run a validator heart: want to participate in voting
prudent-gas
commented
7 months ago Time to try some new ideas for cosmos
vixcontango
commented
7 months ago If you have run a business or a political organization in any capacity, you would know that there is a tremendous turnover in the clientele. Over a period of 5 years, 90% of your clients turn over - they leave because they are not interested anymore, maybe it is too expensive and they need to spend their money elsewhere, maybe a life event happened and they don't have the time or money to continue to pay attention. There is a lot of reasons that force people to stop being interested in something. If the GOVNO token is not transferable by 2028 only 10% of them will be used during voting. You won't reach quorums on anything. It might be even less than that because the people that voted NO on 848 were primarily economically motivated people - they wanted higher percentage rewards since they assumed that the ATOM price and its inflation have no relation (clearly economically illiterate). If they can't make money out of Atom One, they will have no incentive to vote. If a business or a political group doesn't keep its membership the same through recruiting, it dies out slowly over time. Not being able to transfer these voting rights to someone in the future who might be interested in taking over the voting practically guarantees this is a dead project after a certain amount of time (if not already).
jaekwon
commented
7 months ago Hi @vixcontango, well, those are all good points. I think over time we will discover nuance in some of those points, but overall i agree with you. It is so bad, the name GOVNO is apt for it.
SIDE NOTE DIGRESSION: maybe there is a way to make GOVNO evolve over time and become better without succumbing to liquidity, in the context of GOVNO is like "selling out". I'd say GOV*** tokens should not be transferable in that way, but I can imagine growing GOVNO through peer connections somehow for example, or other meritocratic means like through standardized testing events, or some gauge over applications. Assuming we can prove "proof of human. /DIGRESSION
And yet I believe it is critical at this stage for us to gauge sentiment. That is undeniable, regardless of its long term fate.
dongwon8247
commented
7 months ago It's great to see the plan. Thank you for sharing.
The Onbloc team wants to contribute to the AtomOne Governance-Only “GovNo” Chain with:
One question,
This chain software is proposed to be a fork of cosmoshub4 with minimal modifications.
Besides the shift to a ⅔ supermajority for any governance proposals, what other modifications do you anticipate occurring? This information will help us, as well as others, understand the scope of the proposed changes.
Thank you.
jaekwon
commented
7 months ago what other modifications do you anticipate occurring? This information will help us, as well as others, understand the scope of the proposed changes.
UPDATE: SEE THREAD FOR UPDATES TO THIS LIST
dongwon8247
commented
7 months ago
- [ ] I think the voting period should be longer too.
- [ ] validators should not inherit voting power from delegators in a new type of governance proposal "sentiment".
- [ ] for the above, it would be nice to look back at past proposals and see what quorum threshold is reasonable.
I will work on researching this with @adr-sk and come back with a suggestion.
jaekwon
commented
7 months ago Interesting theoretical (possibly of no immediate consequence) question is, should GovNo proposals themselves be used to air-drop to voters depending on the vote of GovNo proposals? The pro is, more liberty, the con is, this could be used to create unnecessary splits and divide focus; too much of anything can be bad. The latter effect is mitigated by social intelligence of what is reasonable to expect, but it is now post-singularity and we cannot trust our traditional web2.0 social senses. Also, it would seem hypocritical to ban something while we are benefiting from it (though there is also the matter of what, exactly, is publicly announced).
So for example, after proposal GovNoChain#123, some people might want to create the GovNo123 chain and token. Should that be allowed? I think sometimes this might be necessary, but at other times this can become an unwanted distraction.
I propose this compromise as a kind of social contract; Anyone is free to suggest new air-drops based on the voting results of GovNo governance proposals that make additional modifications (slashings and or rewards), but should it be discovered that there is an air-drop proposed that is conditional on an ongoing proposal, then the air-drop supporter should offer to pay the deposit for a second proposal where the voting there may NOT be used for any air-drop purposes. This way the original proposal has a better chance at a fair governance trial without anyone changing their votes merely to chase the air-drop. This expectation of no-airdrop-usage for the second proposal vote may be voided if there are ethical or legal grounds, e.g. if the second proposal vote was used to commit a theft, for example. If nobody takes up the offer for a timely second proposal, then the offer had no impact anyways.
Also, that all offers such as airdrop offers be made equally to everyone (pro-rata stake, unless it has a different constitutional mandate), and ideally its principle announced before the proposal is even made, such as in the claim, "we would slash anyone who votes to do XYZ for security reasons". If such statements were already publicly made, then it makes sense to remind everyone of the prior commitment, but without alluding to any specific airdrop, so as to limit discussions to the matter at hand. If such a principle is discovered only after the proposal had already become active, then it may be better to stay silent, so as to not unfairly benefit those who discover the principle in such a way that can be gamed by insiders. But if this were to happen anyways, first the offer should be made for a second proposal as mentioned above, without air-drop potential according to this social contract, and then a third proposal can be considered where air-drops are considered again.
Also that we prefer to frame things as a reward rather than as slashing, whereever reasonable.
In all cases, offers should be made to everyone equally, weighted by stake; and all offers should be made public. On the latter point, there should be a place to disclose all such offers and discussions. If you want to "arguably bribe" someone to vote a certain way, then at least make it transparent and open, such that it is an offer to the entire distribution set, and the GOVNO voters (and the universe at large) will determine whether it is undesirable bribing, or a reasonable offer.
All that said, these are just some of my thoughts written down, learnings from 69 and 82 and 848, and my intent here isn't to imply that GovNo will have any value, or have any potential for use for bribes. Most likely what will happen is, if you are discovered to have bribed someone in secret, you will get slashed; if you are discovered to have offered an air-drop, then it better have merit and you better follow guidelines or people will get upset and there will be unintended consequences; and if you offer something to somebody but not others, then you will make enemies. These are theoretical points that apply to all governance voting tokens (including ATOM); but ultimately we REALLY REALLY don't expect GovNo to have any value whatsoever, not even the potential to profit from bribes.
jaekwon
commented
7 months ago [ ] validators should not inherit voting power from delegators in a new type of governance proposal "sentiment".
On further thought, I think what we want is for proposals to pass both measures... with delegation, and without. That way the validator set is in support as well as the stake base. Less than 1/3 of the validators must veto. How much of the non-delegated stake must be in support, whether a simple majority, supermajority, or "constitutional majority" isn't always clear, but requiring a supermajority for all decisions as a baseline can help minimize conflicts and keep chains conservative. - https://github.com/atomone-hub/genesis/issues/72#issuecomment-1848329504
I'm not suggesting that we make the above change to governance. Maybe as an alternative we can just have a second method of calculating the acceptance %, without delegation, for all proposals. For the purpose of GovNo chain's governance tallying, not counting validator delegations also makes sense, so implementing a "sentiment" proposal type that is only used for govno-type voting makes sense too. Either way.
adr-sk
commented
7 months ago Dongwon @dongwon8247 and I drafted two improvement suggestions after reflecting on the past behaviors and statistics of the Cosmos Hub Governance.
TL;DR:
The Cosmos Hub Forum is where the preliminary discussions for proposals are held. While the number of accounts that participate in voting for each proposal mostly ranges between 10~50k (might need a further investigation to filter out dust/sybil wallets for more accurate numbers), the median of views per governance-related post in the Forum is ~1k. This indicates that a significant portion of voters encounter proposals after their submission.
When it comes to controversial proposals, casting a rational vote involves a lot of time and effort on research. Especially considering that we're designing a system that fosters active participation from individual voters, more time should be given compared to a validator-centric voting system.
The simplest solution to achieve this would be to extend the current voting period of 2 weeks by a fixed amount of time, but there are 2 challenges to this approach.
Therefore, we propose a system where the duration of voting periods is optionally extendable when needed. There are two ways this could be implemented.
Option 1. Dynamically Extendable Voting Periods
The first option is to implement a voting period system that is dynamically extendable, inspired by a concept conceived by Sunny in the past (Source).
The idea is to maintain the current voting period of 14 days, while allowing validators to request an extension. The duration of the extension scales with their voting power, with a 1-day extension granted for every 2% of voting power (these values should be made adjustable via governance proposals). This would result in the maximum possible voting period of 64 days (~ 2 months).
We suggest only allowing validators have access to this feature as a layer of spam protection. If given to all stakers, a group could spam this feature for every single proposal, unnecessarily extending them by a few minutes/hours just to waste everyone's time. On the other hand, it is safe to assume that a validator would be unlikely to abuse this feature, as validators would already be aligned to our vision if they were to participate in this non-economically rewarding initiative.
Some open considerations: Should there be a way to identify/penalize those who abuse this mechanism? Should stakers be allowed to override their validator's extension request?
Option 2. Statically Extendable Voting Periods
An alternative system could have a pre-defined value of extendable duration (e.g. 14 extra days) that is automatically triggered if more than 33% (the veto threshold) of total voting power vote agree to extend the duration. This system is more intuitive as it only results in 2 different voting periods: 14 or 28 days. The downside is that it offers less flexibility compared to Option 1.
Either way, both implementations should involve:
ExtendVotingPeriodGovNo is designed to be a governance-only chain with a mutual purpose of building and maintaining a minimal IBC & ICS Hub. This requires a system governed by active participants to foster tighter coordination and alignment.
Therefore, we propose increasing both the Passing Threshold and the Quorum Threshold to 67% (supermajority). Our quick research (link to sheets) indicates that these thresholds are reasonable and effective requirements.
For ~25 proposals submitted after Q1 this year, if we were to adjust the results to where the non-voting exchange validators are cancelled out and the proposed thresholds are applied, only the following proposals would be either rejected or failed to reach the quorum: Prop #793 (Drop the Lawsuit), #817 (Stride Delegation Process Advisory Council), #848 (ATOM Halving), and #853 (ATOM Allocation for pSTAKE).
As it's reasonable to anticipate higher governance participation for the GovNo chain, these requirement will likely not restrain beneficial proposals from passing, while preserving the conservative stance towards controversial proposals that could not only split the community in half, but could also undermine the core philosophy of Hub Minimalism.
Looking forward to everyone's feedback.
jaekwon
commented
6 months ago On the other hand, it is safe to assume that a validator would be unlikely to abuse this feature, as validators would already be aligned to our vision if they were to participate in this non-economically rewarding initiative.
I don't agree with this, because this would certainly be abused by validators against the stakers at some point. A purely stake based system sounds reasonable.
For the purpose of GovNo I think it is simple and sufficient to remove the voting limit, and to just make the voting period longer, even indefinite. We already have spam prevention (written in the post above), and this way we can get it started sooner, and also we don't really know how long it will take to decide on major factors; probably people will frequently change their minds.
I think the key thing right now is to get started sooner, and then to iterate. Starting off with less changes; We should not even use new UX for voting... all potential for security vulnerabilities. But we can make small changes and audit those changes.
zdeadex
commented
6 months ago Hi there, will support it on Wallet side within XDEFI Wallet (a multichain wallet that added a week full support of Cosmos ecosystem with custom network integration - thus would allow supporting Gno if information registered on the chain-registry repository).
On the validator side with Stakelab, we will be able to add ATONE on our staking platform (with all the features that goes with Cosmos chain). Technical side, we will be able to build an helm chart and support one click node setup using Kubernetes and also maintain omnibus repository for launching decentralized node on Akash.
We will be keen to add more infrastructure and business support depending on the needs (can scope it fast on our side and priorize).
MasterFrenchie
commented
6 months ago Anybody that knows how gov works in cosmos. It’s very controversial.. it has a lot of implications but also a lot of potential.
I think GOV NO is a perfect vision for atom ONE..
Let’s keep it going kings and queens. 🤴
We have a purpose and vision. This extends cosmos and the purpose of blockchain.
AIB is a core contributor to cosmos, let alone crypto..
your good friend- Welding.BTC
devmev10
commented
6 months ago The idea is interesting but I disagree with non transferrable part. What if some of the OG voters leave the chain permanently? Those would be wasted accounts without transferability
tbruyelle
commented
6 months ago For the purpose of GovNo chain, not counting validator delegations also makes sense
This is why I'm in favor of excluding lazy voters from the GovNo distribution. If we remove vote inheritance in GovNo, it will be harder to reach quorum at 40%, and even harder if we decide to increase it as has been mentioned in some other discussions. There's a chance that lazy voters will stay lazy for GovNo proposals, so removing them may help reach quorum.
3eph1r0th
commented
6 months ago I expected to see April 1st date in my calendar, but no - it is still December 15.
jaekwon
commented
6 months ago XDEFI Wallet
No new wallets or tooling should be required, and any modifications should be minimal. The primary tool will be gaiacli or a fork of it.
Those would be wasted accounts without transferability
For the purpose of genesis this isn't true, because they would get genesis ATONEs; they don't need ATOMs for this.
For the purpose of GovNo chain, not counting validator delegations (for tallying) also makes sense
This is why I'm in favor of excluding lazy voters from the GovNo distribution. There's a chance that lazy voters will stay lazy for GovNo proposals, so removing them may help reach quorum.
I cannot support removing non-voters from the GovNo distribution though, even as I support tallying on GovNo without delegations. There was no prior agreement that non-voters (who otherwise inherit their validator's votes) would ever be punished. So why should we exclude them? For all intents and purposes on the CosmosHub the social contract was that they completely inherit their vote. We don't plan on changing this either for AtomOne governance.
This GovNo and even AtomOne split only makes sense because of the large % of NO+NWV voters including delegations at 47%. We would be significantly diluting this authority by excluding the stakers who inherited their validators' votes. What % of stake would that be, and, how many voters would there be?
With the new no-delegation tallying method the previous quorum isn't sensible (it is probably too high). We don't know what is sensible, do we? Maybe we can estimate it by calculating NO+NWV_WITHOUT_DELEGATIONS / NO+NWV_WITH_DELEGATIONS, but I don't know what that % is, and I don't think it's quite enough information to make a conclusion.
My latest thinking is that the governance votes on GovNo should pass both modes of tallying (with and without delegations), so that validators can also agree to the changes proposed as well as the stakers. We could start off by just keeping the governance delegation as is, and just adding a secondary tallying mechanism for all proposals to see the tally without validator delegations. And the quorum then can be left otherwise unchanged (tallied with delegations), and for the purpose of the secondary tallying mechanism we can say that the quorum is yet undetermined.
Therefore, we propose increasing both the Passing Threshold and the Quorum Threshold to 67% (supermajority). Our quick research ([link to sheets](https://docs.google.com/spreadsheet /d/1r1FB8R1i_UGe7E3MtyRqL6GgOhalFpZnfSDqoy6oopg/edit?usp=sharing)) indicates that these thresholds are reasonable and effective requirements.
For ~25 proposals submitted after Q1 this year, if we were to adjust the results to where the non-voting exchange validators are cancelled out and the proposed thresholds are applied, only the following proposals would be either rejected or failed to reach the quorum: Prop #793 (Drop the Lawsuit), #817 (Stride Delegation Process Advisory Council), #848 (ATOM Halving), and #853 (ATOM Allocation for pSTAKE).
I don't think the calculation for thresholds is done right. For example look at #854 on the spreadsheet. The actual quorum is 58.70%, but why is this being multiplied by 1.25? No validator voted abstain, and almost all voters that voted voted yes. The actual and adjusted turnout is still only 58.x%, not 73.38%. Multiplying any probability by 1.25 also doesn't make sense, as it would allow probabilities greater than 100%.
We don't really know what the right quorum threshold should be, so I suggest we keep it the same for now (which is low at 40%) and not put too much weight on it for the purpose of GovNo.
Here is the new suggested TODOs:
ccomben
commented
6 months ago Can we think about renaming the Govno chain? We are receiving more and more feedback about the offensive nature of the name. I know it is meant to reflect its lack of monetary value, but I also don't like how it could reflect upon the project itself. It would be a shame if people didn't take this seriously because of its name.
amritkumarj
commented
6 months ago Built a service in pure golang that creates the prop 848 snapshot
Really love to get some feedback from you guys! - https://github.com/blockdudes/atomone-vote-snapshots
tbruyelle
commented
6 months ago Hey @amritkumarj thanks for that, it's an interesting approach. I worked also on the snapshot data extraction here, using jq : https://github.com/atomone-hub/genesis/pull/96
About data consolidation, I also have a pending work here https://github.com/tbruyelle/govgenesis. I need to work on it a little bit then I'll submit a PR.
amritkumarj
commented
6 months ago Thanks for checking my code and your data consolidation code looks great @tbruyelle!
More production ready than mine 😅
I want to contribute in atomone, so if possible can you point me to the best place where I can use myself more productively!?
Thanks!
tbruyelle
commented
6 months ago Well, your approach of working directly with the snapshot file is nice, because it eliminates the extraction step that I need, but since it's a 3,5Gb file, I prefer to have that extra step first, and then deal with smaller files. It's faster to test the program.
About contributions, sorry I have nothing to point, try to read everything and find where you can help!
amritkumarj
commented
6 months ago Yes, dividing the large file into smaller files is a great approach as it is more efficient and faster to test and write code.
However, it took multiple extra steps that I was trying to avoid so that anyone can just start it with one command but now I understand that my way is not the most efficient one
Maybe we can also write Go code that divides the large snapshot file into smaller pieces if they are not available?
Anyway, I am currently discontinuing my snapshot work and will find something else I can contribute to.
Thanks!
Proposed GOVNO.md file with following contents:
AtomOne Governance-Only “GovNo” Chain
The governance-only chain AtomOne GovNo chain is hereby proposed to be an independent component of genesis. The proposed token GOVNO is only for governance (and staking for governance). This chain software is proposed to be a fork of cosmoshub4 with minimal modifications.
SendTx will be disabled for GOVNO. GOVNO cannot be transferred, sold, or given to another individual or entity, have no cash value and cannot be redeemed for cash, credit, or any other item of value. GOVNO are intended solely for use within the governance-only chain. (Govno is also slang for “shit” or "turd". This helps communicate that the token is not expected to have any value. 💩)
The AtomOne GovNo chain is not the main chain, and it is intended only for the purposes of assessing the sentiments of the No and NoWithVeto voters for proposition #848* and for discussion of next steps such as the AtomOne proposal. NoWithVeto voters will not be given a bonus for their veto for the purpose of the AtomOne GovNo chain.
This governance-only chain is inclusive of alternative proposals which can or should have their own distinct name. Nothing shall prevent this governance-only chain from discussing alternative forks of the AtomOne draft proposal in github.com/atomone-hub/genesis unless the chain DECIDES to limit itself. In this way, the github.com/atomone-hub/genesis repository is not exclusive, and this process can be inclusive of alternative ideas.
The criteria for inclusion in this governance set is simply the No and NoWithVeto voters of proposition 848. The dissenters were a sizable minority at 48.2% (nearly half) where the voting turnout was 73%, and these dissenters have uniquely demonstrated alignment (since prop 82) for a proposal that cut to the heart of identity. Therefore it is naturally up to this group to decide the genesis distribution, constitution, and other founding documents of the AtomOne split. In this way, proposal 848 was fortuitous. (We may not be so lucky in the future, and we should invest in tools to better help split a community in the face of distributed adversity.)
No decision from the chain will be used to force a change of this or any genesis repository if there is disagreement from the owners and maintainers of such repository. In this way, every subgroup working on their own genesis recommendations (especially forks of github.com/atomone-hub/genesis) can have their own opinion about genesis, and they can update it and accept merge-requests voluntarily, and work over time to convince GOVNO to accept its version again later. Anyone can resubmit the (substantially same) proposal after the community has had a chance to rethink it (but your deposit is at risk; see below).
We propose that in our public communications we emphasize that it requires a ⅔ supermajority for anything to be “decided” by governance of this chain (partially because that will be the acceptance threshold for all proposals on AtomOne, but primarily to avoid accidentally inducing another split). We propose that all proposals on the AtomOne GovNo chain only be used to determine the sentiment of the Proposition #848 No and NoWithVeto voters; and that all proposals first be discussed on GitHub (namely github.com/atomone-hub/genesis/issues).
We propose that in order to reduce spam, the governance chain set a very high deposit limit for the proposals to prevent spamming. Furthermore, if a proposal is rejected with more than ½ voting NoWithVeto, we suggest as the initial assumption that the deposit be considered for slashing for any relevant future genesis distribution, and how much. Furthermore, if the No and NoWithVeto voters judge an account to be spamming, that the spammer’s tokens in any relevant future genesis distribution may be considered for slashing, and how much.
This document does not specify any further the potential role of the AtomOne GovNo chain with regards to genesis and what it can decide on. When and how genesis happens should be guided by reason in the discussions on chain and in the various repo issues (such as those on GitHub).
Here are some suggestions and ideas about what may happen after launching the governance-only AtomOne GovNo chain:
Security Specifications
Nothing that hasn’t already been in use and audited (except a custom cli if required, any such cli will need to be audited first by the chain and at least one independent security firm).
AIB has volunteered to publish recommendations about genesis software readiness and the release and audit of procedures, but should not be the only source of information especially as this is a decentralized process.
Wallet Integrations
We can use permissionless APIs like the one that Kelpr offers for hardware wallet signing, but we should use the same Cosmos signing app, not create a new one. We can also recruit validators and blockchain explorers to support the AtomOne GovNo chain (and similar GovNo chains for other projects) Anything else?
Disclaimer: Nothing in this document shall be construed as a token offering. Nothing is guaranteed, such as participation for those addresses that are on the OFAC sanctions list.