Hi @vixasi7192 ,
While I agree with you to the fullest extent possible, and have been working with some others including @raider7019 (the author of pull request 776), who himself is a blockchain developer and has undergone a review of the code regarding the protocol change, I feel compelled to respond to your governance discussion toward a proposal and ask that you realize a few things up front (to be successful):
- You do not need a proposal to re-enable staking. Documentation specifically states that legitimate protocol changes are made only by governance proposals that have passed, and that governance is decentralized. The protocol code changes that stopped staking, and thereby prevented and excluded all pre and post crash LUNA owners who were not already staked from staking for voting purposes, were not made in accordance with, and actually violated, the documented governance rules. As the github pull request 63 that you pointed to for the cosmos-sdk changes also resulted in companion pull requests to the classic-core to change to the protocol for classic-core from 0.5.18 to 0.5.19 without a governance proposal vote (which is contrary to the very governance documents and was a violation of the protocol).
- The correct protocol, according to governance passed proposals, would be classic-core 0.5.18 (and every validator should either roll back to it, or upgrade to a path that disables 0.5.19 - which disabled MsgCreateValidator and MsgDelegate).
- However, you need 2/3 of the validators by voting power to halt at the same time [and preferably 2/3 of physical validators], upgrade, and then un-halt (and preferably it would be all v1 validators at the same moment). Please correct any mis-statement @raider7019 .
- Let’s just say there are some legitimate and appropriate back channel efforts that are ongoing that get at the end result of your discussion without a proposal, but on the basis of returning to the appropriate protocol code (however, if there should be a proposal, see my notes below for humble suggestions that I would ask that you consider).
- Up until proposal 3568 no proposal has passed without, in my estimation, TFL / LFG’s support (I could be wrong, but if so, then some one sympathetic to what would be in their best interests as I think through those interests from a business perspective). Terra “Classic” Proposal 3568 either also passed with support from TFL / LFG, or from heightened validator support (which it certainly had validator support that previous proposals have not).
- If this proposal goes into the system, then there is no sitting back by any of us, we must all coordinately communicate with validators. I would suggest that @Paul_Leprecheur and @raider7019 be tapped for that coordination effort and help the rest of us know which things should be done that does not shut off legitimate communication channels with validators, but also enables validators to understand in no uncertain terms, that as far as we are concerned, that this is a must pass proposal with great amount of support (and we would need to identify that support). They know the actors that are currently working on legitimate validator communication, and probably have the best ability to coordinate that information with those persons.
- If you are going to put in a proposal, let me suggest that your proposal should include the following language (or at least include these items):
- While there are some other good pull requests out there (such as 775, and 778), there is only one, in my estimation that reverts 0.5.18 using an upgrade path, a cosmos version that has been in production previously, and uses the absolute minimum code in accomplishing this [only makes one dependency change]. Each of those, 776, 775, and 778 [which does make minor protocol changes] capture the majority of intent of returning to the protocol as it was in 0.5.18 [however, they focus on the necessary changes for governance, and so 776 and 775 have not focused on changes in 0.5.20]. Validators need to have a path for upgrade or downgrade - depending on how they proceed (I think that if a proposal is passed, rather than signal “permission” to return to a protocol change that should never have been made, and was not appropriate the way that it happened, that it signal to validators an upgrade or downgrade path. You can at least say that the promise that “Once… what is being termed as Terra Classic launches, this will be reverted obviously” from pull request 63 for cosmos-sdk, at least for delegation and validator node registration, has not happened and is long overdue. Language being humbly suggested for a proposal:
-
Proposal to return to appropriate protocol as passed by governance community:
- If TerraForm Labs does not merge classic-core pull request 776 ( https://github.com/terra-money/classic-core/pull/776 ), build, test, and coordinate with validators instructions for upgrade within 5 days directly after the passage of this proposal, then on the 5th day after this proposal shall pass at exactly 4pm UTC, validators shall: -- halt (and unhalt after downgrade) -- downgrade to classic-core 0.5.18 downloading at the bottom of this page: --- https://github.com/terra-money/classic-core/releases/tag/v0.5.18 --- classic-documentation that may help: ---- https://classic-docs.terra.money/docs/full-node/run-a-full-terra-node/updates-and-additional.html --- support contacts ("classic" community support of two blockchain developers): ---- https://github.com/Raider7019 ---- https://github.com/ZaradarDFDS - If classic-core 0.5.18 build is no longer available for download at (near bottom of page): -- https://github.com/terra-money/classic-core/releases/tag/v0.5.18 -- Then validators should download a build of pull request 776, with instruction for upgrade, specified in the readme.txt file at: --- https://github.com/terra-rebels/classic-core --- This repository is a community driven repository of v1 community developers. ---- See here for the list of developers involved in the project: ----- https://github.com/orgs/terra-rebels/people ----- Many of these developers have years of experience in blockchain development, and understand the need for appropriate financial institution grade testing, including the two developers listed above.
For those who believe this would present a problem security wise, let me remind you that every person who owns LUNA “classic” is part of governance, and by definition has a right to stake and vote. If you would like to protect your stake, I suggest start purchasing LUNA at those exchanges that are still selling it if this becomes an active proposal. For those who are still skeptical on this point, I suggest you read my response on this point, especially the bullet points around proof of stake and governance attack:
Thank you so much for your consideration - I hope you each have a great day 