This article is a summary of various implementation strategies in the field of scalable smart contract development in Ethereum. The purpose is to summarize relevant resources to date to help us consider how to upgrade and update smart contracts when designing and developing them.
100% smart contract development and upgrade mechanism
There are currently two main strategies for implementing scalable smart contracts:
- Use proxy contracts
- Separate logic and data into separate contracts.
The fundamental problem to be solved by these two approaches is how to update the logic of the contract while still retaining access to the state of the contract.
Proxy smart contract
Proxy contracts use delegatecallopcodes to forward function calls to updatable target contracts. Since the delegatecall preserves the state of the function call, the logic of the target contract can be updated, and the state will be preserved in the delegate contract for use by the logic of the updated target contract. Like delegatecall, msg.sender will maintain the caller identity of the delegated contract.
Due to the recent Byzantine hard fork, it is now possible to get the return size of a function call, so this method is currently generic compared to the method first proposed by Nick Johnson. An example of a generic proxy contract can be seen in Daonomic's article where you can learn more about the mechanism.
Smart contract development separates logic and data
This method involves splitting the smart contract into two contracts:
- Data contracts that contain data (variables, structs, maps, etc.) and getters/setters
- A logic contract that contains the business logic of how to update this data
Logic contracts update data through setters, and data contracts only allow logic contracts to call setters. This allows the implementation logic to be replaced while keeping the data unchanged, enabling a fully scalable system.
Contract updates are achieved by directing the user to use the new logic contract (through a resolver such as ENS) and updating the permissions of the data contract to allow the new logic contract to execute the setter.
Check out Thomas Wiesne's video to better understand this mechanism.
Separating logic and data contracts using a key-value data model
This strategy works similarly to the above, except instead of using the final expected data structure (struct, mapping, etc.) to define the contract data model, all data is abstracted and stored in key-value pairs, then a standard naming system is used And the sha256 hashing algorithm is used to find the data value.
See David Rugendyke's article for a better understanding of this mechanism.
Some smart contract development strategies can be upgraded
Creating a fully upgradable contract sounds great, but requires a big compromise: guaranteeing the immutability of the contract. Therefore implementing partially upgradable contracts may be a more reasonable option in many cases.
In this strategy, the core functionality of the smart contract can remain non-upgradable. Other components that may be less complete or more complex are implemented with a scalable strategy.
There are already some good examples of this:
- Ethereum Name Service ENS: The ENS core contract is a very simple contract that cannot be changed. Domain registrars can be upgraded by administrators. The domain registrar is a contract factory, and if a new domain manager is used, it can be relinked with all the previous data states without too much trouble.
- 0xProject: 603DEX (Decentralized Exchange) core smart contracts can be fully upgraded, while proxy contracts (one per user) remain the same. The 0x "proxy" contract (unlike the proxy strategy described earlier) contains user funds and related settings. For this reason, it is not an upgradeable part of the 0x contract system.
other challenges
- In all cases, there is a trade-off between keeping the immutability of the smart contract.
- Creating an optional system of upgradable smart contracts is possible and valuable to users, but adds complexity.
- Changes to the Solidity compiler may break compatibility between old and new contracts.
- Gas overhead needs to be considered when developing a scalable strategy.
in conclusion
No strategy is perfect, and choosing the right strategy depends on the smart contract to be implemented. All strategies are very complex and smart contract designers should be very knowledgeable about the scalable strategies they choose to avoid security breaches.
- In order to create an upgradeable smart contract, the proxy mechanism seems to be the best overall strategy because it allows the programmer to separate the upgradeable mechanism from the contract design, which makes everything easier and produces fewer bugs , and errors are the main reason we need to upgrade the contract.
- In the case of the simplest core logic unchanged, adopting a partial upgrade strategy is also a good idea to maintain user trust.
- It is a practical and ideal way to design a non-upgradable smart contract system first, and then develop an upgradeable strategy.