DeFi has been exceptionally hot in the last two years, and it can be said that smart contracts provide the most powerful support. However, behind the rapid development, endless security issues have been plaguing us, such as TheDAO attacks, PolyNetwork attacks and so on, which have largely limited the development of the whole industry as well. Of course, the factors of these security vulnerabilities are multi-faceted, and even in centralized fields, developers and business people can’t guarantee that the contracts are completely bug-free, let alone decentralized scenarios. In view of all the reasons, Etherpad has finally concluded a set of contract upgrade solutions, which we will analyze later.
Next, we will analyze it from the legal point of view.
In fact, in reality, the laws of each country are not set in stone. As the times change, new things appear, new perceptions are generally accepted, and old things should be washed, so the laws should be constantly improved to meet the requirements of the times and be embraced by the society. Of course, we also know that laws should not be changed overnight. Therefore, the law can also be further improved as long as it follows a certain charter under certain constraints and reaches a general consensus.
The code is the law, and since the law can be constantly improved under certain constraints, shouldn’t the contract also be allowed to be upgraded under certain constraints? The answer is yes. The key to “code is law” is not “contracts cannot be upgraded”, but “under what constraints can contracts be upgraded”.
Starcoion Contract Upgrade
Starcoin is an advocate of “code is law”. Starcoin has done a lot of exploration on contract upgrade.
Firstly, Starcoin’s account model is designed to support contract upgrades.
Secondly, Stdlib has a variety of built-in contract upgrade strategies (including those that prohibit upgrades) for users to choose freely.
Third, Stdlib includes a complete DAO on-chain governance function, which can be easily combined with contract upgrade policies to play a binding role.
Starcoin has flexible contract upgrade features and leaves the choice to the user. Here we go deeper into Starcoin’s design for contract upgrades.
A more advanced account model
While Starcoin and Ethereum both use the Account model for their accounts, Starcoin’s account model is more advanced and has very significant design differences.
●Starcoin has only one type of account, while Ethereum distinguishes between regular accounts and contract accounts.
●Starcoin’s data is decentralized and stored with clear ownership.
●Starcoin’s account distinguishes between data and code areas.
●Starcoin’s contracts are supported for upgrades, Ethereum’s contracts cannot be upgraded once they are deployed.
●There are of course many other differences, and we focus here on the differences in contract code storage, as shown in the following diagram.
1.Storage and query of Ethereum contract code
Ethereum’s contract code is stored by first calculating the hash of the code, and using the code hash (also known as code_hash in the figure) as a unique index to map to the real contract code by code_hash. So when loading the code, you need to use code_hash to find the code.
2.Storing and querying Starcoin contract code
Starcoin has a ModuleId data structure that stores the address and Identifier of the account (that is, the module name), and then does a hash calculation on the ModuleId (that is, the ModuleId hash in the figure) and uses it as a unique index to map to the real contract code. So when loading the code, you need to use ModuleId hash to find the code.
The above is an analysis of the contract code storage for Starcoin and Ethereum. So what kind of impact does it have on contract upgrades?
●Ethereum: If the contract is upgraded, it will cause the code_hash to change, and the old code_hash cannot be mapped to the updated code, which means that once the contract is deployed, no more updates can be made; so the Ethereum community usually deploys a new contract through the Proxy solution to achieve the “upgrade “upgrade” effect, rather than making changes to the old code.
●Starcoin: as long as the ModuleId is guaranteed to remain the same (i.e. address and module name Identifier remain the same), then the ModuleId hash will not change and the actual code can be updated.
The difference in code storage will eventually lead to different contract upgrade options, and Starcoin’s has better contract upgrade features.
Proxy contract upgrade scheme of Ethernet
The previous section introduces the contract code storage of Ethernet, and here is the principle of the Proxy Contract upgrade scheme of Ethernet.
The role of Proxy Contract can be simply understood as storing the code_hash of Real Contract. The old contract (the Before upgrading contract in the diagram) needs to be upgraded in two steps.
●Deploying a new contract (Latest real contract in the figure).
●Update the data of the Proxy Contract (which can be interpreted as setting the code_hash to the code_hash of the new contract), see the red part in the figure
Starcoin’s two-phase update
Unlike Ethernet’s Proxy contract upgrade solution, Starcoin is a true contract upgrade. To better enable contract upgrades, Starcoin supports multiple contract upgrade strategies, leaving the choice to the user.
●STRATEGY_ARBITRARY: random updates
●STRATEGY_TWO_PHASE: TwoPhaseUpgrade
●STRATEGY_NEW_MODULE: Only Module can be added, not modified.
●STRATEGY_FREEZE: Freeze, no update contract allowed
There are a few things that need to be noted here.
Starcoin’s contract update policy is account level. Once the user sets a policy, it will be applied to all contracts under the current account.
●Starcoin’s contract update policy is increasingly restrictive from ●STRATEGY_ARBITRARY to STRATEGY_FREEZE, from low to high. Only the lower strategy is allowed to be set to the higher strategy, not the other way around.
●The default contract upgrade policy is STRATEGY_ARBITRARY.
TwoPhaseUpgrade is a very interesting strategy in Starcoin’s upgrade protocol, and we focus on this strategy below, as shown in the figure.
The TwoPhaseUpgrade upgrade contract consists of the following steps.
First submit a transaction to update the plan (upgrade plan txn in the diagram)
After a certain number of blocks, submit a contract update transaction (code txn in the figure), and after the transaction is executed, the new contract code will overwrite the old one.
This type of contract upgrade includes two steps, so it is called “two-stage update”. Among them, the waiting block, which can be understood as a public announcement of the updated contract. It should be noted here that the contract upgrade method of TwoPhaseUpgrade is a common way of community governance, announcing the Roadmap, determining the update date, and finally replacing the old version with the new one.
DAO & TwoPhaseUpgrade
Starcoin offers four upgrade strategies, and the choice of which one to choose is in the hands of the contract owner. So, in what way does Starcoin constrain the contract owner to represent the will of the majority? The answer is DAO.
Starcoin has a complete on-chain governance DAO.
●Submitting a Proposal and entering the PENDING state.
●Waiting for a period of time for the community to learn about the Proposal, and then entering the ACTIVE state.
●A period of time from the time the Proposal becomes ACTIVE, which belongs to the community vote voting phase.
●When the vote reaches the threshold, the Proposal becomes AGREED state.
●The voted proposal enters the update queue and becomes queued in the QUEUE state.
●Finally, it enters the public phase, and the public period passes into the EXECTABLE state.
Starcoin is precisely through the voting, on-chain governance, to reach a general consensus. Starcoin encourages users to trust their contracts to DAOs.
Starcoin’s DAO and TwoPhaseUpgrade perfectly illustrate a fair and open community governance process. starcoin’s Stdlib also uses DAO + TwoPhaseUpgrade for governance, and the entire Stdlib upgrade process is shown in the diagram below.
