[DED] Permissionless CosmWasm

Proposal Discussion
1

notice of abandonment

I think that it is highly unlikely that this proposal would pass so I don’t think there’s a lot of sense in putting it on the chain. I am very open to exploring this path in the future however, because it makes me profoundly uncomfortable to approve contract addresses instead of contracts, and to say yes to anything that is not open and fully auditable.

For the time being, notional will be voting no or veto on closed source contracts, to avoid even the slightest hint of endorsement of such practices.

In the case of open source contracts, since we are approving uploader addresses, we will make case by case decisions depending on team reputation and our impression of a brief review of the code. Our delegators can expect votes that range from yes to no on approve address proposals that are connected to a clear open source contract from a known developer.

restatement of reasoning

It is our belief that it is very important that we do not endorse work we cannot check. There are additional reasons for concern when it comes to contracts that are adding new logic to the chain, and we felt that making the chain permissionless was a better solution overall. Permissionlessness will not disrupt the excellent curated app store model.

thanks

I would like to thank, in no particular order, a number of individuals and teams who discussed this proposal with us:

I’m still of the opinion that this is a good path forward, but I don’t think that I’m even close to in the majority here, so rather than bother with the potentially contentious governance proposal, let us all continue on with the current system.

Context: today I met with a CosmWasm developer and he had a very serious lament about permissioned CosmWasm DX.

There you have it, the very first video governance proposal.

However, for those who like text:

Proposal Summary

  • The developer experience on Osmosis would be better if the CosmWasm was permissionless.
  • Changing to permissionless could possibly break osmosis, but that is relatively unlikely and being exposed to permissionless CosmWasm will harden both CosmWasm and Osmosis.
  • Permissionless does not prevent the curation of apps in the front end app store.
  • Permissionless will mean more good apps and more bad apps, so let’s highlight the good ones in the app store instead of getting hung up on the fact that the bad ones will exist.

Vote Options

YES - enable permissionless cosmwasm at the next release of osmosis, v19
NO - stay permissioned, change nothing
ABSTAIN - express no opinion, but be counted towards quorum
NOWITHVETO - vote no, and vote veto. If 1/3rd of votes are veto, this proposal automatically fails and the deposit is burned

1 Like
2

“could break Osmosis” seems like a poor trade off for getting apps that don’t want to go through the governance process.

This also removes any requirement for open sourcing which has been a major sticking point in getting contracts on chain in the past. What changed this viewpoint?

2 Likes
3

So, this has always been my POV:

  • if we are permissioned, then I won’t approve any contract upload containing closed code because that is an obvious quality standard.

  • If we are permissionless, then I as a validator don’t need to go and review every contract. Teams can truly do what they’d like to.

In the current state of affairs, I see it as a risk to vote on these contract approvals at this point:

  • though notional offers audit services, no, we don’t intend to do unpaid audits of every contract to hit the chain just because we can. But we will and do check. But we can miss stuff. We have missed stuff, like closed source contracts. Means we did not check well enough, usually because time is elsewhere.

  • Permissionless dones’t carry risk to validators

  • Permissioned carries risks to validators

  • Permissionles contract development is noticeably faster

There’s some risk of a chain halt or something. These things can be fixed.

Additionally, if we were permissionless, we wouldn’t make dumb assumptions like “we are safe cause permissioned”. The truth is we already don’t know, and if devs see this as friction, then it’s on us (the validators and user community) to clear the friction out of their way.

The permissioned wasm flow we have going here is basically a false sense of security

4

In essence the only thing we have right now with permissioned is that we control the addresses who upload contracts on chain. The content of the first contract is maybe open, but all contracts coming after that (even new ones, since we can’t block that) is a Pandora’s Box in potential.

So I do understand the reasoning of @faddat here to go permissionless, since the step from our current situation towards the proposed one is relatively small.

Are there any checks which can be included blocking state-breaking contracts like we saw on Juno? Or is CosmWasm already evolved far enough that the risks are manageable?

1 Like
5

First, can you please quantify the following claims.

