Ethereum Smart Contract Upgrade Strategy-Authoritative guide

This is a creation in Article, where the information may have evolved or changed. This article is a summary of the various implementation strategies in the realm of upgradeable smart contracts in Ethereum to summarize the resources so far to help us consider how to upgrade and update them when designing smart contracts. # 100% upgradeable mechanism There are currently two main strategies for implementing upgradeable Smart contracts:-Using proxy contracts-separating logic and data into different contracts. The fundamental problem for both approaches is how to update the logic of the contract while still retaining access to the contract status. # # Proxy contract proxy contracts use the ' delegatecall ' opcode to forward function calls to updatable target contracts. Because Delegatecall retains the state of the function call, the logic of the target contract can be updated, and the state will remain in the proxy contract for the logical use of the updated target contract. As with Delegatecall, Msg.sender will maintain the identity of the caller of the proxy contract. Because of the recent Byzantine hard fork, it is now possible to get the return size of a function call, so this method can be used in comparison with the method first proposed by Nick Johnson (https://medium.com/@weka). In [Daonomic] (https://medium.com/@daonomic) article you can see an example of a generic proxy contract, you can learn more about this mechanism. # # Separation Logic and data contracts this approach to splitting a smart contract into two contracts:-Containing data (variables, structures, mappings, and so on) and getter/setter data contracts-logical contract logic contracts that contain the business logic to update the data, update the data by setter, The data contract only allows the setter to be invoked by the logical contract. This allows the implementation logic to be replaced while keeping the data intact, thus enabling a fully upgradeable system. Contract updates can be implemented by directing users to new logical contracts (through parsers such as ENS) and by updating the permissions of the data contract to allow the new logical contract to execute the setter. View the video of [@Thomas Wiesner] (https://github.com/tomw1808) for a better understanding of this mechanism. # # using key values to separate logical and data contracts from the data model This strategy works like this, except that the contract data model is defined by not using the final expected data structure (struct,mapping, etc.), all of which are abstracted and stored in key-value pairs. Then use a standard naming system and the SHA256 hashing algorithm to find the data values. You can review the articles of [David Rugendyke] (https://medium.com/@darcius) to better understand thisMechanism. # # Partial upgradeable policy creating a fully upgradeable contract sounds good, but requires a big compromise: guarantee the immutability of the contract. Therefore, in many cases, implementing a partially upgradeable contract may be a more reasonable option. In this strategy, the core functionality of the smart contract can be reserved as non-upgradeable. Other components that may be less complete or more complex are implemented with an upgradeable strategy. There have been some good examples of this:-Ethereum name Service [ENS] (https://github.com/ethereum/ens): Ens core contract is a very simple contract that cannot be changed. The domain registrar can be upgraded by an administrator. A domain name registrar is a contract factory, and if you use a new domain manager, it can relink with all previous data states without too much hassle. -[0xProject] (https://0xproject.com/): 603DEX (de-centralized exchange) core smart contracts can be fully upgraded, while the agent contract (one per user) remains the same. The 0x "proxy" contract (unlike the agent policy 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, it is necessary to choose whether to maintain the invariant of the smart contract. -Creating an optional upgradeable smart contract system is both possible and valuable for users, but adds complexity. -Changes to the solidity compiler may break compatibility between the old and new contracts. -You need to consider gas overhead when developing an upgradeable strategy. # # Conclusion None of the strategies is perfect, and choosing the right strategy depends on the smart contract to be implemented. All policies are complex, and smart contract designers should be well aware of the upgradeable policies they choose to avoid security vulnerabilities. -In order to create an upgradeable smart contract, the proxy mechanism seems to be the best overall strategy because it allows programmers to differentiate the upgradeable mechanism from the contract design, which makes everything easier and produces fewer errors, and the error is the main reason why we need to upgrade the contract. -With the simplest core logic unchanged, adopting a partial upgrade strategy is also a good idea to keep the user trusting. -It is a practical and ideal way to first design a non-upgradeable, intelligent contract system and then develop an upgradeable strategy. # # Reference Resources __ Ideas and viewpoints __-2018-02-01 Zeppelin Solution: [Evolution of Zeppelin and intelligent Contract Development] (https://epicenter.tv/episode/220/)-2016-2017: [ Stackexchange questions and answers about upgradeable smart Contracts] (Https://ethereum.stackexchange.com/questions/2404/upgradeable-smart-contracts)-Consensys: [Ethereum Smart Contract Best Practices] (https://consensys.github.io/ smart-contract-best-practices/general_philosophy/)-Evoluchain: [Evoluchain] (https://consensys.github.io/ smart-contract-best-practices/general_philosophy/) __ Agent contract __-2018-02-22 Jorge Izquierdo: [ERC delegateproxy #897] ( https://github.com/ethereum/EIPs/pull/897)-2018-02-15 Economics: [Upgradeable Ethereum Smart Contract] (https://medium.com/@daonomic/ UPGRADEABLE-ETHEREUM-SMART-CONTRACTS-D036CB373D6), [GitHub Project] (https://github.com/0v1se/contracts-upgradeable)- 2018-01-11 B9lab Team: [Upgradable-github Project] (https://github.com/b9lab/upgradeable)-2018-01-10 Manuel araoz: [ Olidity-proxy-github Project] (https://github.com/maraoz/solidity-proxy/)-2017-06-02 @Ownage: [Ether-routher-github Project] ( Https://github.com/ownage-ltd/ether-router)-2017-05-24 Nick Johnson: [Crazy Blockchain Science: 100% upgradeable contracts] (https://www.reddit.com /r/ethereum/comments/4kt1zp/mad_blockchain_science_a_100_upgradeable_contract/), [Gist File] (https://gist.github. com/arachnid/4ca9da48d51e23e5cfe0f0e14dd6318f)-2017-03-15 Jorge Izquierdo: [Solidity code Deployment Advanced technology] (https:// blog.aragon.one/advanced-solidity-code-deployment-techniques-dc032665f434)-2017-03-07 Manuel Araoz: [ Agent library in solidity] (HTTPS://BLOG.ZEPPELIN.SOLUTIONS/PROXY-LIBRARIES-IN-SOLIDITY-79FBE4B970FD)-2017-02-13 Jorge Izquierdo: [Development of solidity library-driven] (https://blog.aragon.one/library-driven-development-in-solidity-2bebcaf88736)- 2017-01-21 Tjaden Hess: [Upgradeable Smart Contract] (https://ethereum.stackexchange.com/questions/2404/upgradeable-smart-contracts) -2016-06-16 @Martin Swende: [Implicit method Agent Tip] (http://martin.swende.se/blog/EVM-Assembly-trick.html) __ separating logic and data contracts __- 2017-12-09 @Thomas Wiesner: [Upgrade chain Smart Contract] (https://vomtom.at/upgrade-smart-contracts-on-chain/)-2017-11-13 Jacktana: [ Upgradeable Smart Contract] (Https://docs.google.com/presentation/d/1veuPxAQD88z5holb-6SjWLhyDABuzNeVPZpZvzemJ3A), [GitHub Project] ( https://github.com/AvanceHub/upgradable)-2017-08-21 Lukas K: [Upgradeable Smart Contract] (https://medium.com/aigang-network/ Upgradable-smart-contracts-what-weve-learned-at-aigang-b181d3d4b668). We have learned to establish insurance on blockchain-2016-08-16 @nikolai: [dapp-a-day 6: Upgradeable pass contract] (https://steemit.com/ethereum/@nikolai/ Dapp-a-day-6-upgradeable-tokens)-@monax: [solidity 1:solidity five contract models] (https://monax.io/docs/solidity/solidity_1_ the_five_types_model/)-@monax: [Solidity 7: Update solidity contract] (https://monax.io/docs/solidity/solidity_7_updating_ solidity_contracts/)-@z.com-cloud-blockchain: [Contract Version upgrade solution] (https://guide.blockchain.z.com/en/docs/problem/ versionup/solution/) __ Use key values to separate logical and data contracts from the data model __-2018-01-20 Hassan abdel-rahman: [Solidity upgradeable contract] (https://medium.com/ cardstack/upgradable-contracts-in-solidity-d5af87f0f913)-2017-11-22 David Rugendyke: [Upgradeable solidity contract design] (https:// MEDIUM.COM/ROCKET-POOL/UPGRADABLE-SOLIDITY-CONTRACT-DESIGN-54789205276D), [GitHub Project] (https://github.com/ Rocket-pool/rocketpool/blob/master/contracts/rocketupgrade.sol)-2017-06-29 Chandan Gupta: [Solidity upgradeable contract Interface Design] ( https://medium.com/@nrchandan/INTERFACES-MAKE-YOUR-SOLIDITY-CONTRACTS-UPGRADEABLE-74CD1646a717), [GitHub Project] (https://github.com/nrchandan/lms)-2016-06-08 Elena Dimitrova: [Writing upgradeable contracts in solidity] (https:// BLOG.COLONY.IO/WRITING-UPGRADEABLE-CONTRACTS-IN-SOLIDITY-6743F0EECC88) [Original link] (https://blog.indorse.io/ ethereum-upgradeable-smart-contract-strategies-456350d0557c) > If you want to start learning Ethereum dapp development immediately, you can access the excellent online interactive tutorials provided by the wisdom network:> >-[Ethereum Dapp Practical Development] (http://xc.hubwiz.com/course/5a952991adb3847553d205d1?affid=go7878) >-[go to Central e-commerce Dapp Combat Development] ( http://xc.hubwiz.com/course/5abbb7acc02e6b6a59171dd6?affid=go7878) 589 reads  ∙  1 likes