V1.1.0 software upgrade proposal

[ek826]

Introduction

This is a summary and culmination of the discussions around the release v1.1.0. The release can be found at Release v1.1.0 · classic-terra/core · GitHub

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 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. 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 v1.1.0.

What is included

Features

(build) #101 Upgrade test fix: add github action for upgrade testing by nghuyenthevinh2000 · Pull Request #101 · classic-terra/core · GitHub

(ante) #103 Add burn tax split logic v1.x backport: add burn tax split logic by nghuyenthevinh2000 · Pull Request #103 · classic-terra/core · GitHub

(ante) #107 Burn Tax Whitelist feat: add burn tax exemption list by nghuyenthevinh2000 · Pull Request #107 · classic-terra/core · GitHub

(ante) #137 Update burn tax exemption feat: tax exemption update by inon-man · Pull Request #137 · classic-terra/core · GitHub

(build) #118 localnet for Apple Silicon build: localnet for Apple Silicon by inon-man · Pull Request #118 · classic-terra/core · GitHub

(app) #128 Panic at InitChainer for the Columbus mainnet

Improvements feat: panic at columbus genesis by inon-man · Pull Request #128 · classic-terra/core · GitHub

(build) #93 Use golang 1.18 and fix ad-hoc security vulnerabilities Upgrade to golang 1.18 and fix ad-hoc security vulnerabilities by ZaradarBH · Pull Request #93 · classic-terra/core · GitHub

(build) #97 Change module path to classic-terra/core Change module path to classic-terra/core by inon-man · Pull Request #97 · classic-terra/core · GitHub

(build) #102 Snyk secops patches Snyk secops patches by ZaradarBH · Pull Request #102 · classic-terra/core · GitHub

(build) #105 Update docker assets

Bug Fixes Updated docker assets by ZaradarBH · Pull Request #105 · classic-terra/core · GitHub

(auth/client) #106 fix ungraceful error on failed client tax query fix ungraceful error on failed client tax query by fragwuerdig · Pull Request #106 · classic-terra/core · GitHub

(ante) #113 Fix burn tax split bug fix: burn tax split bug by inon-man · Pull Request #113 · classic-terra/core · GitHub

All changes from the v1.0.5-full-archive release

V1.0.5-full-archive…v1.1.0 Comparing v1.0.5-full-archive...v1.1.0 · classic-terra/core · GitHub

Discussion Threads around v1.1.0

V1.0.6 Release Candidate

Binance burns much more through fees on their platform as with onchain fees. This is at least what community can do for them. If they stop burning this can be reversed. Yes to this one. And please put it up for voting.

Signaling Proposals around 3 Optional Features in the next release

What you described is a purchase tax. Sales tax must be paid by the seller. This is logical. And 8% is a lot. Imagine yourself as a speculator. You bought 0.00017 million LUNC for $170. The price must rise to 0.0001836 to reach 0. But you need to earn something. Traders will not use this tool with such a commission. But, in my opinion, it is the sales tax that can pull the TERRA CLASSIC project. Certainly not 8%. Enough 1%. The total trading volume for the asset is $120,000,000. Approximately …

Optional Feature # 1 - Wallet Exemption to On-chain Tax (Binance Request 1/2)

Summary: Add exemption to the burn tax between wallets on a tax exemption list. This applies to MsgSend, MsgMultiSend

[CODE v1.1.0] Optional Feature # 1 - Wallet Exemption to On-chain Tax

thanks! and what would be the process of excluding a smart contract from taxes? say for example if I wanted to add LUNC-UST swap contract from terraswap (terra1l7vy20x940je7lskm6x9s839vjsmekz9k9mv7g) to the exemption list - do I just create a PR here: core/migrations.go at main · classic-terra/core · GitHub with the contract address and create a text proposal for governance vote for merging the PR?

Optional Feature # 2 - Separate Burn Wallet Exempt from Seigniorage (Binance Request 2/2)

Summary: In discussion with Binance and L1 senior devs, introduction of 2 burn wallets with different functionality was deemed confusing and introduces unnecessary redundancy. Accepted implementation is a single “new” burn wallet (with the same the old burn address) with seigniorage turned off at the L1 level.

Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy

Do you happen to have an order of magnitude of accumulation over a week using the Tx fees excluding tax-based proceeds? To be honest with you I gave up on the cap idea in favor of the fee increase, it feels like the natural way of doing this and is future-proof. So, maybe we need to rework the increase rate. For a low-volume week, I got down to a monthly collection of 75M (that excludes noticeable big jumps in the CP allocation due to remint). That’s circa 375M per month on low volume with an …

Optional Feature # 3 - Burn Tax Split to Community Pool

Summary: Tax collected will be split directly with the community pool and the burn wallet. The split is initialized at 90/10 burn/cp and can be changed via parameter proposal.

Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy

Do you happen to have an order of magnitude of accumulation over a week using the Tx fees excluding tax-based proceeds? To be honest with you I gave up on the cap idea in favor of the fee increase, it feels like the natural way of doing this and is future-proof. So, maybe we need to rework the increase rate. For a low-volume week, I got down to a monthly collection of 75M (that excludes noticeable big jumps in the CP allocation due to remint). That’s circa 375M per month on low volume with an …

[CODE v1.1.0] Optional Feature # 3 - Burn Tax Split to Community Pool

Thank you @ek826 and @dfunk , I just wanted to give my opinion on this. If the 0.8% passes a 75%/25% gives us nice flat figures of 0.6% burn 0.2% CP. Ease of figures is a valid factor to the community, especially when something is parameterised. This 3x our burns and 2x our dev funding (from 50/50 of 0.2%). But we do absolutely need to fund the oracle rewards pool. Dfunks idea would be for example using my figures, 0.6% burn, 12.5% CP, 12.5% oracle rewards pool (0.1% and 0.1%). I’m okay with…

Mandatory Upgrades

• Ibc-go 1.1.5 → ibc-go 1.3.1
• wasmvm v0.16.6 → wasmvm v0.16.7
• cosmos-sdk v0.44.5 → cosmos-sdk v0.44.8
• Other library “bumps” are dependencies around these library upgrades

Testing

Unit tests can be found at previous code discussions

[CODE v1.1.0] Optional Feature # 1 - Wallet Exemption to On-chain Tax

thanks! and what would be the process of excluding a smart contract from taxes? say for example if I wanted to add LUNC-UST swap contract from terraswap (terra1l7vy20x940je7lskm6x9s839vjsmekz9k9mv7g) to the exemption list - do I just create a PR here: core/migrations.go at main · classic-terra/core · GitHub with the contract address and create a text proposal for governance vote for merging the PR?

[CODE v1.1.0] Optional Feature # 3 - Burn Tax Split to Community Pool

Thank you @ek826 and @dfunk , I just wanted to give my opinion on this. If the 0.8% passes a 75%/25% gives us nice flat figures of 0.6% burn 0.2% CP. Ease of figures is a valid factor to the community, especially when something is parameterised. This 3x our burns and 2x our dev funding (from 50/50 of 0.2%). But we do absolutely need to fund the oracle rewards pool. Dfunks idea would be for example using my figures, 0.6% burn, 12.5% CP, 12.5% oracle rewards pool (0.1% and 0.1%). I’m okay with…

Integration Testing can be found here

[CODE v1.1.0] Integration Tests

Integration Tests for v1.1.0 halt chain v1.0.5 via software governance proposal resume chain via v1.1.0 terrad [image] [image] IBC Test Establish hermes on v1.0.5 to Osmosis v14 hermes auto reconnect on v1.1.0 after upgrade Successful IBC transfer on v1.1.0 after upgrade [image] [image] Burn Tax Split Test Burn tax split parameter introduced in v1.1.0 …

Additional Notes

The current recommended version of go 1.17 → 1.18. Go 1.19 is not supported yet and should not be used at this time.

Wallet exemption to on-chain taxes is a new type of proposal not available on the Station UI. This is similar to Software Upgrade Proposals (they are not available on Station). Caution should be used when performing these proposals on the command line. Station may have unexpected behaviors since these are not recognized. While a patch on testnet for the station UI has been made, please use caution until a patch can be incorporated onto various station wallets for mainnet.

[pivo4et]

Agree.

[SwordDemon]

Yes yes yes,and let’s directly go to Parity and Repeg part

[JESUSisLORD]

Thank you Ed! My validator JESUSisLORD will definitely be voting YES!

The 28th is just in time before Binance burn, excellent.

[GERALDGERALD]

Agreed!

[NovaValidator]

Hi @ek826, thanks for putting this discussion up. Can you expand on why Updated docker assets by ZaradarBH · Pull Request #105 · classic-terra/core · GitHub exists in the release and why work is being done on a Terra Operator?

[ek826]

I believe it is related LocalTerra. Install LocalTerra — Terra Classic Docs documentation. But I personally don’t use the docker tooling, so I’ll have to ask the others on the team how they utilize it.

[NovaValidator]

Please do and get back to us. We want to know what exactly Terra Operator is and what’s planned for it.

[iamgorets]

Hi guys. I am new here. How can I monitor the voting process for 11367? It is not visible on terra station

[RabbiJebediah]

@ek826

This proposal will HALT the chain at block, 11,734,000, or approximately February 28th, 10PM UTC.

Hey @ek826 thanks for keeping us in the loop! Did you ever figure out what exactly in this update is causing the chain halt?

Shalom!

[ek826]

