Releases: classic-terra/core
v2.0.1
This is a summary of the items included in the upcoming software governance proposal for release v2.0.1.
This release contains governance approved features to the Terra Classic blockchain, including minimum initial deposit for governance proposals, Cosmos SDK v0.45.13, Tendermint v0.34.24, as well as mandatory security updates. This is the second major release that will utilize the upgrade governance proposal mechanism to upgrade the chain. This proposal will HALT the chain at block, 12,815,210, or approximately May 17, 2023, 16:32:40 UTC. If this proposal passes, at this time, all full nodes and validators will NOT be able to continue until they install and run the current upgrade version v2.0.1
Upgrade name: v3
What is included
The following is a list of features that directly effects the inner workings of the terrad binary and therefore the mechanics and external accessibility of the blockchain and its data:
V0.45.13 proposal (#176): Upgrade Cosmos SDK to v0.45.13
V3 Upgrade Handling (#177): This is going to handle any needed store migrations during the software upgrade procedure.
Min Initial Deposit (Recreated using main as base branch) (#138): This introduces minimum initial deposit parameter for spamming prevention.
37dc8b2 Update classic-terra module tag to classic-terra/core/v2 & WASM cherry patch
v1.1.0
Description
This release contains governance approved features to the Terra Classic blockchain, including tax exemption list, burn tax split, no-reminting of the burn wallet, as well as mandatory security updates. This is the first major release of that will utilize the upgrade governance proposal mechanism to upgrade the chain. This proposal will HALT the chain at block, 11,734,000, or approximately February 28th, 10PM UTC. At this time, all full nodes and validators will NOT be able to continue until they install and run the current upgrade version v1.1.0.
Upgrade name: v2
What is included
Features
(build) #101 Upgrade test
(ante) #103 #113 #134 Add burn tax split logic
(ante) #107 #137 Burn tax exemption list
(app) #128 Panic at InitChainer for the Columbus mainnet
Improvements
(build) #93 Use golang 1.18 and fix ad-hoc security vulnerabilities
(build) #97 Change module path to classic-terra/core
(build) #102 Snyk secops patches
(build) #105 Update docker assets
(build) #118 localnet for Apple Silicon
Bug Fixes
(auth/client) #106 Fix ungraceful error on failed client tax query
Default Tax Exemption List Updates
(ante) #149 Updated Wallet Addresses
All changes from the v1.0.5-full-archive release
Upon successful upgrade to v1.1.0, the latest version of the blockchain will be hash, "70d118b0ab38c5c2b61288a090177fdfa33dfe76"
v1.0.5-full-archive
This is the release of the v1.0.5 that should be used when syncing from columbus-5 genesis.
This addresses the historic indexing bug found in tendermint 34.14 that was ultimately addressed in tendermint 34.20.
This also adjusts the version map and fixes dependencies on other repos.
This should be the version you run if you want to run a full archive node and the FCD.
Required go version: 1.18
v1.0.5
This is a state breaking software upgrade proposal to the Terra Classic blockchain to transition from v1.0.4 to v1.0.5. Block height guards have been introduced so validators and full nodes can upgrade at their convenience up until the state breaking change at block 11,543,150, which will be approximately February 14th, 2023.
Release v1.0.5 includes the following changes.
Current version running, v1.0.4, hash “a6f1a39f00c2723b62f42d40d024bd1181225a8d”
Change #1, hash “ebba0521fec4fc5655d90c0b3fdb2dbb2ec8d11f”
Hash “7fe4468fab7a767b8779e093d671a69f26b19781”
Link: ebba052
7fe4468
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”
Hash “162f75579de1fca344cbd7e3f445aebf71560476”
Hash “24eb873f22b609d92dbaae9aaf491413e62b4671”
Hash “6bf1a7e8f2e6c048b2fe56a13b1edb9aa48fa557”
Hash “8bb56e9919ecf5234a3239a6a351b509451f9d5d”
Link: 2d50ef2
162f755
24eb873
6bf1a7e
8bb56e9
Title: upgrade version map hot fix
Description: This is the most important change we are making in the version upgrade. This is a state breaking fix made to the upgrade keeper that stores the current version map of the modules in the applications memory. This code is set to trigger at block 11,543,150 and does query the KV store (key value store, e.g. database) and thus results in a change in the block hash generated by nodes. 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 “8bb56e9919ecf5234a3239a6a351b509451f9d5d”
Required go version: 1.18