Terra Classic Core Developer Reveals Proposal To Eliminate Canonical LUNC Repo

The proposal will eliminate the need for a central authority overseeing code changes to the blockchain.

Edward Kim, Terra Classic developer and associate professor at Drexel University, has proposed eliminating the existing canonical repository for the Terra Classic blockchain. If the proposal passes, code changes made by developers will not be overseen by a central authority but by the active validator set, further promoting decentralization.

Motivation Behind the Proposal

Ed introduced the proposition on Thursday, explaining its details and the motivation behind it as he opened it for community discussion. According to Ed, Terra Classic developers are still facing the issue experienced when Terraform Labs had absolute authority over code changes made on the blockchain.

Discussion for no canonical repository for Terra Classic, https://t.co/j2TqbIt9cA

— Edward Kim (@edk208) January 5, 2023

He noted that the developers currently working on the chain do not have write access to the current canonical repository for the blockchain, dubbed “Classic.”

After the Terra implosion of May, which birthed the Terra Classic (LUNC) token, the Terra Money Classic Core repo was created and served as the canonical repo for the blockchain. Consequently, code changes made on the Terra Classic chain were subject to the approval of Terraform Labs since the firm oversaw the repo. But TFL were more focused on the Luna blockchain, leaving Terra Classic unattended.

In September 2022, Proposal 4940 passed, aiming to make the Terra Rebels “Classic Core” repo the canonical repository for the blockchain. However, following patches made to the repo to fix the Dragonberry exploit witnessed in its IBC code, the current “Classic” repo emerged as the canonical repo.

Impact On The Procedure For Terra Classic Code Changes

If the proposal passes, the Classic repo will cease being the canonical repository, and upgrades made on the Terra Classic blockchain will be overseen by the community, going through a few procedures. According to Ed, these upgrades should contain commit hashes detailing the changes and always start with the active or latest commit hash on the chain.

Additionally, Ed noted that all the appropriate entities; including validators, projects, nodes, and CEXs; should receive information on the upgrades being made. He pledged the L1 team’s support in compiling and offering the necessary information on their repo.

These procedures might be cumbersome for developers and validators alike, Ed said. Developers would have to go through greater scrutiny from the community before making code changes as they attempt to garner community trust. For validators, it will require extra effort to oversee the code changes embedded in any upgrade.

Even so, the proposal’s benefits, as Ed outlined, include proper reviews from the community on upgrades being made on the blockchain. Secondly, it promotes decentralization by allowing any competent group of developers to contribute to upgrades on the network.

Source