I am particularly interested answers to the following questions:

  • what you mean by “break”

  • how unlikely Osmosis would “break” if it became permissionless.
    Are you putting the chances of Osmosis “breaking” if it moved to
    permssionless close to the odds of:
    - being robbed (~1 in 700) or your home catching on fire (~1 in
    850);
    - being struck by lighting (~1 in 15,300) or dying during a
    tonsillectomy (1 in 20,000)
    - a surfer getting attacked by a shark (~1 in 3,750,000),
    - winning the Powerball lottery (~1 in 292,200,000).

  • What are the economic costs of Osmosis “breaking”?
    - less than $1 million;
    - between $1-$10 milion;
    - more than $10 million?

  • How many “bad” apps will users have to “put up with” for every “good” app that is deployed?

    • 2:1?
    • 5:1?
    • 10:1?
    • 20:1?

Second, how many apps has Osmosis governance ultimately not allowed to be uploaded? What were these apps? Of the apps that governance did not allow to be deployed, was a similar app ultimately get deployed on Osmosis or on another chain (e.g. Juno, Archway, etc) which Osmosis users can easily access?

6

Hey thank you for this great reply.

Breaking stuff
1 in 100 let’s say, but could be higher than that even. And as for the economic cost, the most likely consequence of a “break” is a chain halt due to a malicious contract.

Let’s keep in mind that at minimum, 2 of the 19 Osmosis chain upgrades broke osmosis. Osmosis is resilient.

bad apps

10:1 or 20:1 – between the two I reckon

history of upload blockages

It happened once to my knowledge that @larry0x found a contract that did not match its hash. But that was when we were approving contracts.

These days, we approve contract upload addresses, and I think that everyone has been approved.

Market effect

I actually think it is a bit significant. It is quite time consuming to get a new contract uploaded to the chain as things stand today. Also, the current model doesn’t really enhance security.

I would not really look at this as competing with a generalized contract chain though – in fact I’m much more interested to see what people build in terms of things that can interact with Osmosis.

7

This proposal is going to go up today.

Update:

I do not think that Osmosis should follow US holidays, but no reason not to tip hat to Johnny.

8

Monday September 4th is not only Labor Day holiday in the US, but also Labor Day holiday in Canada, Palau, and Bermuda.

It is also a Vietnamese and Eswatni national holiday; National Day in Vietnam and Reed Dance Festival Day in Eswatni.

1 Like
9

Thanks for bringing up the discussion of whether or not Osmosis should change from Permissioned Cosmwasm to Permisionless Cosmwasm.

Currently Osmosis whitelists addresses to upload contracts to Osmosis without the need to submit a governance proposal for each upload. This means that teams, through an address whitelisted by Osmosis governance, can upload any contract to Osmosis permissionlessly.

This reduces the governance burden on Osmosis validators and community members so that they do not need to vote on each individual contract being uploaded or updated to the latest version (having a new version of the contract deployed. For validators this means making trust assumptions that the teams/parties who control the whitelisted address will act in the best interest of the Osmosis chain and deploy safe and trustworthy contracts.

Also, as mentioned by @faddat and Notional, both the teams who upload contracts and the validators who approve to whitelist addresses cannot ensure/guarantee that bugs do not exist on contracts that are uploaded. Code can be reviewed, however bugs can be missed and also contracts could be uploaded which are closed source.

The arguments are that , in this design, where addresses are whitelisted for contract uploads, similar risks are taken on by the Osmosis chain and by validators as those that would be taken on if the Osmosis chain had Permissionless Cosmwasm. An added risk to validators is that currently they must approve the upload of contracts by a whitelisted address, and in doing so endorse/signal approval for contracts that are uploaded and in the event that there is an issue with the contract, or that the address acts maliciously, the validators would be somewhat liable, even if just socially, for allowing that team to upload contracts, or for that particular contract to be uploaded.

In the case that Osmosis were to move to Permissionless Cosmwasm, this burden and potential liability for validators when ANY contract is uploaded would be removed. At the same time moving to permissionless would allow many more contracts to be deployed on Osmosis. Whilst some may be ‘junk’ or ‘spam’ or simply just take up space on the Osmosis chain, some permissionless deployments could be highly successful, with a positive impact to Osmosis, bringing users, liquidity, volume or culture to the Osmosis chain.

The crutch of the argument here, as I understand it is this:

A) Permissionless Cosmwasm opens Osmosis up to additional risks from contract deployments however these additional risks are not much greater than the existing risks taken on by the model of whitelisting addresses for contract deployment.

