Introduction
Terraform Labs were the original developers of the blockchain and used the github repository, https://github.com/terra-money as the canonical repository for the Luna blockchain. After the de-peg event in May, the Terra Classic repo was created, https://github.com/terra-money/classic-core, but not actively maintained. Thus, any code changes by active developers in the ecosystem were subject to the approval of a centralized entity, whose focus had shifted to a different blockchain project. Until August 2022, the terra-money repository was still the authoritative repository.
Given that TFL was no longer actively working on the classic chain, community governance passed proposal 4940 and elected to change the canonical repository to the Terra Rebel’s classic repository, https://github.com/terra-rebels/classic-core. This repo was then archived and switched to https://github.com/terra-rebels/classic due to an exploit found in the IBC code, known as Dragonberry. We received an urgent request to create a private repo to patch the Dragonberry exploit before the presence of the exploit was made public. This resulted in the “classic” git repo now being used as the latest “canonical” repo.
Motivation
However, at this time, we are facing a similar situation where a group of Terra Classic L1 developers are working on the blockchain, yet do not have write access to the current canonical repository, and are subject to the approval of a centralized entity. Given the decentralized nature of our blockchain, we are proposing that there be no canonical repository for Terra Classic. Thus, there is no one centralized entity or developer group that has default control over the code base. Guardianship of what code runs on the blockchain is solely in the hands of the active validator set.
Procedure
Upgrades to the blockchain must contain commit hashes outlining the changes being proposed, and must always begin with the latest active / current commit hash running on the blockchain.
For example, the current release of the Luna Classic blockchain is v1.0.4.
Notice the beginning of the hash related to this release is “a6f1a39”. Any new release to the block chain must outline the changes made beginning with this hash. Below is an example of the changes one would need to show beginning with “a6f1a39”.
If these changes shown above are accepted to the blockchain, then the current release would be at hash, “2d50ef2”, and any future release must begin with the latest hash running on the chain, “2d50ef2”.
There is a time and effort cost involved with this model. For the developer, it will require extra effort to gain the validator/community trust on a software upgrade proposal to pass it through governance. This may mean independent security reviews, or extra documentation. There is an additional burden on the validator set as well. Validators must be active guardians of what code they chose to run on the chain, and cannot rely on the “canonical repo trust factor” that existed before. It is recommended that validators perform their own security assessment or audit. Again, while this requires more effort, we view it as a benefit - the more eyes and reviews on the code, the better.
Finally, communication of upgrades must reach all relevant infrastructure parties → validators, dApp projects, CEXs, full nodes, LCD/FCD endpoints etc. If this proposal passes, the Joint L1 Task Force will assist, compile, and offer this information on their GitHub repository, https://github.com/classic-terra/
In summary, we believe that this proposal offers two major benefits to the community. First, it decentralizes the developer validator relationship, allowing any competent developer group to contribute freely to the blockchain. Second, it inherently requires a second level of review from the validator set and community body. On the other hand, this does require extra effort and scrutiny on the part of the developers, validators, and community during the upgrade process.
By voting YES, you are communicating that you believe that there is no central canonical repository required for the Terra Classic blockchain, and you support the procedure of using code commit hashes (starting with the current code hash) as the preferred method of upgrading the blockchain.
By voting NO, you are communicating that you would like the canonical repository to stay as the Terra Rebel’s classic repository, https://github.com/terra-rebels/classic-core, or you would prefer that we propose to change the canonical repository instead.