Find out everything you need to know about Upgradable Smart Contracts.
As decentralized applications progress, there may be a need for additional features or enhancements. Upgradable Smart Contracts allow for the smooth integration of these improvements.
Types of Upgradable Smart Contracts
1. Not Upgrading (Adjusting All Parameters)
This method includes creating contracts with adjustable parameters, avoiding the need to modify the contract code.
Advantages: Easy to execute, no complicated upgrades are needed.
Downsides: There is only a small amount of flexibility as any future changes that need to be predicted during the initial deployment may result in complicated and ineffective contract creation because of too many parameters.
Advantages: Easy to execute, no complicated upgrades are needed.
Downsides: There is only a small amount of flexibility as any future changes that need to be predicted during the initial deployment may result in complicated and ineffective contract creation because of too many parameters.
2. Social Migration
Social migration consists of implementing a new contract version and advising users to voluntarily transfer their activities to the updated contract.
Advantages: Completely decentralized and transparent as users opt to transfer, no central control is needed to handle the upgrade.
Downsides: Risk of user fragmentation, resulting in a divided user base due to some users not transitioning, issues with coordination, and the risk of losing user funds during the migration process.
Advantages: Completely decentralized and transparent as users opt to transfer, no central control is needed to handle the upgrade.
Downsides: Risk of user fragmentation, resulting in a divided user base due to some users not transitioning, issues with coordination, and the risk of losing user funds during the migration process.
3. Proxy
Proxies consist of a proxy contract that forwards calls to an implementation contract, enabling the implementation to be changed when required.
Advantages: Versatile and robust, allowing extensive enhancements without needing to redeploy the contract, users persist in engaging with the initial contract address.
Downsides: Difficult to set up and upkeep, potential threats like storage conflicts and function selector clashes.
Advantages: Versatile and robust, allowing extensive enhancements without needing to redeploy the contract, users persist in engaging with the initial contract address.
Downsides: Difficult to set up and upkeep, potential threats like storage conflicts and function selector clashes.
Issues With Proxies
Conflicts in Storage
Storage conflicts happen when the way storage is organized in the proxy contract contradicts that of the implementation contract. Every index in a contract's storage is unique, and sharing the same storage slots between the proxy and implementation contracts for different variables may lead to data corruption.
Function Selector Conflicts
Function selector conflicts arise when the proxy and implementation contracts have different functions with identical signatures, which are determined by the first four bytes of the Keccak-256 hash of the function's prototype. In Solidity, every function is distinguished by a unique selector, however, conflicts can occur when delegatecall is employed if two functions in separate contracts share the same selector.
What Occurs During a Conflict?
When the proxy contract calls setData, Solidity will examine the function selectors to decide which function to run. Because the proxy contract has a setData function with the same selector, it will run the proxy's setData function instead of passing the call to the implementation contract.
DELEGATECALL
DELEGATECALL is a feature in Solidity that permits a contract to run code from a different contract without losing the initial context, such as msg.sender and msg.value. This is crucial in proxy patterns, where the proxy contract forwards function calls to the implementation contract.
Difference Between Delegate Call and Call Function
Delegatecall, much like a call function, is a key aspect of Ethereum. Nevertheless, their functioning varies slightly. Consider delegatecall as a feature that enables a contract to utilize a function from a different contract, similar to a call option.
Comprehending Storage in DELEGATECALL
It is fascinating to observe the inner workings of delegatecall with storage at a more profound level. The setVars function from Contract B does not consider the names of the storage variables in Contract A but rather looks at their storage slots. If we utilize the setVars function from Contract B through delegatecall, the value in the first storage slot will be modified instead of the num in Contract B, and so forth.
Another key point to keep in mind is that the storage slot's data type in Contract A doesn't necessarily have to be the same as in Contract B. Despite their differences, delegatecall simply updates the storage slot of the called contract. Delegatecall allows Contract A to use the functionality of Contract B without changing its storage configuration.
Another key point to keep in mind is that the storage slot's data type in Contract A doesn't necessarily have to be the same as in Contract B. Despite their differences, delegatecall simply updates the storage slot of the called contract. Delegatecall allows Contract A to use the functionality of Contract B without changing its storage configuration.
What Does EIP1967 Refer To?
EIP1967 establishes unique storage slots for implementation addresses to guarantee consistency and resilience among various implementations.
Kinds Of Proxies And Their Advantages And Disadvantages
Transparent Proxy
This agreement establishes a proxy that can be upgraded by an administrator. In order to prevent conflicts with proxy selectors that could be exploited in an attack, this contract adopts the transparent proxy pattern. This pattern suggests two interconnected things.
1. If the proxy receives a call from any account that is not the admin, it will be redirected to the implementation, regardless of whether the call corresponds to one of the admin functions provided by the proxy.
2. When the proxy is contacted by the admin, it is able to utilize the admin features, however, any requests made will not be transferred to the implementation. Should the administrator attempt to invoke a function on the implementation, an error will occur indicating that "admin cannot fall to proxy target".
These characteristics indicate that the admin account should only be utilized for administrative tasks such as updating the proxy or modifying the admin, making it advisable for it to be a separate account solely for this purpose. This will prevent headaches caused by abrupt errors when attempting to invoke a function from the proxy implementation.
Universal Upgradeable Proxy Standard (UUPS)
UUPS operates in much the same way as the Transparent Proxy Pattern. We employ msg.sender as a key similarly to how it was illustrated in the previous pattern. The only variation is the placement of the function for upgrading the logic's contract: within the proxy or within the logic itself.
In the Transparent Proxy Pattern, the upgrade function resides within the proxy contract, and the process for altering the logic remains consistent across all logic contracts. UUPS has undergone modifications. The upgrading function is integrated into the contract's logic, meaning the process of upgrading may evolve in the future.
Furthermore, without an upgrading mechanism in the new logic version, the project will become fixed and unable to be altered. Hence, if you intend to utilize this design, it is important to avoid unintentionally limiting your ability to improve.
In the Transparent Proxy Pattern, the upgrade function resides within the proxy contract, and the process for altering the logic remains consistent across all logic contracts. UUPS has undergone modifications. The upgrading function is integrated into the contract's logic, meaning the process of upgrading may evolve in the future.
Furthermore, without an upgrading mechanism in the new logic version, the project will become fixed and unable to be altered. Hence, if you intend to utilize this design, it is important to avoid unintentionally limiting your ability to improve.
Why May You Steer Clear Of Upgradable Smart Contracts?
1. Complications: The increased complexity during development, testing, and auditing may lead to the emergence of new vulnerabilities.
2. Gas Expenses: Proxy mechanisms have the potential to raise gas expenses, affecting the contract's efficiency. Although upgradability allows for flexibility, it needs to be in harmony with the core values of security and decentralization.
2. Gas Expenses: Proxy mechanisms have the potential to raise gas expenses, affecting the contract's efficiency. Although upgradability allows for flexibility, it needs to be in harmony with the core values of security and decentralization.
.webp?locale=en)
.webp?locale=en)