B) Whilst Permissionless Cosmwasm results in many more contracts being deployed many of which are scams, junk, rugpulls or otherwise, taking up execution space in blocks and adding to state, a few significant and impactful applications which see strong adoption will likely also be deployed on chain, and the benefits of having these positive deployments will outweigh the negatives of having a bunch of scam, rug, junk and spam contracts on the chain.

C) To point b, Permissionless Cosmwasm allows for permissionless deployment of contract and therefore of products/applications. This greatly improves the developer experience on Osmosis, specifically in that the barrier to deploying on Osmosis would be removed entirely, allowing developers to experiment with new products, apps and contracts on Osmosis.

So you may be reading and thinking hey Liam, so this means you are in favour of Permissionless Cosmwasm on Osmosis? However I am here to say that my perspective on Osmosis, Permissionless Cosmwasm, and on the current implementation of Permissioned Cosmwasm is slightly different.

Firstly, I want to say again that I think this is a great discussion to have and there are many benefits to opening up access to the Osmosis brand, users, liquidity, capital, security and block space to as many teams as possible. The more developments on Osmosis, the more the chances of a select number to evolve into power users of Osmosis block space, adding significant value to the network.

A challenge to having multiple applications , competing with one another, within the same execution environment (ie competing for the same block space) is the user experience. It is certain that the user experience would be impacted by a change to Permissionless Cosmwasm, but the question is by how much.

Let’s consider the objectives and goals of Osmosis. What is it trying to achieve? The way I understand Osmosis today is that it is trying to bring a suite of DeFi products to users, built around a decentralised exchange. The competition? Centralised Exchanges… we’re talking Binance, Huobi, Coinbase and so on.

So when we talk about a suite of financial or DeFi products, what were are really talking about is delivering a full exchange experience to users. Not just trading or swaps, but actually the full product suite. Lending, borrowing, a launchpad, deep liquidity, leverage, perps (futures) and so on and so forth. All of these products/apps are part of an ‘Exchange’ experience. So when we talk about Osmosis as a DeFi Hub, we are really talking about Osmosis as an Exchange.

Exchange Product
Exchange Product1920×1080 112 KB

What does it take to deliver an decentralised exchange product which rivals the experiences delivered to users by exchanges such as Binance or Coinbase? What levels of performance are required, and how can we ensure users can navigate the product suite with confidence and understanding?

It is my belief that by limiting the applications which are able to launch on Osmosis to applications which specifically are linked to the the running of and/or user interaction with the Osmosis exchange experience.

Yes apps/products can be curated from a perspective of the front end and the communications, marketing and support undertaken by the people employed by the Network to do so. This would not be affected in any major way by the implementation of Permissionless Cosmwasm on Osmosis, outside of the need to focus some resources more specifically on a curated set of dapps/products.

What I do believe will be impacted by Permissionless Cosmwasm, would be the performance, however small, of these curated applications which are the compenents of the Osmosis exchange experience and what have established the existing product market fit for Osmosis.

This degradation of performance, transaction times, gas fees, potential chain halts and the like will ultimately hinder the ability for Osmosis to provide an experience which outcompetes rivals such as binance, Huobi or Coinbase, who likely have dedicated servers for executing actions done by users on their exchanges. There are no transactions in competition with user transactions happening within their exchange products.

Whilst I am not an expert on the level at which the user experience is degraded by competing transactions, a slight delay for example in a users action being completed, such as implementing a stop loss, can have larger negative impacts on a users experience on a platform. Why would a user accept this degraded performance, when a better experience can be had on a competing product or service?

