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.
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:
