Proposal for No Canonical Repo for Terra Classic

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.

37 Likes

This is a no brainier. A yes from me.

7 Likes

Few question @ek826

  1. Will we be building releases on-the-spot (for the validators) based on the agreed release hash which becomes the versioning factor?
  2. How would other development groups know which dev group provided the latest release bundle in order to clone from their repo should they wish to contribute as well?

P.S. I think this is a great idea as it opens the horizon for multiple development teams contributing to the chain’s evolution. I am interested in the interoperability challenges i.e. how race conditions can be identified and avoided

I think it is more prudent to change the canonical repo. Are validators and the community ready to accept the responsibility of auditing code submissions? In theory, decentralizing the repo sounds great, but it could leave us very vulnerable. There is a reason the chain has always had a trusted canonical repo. It needs to be separated from Terra Rebels, but it sounds very risky to give this responsibility to a non-dev community.

9 Likes

Great idea to decentralize the network Ed! I agree this is a great way to improve the developer-validator relationship and prevent a centralized developer entity from having too much control. As a Validator myself, this will give more responsibility on my end to properly represent the community. I believe with more responsibility on the validator set, further distribution of VP is important to prevent just a few validators having too much control.

8 Likes

Thank you, good move.

1 Like

So to be clear… with NO canonical repo any other L1 dev/devs can make changes?

3 Likes

Please clarify the risks more.

8 Likes

My concern, although you did mention it,would be the oversight of any code changes.

1 Like

A yes from my side!

1 Like

I am wondering if just changing the canonical repo will be the best and simplest option, but really as this option places more responsibility on Validators, if they are ok with it then I support it.

1 Like

Absolutely, YES.

This is pure decentralization.

In reply to @awlionking sure the Validator are able to let pass the good proposal and stop the bad one, about auditing we will make a pool of expert for it, when we want the code to be implemented.

in reply to : @DJTrev1 any other L1 developer can propose change and the change if are valuable and audited will be voted in governance and implemented.

in reply to: @M1NZIE if a validator do not want take responsibility can easy go to do other, we are here to support the chain and we have to take the responsibility.

5 Likes

Makes sense to me.

Yes and yes

2 Likes

Decentralization is usually a net positive, but I’m not so sure about this particular case…

The active validator set can be subverted. Collusion is always a possibility (I’m not saying it’s probable, but it is possible). Having a centralized code base entrusted to a group of senior caretakers sounds a lot safe and better than leaving it open to validator shenanigans. Again, not saying anything bad will happen, only that it can… and do we really want to take that chance?

This part is definitely a positive change - more audits and scrutiny over updates is always good. :+1:

See, this is where the problem lies - most validators don’t have the technical chops to become guardians of the chain. And even if they did, do we really want to entrust an asset as valuable as LUNC to the current active set? How is this beneficial to anyone? You open the chain to multiple vectors of attack, ranging from simple collusion all the way to Sybil events. And what if the validators don’t trust each other, get into disagreements, and the majority fails to reach consensus on future upgrades? How long can the chain remain gridlocked? Do we even want to try and force consens across what should be an independent and decentralized set? I feel like we’d be straddling them with a massive burden; look how much trouble many of them have with taking part in simple governance (most don’t even vote on props, or don’t read them thoroughly), and you’re wanting to increase their responsibility by an order of magnitude? They’ll buckle under the strain, and it surely won’t end well if their present performance is any indication (please note I’m speaking of the entire active set as a general whole - sure there’s outliers and positive performers, but looking at all of them together leaves a lot to be desired, especially on the topic of technical proficiency).

More work for an already overworked and overburdened team. There’s a limit to how much labor the Task Force can output - your time is most valuable working on code, not spending it on coordinating all of these moving parts which can easily blow up in your faces and cause massive setbacks in scheduling. Please don’t misunderstand me, I’m not saying you’re not up to the task - I just think that looking at worst case scenarios needs to be done if we’re to gauge how much this change could impact the JTF’s ability to produce tangible code updates. It’s a waste of your time and skillsets to get bogged down coordinating disparate groups by shepherding them all through code audits and governance upgrades. That’s not what you were paid and contracted for, and it’s also far from the optimal use of your skills and time.

But we already have this, no? Pull requests and code audits are already a thing. :man_shrugging:

I fear you’re looking at these tasks through the eyes of a seasoned, senior developer (yourself). The vast majority of the community and validator set isn’t nearly as proficient in these tasks as the L1 team is… and it’s entirely possible y’all will get bogged down with these minutiae to the point it’ll seriously gridlock your ability to do core L1 work (which should be the Task Force’s primary concern). The more moving parts we introduce into this process, the greater the change one of these cogs will break and grind everything to a halt. It’s just how systems tend to operate, whether mechanical or digital… add humans into the mix, and it gets ever worse + slower.

