Upgrade strategies in Blockchain / Solidity - Mini Project: Build & Apply

Upgrade Strategies in Blockchain Smart Contracts

📖 Scenario: You are working on a blockchain project where smart contracts need to be upgraded safely without losing data or breaking existing features. This is common in decentralized applications where improvements or bug fixes are required after deployment.

🎯 Goal: Build a simple smart contract upgrade system using a proxy pattern. You will create an initial contract, set up an upgrade mechanism, implement a new version of the contract, and finally show how to switch to the upgraded contract.

📋 What You'll Learn

Create an initial smart contract with a stored value and a function to get and set it.

Create a proxy contract that delegates calls to the implementation contract.

Create a new version of the implementation contract with an added function.

Demonstrate upgrading the proxy to point to the new implementation and verify the new function works.

💡 Why This Matters

🌍 Real World

Smart contract upgrades are essential in blockchain projects to fix bugs or add features without losing user data or requiring users to switch contracts manually.

💼 Career

Understanding upgrade patterns is important for blockchain developers working on decentralized applications, ensuring maintainability and security of smart contracts.

1

Create the initial implementation contract

Write a Solidity contract named ImplementationV1 with a uint256 state variable called value. Add a function setValue(uint256 newValue) to update value and a function getValue() that returns value.

Blockchain / Solidity

// Your code here

Hint

Define a contract with a public uint256 variable and two functions to set and get its value.

2

Create the proxy contract

Write a Solidity contract named Proxy with an address variable called implementation. Add a constructor that sets implementation. Implement a fallback function that delegates all calls to the implementation address using delegatecall.

Blockchain / Solidity

pragma solidity ^0.8.0;

contract ImplementationV1 {
    uint256 public value;

    function setValue(uint256 newValue) public {
        value = newValue;
    }

    function getValue() public view returns (uint256) {
        return value;
    }
}

// Create Proxy contract below
// Your code here

Hint

Use a fallback function with assembly to forward calls to the implementation contract.

3

Create the upgraded implementation contract

Write a Solidity contract named ImplementationV2 that inherits from ImplementationV1. Add a new function increment() that increases value by 1.

Blockchain / Solidity

pragma solidity ^0.8.0;

contract ImplementationV1 {
    uint256 public value;

    function setValue(uint256 newValue) public {
        value = newValue;
    }

    function getValue() public view returns (uint256) {
        return value;
    }
}

contract Proxy {
    address public implementation;

    constructor(address _implementation) {
        implementation = _implementation;
    }

    fallback() external payable {
        address impl = implementation;
        assembly {
            calldatacopy(0, 0, calldatasize())
            let result := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
            let size := returndatasize()
            returndatacopy(0, 0, size)

            switch result
            case 0 { revert(0, size) }
            default { return(0, size) }
        }
    }
}

// Create ImplementationV2 contract below
// Your code here

Hint

Extend the first contract and add a function to increase the stored value by one.

4

Upgrade the proxy to the new implementation and test

Add a function upgradeTo(address newImplementation) in the Proxy contract that updates the implementation address. Then, write a simple script or comment showing how to call upgradeTo to switch to ImplementationV2 and call increment() through the proxy.

Blockchain / Solidity

pragma solidity ^0.8.0;

contract ImplementationV1 {
    uint256 public value;

    function setValue(uint256 newValue) public {
        value = newValue;
    }

    function getValue() public view returns (uint256) {
        return value;
    }
}

contract Proxy {
    address public implementation;

    constructor(address _implementation) {
        implementation = _implementation;
    }

    fallback() external payable {
        address impl = implementation;
        assembly {
            calldatacopy(0, 0, calldatasize())
            let result := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
            let size := returndatasize()
            returndatacopy(0, 0, size)

            switch result
            case 0 { revert(0, size) }
            default { return(0, size) }
        }
    }

    // Add upgradeTo function here
    // Your code here
}

contract ImplementationV2 is ImplementationV1 {
    function increment() public {
        value += 1;
    }
}

// Example usage:
// proxy.upgradeTo(addressOfImplementationV2);
// Call increment() through proxy

Hint

Add a public function to change the implementation address and show how to call it.

Practice

1. Which of the following is a common upgrade strategy in blockchain development?

easy

A. Changing the blockchain consensus algorithm without notifying nodes

B. Using proxy contracts to allow logic changes without changing the contract address

C. Deleting old blocks to save space

D. Ignoring backward compatibility during upgrades

Solution

1. Step 1: Understand upgrade strategies

   Common upgrade strategies include proxy contracts, hard forks, and soft forks.

2. Step 2: Identify the correct method

   Proxy contracts allow changing logic while keeping the same address, enabling safe upgrades.

3. Final Answer:

   Using proxy contracts to allow logic changes without changing the contract address -> Option B

4. Quick Check:

   Proxy contracts = safe upgrade method [OK]

Hint: Proxy contracts keep address same for upgrades [OK]

Common Mistakes:

• Confusing hard forks with proxy contracts
• Thinking deleting blocks is an upgrade
• Ignoring backward compatibility

2. Which syntax correctly declares a proxy contract upgrade function in Solidity?

easy

A. function upgradeTo(address newImplementation) external onlyOwner {}

B. upgradeTo(address newImplementation) public {}

C. function upgrade(address newImplementation) private {}

D. function upgradeTo() external {}

Solution

1. Step 1: Check function declaration syntax

   In Solidity, functions must start with 'function' keyword and specify visibility.

2. Step 2: Match upgrade function signature

   The upgrade function usually takes an address and is external with access control like 'onlyOwner'.

3. Final Answer:

   function upgradeTo(address newImplementation) external onlyOwner {} -> Option A

4. Quick Check:

   Correct Solidity function syntax = function upgradeTo(address newImplementation) external onlyOwner {} [OK]

Hint: Solidity functions need 'function' and visibility keywords [OK]

Common Mistakes:

• Omitting 'function' keyword
• Using wrong visibility like private for upgrade
• Missing function parameters

3. Given this Solidity proxy upgrade snippet, what will be the output of implementation() after calling upgradeTo(newAddress)?

contract Proxy {
  address private _implementation;
  function implementation() public view returns (address) {
    return _implementation;
  }
  function upgradeTo(address newImplementation) public {
    _implementation = newImplementation;
  }
}

medium

A. Compilation error due to missing visibility

B. Always zero address (0x0)

C. The address of the Proxy contract itself

D. The address stored in _implementation after upgradeTo is called

Solution

1. Step 1: Understand state variable update

   The function upgradeTo sets _implementation to newImplementation address.

2. Step 2: Check implementation() return value

   implementation() returns the current _implementation address, which changes after upgradeTo call.

3. Final Answer:

   The address stored in _implementation after upgradeTo is called -> Option D

4. Quick Check:

   State variable updated = returned address [OK]

Hint: State variable returns updated address after upgrade [OK]

Common Mistakes:

• Assuming implementation() returns Proxy address
• Thinking _implementation stays zero
• Confusing visibility keywords

4. Identify the bug in this upgrade function and how to fix it:

function upgradeTo(address newImplementation) public {
  _implementation = newImplementation;
}

medium

A. Incorrect parameter type; should be uint256 instead of address

B. Function should be private to prevent external calls

C. Missing access control; add 'onlyOwner' modifier to restrict upgrades

D. No bug; function is correct as is

Solution

1. Step 1: Analyze function security

   The function allows anyone to call upgradeTo and change implementation, which is unsafe.

2. Step 2: Add access control

   Adding 'onlyOwner' modifier restricts upgrades to contract owner, preventing unauthorized changes.

3. Final Answer:

   Missing access control; add 'onlyOwner' modifier to restrict upgrades -> Option C

4. Quick Check:

   Access control needed for upgrade functions [OK]

Hint: Always restrict upgrade functions with access control [OK]

Common Mistakes:

• Ignoring security risks of public upgrade functions
• Changing parameter type incorrectly
• Making function private disables upgrades

5. You want to upgrade a deployed smart contract without changing its address or losing stored data. Which upgrade strategy should you use and why?

hard

A. Use a proxy contract pattern to separate logic and data storage

B. Perform a hard fork to replace the entire blockchain state

C. Deploy a new contract and ask users to switch manually

D. Delete the old contract and deploy a new one at the same address

Solution

1. Step 1: Understand upgrade goals

   We want to keep the same contract address and preserve stored data during upgrade.

2. Step 2: Evaluate upgrade strategies

   Proxy contracts separate logic and data, allowing logic upgrades without changing address or data loss.

3. Step 3: Compare other options

   Hard forks replace blockchain state, deploying new contracts requires user action, deleting contracts is impossible on blockchain.

4. Final Answer:

   Use a proxy contract pattern to separate logic and data storage -> Option A

5. Quick Check:

   Proxy pattern = upgrade without address or data loss [OK]

Hint: Proxy pattern upgrades logic, keeps data and address [OK]

Common Mistakes:

• Thinking hard forks preserve contract address
• Assuming users will always switch to new contract
• Trying to delete deployed contracts