Smart contracts are self-executing programs that run on the Ethereum Virtual Machine (EVM). These programs are immutable by design, which means no update to the business logic after deployment. While this is good for user trust, decentralization, and security of smart contracts, it may be a drawback as vulnerabilities in smart contracts cannot be fixed after deployment.
Smart Contracts are upgraded for various reasons, which include:
- Fixing Bugs
- Fixing Security issues
- Adding new features to the Smart Contract
What is a Smart contract upgrade?
A smart contract upgrade is a process of updating the business logic of an already deployed smart contract while preserving the states (data) of the smart contract.
There are different ways of upgrading smart contracts, and we will talk about a few of them in this article.
- Contract Migration
- Data separation
- Proxy Pattern
- Diamond Pattern (EIP-2535)
Contract Migration
This is one of the oldest and crudest way of upgrading smart contracts, it is very tedious and expensive in terms of gas fees and may be impractical in large applications. It is implemented by deploying a new smart contract with the updated business logic, and then copying the states from the old smart contract to the new one, then changing the smart contract address to the new one in your DApp.
This method is used when the smart contract was developed without the intention to upgrade it.
Data separation
This method uses two smart contracts; one smart contract contains the business logic, and the other smart contract contains the contract's data, users interact directly with the logic contract, and the logic contract calls the data contract as the name implies all state variables are stored here.
Upgrades are done by changing ownership of the data contract to that of the new business logic contract and using the address of the new business contract in your DApp. This method is better than Contract Migration as it is cheaper, but you have to change the contract address with each upgrade you make which is not ideal as other software may depend on your Smart contract.
Proxy Pattern
This method makes use of an immutable proxy contract that stores the data and an upgradable logic contract, the user interacts directly with the immutable proxy contract, and this contract delegate calls the logic contract.
To upgrade in this pattern, you need to deploy a new logic contract, then update the address on the proxy contract to that of the new one, subsequent calls to the proxy contract will be implemented by the new logic contract.
Diamond Pattern (EIP-2535)
This method is an extension of the Proxy Pattern. This pattern uses a contract called the Diamond. The Diamond contract delegate call multiple logic contracts called facets. These facets execute the logic, and the diamond contract stores the state (data). The most important feature of the Diamond pattern is that it is not constrained by the 24kb maximum contract size in solidity, as larger contracts can be splited into smaller facets, also with this pattern you don't need to update the whole contract during upgrades, you only need to deal with the facet that contains that function or add a new facet.
In the Diamond pattern, upgrades are handled by a facet called the DiamondCutFacet with this facet, you can add, remove or replace functionalities. If this facet is removed the contract can't be upgraded anymore.
Conclusion
In this article we have talked about four popular methods of upgrading smart contracts, the Contract Migration pattern should only be used when you deployed the contract without intention of upgrading it, it is not advisable to use Separation of Logic method as it brings the inconvience of changing the contract address with each deployment the Proxy Pattern is currently the most used pattern so more people in the EVM community understands it, but the Diamond pattern is a game changer, it makes it possible for developers to exceed the 24kb size limit of smart contracts, so you smart contract can grow to any size.
Top comments (0)