MOTIVATION & AIMS:
With the recent passing of Proposal 11310, validators have been preparing in the background to begin the upgrade process to v1.0.5. However, with the recent news that has happened as of late in regards to Allnodes, compromised validators, and the overall security of the Terra Classic chain and the entire Cosmos network itself, it has become clear that the proposed timing for validators to upgrade to v1.0.5 by block height 11,543,150 (approximately February 14th, 2023) needs to be reconsidered and postponed so that the v1.0.5 release itself can be looked at it in more detail and more thorough testing can be done.
The reasoning for wanting to do this are many, and from a professional development perspective many yellow and red flags have emerged since last week that make validators postponing the upgrade the only safe choice we can currently be taking to ensure that we are fulfilling our role of properly securing the Terra Classic blockchain. Those flags are as follows:
- PFC’s departure from L1 JTF in under a month (yellow flag)
- L1 JTF’s failure to properly communicate about the details of the v1.0.5 release in the Terra Classic Validator discord in a timely manner (yellow flag instead of a red flag considering everything that’s been going on)
- Jacob Gadikian’s departure from L1 JTF in under a month due to the Allnodes security risk (red flag)
- Zaradar’s public handling of the Allnodes security risk and denial of it for being the risk it is (red flag)
- Notional’s departure from the chain, as well as other notable validators starting to consider their departure from the chain as a result of the L1 Team’s handling of the Allnodes security risk (red flag)
- The fact that there needed to be an updated v1.0.5 Upgrade release that changed it from being a non state breaking change to a state breaking change, which is an indication of inadequate testing (red flag)
- The fact that the upgrade seems to currently not account for 7TB of state data that already exists on the blockchain, which may be intentional but needs to be confirmed all the same and could also indicate a potential loss of smart contract data (red flag)
- The fact that after much talk about implementation of Constrained Pools, not only is the code poorly written from a professional perspective via it’s use of:
- Hard coded magic numbers that provide no context or explanation for why they exist in the codebase for other programmers to understand as well as not exposing those values as parameters that can be changed via governance (red flag): Constrained pool to ensure LUNC can never have more then 2T supply by ZaradarBH · Pull Request #51 · classic-terra/core · GitHub
- Self described “hacks” written into code that’s intended to be deployed into production code (red flag): Constrained pool to ensure LUNC can never have more then 2T supply by ZaradarBH · Pull Request #51 · classic-terra/core · GitHub
- A conversation from another developer (inon-man) that raised concerns that the changes Zaradar had implemented would not actually fulfill the needed functionality, which Zaradar resolved without any proper resolution implemented in the code or described in the conversation (red flag): Constrained pool to ensure LUNC can never have more then 2T supply by ZaradarBH · Pull Request #51 · classic-terra/core · GitHub
- But also the fact that Zaradar proceeded to merge the contentious changes for his Constraint Pools (which are implemented incorrectly) into the main branch when it hasn’t passed code review from other developers on the team anyways (red flag): Constrained pool to ensure LUNC can never have more then 2T supply by ZaradarBH · Pull Request #51 · classic-terra/core · GitHub
- The actions of which then forced another developer (inon-man) to create a second pull request to revert the changes that Zaradar should have never merged into main in the first place, and giving excuses upon inon-man calling him out for said behaviour that goes against how development on teams is intended to work, and also having another developer (lehajam) have to pipe in and explain that Zaradar’s code was fundamentally incorrect and have to explain to him why it was even broken in the first place (which is generally fine in practice, but is an issue when Zaradar has merged the code into main without the changes having gone through proper code review - a very HUGE red flag): Revert "Constrained pool to ensure LUNC can never have more then 2T supply" by inon-man · Pull Request #82 · classic-terra/core · GitHub
All of the above reasons are very concerning, but any developer who has been paying attention to the codebase like I have has also already observed these behaviours from Zaradar. These behaviours and all the other yellow and red flags that have surrounded the release of v1.0.5 that when combined with the fact that a large amount of the voting power on chain currently consists of validators that have had their seed phrases compromised by Allnodes’ business practices creates a multitude of vectors of risk that make it impossible for any sane validator that is working to secure the Terra Classic blockchain to adopt the v1.0.5 release at this time until our chain security issues have been more thoroughly handled and the actual code that is present in the v1.0.5 release has been more deeply looked at, and more testing has been done (outside of just the L1 Task Force doing the testing) then what we’ve seen to date.
That all validators hold off on upgrading to the v1.0.5 release on their machines until chain security has been sufficiently improved to a point where the chain is no longer compromised or at risk. We’ve already got enough of a crisis on our hand with the chain’s security being compromised, the last thing we need is to risk potentially losing chain state. Once chain security is back at a point of confidence, we can look at releasing a new version of v1.0.5 that has an updated upgrade block height and has had it’s code thoroughly reviewed by multiple validators and experts in Cosmos like Jacob Gadikian.
By voting YES - You acknowledge that there is risk to the chain present in v1.0.5, and that validators should NOT upgrade their nodes to v1.0.5 so that the code can be more closely looked at by validators and undergo more thorough testing at a later date when the chain’s security isn’t in such a tenuous state.
By voting NO - You do not think that there is any risk to the chain present with v1.0.5, and that validators should not do their due diligence on the code of the release and push back the upgrade, and that they instead should upgrade their nodes anyways despite the many red flags and risks presented above.
By voting ABSTAIN - You have no particularly strong thoughts on the matter either way.
By voting NO WITH VETO - You are vehemently against the entire premise of this proposal.