hi this is just the designed mechanism of chain upgrades in newer versions of cosmos. We were on the old version, which is why we had to do it the other way before. With the modifications of v1.0.5, we are able to follow the proper procedures now.

excerpt from this article (Cosmos Dev Series: Cosmos Blockchain Upgrade | by zeroFruit | Web3 Surfers | Medium),
For the old version of the application, it just panic and self-killed its process . Every time the block is created x/upgrade module checks the Plan whether it’s time to run the upgrade procedure. It is normal that the old version application to panic and be killed when reaches the target block height because it has not UpgradeHandler. The old version application just writes the Plan data into the $DAEMON_HOME/data/upgrade-info.json file and exits the process when reaches the block height. So don’t panic about the panic message of the application.

[kch2134]

Strongly yes!!! Thank you!

[JESUSisLORD]

FYI the LUNC chain is temporarily halted. The L1 team and validators are working to make the upgrade to v1.1.0, but are encountering some technical difficulties. I or another person will update when there is more information.

[JESUSisLORD]

The chain is upgraded successfully to v1.1.0 thanks to all the validators working together and the L1 team in the validator discord. Great work!

Terra Station is still not working though.

[BobbyD]

Hey. A full node still broken here. Can you advise which version to use starting from 11734000 or above? Has anything changed in v1.1.0 repo after the chain restart? Can’t sync using v1.1.0 (nor v1.0.5).

[aeuser999]

You need to use v1.1.0. Here are the instructions:

How to update (compile):

$ git clone https://github.com/classic-terra/core.git
$ cd core
$ git checkout v1.1.0
$ make install

Update instructions if you already have the repository:

$ git fetch --all --tags
$ git checkout v1.1.0
$ make install

Then check for correct binary version:

$ terrad version --long

name: terra
server_name: terrad
version: 1.1.0
commit: 70d118b0ab38c5c2b61288a090177fdfa33dfe76
go: go version go1.18.1 linux/amd64

You can restart your binary using the command

$ sudo systemctl restart terrad

If you have problems, then check to make sure the consensus module is working:

curl localhost:26657/consensus_state

If it does not return back anything, then you will need to resync from the following (my suggestion is to backup everything in the config folder, and the data folder too just to be safe):

sudo systemctl stop terrad
cp $HOME/.terra/data/priv_validator_state.json $HOME/.terra/priv_validator_state.json.backup
rm -r $HOME/.terra/data

cd $HOME/.terra
wget -O - https://www.dropbox.com/s/d1z3k1l1misn05x/columbus-5-Mar-01.tar.lz4 | lz4 -d | tar -xvf -

mv $HOME/.terra/priv_validator_state.json.backup $HOME/.terra/data/priv_validator_state.json
sudo systemctl start terrad

Note: Always double/triple check priv_validator_state.json

If the address book is corrupted (has phoenix-1 information), then this was the suggested address book (although the address book in TR guides should still work I would think, but this is the one that got everyone up and running):

https://www.dropbox.com/s/bina9qfqkbsko6f/addrbook.json

Hope that helps out, and that you have a great day today

[BobbyD]

Thanks for your reply aeuser999. Unfortunately this is exactly what I’ve been doing. No luck ser. Some pruned state snap after 11734002… anyone? Thanks

panic: Failed to process committed block (11734002:2567013EB5E4ED5D538672B668B57A276F30129952572150C4FEE00F62E9E727): wrong Block.Header.LastResultsHash. Expected 658EC57B453249685F1074BC1F6CE5C56C04730BD850F0F05DFAAD41BF02B3B1, got AFE97BD368F0D6B92206B83EB89A1CBC8DED4B9EE1596F4A819C6817F53F47C9

terrad version --long
name: terra
server_name: terrad
version: 1.1.0
commit: 70d118b0ab38c5c2b61288a090177fdfa33dfe76
build_tags: netgo,ledger
go: go version go1.18.1 linux/amd64

[aeuser999]

We had one other person report the same issue. The above process worked for them. Just wondering… can you check sudo ps -e u | grep terrad and see if it shows any other instances of terrad running? If so, you may want to stop them.

Other than that, if you are upgrading, you may want to start with a fresh folder and git clone and build (although you have the right commit hash and golang version, so it should be ok). The only other thing I can think of is to make sure the snapshot is extracting correctly, in the right directory, and make sure the priv_validator_state.json file is copied back into the directory.

Just a few thoughts…

[aeuser999]

One other helpful comment was this:

if you use systemd and you’ve put wasm libraries in chain-specific folders, and if you build terrad on a different machine… make sure you actually copy over the wasm lib and set the LD_LIBRARY_PATH or risk an app hash error

[BobbyD]

Thanks for the last tip. Can you please give me your ldd output of the working binary (regarding libwasmvm.so ver) ? BTW positive, no other instances running and yep I tried from scratch.