Require Whitelisted addresses to make code Visible prior to upload

Proposal Discussion
1

Original Post: Commonwealth

Osmosis Community

Proposal #548, to Allow Levana Contracts to be uploaded by a whitelisted address has seen strong opposition due to the fact that the initial contracts to be uploaded will not have their code visible prior to upload. The opposition stance is, that in order for validators and community members to ensure code is safe prior to upload (and can be publicly inspected) the code must be visible before being uploaded on chain. If code is not visible prior, it should not be approved by governance.

This has lead to discussion around the idea of making Osmosis a permissionless chain for contract/code uploads by teams. A stance which may be opposed by many due to Osmosis specifically positioning itself for contracts and applications with a focus or utility around DeFi to deploy on chain, not others. This can also ensure that products which launch on Osmosis are of sufficient quality.

Currently multiple teams can upload contracts to the Osmosis chain (some of specific nature) without further governance approval, if they are uploaded by a particular address which is whitelisted. The following proposals show the teams and addresses allowed to upload contracts:

Interchain Explorer by Cosmostation Mars

Interchain Explorer by Cosmostation Apollo DAO

Interchain Explorer by Cosmostation Kado

Interchain Explorer by Cosmostation TFM

Interchain Explorer by Cosmostation IBCX

Interchain Explorer by Cosmostation CronCat

Interchain Explorer by Cosmostation Calc Finance

Interchain Explorer by Cosmostation Squid

Interchain Explorer by Cosmostation Levana - (Subject to proposal passing)

Currently, these teams do not require any sort of publicly visible code as part of their agreement with the Osmosis community to be whitelisted for contract uploads (without needing to seek further approval).

This discussion around proposal #548, spearheaded by teams such as Notional DAO, has made us aware of the following inconsistency:

Validators and community members previously approving whitelisted addresses to upload contracts (without a formalised agreement on-chain for future contracts to be public visible), however not approving of proposal #548 on the basis of contract code not being visible before upload.

Therefore Stakecito would like to suggest possible remedies and also ignite discussion around whether or not the Osmosis community would like to see further stipulations for teams uploading contracts to Osmosis.

  1. Signalling proposal to require all teams whitelisted for contract uploads (without needed further approval from governance) to make code publicly visible X days prior to upload, with failure to do so resulting in revoked rights to upload code without governance approval.

  2. Or/And future governance proposals pertaining to contract uploads from external teams, with the stipulation that future uploads do not require approval from governance to have a further stipulation that contract uploads be made publicly visible X amount of days prior to upload.

Some Initial thoughts are that option 1 would be sufficient to apply to all past and future contract upload & address whitelisting proposals, formalising the need for code to be publicly visible prior to upload. However, there may be a better solution, or it may be that the Osmosis community does not feel the need to impose these rules on teams uploading code without future governance approval.

DISCUSS :slight_smile:

2

Please post responses on Commonwealth, since there are a couple of them there already until we fully migrate this topic.

3

Oh no no no no no no no I’m going to be that guy who just posts here instead because using Commonwealth is unpleasant like being microwaved.

1 Like
4

I was already afraid of this when I saw all the topics being copied from Commonwealth.

We need to choose where to have our discussions. Having the same one on 2 different platforms is counterproductive and goes against the fact that we are trying to achieve a platform where conversations are more or less centralized for everyone to see.

Also worth noting that there is a bunch of comments already on Commonwealth which are now lost, since no-one will open the link to Commonwealth and read it.

5

Suggest that you migrate the conversations you care about, the difference between Commonwealth and this forum for me is that I can participate now I know those comments might be really valuable to you but are they more valuable to you then the ability of the entire community to be able to participate in the governance deliberation process?

6

I already suggested a hard cut for the governance discussions a long time ago, to avoid exactly this scenario ^^

I am very much ok with a move to Discourse if that is better for everyone to participate. But I am against a greyish scenario where nobody exactly knows which is the location to go to.

7

Life is very gray

