How is smart contract upgradability implemented?

Hey there, friend! That's an excellent question, and it's one of the most confusing aspects for many people just starting with smart contract development. Let me give you an analogy to help you thoroughly understand it.

The Core Contradiction: Blockchain's Immutability

First, we need to know that one of the biggest features of blockchain is its immutability. Once a smart contract is deployed on Ethereum, its code is like it's carved in stone; no one can modify it. While this is a huge advantage (security, trustworthiness), it's also a significant drawback.

Think about it: what if there's a bug in your code, or you want to add a new feature to your product in the future? Are you supposed to abandon the old contract and make all users migrate to a new one? That's too much hassle. Users' assets and data are tied to the old contract, making migration both difficult and costly.

So, the brilliant minds in the community came up with an ingenious solution to this problem: the Proxy Pattern.

Core Idea: Separating Address and Logic

Don't let the term "Proxy Pattern" intimidate you; its concept is actually very simple. I'll explain it with a real-life example:

Imagine you've opened an online shop, and your website address is www.my-awesome-shop.com.

All customers only know and use this URL. Initially, this URL points to your server A, which runs your online shop's V1.0 code.

Later, you want to upgrade your shop, perhaps by adding a flash sale feature. So you develop V2.0 and deploy it to a new server B.

At this point, you don't need to notify all customers by saying, "Hey, we've got a new website address!" Instead, you just update your domain management settings to point www.my-awesome-shop.com from server A to server B.

For customers, the address they visit remains the same, but they're already experiencing your latest features.

In this example:

• The unchanging URL (www.my-awesome-shop.com) -> This is the Proxy Contract.
• The swappable servers (Server A, Server B) -> These are the Logic Contracts (or Implementation Contracts).

The upgradability of smart contracts essentially applies this concept to the blockchain.

Two Key Roles and How They Cooperate

In an upgradable contract architecture, we typically deploy at least two contracts:

1. Proxy Contract

   • This is the entry point that users actually interact with; its address is permanently immutable.
   • It has almost no business logic itself; it's very simple.
   • It's responsible for storing all data and state (e.g., user balances, NFT ownership, etc.).
   • Its most important function is to act like a "dispatcher," forwarding all received requests (e.g., a user calling a function) to the "Logic Contract" for processing.

2. Logic Contract (Implementation Contract)

   • This contains all the actual business logic code for our project (e.g., transferring funds, minting NFTs).
   • It does not store any state data; it's a "stateless" utility worker.
   • This contract can be replaced. We can deploy V2, V3, and subsequent versions of the logic contract.

The Magic of delegatecall

How does the proxy contract forward requests to the logic contract? It uses a very special opcode called delegatecall.

The magical thing about delegatecall is:

It allows the proxy contract to "borrow" the logic contract's code for execution, but the execution context (i.e., storage, msg.sender, msg.value) remains that of the proxy contract itself.

In simpler terms: The proxy contract says to the logic contract, "Hey, use your brain (the logic contract's code) to process the files on my desk (the proxy contract's data and state)."

This way, all state changes (like increases or decreases in user balances) happen within the proxy contract's storage space, not the logic contract's. So even if we replace the logic contract later (swapping out for a smarter "brain"), the data remains intact and safely stored within the proxy contract's "home."

What does a complete upgrade process look like?

1. Initial Deployment

   • Deploy Logic Contract V1 (Logic_V1).
   • Deploy the Proxy Contract (Proxy), and during deployment, tell it that its logic contract address is Logic_V1's address.

2. Regular Use

   • All users interact only with the Proxy contract's address.
   • When Proxy receives a request, it uses delegatecall to have Logic_V1's code execute the request, with all data being stored in Proxy.

3. Initiating an Upgrade

   • A bug is found, or a new feature is desired, so we develop and deploy a new Logic Contract V2 (Logic_V2).
   • As the contract administrator, you call a special administrative function on the Proxy contract (e.g., upgradeTo()).
   • You tell the Proxy contract: "From now on, your new logic contract address is Logic_V2's address."

4. Upgrade Complete

   • The Proxy contract's internally recorded logic contract address is updated from Logic_V1 to Logic_V2.
   • Users continue to interact with the same Proxy address, but now the Proxy will forward requests to Logic_V2 for execution.
   • The entire process is transparent to users; the contract address they use never changes, but the contract's functionality has been completely revamped!

In Summary

This is the core secret to achieving upgradability in smart contracts. By separating immutable addresses/data from changeable logic, we can fix and iterate on contract functionalities without changing the contract's entry point or migrating data. Currently, the most prominent implementation standards are OpenZeppelin's UUPS and Transparent Proxy Pattern.

Hope this explanation helps you out!