Hi @almutasem_alhaj ,
In a nutshell: This proposal gives governance, which includes validators, a path for distribution of code that has been developed for proposal 3568 (for the 1.2% burn) and for 4095 (re-enable delegation and staking) - both of which passed governance votes. This proposal only deals with the distribution of the code, and the code itself, and a security proposal regarding code for 4095.
If the vote passes, it gives TerraForm Labs (TFL) 10 business days (so does not count weekends) to either come up with their own implementation of 3568 and 4095, or merge, build, and distribute the code proposed in this proposal. If they do not, then the proposal outlines the path to distribution of the proposed code using these instructions.
The code current gives until block height 9346889 for catch-up consensus (where both v0.5.20 and v0.5.21 [the code being voted on with this proposal] can coexist on the same network for validators). The date for this would be approximately September 12. After that date, staking and delegation would be active again, and the underlying code for 3568 (for the 1.2% burn) would be distributed. However, since the code for 3568 relies on keys within a parameter that is stored on the block chain, and a parameter proposal is the means that the system gives to change parameters on the block chain, another proposal (a parameter proposal) will need to happen to move the percentage from 0% (the current value of that parameter) to 1.2%. There are a few caveats in section 10.1 of “Emergency Management and Recovery of Luna Classic” to consider however re: the parameter proposal.
At blockheight 10225289, which is approximately November 12, new validators would be allowed to join the active validator set.
It is important to note that the approximate dates of September 12 (for staking and delegation) and November 12 (for new validators) are subject to change (as the proposal mentions).
The proposal itself gives a template to use for future update and upgrade changes to protocol and code based upon the protocol. This gives the Terra v1 governance community (which includes validators) the ability to establish the code is well tested and reviewed and gives a path for distribution.
This is important since as I have mentioned in a different setting a trusted source for code has governance as well as security and project management considerations:
At least for myself personally: for governance chains, code distribution is a decision, and decisions are made by governance. That governance includes validators (and right now, it probably mostly consists of validators, and those who had staked before). For chains that are not governance, the miners/validators own the network aspect, and they would make network decisions. The one situation that I can see for this chain that would allow for a validator alliance is where the chain is hard forked (which by the way, with this particular chain it sees hard forks as a threat and makes efforts to mitigate it appropriately), at that point there are now two chains with governance claims - at that point a validator alliance would be necessary to align with which governance side of the chain they will follow.
- “Since the Tendermint is designed to never fork at all” [hard fork]:
- Alliance agreements (recognizing that Terra v1 has its own additional governance aspects layered on in its documentation):
- A few other sources without overloading:
On the security side (again as a personal professional opinion): from my time in various aspects of IT, code distribution has security as well as project management aspects. For a large proof of work blockchain and network (such as Bitcoin, or currently Ethereum), where miners/validators are indefinite in number it can withstand malicious code (whether intentional or unintentional). This chain though has a small number of active validators, where it is more crucial (especially where it deals with peoples money) to have good testing, security, and review standards in place. This proposal would be voting on the distribution path for this particular code, the code itself, and an additional preventative security aspect (extending what was approved in 4095). I also have other concerns, but this proposal attempts to remain neutral for all parties, and at least provides a template for code distribution in case TFL does not consider community contributions as they have in the past, and includes governance (and therefore validators) in the process.
As the Cosmos documentation states (the Terra v1 ecosystem is built on top of Cosmos and Tendermint):
“…the protocol and software must also be obtained from a trusted source”
I hope that helps out a little bit, and that you have a great day today 