The Case for Small Contracts
Requirements change. Needs expand. Bugs are found. Better ways to do things are identified. Security is breached.
What do we do? We change the code.
Blockchain smart contracts present a problem. Once deployed, the code can no longer be changed. So what happens when we find a bug after people are using the contract in production?
The whole idea behind blockchain is decentralization, so once you have deployed a contract, you can’t know who is using it and update them with a new contract address to which to switch. That rules out fixing the bug and redeploying the contract as a serious solution. (This is because the newly deployed contract will have a new address, and the old contract will still live at the old address.)
A different idea is to break up big contracts into many small contracts and have the top level contract point to them. (You’d also include methods to change all of the pointers.)
This is essentially object oriented programming (OOP).
In OOP, you want to be able to send messages to objects to trigger some kind of behavior without caring what the underlying implementation details are. To this end, if you have many small contracts that implement features, you could deploy an update to the implementation of a specific function on one of them, and then you could update the top level contract to point to the newly deployed version.
A limitation of this strategy is that the public API of all of the underlying contracts cannot be edited. It can be extended, but method names and signatures already in use must remain the same. However, the code inside those methods can change, and that is what we care about.
In reality, this creates a very similar situation to running a large scale public API on the web. Changing the web endpoints for a public API is very difficult because you will break applications that communicate with your API. If you rule out breaking client applications as an option, you could say that changing those sorts of things is impossible. However, you are free to change the underlying implementation.
Considering this, I would argue that the strategy I outline is a viable and reasonable approach to changing code over time on the blockchain.
In future articles, I’ll dig into specific examples.