Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Upgradeable Smart Contracts #22
Aside from solving performance issues, GoChain also has a goal of fixing another huge problem with Ethereum and that is theft prevention. Theft on Ethereum is almost always related to bugs in smart contract code (besides gaining someone’s private key via social engineering, SMS hijacking, etc). $100’s of millions (if not billions) have been stolen in the past couple of years due to bugs in smart contracts.
One way to reduce the chance of theft by bugs is the ability to pause a contract (stop the theft) and upgrade it (fix the bug that makes the theft possible). This proposal is to enable both of those features. A nice side effect of this is that contracts can be upgraded for other reasons too, such as adding new functionality to a DApp or amending a contract which reflects real-life contracts.
Pausing a contract
The first step would typically be to pause a contract to stop someone from taking advantage of a known bug. Since this one doesn't change the contract or the data, the owner could pause a contract without the knowledge of other involved parties and this would not break trust. Also, this has to be able to happen immediately so letting a single entity be able to do this is a must.
Who can upgrade a contract?
One of the main selling points about smart contracts is that they are immutable and therefore you create a level of trust between different parties that may otherwise not trust each other. If one party can change the contract, you lose the trust. So how can we continue to have trust between parties while still allowing a contract to be upgraded? Upgrading the contract itself isn't the hard part, having a system that retains trust while allowing upgrades is the hard part.
The default upgradeability will remain the same as it is now, which means nobody can upgrade it. To enable an upgradeable contract, it must be set during the deployment of the contract.
The owner (the deployer) would set upgradeability rules on the contract during deployment which defines how a contract could be upgraded. Some example rules:
These rules would be visible to all, so a user can decide whether to interact with the contract or not. If they know the upgrade rules, they can make an informed decision.
How it would work technically
Interacting with a smart contract requires the contract address. The contract state is also stored in the Merkle Patricia Trie under that same address. One requirement is that the address stays the same so people can continue to use the same address after the upgrade.
The owner would call
In order to use the same address with new code, we could do one of the following (after it's been voted in):
Once deployed, the contract becomes active again (unpaused).