Embrace it

8

Life is only grey if we make it that way by not making choices. Fact ^^

9

Oh I disagree strongly, many many things about our lives are highly ambiguous .

In fact, the ambiguity around governance discussion forum, is really one of the milder forms of ambiguity that we may face in our lives.

10

Unless we choose to go for Discourse or for Commonwealth.
Then the ambiguity is gone, since we have a nice choice made ^^

11

Well I think that the choice is pretty obvious

1 Like
12

Looking at the sentiment, it might be indeed, totally agreed.

But then we must close Commonwealth asap to remove the grey area in which everyone loses clarity about whether placing a remark or delivering input makes sense, because it might or might not be read.

13

Transferred Comment
madcapslaugh
cosmos1r3

•

7/2/2023

Hi!. We had a detailed conversation on this subject here: Levana's Code - Osmosis Smart Contract TG - Google Docs

The request of the Levana Proposal Commonwealth is as follows:

Should Levana be able to run a mainnet test with a 10K ATOM capped liquidity pool.

This pool would enable an estimated 5-10 users to test the protocol via a beta on mainnet.

Levana would like to run this test on mainnet before the source code is published.

14

Transferred Comment
Notional
osmo1083s

•

7/2/2023

Hey Stakecito, Commonwealth worked for me today.

Simplifying the argument

I think that there’s no need for the x number of days requirement, and might try and simplify the argument here, which in my opinion boils down to:

  • Do we want to ensure that all code on Osmosis is auditable by the user community?

I am a soft yes here. I think that’s always desirable.

If the answer is “yes” then we can:

  • continue to approve addresses, with some kind of a diligence program (not my favored option)
  • revert to the former style that requires explicit approval for each contract (not my favored option)

If the answer is “no” then we can:

  • go permissionless as a community

upsides of permissionless contract uploads

  • these conversations would not be necessary
  • anyone is free to run any contract
  • contracts don’t need to be open source, which assuages commercial concerns for some

downsides of permissionless contract uploads

  • not every contract does desirable things
    • security
    • user harm
    • meshing with the direction of the chain that the osmosis community is attempting to achieve

When I spoke to Levana, they made it clear that commercial concerns, and the reality that burden of proof is on the accuser in copyright cases, was behind their decision to remain closed source for the time being. Contrary to popular belief, I’ve a lot of respect for this point of view and line of argument, except where it could involve Notional implicitly endorsing code that we cannot see.

what if

  • anyone can upload contracts at any time for any reason without permission
  • There’s a field in contract upload that links to the source code, to an exact commit hash
  • contracts cannot be executed until after a governance vote approving execution, and one of the things that ought to be checked by voters and validators is code that matches the contract

We would still be lacking a decent mechanism for upgrades to contracts over time, but I think that this scenario is likely better than a stick in the eye.

Here are some additional, perplexing facts:

  • I want the levana proposal to pass, and I think they are a good team.
  • I do not want to endorse levana’s code, I haven’t seen it and for all I know it will shoot your dog like an American cop.
  • The option of abstaining was suggested to me, but voting yes can seem like an endorsement of the code, and I can’t do that due to not having seen it?
  • The current setup could be seen as validators endorsing teams, but the fact is that those teams could do anything, or even lose the credentials to their upload wallet
    • Disaster could ensue if those credentials were used by an attacker
15

Transferred Comment
Leonoor’s Cryptoman
osmo14amd

•

7/2/2023

I am also torn here. Having the code open-source without anyone effectively checking it is just as effective as closed-source code at the point of launch (ofcourse open-source offers the possibility to audit also afterwards, but at the moment of launch if no-one checked closed or open does not actually matter).

So if we want to go to a scenario where contracts need to be checked, then we also need some kind of (formal) route who, how and when is checking the code.

Permissionless would not be my preference, since it gives an extra attack vector for Osmosis which is not desireable imo.

