Summary of Ethereum Upgradeable Smart Contract R&D — Part 1–2018

Jack Tanner
Indorse
Published in
7 min readMar 6, 2018

This article is a summary of research and development in the area of upgradeable Ethereum smart contracts. It is meant to be a convenient resource to centralise the research to date, and to continue this technical discussion. In addition, I have created a summary table of the pros and cons of different strategies that are being proposed. If you are working/watching this area of R&D please comment on this article as to your agreements, disagreements or opinions on this table and my descriptions of strategies.

Please see Summary of Ethereum Upgradeable Smart Contract R&D — Part 2–2020 for the latest updates on this R&D.

Other than my own contributions as part of the AvanceHub project several months ago, this article does not add new technical R&D. The ordering of the strategies in this articles should not be interpreted as their level of adoption or preference by myself or the developer community. As part of the indorse.io project, this article will begin our own formulation of an upgradeable strategy which we consider necessary.
Update June 2018: indorse.io has continued to research and deployed contracts that use the proxy contract pattern.

At the bottom can be found what I believe to be a comprehensive list of links of R&D to date.

100% Upgradeable Mechanisms

Creating a smart contract that can be completely replaced with new logic is possible just by using more smart contract infrastructure. There are two main streams of strategies: proxies and the separation of logic and data into different contracts. Separating logic and data in a contract can be done in two ways.

The fundamental problem that both methods solve is how to update a contract’s logic while still retaining access to a contract’s state.

I have given a brief summary of how these strategies work below but I recommend going to the latest resources at the bottom of this article to become intimately familiar with how they work (especially if you are just starting down the rabbit hole of upgradeable contracts).

Proxy Contracts

A proxy contract uses the delegatecall opcode to forward function calls to a target contract which can be updated. As delegatecall retains the state of the function call, the target contract’s logic can be updated and the state will remain in the proxy contract for the updated target contract’s logic to use. As with delegatecall, the msg.sender will remain that of the caller of the proxy contract.

Due to the recent Byzantine hard fork, which now gives access to the return size of a function call, this method can now be generic (compared to when it was first proposed by Nick Johnson). An example of a generic proxy contract can be seen in Daonomic’s resources which is also is a great article to read about this mechanism in more detail to get a simple overview.

Update June 2018: There are several ways to create an upgradeable contract using a proxy with delegate call. Zeppelin has a very good articles explaining the three patterns that they have researched and tested. The pattern that has been chosen for the ZeppelinOS smart contract system is called the Unstructured Storage pattern and has now gone through a full security audit by Nomic Labs. This audit identified one critical issue with the pattern which has now been fixed.

Separate Logic and Data Contracts

This involves separating the smart contract into a data contract which contains the data (variables, structures, mappings etc) with appropriate getters and setters, and a logic contract which contains all of the business logic of how to update this data. The logic contract updates the data through the setters and the data contract only allows the logic contract to call the setters. This allows the logic to be replaced while keeping the data in the same place, allowing for a fully upgradeable system.

The contract can be updated by pointing users to use the new logic contract (through a resolver such as ENS) and updating the data contract permissions to allow the new logic contract to be able to execute the setters.

Check out @Thomas Wiesner’s video to get a better understanding of this mechanism.

Separate Logic and Data Contracts with Data as Key-Value pairs

This strategy works with a similar principle to the one above, except that instead of using the final desired data structures that your contract would normally use (structs, mappings etc), all data is abstracted down and stored in primitive key-value pairs. A standard naming system along with the sha256 hash algorithm is used to find the values of data.

Check out David Rugendyke’s article to get a better understanding of this mechanism.

Partially Upgradeable Strategies

Creating a fully upgradeable contract sounds great but there is a large trust compromise required: the immutability of the contract. Using only partially upgradeable contract systems may make sense in many cases.

In this strategy, core features of your smart contract can be left as non-upgradable. Other components that may be less-integral or more complex (and hence have high probability of requiring upgrade) are implemented with an upgradeable strategy.

I have seen a few good examples of this but if you know of any more please let me know:

  • The Ethereum Name Service “ENS”: The core ENS contract is a very simple contract and cannot be changed. Domain registrars (eg for the“.eth” domain) however can be upgraded by administrators. The registrar for the “.eth” domain is a contract factory for Deed contracts which are created one per deed, so that if a new domain manager is used, it can be relinked with all previous deeds and their state without much hassle.
  • The 0xProject: The 603 line core DEX (Decentralized exchange) smart contract can be fully upgraded while the proxy contracts (one for each user) remain the same. The 0x “proxy” contract (not the same as the proxy strategy mentioned above) contains the user funds and settings. For this reason it requires more trust and is not an upgradeable part of the 0x contract system.

