Smart Contract Upgradability Patterns

Smart contracts have emerged as one of the critical components of Blockchain. However, as the industry evolves, smart contracts need to be upgraded to maintain compatibility, fix bugs, or enhance functionality.

This article will explore various smart contract upgradability patterns when to use them, and the trade-offs associated with each.

Proxy Pattern

The proxy pattern is one of the smart contract ecosystem’s most widely used upgradability patterns. It involves separating the logic of the smart contract from its storage. The proxy acts as a middleman between the user and the implementation contract, forwarding function calls and preserving the storage.

When to use:

• You need a flexible and robust system to upgrade the smart contract logic without losing data.

Trade-offs:

• Increased complexity: Managing proxy contracts may add complexity to your system.
• Gas costs: Using proxy contracts can lead to higher gas costs due to additional function calls.

Registry Pattern

A registry pattern is a decentralized approach that utilizes a registry contract to store the addresses of multiple versions of a smart contract. Users interact with the registry contract to select the version they want to interact with.

When to use:

• When you want to provide users with the option to choose between different versions of a smart contract.
• When you expect frequent upgrades.

Trade-offs:

• User Responsibility: Users must know the different versions and select the appropriate one for their needs.
• No centralized storage: Storage is not shared between different versions, which can lead to data consistency issues.

Eternal Storage Pattern

The eternal storage pattern decouples the smart contract’s storage from its logic, allowing you to upgrade the logic without affecting the stored data. A separate storage contract holds all the data, while the logic contracts interact with the storage contract to read and write data.

When to use:

• When you need a robust upgradability solution with centralized storage.
• When you want to minimize the risk of data loss during upgrades.

Trade-offs:

• Increased complexity: The eternal storage pattern introduces additional complexity in managing separate storage and logic contracts.
• Gas costs: Interacting with the storage contract may increase gas costs.

DelegateCall Pattern

The DelegateCall pattern involves using the ‘delegatecall’ opcode to forward function calls to a library contract containing the logic. This enables upgrading the logic by deploying a new library contract and updating the address in the main contract.

When to use:

• When you want a simple upgradability solution that allows for upgrading the smart contract logic without affecting the storage.

Trade-offs:

• Security risks: The use of delegatecall comes with potential security risks, as it allows the called contract to modify the storage of the calling contract.

Selecting the correct smart contract upgradability pattern depends on factors like the need for centralized storage, user preferences, and the desired level of complexity.

Understanding the trade-offs associated with each pattern is essential as choosing one that best fits the project’s requirements.

Follow me on Medium, LinkedIn, and Twitter.

All the best,

Luis Soares

CTO | Head of Engineering | Cyber Security | Fintech & Blockchain SME | NFT | Web3 | DeFi

#blockchain #smartcontracts #ethereum #nft #ethereum #evm #solidity #web3 #cryptography #softwareengineering #softwaredevelopment #coding #software

More content at PlainEnglish.io.

Sign up for our free weekly newsletter. Follow us on Twitter, LinkedIn, YouTube, and Discord.

Interested in scaling your software startup? Check out Circuit.