It is this thought process that currently leads me to believe that the best design for Osmosis, continues to be a Permissioned implementation of Cosmwasm, with a curated set of applications which work together cohesively, delivering the high quality Osmosis exchange experience to users.

Not to dive too deeply into the topic today in the comments on this proposal draft, but I do also believe that the idea of Permissionless Cosmwasm, does have a place within the Osmosis ecosystem and its this:

An Osmosis sister chain, a canary chain or sorts… lets call it ‘Osmosis Innovate’ for simplicity. This second Osmosis chain would act as the Permissionless Cosmwasm hub for Osmosis. Why? Because, as mentioned here by @faddat, there is a lot to be gained by opening up Osmosis to permissionless development. It improves the developer experience on Osmosis, it allows innovation and, for all of the bad applications deployed, many can still be impactful and power users of Osmosis block space and security. An ‘Osmosis innovate’ chain can be compared to what Binance smart chain is to Binance exchange.

I do not think this discussion needs to be had today, however when the time is right and the exchange product and chain is well established and competing with the centralised exchange experience, I think it would then be time to launch the second chain, and open up the Osmosis brand and the liquidity, capital and users supporting that brand to a wider range of teams, products and applications resulting in a great expansion of the Osmosis ecosystem

Edit: Image of the dual chain concept:

Untitled 2
Untitled 21920×1080 173 KB

4 Likes
10

This concept is more elegant and quite frankly better.

I may table the proposal because of this

1 Like
11

How do we go about working towards the concept? Would love to help move in the direction, or at least start some serious discussion around this as an alternative to Permissionless CW on the main chain

12

Possibly we begin playing with mesh.

Another issue is maybe reforming the “approve contract upload address” mechanism. So in the beginning we could actually check the code on contracts, but few checked and imo only one checked well – @larry0x.

I think that is better than what we have today.

Another option might be to forge a deeper partnership with neutron, which could include “mesh stuff”.

I checked in on Juno today and I’ve no idea how that is going to be a viable path forward in terms of a partner chain for the development and deployment for mesh.

I’d love to be proven wrong, of course.

13

Many many many thanks for these elaborate thoughts @L1am-Stakecito
Good to see that you’ve taken your time to put the thoughts very clearly on paper.

Regarding the path forwards, there are simple and hard ways to do this.
One possible option would be imo (taking an Agile-ish approach) to just start a 2nd Osmosis chain which has permissionless CosmWasm and can serve as the testing/breeding grounds. Maybe with a limited version of the Osmosis experience or a capped exposure to the real elements making up the Osmosis-space.

Let this second chain work with OSMO as well.

Promising contracts who have proven itself can be ported / uploaded to the master-chain to get it working for the larger public?

1 Like
14

Serious question: why do we need other chain so Osmosis can have permissionless smart contracts?

I think we have a lot of chains with no real purpose right now in Cosmos and adding a new one will only fragment the liquidity more.

Also, one of the advantages of permissionless should be to facilitate the deployment process to builders/developers, we will be doing the opposite with other chain and a migration process.

We have three main permissionless blockchains in Cosmos: Juno, Archway and Neutron and security doesnt look like a risk. Why can’t Osmosis simply replicate the idea and avoid boilerplate code with other new chain?

1 Like
15

Risk does tend to go where liquidity and volume is.

And there is still a lot available on Osmosis (although it has been dwindling sadly). So risk is also unmistakingly related with the fact that liquidity on JUNO is not that spectacular. Can’t talk about Neutron / Archway tbh since I don’t have the numbers there.

Main advantage from having a copy of the Osmosis chain, is that the codebase is 1:1 and therefore you can predict behaviour better than with JUNO or another chain, since their codebase can be different and can therefore also trigger other effects (imo)

1 Like
16

We don’t. I think that I’d misinterperted some of the team and community’s ideas.

Hence, once that was apparent, I simply labeled this proposal [DED] and marked it as abandoned.