Add docs for non-upgradable contracts

Start by locating the existing Soroban documentation about contract upgrades and review the two linked resources for context. Document how developers can disable upgradeability, including a practical example if the existing documentation supports one. Done when users can find and follow the guidance for deploying a non-upgradable contract.

This has been requested by a few parties in the ecosystem. For Dev Survey

If I could change one thing about Soroban it would be this.

All contracts in Soroban are upgradeable by default. This enables developers to update their code at any point. I think this was implemented to enable upgradeable contract functionality as standard without the need for proxies which are widely used in other platforms.

When I write smart contract code it is always for one of two reasons:

I’m writing a contract that is just going to be run by myself. I can use ownable libraries to ensure no one else can run it and proxies to enable me to upgrade it at a later date. This would be akin to a script run locally which might be doing something like trading or automating a DeFi strategy. There is absolutely no problem with having these contracts upgradeable because they are fully centralized around myself as the developer anyway.
I’m writing a contract that is going to be run by anyone and everyone. For this we should strive to make the contracts permissionless so that all users including the original developer have equal permissions and code is law. An example would be a fair launch token contract where the initial balance is minted and put on a DEX when deployed and then everyone has the same rights within that contract. The developer should not be able to mint new tokens or change the logic within that code, he/she should have the same access as everyone else.

The reason I am obsessed with blockchain technology is because it gives me the ability to deploy immutable permissionless code on censorship resistant decentralized peer to peer networks. There is something elegantly beautiful and pure about this, even if we do use it to create memecoins.

There are no permissionless contracts on Soroban!

Apparently there is a way you can add something to the code to disable the upgrade functionality but I’ve seen no documentation of this or examples of it being used in practice. Every single contract deployed on Soroban has a single point of failure. The private keys used to deploy the contract can be used at any time to “upgrade” the logic within that contract.

If a lending platform holds pools of assets a developer could at any time upgrade the contract to inject a backdoor allowing them to steal all the assets.

Developers, as well meaning as we are, should not be trusted as default. We saw a very sophisticated attack on Radiant capital where hackers were able to compromise an outgoing transaction from the developers device. If Soroban is successful and ends up having billions of dollars in TVL then the Lazarus group will have an absolute field day compromising dev wallets and upgrading contracts for fun and profit.

I believe proxy contracts are over-used on Ethereum where they maybe make up 5-10% of all deployed contracts (you can tell in etherscan if a contract uses a upgradeable proxy pattern). Having 100% of contracts upgradeable is a disaster waiting to happen.

It also opens the platform up to criticism. If someone is on a public panel debating “Stellar vs Solana” and Anatoly fires off “why are all contracts on Stellar centralized?” how do we justify or explain that?

It is going to be difficult for Soroban to compete with Ethereum, Solana and other emerging decentralized computing platforms over the next decade. It is impossible and pointless to build permissioned systems to compete with AWS and Gcloud.

The whole point of web3 is that we can build trustless code and upgradeable contracts are not trustless or permissionless. They are useful for certain things but should not be default or a feature of the Soroban platform.

There are a couple of resources here which I think would be very valuable:

https://www.youtube.com/watch?v=2XlYSmIlpfs

https://diligence.consensys.io/blog/2019/01/upgradeability-is-a-bug/