Updated v1.0.5 upgrade

Governance & Proposals
1

Introduction
Upon further integration testing, we have updated the v1.0.5 release. This is now a state breaking software upgrade proposal to the Terra Classic blockchain to transition from v1.0.4 to v1.0.5. State breaking means that there will be changes to the states created by the validators, when particular parts of this upgrade code is triggered. 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.

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”
Hash “162f75579de1fca344cbd7e3f445aebf71560476”
Hash “24eb873f22b609d92dbaae9aaf491413e62b4671”
Hash “6bf1a7e8f2e6c048b2fe56a13b1edb9aa48fa557”
Hash “8bb56e9919ecf5234a3239a6a351b509451f9d5d”
Link: upgrade version map hot fix · classic-terra/classic@2d50ef2 · GitHub
move version map register to begin block · classic-terra/classic@162f755 · GitHub
add UpgradeKeeper.SetModuleVersionMap to InitChainer again · classic-terra/classic@24eb873 · GitHub
Added block height guards for the version map update · classic-terra/classic@6bf1a7e · GitHub
Merge pull request #44 from classic-terra/v1.0.5-vm-fix · classic-terra/classic@8bb56e9 · GitHub

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”

Summary
This upgrade is state breaking and required; it is the crucial first upgrade needed to proceed with further upgrades. If nodes do not upgrade, by block 11,543,150, their nodes will fail to sync and return app hash errors. Additionally, 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).

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
  • Successful upgrade tested on a Testnet without version map initialized at genesis
  • 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.

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.

29 Likes
2

Well done Team! Fantastic work.

5 Likes
3

Road to recovery.

4 Likes
4

Super, thanks for the hard work and for the true passion :+1:

2 Likes
5

Go ahead @ek826 & @Zaradar . I dont see the need for us to vote on proposals of this sort.

On a different node if I may, have you considered moving to Phoenix?

6

Well done Ed!

1 Like
7

Well done Ed and L1 team! Thanks

1 Like
8

Good job L1 team! Keep it up!

1 Like
9

Let’s do it !

1 Like
10

Thank you, sir. Let’s do this.

1 Like
11

A vital update that requires implementation at the earliest. A YES vote…

1 Like
12

Thank you ed! You can request if you need more dev fund. Community will support task force team.

1 Like
13

Thanks for getting this update out, Ed.

What has contributed to making this upgrade a state breaking software upgrade, whereas the original upgrade you posted was described as being a non state breaking software upgrade?

1 Like
14

Yes good question. It was the SetModuleVersionMap method tested within the InitChainer function. This was the correct place for all cosmos chains in general; however, for us, we needed to move this function to the begin block method… due to the fact it wasn’t run when columbus-5 initially started. All to say, we needed this method to trigger in the past, and since it didn’t, we need to trigger it at a certain block. That changes the state of blocks produced, so all validators need to trigger it at the same time.

2 Likes
15

Yes from me! Nice work Sir and Team! I think we all appreciate the clear description of the problem, fix, and intended results. Good or Bad.

Your obvious talent, and the Team, I am grateful for. Thank you!

1 Like
16

Very thorough proposal as always, Thank you Ed.

On the subject of a canonical repository it is a very thought provoking question. With many advantages and disadvantages both ways. What is sure is that we cannot rely on TR to do the correct thing.

With the state of knowledge across the chain amongst the validators as it is I believe ‘currently’ there is insufficient knowledge available to allow validators to safely judge the quality of the code.

However, we could set up a ‘Counsel’ of technically competent validators with some kind of transparent assessment of their capability to offer expert evaluation of code. Then not having a canonical repository may be feasible because the members of such a ‘Counsel’ could be consulted on key votes.

For this to work rather than a canonical repositiory we would need a ‘canonical validator forum’ where those validators could be sure that those in the ‘counsellor’ seats are indeed technical experts, even though politically they would have no requirement to share politically alligned views.

I believe this would be a suitable solution because it also provides a forum where additional development groups can propose and discuss code with those validators in an open forum prior to creating more formal Agora style proposals. Thus opening up the chain to additional development groups.

3 Likes
17

Why did the list of validators who vote disappear in the application in the Manage section?

18

Without this update, there will be no further support from Binance. In my opinion, this is a must. Great information, ED is working on it and we have a real chance to do it at a very high level. THX Edward !

keep dreaming
keep dreaming680×680 63.4 KB

24

Hi @Dannavan_Morrison ,

I realize that you meant your comment to encourage the L1 Joint Task team, and particularly ek826 and Zaradar.

However, I do think that the comment itself, if it were to happen, would be destructive, and would actually undermine governance. I just wanted to take a few moments to outline why.

The documentation states:

  • “The Terra protocol is a decentralized public blockchain governed by community members. Governance is the democratic process that allows users and validators to make changes to the Terra protocol. Community members submit, vote, and implement proposals.”

By protocol it is meaning a set of rules or procedures for communication, transmission, and consensus, which are defined by the code. A change to the code is in itself a change to the protocol - particularly where it changes the rules, process, or procedure, by which validators reach consensus while maintaining state.

Every blockchain has governance, or at least some process for how decisions about protocol and other changes are made, it is just how that governance is carried out. Bitcoin for instance, as a proof of work blockchain, uses Bitcoin Improvement Proposals (BIP)(which can take years, precisely to make sure implementations are not harmful). In the case of Bitcoin, the 2008 whitepaper gave the answer as to who is governance, and how they vote, when in the final line of the paper, Satoshi Nakamoto stated “[a]ny needed rules and incentives can be enforced with this consensus mechanism.” The BIP’s use a message in the consensus blocks to determine their support or not for the BIP. But, in the end, the code is either accepted or rejected by the miners, and that support or rejection is determined by consensus of blocks. If there are bad actors among the miners, and they happen to capture the network, the economic community is ultimately the one who will choose to remain, or create/follow a fork, or take the code, spin up another network, and start a new project based on the original, or leave the project all together. This works in proof of work where there are thousands of nodes that mine.

In a proof of stake network that has a small active set of validators, such as Terra v1, it is stake, rather than work, that secures the network and the consensus block producing process. For that reason, it is those who stake who determine what runs on the network. This is the reason that those who stake are the ones who vote on governance in Terra v1. Those who stake include both delegators, and those validators who self-delegate. Securing the network and producing blocks is a partnership between delegators and validator operators who maintain the hardware. Delegators are the ones who determine the protocol, through governance, by their vote recorded on the blockchain. If delegators do not vote, then in order to prevent the network and governance from stalling, and based on their partnership with the validator operators they delegate with, the delegators allow their validator operators, via the cosmos-sdk governance module, by a type of proxy vote, to vote on their behalf. However, this is done in a way that the delegator’s vote will always prevail over their validator operator’s vote if the delegator votes during open voting.

If governance is bypassed in determining the protocol, or other aspects governance votes on, they will delegate away from their validators (if those validators should run protocol software governance did not agree upon), and if needed, individual members of governance may create new validators to capture voting power from sympathetic delegators in the active set. Any forced acceptance, whether through forced limitations, or forced code changes, will only last a short period of time (this is why ideas of capturing control to certain groups, rather than doing the hard work of convincing governance, is not only harmful, it actually pours fuel onto the fire, and will not only not work in the long run, but will create backlash).

Critical dependency upgrades, and critical security patches that are reported in the underlying dependencies (such as CVE)(or for cosmos, security patches that would apply to each of the cosmos chains on affected versions), and potentially critical bugs, tend to get a pass in blockchains depending on their severity/impact, and the fact that their main inclusion in the code, was a result of a prior governance vote. Although by every definition they can still be a change to the protocol, consensus, and/or state, and governance can maintain a vote be required before receiving the newer changes. These changes should at least be fully tested - since changes to underlying dependencies can themselves cause critical issues elsewhere. The dragonberry patch for instance was released to all cosmos chains prior to acknowledging it to the public to help prevent exploits in the wild once it became public.

Just allowing developers, or anyone, or any group, myself included, to make unilateral changes, without governance, or in an attempt to limit governance, even if their intentions are not intended to be bad, can lead exactly to where Terra v1 was under TFL. TFL only put 2 major proposals up for changes to the protocol that I could find (13, and 119). They disabled staking, validator creation, certain market swaps, and IBC to specific channels without governance, in conflict with the stated purpose of governance on the chain. Although to be fair, they mentioned they did this from what they believed to be a security issue - although it also put them in a favorable position for proposal 1623, whether that was intended or not, by effectively closing governance to certain LUNA v1 holders, and preventing new validator creation. There is a reason why many outside the Terra project, have almost taken TFL and the blockchain, before May 2022, to be one and the same. What was designed, by their own documentation, to be community driven, was not in many regards (at least through actual voting regarding changes to the protocol, even if it may have been through sentiment). In my estimation, that opens up many problematic issues, violates the purpose of governance, is dangerous, and will not serve the community nor the security of the blockchain itself.

Having developers put their changes through governance, as ek826 has done, also serves to allow governance and validators to interact with developers regarding the code, testing, and questions - so they have the information needed to vote (to determine if the software changes will be run on the network). It leads to transparency, which leads to trust. In the end, trust serves developers as much as it serves the rest of the governance community. It does not serve developers well if they lose trust of the product owners.

In regards to this specific proposal, it included aspects of 11168 that had been generally outlined, but it also asks for deployment from a non-canonical repository. Thankfully (at least I am very thankful to ek826 for putting it in a proposal) it also allowed governance to review the code in question, see testing results, and vote on it. Having governance vote on code can be a helpful step for determining security of the code, as well as security of the network overall. We should recognize that in the fintech sector, further processes that help secure code, as well as the process around securing finance, should be welcomed - so that it further protects people’s assets. That is not said to hinder, but to help provide good stability.

Just a few thoughts for consideration.

I hope you have an awesome day today :slight_smile:

3 Likes
25

Why should I/we vote on codes that I/we dont understand. How many of us know about basic programming? Now we talk about tendermint! This job is for TGF. Core code development should be allowed to proceed without the need to be voted on. It’s an exercise in futility. 99…% of these core updates are passed every time. They are not parameter changes; they are codes that need to be implemented. In my opinion we are wasting precious and costly L1 developers time.