Introduction
This is a non-state breaking software upgrade proposal to the Terra Classic blockchain to transition from v1.0.4 to v1.0.5. Non-state breaking means that there are no changes to the states created by the validators, rather these are changes made to the client that interfaces to the chain. Validators and full nodes are requested to upgrade at their earliest convenience.
What is Included
Release v1.0.5 includes the following changes.
Current version running, v1.0.4, hash “a6f1a39f00c2723b62f42d40d024bd1181225a8d”
Change #1, hash “ebba0521fec4fc5655d90c0b3fdb2dbb2ec8d11f”
Hash “7fe4468fab7a767b8779e093d671a69f26b19781”
Link: Added Z's fix for the feeutils.go · classic-terra/classic@ebba052 · GitHub
allow uluna to be taxed · classic-terra/classic@7fe4468 · GitHub
Title: Fix for the feeutils.go
Description: This is a simple fix to the node’s LCD endpoint that corrects a calculation issue on the LCD. This is not a problem with the blockchain itself, but rather a problem when the LCD tries to estimate the gas required. A tweak in early September adjusted for this issue in Terra Station wallet, this will fix it on the LCD side.
Change #2, hash “2d50ef215c802a63d4a0b36fe75c2001c0fcb5d3”
Link: upgrade version map hot fix · classic-terra/classic@2d50ef2 · GitHub
Title: upgrade version map hot fix
Description: This is the most important change we are making in the version upgrade. This is a simple fix made to the upgrade keeper that stores the current version map of the modules in the applications memory. The problem we were running into before, is that the software upgrade governance proposals, and upgrade handlers, would not run because they do not have any knowledge about the current versions of the modules on chain. This code initializes the version map, so that future upgrades can utilize the proper upgrade procedures.
Upon the successful upgrade to v1.0.5, the hash would be “7fe4468fab7a767b8779e093d671a69f26b19781”
Summary
This upgrade is non-state breaking but required; it is the crucial first upgrade needed to proceed with further state-breaking upgrades. If nodes do not upgrade, the next upgrade iteration will result in incorrect version maps (version 2.x.x), and cause frozen nodes that will halt and not continue by normal means (will require resync). At the time of future upgrades, we will again remind all validator and node operators that they need to be running this version, v1.0.5.
Important Note about “No Canonical Repo for Terra Classic”. The discussion around the no canonical repository is on-going and all feedback is being considered. Until this is resolved, we are requesting that the validators accept the release from the Joint L1 Task Force’s repository, Release v1.0.5 · classic-terra/classic · GitHub
There are two other repositories that are currently up-to-date with the current version of classic, terra-money/classic-core, and terra-rebels/classic. Upon successful governance of this proposal, the JL1TF will submit the corresponding pull requests to both repositories to keep them sync’d with the JL1TF progress. It is up to the respective organizations to decide to accept and create their own release.
Testing Results
- v1.0.5 is currently running on a full node in parallel on Columbus-5 with no errors.
- Successful upgrade tested on a Testnet using the software governance mechanism using the version hot-fix
- Testnet and Mainnet v1.0.5 correctly computes the tax via LCD.
Note: All existing nodes, dApps, wallets that compute the tax and add it as a “fee” parameter will not be affected (which is likely all of them since the LCD wasn’t adding the tax correctly). Automatic fee calculations will be correct after this upgrade.
Note about community passed proposal #11243
A community member has passed proposal #11243, unrelated to this release. For validators and nodes, we will provide further instructions on how to update their gas fees based upon the governance recommendation to increase gas fees by 5x.
By voting YES, you agree that the following code be accepted and installed on the Terra Classic blockchain. Upon governance acceptance, instructions on how to proceed with the install will be provided in relevant communication channels.
By voting NO, you are indicating that you will not accept this code change.