Other Challenges

  • In all cases, a governance tradeoff is made that compromises the immutability of a smart contract. A strong governance strategy is also needed as part of an upgradeable strategy.
  • Creating an opt-in upgradeable smart contract system is possible and valuable to users but adds complexity.
  • Changes to Solidity compilers may break compatibility between new and old contracts.
  • There are gas overheads to consider when formulating an upgradeable strategy.

Conclusion

No one strategy is perfect and selecting the right strategy depends on the smart contract system to be implemented. All strategies are complex and smart contract designers should be very comfortable with their chosen upgradeable strategy to avoid security vulnerabilities.

My opinions

  • To create an upgradeable smart contract, the proxy mechanism seems the best well rounded strategy because it allows programmers to separate the upgradeable mechanism from their contract design and this makes things much easier to reason with and use, and will create less errors (which is a principal reason why we need upgradeable contracts in the first place).
  • Update June 2018: The Unstructure Storage pattern that is in the final stages of being released as part of ZeppelinOS appears to be the most mature and tested pattern, and will likely be widely adopted.
  • The use of a hybrid partially upgradeable strategy where the simplest, core logic is immutable also a good idea to maintain strong trust with users.
  • Designing your non-upgradeable smart contract system first and then formulating an upgradeable strategy seems like a practical and ideal way to go about this.

Twitter: @theblockstalk

Indorse: indorse.io

Research References

General

Proxy Contracts

  1. 2018–10–30 Nick Mudge: ERC Transparent Contract Standard #1538
  2. 2018–05–11 Nomic Labs: ZeppelinOS Smart Contract Audit
  3. 2018–04–18 Zeppelin: Proxy Patterns
  4. 2018–04–13 Zeppelin: Upgradeability using Unstructured Storage
  5. 2018–02–22 Jorge Izquierdo: ERC DelegateProxy #897
  6. 2018–02–15 Daonomic: Upgradeable Ethereum Smart Contracts, Github Project
  7. 2018–01–11 Team B9lab: Upgradeable Github Project
  8. 2018–01–10 Manuel Araoz : Solidity-proxy Github Project
  9. 2017–06–02 @Ownage : Ether-routher Github Project
  10. 2017–05–24 Nick Johnson: Mad blockchain science: A 100% upgradeable contract, Gist File
  11. 2017–03–15 Jorge Izquierdo: Advanced Solidity code deployment techniques
  12. 2017–03–07 Manuel Araoz: Proxy Libraries in Solidity
  13. 2017–02–13 Jorge Izquierdo: Library Driven Development in Solidity
  14. 2017–01–21 Tjaden Hess: Upgradeable smart contracts
  15. 2016–06–16 @Martin Swende: Implicit method proxy

Separate Logic and Data Contracts

  1. 2017–12–09 @Thomas Wiesner: Upgrade Smart Contracts on Chain
  2. 2017–11–13 Jack Tanner: Upgradeable, Github Project
  3. 2017–08–21 Lukas K: Upgradable smart contracts. What we’ve learned building Insurance on a Blockchain
  4. 2016–08–16 @nikolai: Dapp-a-day 6: Upgradeable Tokens
  5. @monax: Solidity 1: The Five Types Model
  6. @monax: Solidity 7: Updating Solidity Contracts
  7. @Z.com Cloud Blockchain: Solution — Version Upgrade Issue

Separate Logic and Data Contracts with Data as Key-Value pairs

  1. 2018–01–20 Hassan Abdel-Rahman: Upgradable Contracts in Solidity
  2. 2017–11–22 David Rugendyke: Upgradable Solidity Contract Design, Github Project
  3. 2017–06–29 Chandan Gupta: Interfaces make your Solidity contracts upgradeable, Github Project
  4. 2016–06–08 Elena Dimitrova: Writing upgradable contracts in Solidity

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Published in Indorse

Indorse is an enterprise SaaS platform. Enterprise companies use the Indorse platform to build great tech teams, upskill their workforce, and enable innovation. Our all-in-one platform is focused on tech & coding skills and is based on a community of leading industry experts.

Written by Jack Tanner

Blockchain and self-sovereign identity software developer and educator! https://jackandtheblockstalk.com

Responses (12)

Write a response

Great article! As someone who has been surveying how projects implement contract upgrade and storage this serves as a great high-level overview. I particularly like that you delineate the old and new style Proxy contracts that use the Byzantium…

--

Great Article! <a href=”https://immunebytes.com/”> Smart Contract Audit</a> helps you find hidden exploits that might be present in the code. It would eventually reduce the risk and provide you an extra layer of security.

--