Immutability has long been considered a core characteristic and foundation of trust in blockchain technology, ensuring that once the source code has been deployed to the network, no individual or organization can interfere or change the established rules. However, according to research from Tan Phat Digital, the actual operation of decentralized ecosystems in recent years has shown that absolute immutability is a significant barrier to sustainable development. Critical security vulnerabilities that cannot be patched, regulatory changes that cannot be updated, and the need to add new features have driven the developer community to search for ways to "upgrade" smart contracts without breaking address and data integrity.
This study deeply analyzes techniques that allow post-deployment logic changes, from popular Proxy models to controversial Metamorphic techniques, and evaluates the risks security risks and related governance barriers.
The paradox of immutability and the need for variability
Technically, the bytecode of a smart contract, once permanently stored in a block on a blockchain like Ethereum, cannot be changed. Each contract address is associated with a fixed piece of code. However, programmers can simulate mutability by completely separating state storage and logic execution. This creates a layer of disruption, where users interact with a fixed "shell" but the actual behavior is driven by a variable entity.
The need for variability arises from three main factors: security maintenance, product evolution, and risk management. A small logic error can lead to the loss of millions of dollars in assets if not resolved promptly. In traditional financial systems, downtime for maintenance is normal, but in blockchain, where protocols operate 24/7, the ability to "hot-fix" through logic upgrades is vital to the survival of the project.
Comparing design philosophies between Blockchain platforms
Differences in design thinking between popular platforms today now:
Ethereum (EVM):
Default state: Immutable.
Logic change mechanism: Using Proxy and
delegatecall.Upgrade approach: Application Layer (Application Patterns).
Transparency: Depends on verifying the source code of the Proxy.
Stellar (Soroban):
Default state: Mutable.
Logic change mechanism: Directly change WASM bytecode.
Upgrade approach: Protocol-level.
Transparency: Built-in to the contract metadata.
This difference points to a new trend: while Ethereum requires complex design patterns, Soroban allows contracts to modify their own bytecode at the protocol level, helping to reduce the risks arising from incorrect Proxy implementations.
See also: Protection against Malicious Smart Contracts
Proxy Contract Infrastructure and Opcode DELEGATECALL
Most upgrade techniques on EVM compatible networks are based on a single opcode: delegatecall. When Contract A (Proxy) executes a delegatecall to Contract B (Implementation), Contract B's code will be executed but the execution context (storage, balance, msg.sender) belongs entirely to Contract A.
This mechanism allows developers to deploy a new version of logic (Implementation V2) and simply update an address variable in Proxy to point to V2. From the user's perspective, the interactive contract address remains the same, the account balance and related data are not affected, but the processing rules have been changed.
In-depth analysis of modern Proxy models
Proxy deployment requires careful consideration of gas costs, administration security, and scalability.
Transparent Proxy Pattern (TPP)
This model solves the "function selector collision" problem by separating access based on caller identity. If the caller is an Admin, they only see the Proxy's administrative functions. If it is a user, the call is delegated to Implementation.
Disadvantages: Costs about 2,100 extra gas per transaction due to having to perform Admin identity checks.
Universal Upgradeable Proxy Standard (UUPS)
UUPS (EIP-1822) puts the upgrade logic into the Implementation contract itself. The proxy is now just a minimalist piece of code.
Advantages: Extremely gas-saving (only costs about 100 extra gas) for the end user.
Risk: If the new upgrade lacks the
upgradeTofunction, the contract will be "bricked" (permanently locked) and cannot be upgraded anymore.
Beacon Proxy Pattern
This solution is suitable for mass deployment of similar contracts. Proxies do not store a logical address but point to an intermediate contract (Beacon). When updating Beacon, thousands of dependent contracts will be updated simultaneously. This is an effective mechanism but creates a huge "centralized weakness".
Diamond Standard (EIP-2535)
This is the most complex upgrade architecture, allowing a single Proxy (Diamond) to delegate to many different Implementations (Facets).
Diamond Proxy: Single point of interaction, storing the mapping functions.
Facets: Independent logical contracts help the system overcome the EVM's 24KB limit.
DiamondCut: Admin functions allow adding, replacing or deleting specific functions.
Diamond Loupe: Interface allows checking the current structure of Diamond.
See more: What is Smart Contract Audit?
Breaking the boundaries: Metamorphic Contracts and CREATE2
A more extreme method of changing logic is the "Metamorphic Contract". Unlike Proxies, this technique allows complete replacement of the bytecode at the same address using the CREATE2 opcode.
The "transformation" procedure involves using an unspecified init_code (initialization code). Instead of containing fixed logic, init_code can be programmed to call another contract and retrieve the new executable bytecode. When changes are needed, the developer executes the command SELFDESTRUCT to delete the old contract and uses CREATE2 with the same salt value to deploy the new code at the same address. This technique is often considered dangerous because it wipes out state (storage) and can be exploited to deceive auditing organizations.
Security risk matrix in variable contracts
Allowing logic changes introduces specific security vulnerabilities:
Storage Layout Collisions: Occurs when a new version changes the variable order, leading to the overwriting of erroneous data. For example, the Audius hack (2022) cost the project $6 million due to the new variable overwriting the initialization flag.
Initialization Vulnerability: Since Proxies do not use
constructor, they need theinitialize()function. If you forget to call this function, an attacker can take over admin rights. The Wormhole hack ($320 million) is a typical example of this mistake.Administrative Backdoor: Some fraudulent projects deliberately use Proxies to install malicious code after attracting capital.
Popular types of Backdoor:
Minting Backdoor: Admin creates infinite tokens to release to the market field.
Blacklist/Freeze: Locks accounts so users cannot withdraw or sell tokens.
Drainage Logic: Fix withdrawal function to transfer assets directly to attacker's wallet.
Proxy Redirection: Redirect Implementation address to a malicious contract.
Governance Strategy and Multilayer Defense
To balance flexibility and safety, Tan Phat Digital recommends that projects apply a strict governance process:
Using Multisig: Upgrade rights must be held by a multi-signature wallet (like Gnosis Safe) with a 2/3 or 3/5 approval threshold to eliminate individual weaknesses.
Timelock mechanism: Apply a time lock of at least 24 hours up to 7 days for all upgrade commands. This allows the community time to examine the source code or withdraw assets if abnormalities are detected.
Maintain Storage Gaps: Leave gaps in storage to ensure future upgrades can add variables without causing conflicts.
Continuous auditing: Each logic upgrade should be treated as a new project and must undergo an independent audit process.
Frequently Asked Questions (FAQ)
1. What is a Proxy Contract and why is it important?
A proxy is an intermediary contract that holds data and assets, while the execution logic resides in another contract. It allows for logic updates without changing contract addresses, helping to maintain user experience and protocol continuity.
2. Is it possible to upgrade a contract from Solidity to Vyper?
Yes. Because both Solidity and Vyper are compiled into bytecode that runs on the EVM. As long as the storage layout of the new Vyper version exactly matches the old Solidity version, swapping the logic is technically possible.
3. How to check if a contract is Proxy on Etherscan?
Users can use Etherscan's "Proxy Contract Verification" tool. Contracts that comply with the EIP-1967 standard will have a "Read as Proxy" or "Write as Proxy" tab, allowing you to see the actual Implementation address running behind the scenes.
4. What is the 24KB source code limit and how does Diamond Standard address it?
EVM limits the bytecode size of a contract to a maximum of 24KB. Diamond Standard (EIP-2535) allows logic to be broken down into multiple "Facets" (contract pieces), making it possible for a single address to execute a nearly unlimited amount of logic.
5. What exactly is "Storage Collision"?
This is when the Proxy contract and Logic contract accidentally use the same location (slot) in memory to store two different variables. This results in one variable overwriting the other, which can cause serious logic errors or allow an attacker to take over.
6. Why does the project need a Timelock when upgrading?
Timelock creates a waiting period (usually >= 24h) before the upgrade takes effect. This gives the community time to react, check the source code, or withdraw if they don't trust the new update.
7. How are Transparent Proxy and UUPS different?
Transparent Proxy puts the upgrade logic in the Proxy, consumes more gas but is more secure because it clearly separates Admin rights. UUPS puts the upgrade logic in the Implementation, which saves more gas but is high risk because if the upgrade fails, the contract will never be repaired again.
8. How is a Metamorphic contract different from a regular Proxy?
A Proxy keeps the bytecode at that address and only changes the logical address it points to. The Metamorphic contract directly replaces the entire source code at the site itself, but wipes out all existing data and residuals.
9. How does EIP-6780 affect contract upgrades?
EIP-6780 limits the SELFDESTRUCT command to only operate within the same transaction that initiated the contract. This disables most of the old "Metamorphic" techniques that relied on destroying the contract at any point to redeploy new code.
10. What is "Storage Gap" used for?
It is an array of empty variables (usually uint256 __gap) placed in the base contracts. It reserves storage space so that in the future, when upgrading, developers can add new variables to it without skewing the storage layout of legacy contracts.
11. Can a contract be converted from "upgradable" to "immutable"?
Yes. The developer can perform a final upgrade to remove the upgrade function or move the administrator (Owner) to a "zero" address (0x0). Once the upgrade function disappears, the logic is locked forever.
12. What are the risks of "Uninitialized Proxy"?
If the developer forgets to call the initialization function (initialize) immediately upon deployment, anyone can call it to become the contract owner. The Wormhole hack is a typical example when this error almost caused the loss of hundreds of millions of dollars.
13. What proportion of contracts actually undergo upgrades?
Research shows that only about 3% of contracts on Ethereum are designed for upgrades, and of those, only about 0.34% actually undergo upgrades once deployed.
14. When is Beacon Proxy used?
It is used when you need to deploy thousands of identical contracts (like a Smart Wallet). Instead of updating each contract, you only need to update a single address at "Beacon", and all wallets will change their logic simultaneously.
15. When should you use "Contract Migration" instead of Proxy?
When you need to change the core data structure (e.g. change from ERC-20 to ERC-777 standard) that the Proxy cannot handle due to storage slot conflicts. At this point, you have to deploy a completely new contract and ask users to transfer assets to the new address.
The Future of Mutability in Smart Contracts
The development of upgrade techniques has broken the stereotype of static blockchain source code. While immutability is the ultimate ideal, controlled mutability is vital to dealing with security flaws and market changes.
Future trends will be toward decentralization of upgrade authority through DAOs and the use of automated testing tools like OpenZeppelin Upgrades Plugins. Mutability, when implemented transparently and properly, does not detract from the value of the blockchain, but rather creates an ecosystem that is resilient and capable of continuous evolution.
Share
