Hey, fam 👋🏻
Welcome to another quick post on this classic dilemma around Upgradeable Smart Contracts:
🔴 Should we even consider upgradeable smart contracts?
🔴 Isn’t it safer to keep smart contracts as simple as possible? Additional complexity means more bugs, right?
🔴 But, how can we securely develop upgradeable smart contracts? What if we run into issues like storage collisions or inadequate upgrades?
🔴 Even if we develop, how should we upgrade them securely?
And such questions or confusion is what keeps us from choosing upgradeable features for our smart contracts.
I was in a similar discussion a few days ago and therefore wrote this quick post to eliminate some of these dilemmas around the upgradeable smart contracts.
🤔 Dev 1 who wanted to start developing his smart contracts was quite confused about whether or not he should make it upgradeable.
He believed his smart contracts might need additional functionalities in the future which is why upgradable contracts are perhaps the right choice.
However, he wasn’t sure if he should proceed with it, given the complexity of dealing with Upgradeable contracts.
👨💻Dev 2: 𝘜𝘱𝘨𝘳𝘢𝘥𝘦𝘢𝘣𝘭𝘦 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵𝘴 𝘢𝘳𝘦𝘯’𝘵 𝘳𝘦𝘢𝘭𝘭𝘺 𝘢 𝘴𝘢𝘧𝘦 𝘪𝘥𝘦𝘢 𝘢𝘴 𝘵𝘩𝘦𝘺 𝘮𝘪𝘨𝘩𝘵 𝘪𝘯𝘵𝘳𝘰𝘥𝘶𝘤𝘦 𝘢𝘥𝘥𝘪𝘵𝘪𝘰𝘯𝘢𝘭 𝘤𝘰𝘮𝘱𝘭𝘦𝘹𝘪𝘵𝘺 𝘵𝘰 𝘺𝘰𝘶𝘳 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵𝘴 𝘢𝘯𝘥 𝘮𝘪𝘨𝘩𝘵 𝘦𝘯𝘥 𝘶𝘱 𝘪𝘯𝘵𝘳𝘰𝘥𝘶𝘤𝘪𝘯𝘨 𝘩𝘪𝘨𝘩-𝘴𝘦𝘷𝘦𝘳𝘪𝘵𝘺 𝘣𝘶𝘨𝘴.
𝘩𝘦𝘳𝘦 𝘤𝘰𝘶𝘭𝘥 𝘣𝘦 𝘢 𝘣𝘶𝘨 𝘵𝘩𝘢𝘵 𝘭𝘦𝘢𝘥𝘴 𝘵𝘰 𝘴𝘵𝘰𝘳𝘢𝘨𝘦 𝘤𝘰𝘭𝘭𝘪𝘴𝘪𝘰𝘯𝘴 𝘰𝘳 𝘢𝘯 𝘪𝘯𝘢𝘥𝘦𝘲𝘶𝘢𝘵𝘦 𝘢𝘶𝘵𝘩𝘦𝘯𝘵𝘪𝘤𝘢𝘵𝘪𝘰𝘯 𝘱𝘳𝘰𝘤𝘦𝘥𝘶𝘳𝘦 𝘵𝘩𝘢𝘵 𝘢𝘭𝘭𝘰𝘸𝘴 𝘢𝘯𝘺𝘰𝘯𝘦 𝘵𝘰 𝘶𝘱𝘨𝘳𝘢𝘥𝘦, 𝘸𝘩𝘪𝘤𝘩 𝘱𝘶𝘵𝘴 𝘺𝘰𝘶𝘳 𝘢𝘴𝘴𝘦𝘵𝘴 𝘢𝘵 𝘳𝘪𝘴𝘬.
👩💻Dev 3: 𝘐𝘧 𝘺𝘰𝘶 𝘢𝘳𝘦𝘯’𝘵 𝘴𝘶𝘳𝘦 𝘢𝘣𝘰𝘶𝘵 𝘢𝘭𝘭 𝘺𝘰𝘶𝘳 𝘴𝘮𝘢𝘳𝘵 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯𝘴 𝘢𝘯𝘥 𝘵𝘩𝘦𝘳𝘦 𝘢𝘳𝘦 𝘤𝘩𝘢𝘯𝘤𝘦𝘴 𝘵𝘩𝘢𝘵 𝘯𝘦𝘸 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯𝘢𝘭𝘪𝘵𝘪𝘦𝘴 𝘮𝘪𝘨𝘩𝘵 𝘤𝘰𝘮𝘦 𝘪𝘯, 𝘜𝘱𝘨𝘳𝘢𝘥𝘦𝘢𝘣𝘭𝘦 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵𝘴 𝘢𝘳𝘦 𝘵𝘩𝘦 𝘳𝘪𝘨𝘩𝘵 𝘤𝘩𝘰𝘪𝘤𝘦.
𝘜𝘱𝘨𝘳𝘢𝘥𝘦𝘢𝘣𝘭𝘦 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵𝘴 𝘥𝘰 𝘩𝘦𝘭𝘱 𝘺𝘰𝘶 𝘧𝘪𝘹 𝘢𝘯𝘺 𝘣𝘶𝘨𝘴 𝘪𝘯 𝘴𝘮𝘢𝘳𝘵 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵𝘴 𝘸𝘩𝘪𝘤𝘩 𝘤𝘢𝘯’𝘵 𝘣𝘦 𝘰𝘷𝘦𝘳𝘭𝘰𝘰𝘬𝘦𝘥.
𝘈𝘥𝘥𝘪𝘵𝘪𝘰𝘯𝘢𝘭𝘭𝘺, 𝘪𝘵 𝘪𝘴𝘯’𝘵 𝘳𝘦𝘢𝘭𝘭𝘺 𝘵𝘩𝘢𝘵 𝘩𝘢𝘳𝘥 𝘵𝘰 𝘥𝘦𝘷𝘦𝘭𝘰𝘱 𝘶𝘱𝘨𝘳𝘢𝘥𝘦𝘢𝘣𝘭𝘦 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵𝘴, 𝘯𝘰𝘸 𝘵𝘩𝘢𝘵 𝘸𝘦 𝘩𝘢𝘷𝘦 𝘴𝘰𝘮𝘦 𝘳𝘦𝘢𝘭𝘭𝘺 𝘦𝘧𝘧𝘦𝘤𝘵𝘪𝘷𝘦 𝘭𝘪𝘣𝘳𝘢𝘳𝘪𝘦𝘴 𝘢𝘯𝘥 𝘵𝘰𝘰𝘭𝘴 𝘸𝘩𝘪𝘤𝘩 𝘦𝘯𝘴𝘶𝘳𝘦𝘴 𝘵𝘩𝘢𝘵 𝘪𝘴𝘴𝘶𝘦𝘴 𝘭𝘪𝘬𝘦 𝘴𝘵𝘰𝘳𝘢𝘨𝘦 𝘤𝘰𝘭𝘭𝘪𝘴𝘪𝘰𝘯𝘴, 𝘶𝘯𝘴𝘢𝘧𝘦 𝘶𝘱𝘨𝘳𝘢𝘥𝘦𝘴 𝘦𝘵𝘤 𝘢𝘳𝘦 𝘵𝘢𝘬𝘦𝘯 𝘤𝘢𝘳𝘦 𝘰𝘧.
⏩ It has been a well-known theory in the Smart Contract world that 𝙊𝙣𝙚 𝙨𝙝𝙤𝙪𝙡𝙙 𝙠𝙚𝙚𝙥 𝙩𝙝𝙚𝙞𝙧 𝙨𝙢𝙖𝙧𝙩 𝙘𝙤𝙣𝙩𝙧𝙖𝙘𝙩 𝙖𝙨 𝙨𝙞𝙢𝙥𝙡𝙚 𝙖𝙨 𝙥𝙤𝙨𝙨𝙞𝙗𝙡𝙚 𝙖𝙨 𝙖𝙙𝙙𝙞𝙣𝙜 𝙘𝙤𝙢𝙥𝙡𝙚𝙭𝙞𝙩𝙮 𝙢𝙞𝙜𝙝𝙩 𝙞𝙣𝙩𝙧𝙤𝙙𝙪𝙘𝙚 𝙣𝙚𝙬 𝙗𝙪𝙜𝙨.
And it’s quite true, to some extent, as we don’t really need to reinvent the wheel every time, and the security of smart contracts should always be a top priority.
⏩ However, smart contracts, despite their incredible powers of handling money or being immutable, are pieces of code too. And having some bugs in the code is inevitable.
As of now, 𝗨𝗽𝗴𝗿𝗮𝗱𝗲𝗮𝗯𝗹𝗲 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁𝘀 𝗮𝗿𝗲 𝗼𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗲𝗳𝗳𝗲𝗰𝘁𝗶𝘃𝗲 𝘁𝗼𝗼𝗹𝘀 𝘄𝗲 𝗵𝗮𝘃𝗲 𝗶𝗻 𝗵𝗮𝗻𝗱 𝗿𝗶𝗴𝗵𝘁 𝗻𝗼𝘄 𝘁𝗼 𝗿𝗲𝘀𝗼𝗹𝘃𝗲 𝘁𝗵𝗲𝘀𝗲 𝗯𝘂𝗴𝘀 𝗲𝘃𝗲𝗻 𝗶𝗳 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁𝘀 𝗮𝗿𝗲 𝗱𝗲𝗽𝗹𝗼𝘆𝗲𝗱, (in most cases).
⏩ Avoiding Upgradeable contracts just because they might add to the complexity of your existing smart contract architecture is probably a bad idea, especially when you know you might need one.
⏩ 𝙎𝙩𝙧𝙚𝙣𝙜𝙩𝙝𝙚𝙣𝙞𝙣𝙜 𝙤𝙪𝙧 𝙪𝙣𝙙𝙚𝙧𝙨𝙩𝙖𝙣𝙙𝙞𝙣𝙜 𝙤𝙛 𝙪𝙥𝙜𝙧𝙖𝙙𝙚𝙖𝙗𝙡𝙚 𝙨𝙢𝙖𝙧𝙩 𝙘𝙤𝙣𝙩𝙧𝙖𝙘𝙩𝙨 𝙞𝙨 𝙬𝙝𝙖𝙩 𝙬𝙚 𝙣𝙚𝙚𝙙 𝙖𝙣𝙙 𝙨𝙝𝙤𝙪𝙡𝙙 𝙥𝙧𝙚𝙛𝙚𝙧, 𝙞𝙣𝙨𝙩𝙚𝙖𝙙 𝙤𝙛 𝙖𝙫𝙤𝙞𝙙𝙞𝙣𝙜 𝙞𝙩.
⏩ Additionally, I believe smart contract upgrade patterns have now seen quite a journey starting from the Eternal Storage mechanism to the recent ones like Transparent Upgradeable proxy or UUPS.
Watch this video and enjoy, the very cool Thomas Wiesner, taking us to this entire journey of upgradeable smart contracts and how they evolved over time.
Therefore now we have a much safer procedure for upgrading contracts and amazing libraries and tools by Openzeppelin which simplifies the entire procedure.
⏩ While not every contract needs to be upgradeable, the ones that need to be should be upgradeable.
💡The right question for such contracts, however, isn’t whether or not they should be upgradeable.
How should we Upgrade Smart Contracts Securely?
🔴 If you accumulate all the upgradeable capability of your smart contracts to a simple address (EOA), then it’s definitely not a secure contract.
🔴 One safe way of upgrading such smart contracts is to use ProxyAdmin contracts and a Multisig, thus eliminating a single authority control over upgrades.
🔴 Upgrading through on-chain governance is another secure, effective, and decentralized way of doing it.