There is some magic in your suggestion. Having all upgrades going through governance would be a terrible experience in general. In the current setup we are permissioned permissionless for specific teams. Not so sure how to get better though while getting more secure in terms of contract uploads while still having flexibility in governance.

16

Transferred Comment
Johnny Wyles
osmo1

•

7/4/2023

I also don’t think requiring X days before the upload is feasible - many of these permissions are granted because the teams need access to patch any uncaught issues without a governance delay. I bumped into this issue when exploring a multi-sig to have permissions - any multi-sig would need points disclosing and then may exploit these before actioning the upload.

If contract execution is delayed then surely that’s the same as permissioned specific upload?

I think the fields in the upload is a good idea. We currently have a checksum field, a compiler field and a code source field, but I believe the last two are arbitrary.

The question “Do we want to ensure that all code on Osmosis is auditable by the user community?” really contains two significant issues that I believe have different paths to resolution:

Do we want to ensure that all code governing liquidity on Osmosis is secure from External manipulation?

By asking this, we are asking if it has bugs or exploits if it has been audited and thoroughly tested before deployment, and if a user can be sure that no other party can access their funds through abusing a loophole.

If the code isn’t public, then an exploit can be discovered through trial and error, but we are in the dark about how likely this is beyond relying on auditors’ reputations. With the current standard of teams given access, this is likely enough, but won’t be sustainable long term without moving to compulsory open source.

While this is important, 99% of users will not check the code. They are relying on someone else with knowledge or incentive to do that. That incentive is likely due diligence because they are entrusting the contract with their funds or attempting to exploit the contract to gain access.

We should revisit the bug bounty program to encourage white hat checks too. We could use a combination of Gitopia and DAODAO for this. Without this, open source is less impactful.

Do we want to ensure that all code governing liquidity on Osmosis is secure from Internal manipulation?

By asking this, we are asking if the code does what we are told it does; there are no hidden access points or manipulation of the liquidity through developer interaction.

In this case, I don’t think it matters whether or not the code is visible for this aspect since we are saying that a specific team is being trusted to upload new versions in the future. I.e. even if the current code is totally fine, with a permissionless system or these permissioned addresses, nothing stops a team from loading different code and migrating the contracts.

This introduces trust though and is where we are at now.

The most visible way I can think around this is similar to Jacob’s idea to confirm the checksum of a contract on chain against a checksum on a public GitHub repo and labeling apps as compliant with open source on frontends rather than just linking the GitHub, which may not be the same code. However, GitHub doesn’t have the checksum by default; someone needs to download and compile the code.

Both of these require open source, but I come down on the side that open source only matters for Osmosis if it secures significant funds long term. If it doesn’t secure notable funds but performs a task then it can be tested on interaction. Things like Kado’s contracts don’t hold anything so we shouldn’t need to see the code. Things like Mars or Calc hold funds within so need to be verified before significant funds are held within. Because Levana are doing a smaller rollout they fall in the first category until full rollout when they would be in the second.

17

Transferred Comment
Leonoor’s Cryptoman
osmo14amd

•

7/4/2023

Good points @Johnny Wyles !

To add:

  • external manipulation: very agreed on the bug bounty program. Having a decent pay for finding crucial bugs might cause people to report bugs instead of exploiting them.

  • internal manipulation: this will always revolve around trust anyway. Even with a checksum in place a team can upload a change to the contract to Github and the chain and make sure the right checksums are included. We will not work towards a system where this will require governance approval, since it is true indeed that projects need to be able to act fast if they apply a patch for a vulnerability and do not need to wait for the minimum 24hrs for a expedited proposal. So in all cases open source or not does not matter if the team involved decides they want to break trust, upload bad code and execute their bad plans. So I guess the main backstop we have here is to be careful on allowing who can upload so that we only allow teams to do so who we trust to stay on good faith.

18

Have locked all transferred threads and copied all comments over.
Everything over there now should either be duplicated, abandoned or already had chain voting (Which will be migrated via API in a few weeks)
Will be drafting a prop today to properly move us.

2 Likes