Honestly, I think it’d be preferable if the canonical repo would be changed from the current TR-controlled one to something others can access as well (and by “others”, I mean senior trusted devs with a good track record and a spotless resume). That could be a good middle ground, no? And it’s far less disruptive than opening the chain up to validator (mis)management.

I dunno, I’m still on the fence here… I need to think about this a bit more. :thinking:

We’ll see what the rest of the community thinks and comments…

Shalom! :pray:

18 Likes

Thanks but no thanks. Several Validators have proven themselves not to have the communities best interests at heart.
What you’re proposing gives further control and responsibility to 22 year old youtubers with no life experience.

11 Likes

I fear the risk here outweighs the benefits. This would be fantastic in a perfect world but that is not what we have. In reality, we do have some bad actors, we do have some lazy or minimum effort validators and we do have some not so competent developers.

I would much rather go with a new canonical repository, guarded by experienced devs, even if that requires securing of additional funding from the community to maintain.

I just think it is an invitation for chaos. But, it is essential that we do separate from the TR repository to ensure independence.

5 Likes

Hi @ek826 ,

I have had time to consider this issue, off and on, since the canonical repository being transferred to Terra Rebels (as I know you have as well).

I think the proposal you outlined will work, however, I think a potentially preferable solution for the validator set, as well as the community, in terms of independent security reviews, and independent testing would be for the community to hire a service to maintain the canonical core repo (as well as any custom tendermint/ignite and cosmos-sdk repos).

The service would only do the following:

  • make any critical security level dependency upgrades (if not already contributed)
  • independently review submitted code (both for code and security implications - to the best of their ability)
  • independently test submitted code
  • post reviews and test results with recommendations
  • merge code that passes proposals (if it should change the protocol)
  • coordinate with validators for upgrade

The service would be completely neutral in regards to any other criteria for merges (ie. it would meet the ideal of community contributions). The service could be changed by a proposal that passes (outlining the new service). It would also provide an independent security review, and independent testing.

The drawback would be the cost (however, since some validators would rely on a security review that one among the set would provide for, or ask the proposer for one, the cost will most likely be born in either model by the community anyhow). While it still is a central org of repositories, it does remove the issue with the repository maintainer making merge choices based on their own personal criteria or agenda.

  • It is true that the person/service could obfuscate themselves to break the prohibition on code commits minus critical security dependency updates, which itself is a concern, although this could be mitigated by using a trusted service/person, a potential secondary review (either independent or community), as well as removal from service (but I admit this is the weakness to what I mention as an approach - I originally conceived of a second independent reviewer, but that seemed too expensive for where Terra v1 finds itself financially at the moment).

For the person/service to perform - it would need to be someone with 3 years or more of full time tendermint/ignite and cosmos development (and they would not be able to contribute to the code during their time of service [minus what is outlined above], nor audit or merge code that essentially they contributed, nor audit or merge code that was contributed by a company that they work for where that company essentially contributed code).

I would imagine that the service would be most cost effective in hiring an independent contractor for the service at $8k per month (loosely based on 20 hours a week @ $100 hour [although I do realize this is 48 weeks rather than 52 weeks]).

As an aside note (completely separate from above): If there is a concern that Github (or another service) may censor the code, an open source project like Radicle could be used (although they are lacking in tools currently that are used in other platforms, and as an open source project themselves are not as stable financially as other platforms may be).

Just some food for thought - if you find it has any merit.

2 Likes

Changing the canonical repository could be a viable choice? We just need to make certain that “owners” cannot hold the repos in the chain at ransom.

@RabbiJebediah alluded to the following.

Why cant we change the canonical repository and use the below for access?

Repository roles for organizations

You can give organization members, outside collaborators, and teams of people different levels of access to repositories owned by an organization by assigning them to roles. Choose the role that best fits each person or team’s function in your project without giving people more access to the project than they need.

From least access to most access, the roles for an organization repository are:

  • Read: Recommended for non-code contributors who want to view or discuss your project
  • Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access
  • Write: Recommended for contributors who actively push to your project
  • Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions
  • Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository
  • Organization owners. Organization owners have complete administrative access to your organization.

What’s the real issue in using this approach if it is done above board?

Could you please tell us the motivation of this proposal?

If purpose is decentralizing,I think it’s not necessary.We are already decentralized.

If purpose is secure the repo,I think it’s not necessary too.Now your team has the responsibility with the repo,isn’t it secure enough?

By the way,I can’t imagine the United States only has a parliament without a president.So as the Lunc ecosystem.That so called decentralization will bring us to the failed.
Just because the crowd stupidity.
Strongly recommend to read a book < The Crowd: A Study of the Popular Mind > by a France famous socialist Gustave Le Bon.After understanding the theory of stupidity decision from the crowd.You will know so called decentralizing is not work,both in real world and cyber world.

2 Likes

I would be wanting L1 team to focus on their work and not be distracted with non-necessary tasks. Will this take away focus from L1 work?

4 Likes