Upgrade strategies in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a Proxy Upgrade Pattern

Consider a simple proxy contract pattern where the proxy delegates calls to an implementation contract. What will be the output of the following Solidity code snippet when calling getVersion() after upgrading the implementation?

Blockchain / Solidity

contract ImplementationV1 {
    function getVersion() public pure returns (string memory) {
        return "V1";
    }
}

contract ImplementationV2 {
    function getVersion() public pure returns (string memory) {
        return "V2";
    }
}

contract Proxy {
    address public implementation;

    constructor(address _impl) {
        implementation = _impl;
    }

    function upgrade(address _newImpl) public {
        implementation = _newImpl;
    }

    fallback() external payable {
        (bool success, bytes memory data) = implementation.delegatecall(msg.data);
        require(success);
        assembly {
            return(add(data, 0x20), mload(data))
        }
    }
}

A "V1"

B Compilation error due to delegatecall

C "V2"

D Runtime revert due to fallback

💡 Hint

Think about what happens when the proxy's implementation address is changed and a function is called.

The proxy delegates the call to the current implementation address. After upgrading to ImplementationV2, calling getVersion() returns "V2".

🧠 Conceptual

intermediate

Choosing Upgrade Strategy for Immutable Contracts

Which upgrade strategy is best suited for smart contracts that cannot be changed after deployment but require new features?

A Use a proxy contract with delegatecall to the implementation contract

B Use self-destruct to remove the old contract and redeploy

C Modify the contract bytecode directly on the blockchain

D Deploy a new contract and use a registry to point users to the latest version

💡 Hint

Immutable contracts cannot be changed, so think about how to redirect users.

Since contracts are immutable, deploying a new contract and updating a registry or pointer is a common upgrade strategy.

🔧 Debug

advanced

Identify the Bug in Upgradeable Contract Storage

Given the following Solidity contracts, what is the cause of the unexpected behavior where the stored value does not persist after upgrading?

Blockchain / Solidity

contract StorageV1 {
    uint256 public value;

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

contract StorageV2 {
    uint256 public newValue;
    uint256 public value;

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

    function setNewValue(uint256 _newValue) public {
        newValue = _newValue;
    }
}

A Storage layout mismatch between V1 and V2 causes data corruption

B Delegatecall is not used in the proxy contract

C The upgrade function does not update the implementation address

D The fallback function is missing in the proxy contract

💡 Hint

Think about how storage variables are ordered and how that affects upgradeable contracts.

Adding new variables in the middle or changing order breaks storage layout, causing data corruption after upgrade.

📝 Syntax

advanced

Syntax Error in Upgradeable Contract Code

Which option contains the correct syntax for a Solidity function that upgrades the implementation address in a proxy contract?

A function upgrade(address newImpl) public { implementation = newImpl; }

B function upgrade(address newImpl) public { implementation = newImpl }

C function upgrade(address newImpl) public { implementation == newImpl; }

D function upgrade(address newImpl) public { implementation := newImpl; }

💡 Hint

Remember Solidity statements end with semicolons and assignment uses a single equals sign.

Option A uses correct assignment syntax with a semicolon. Option A misses semicolon, C uses comparison operator, D uses invalid operator.

🚀 Application

expert

Calculate Number of Upgrade Steps in a Multi-Stage Upgrade

A blockchain project uses a multi-stage upgrade strategy where each upgrade deploys a new implementation contract and updates the proxy. If the project starts at version 1 and plans to reach version 5, how many upgrade transactions are needed to reach version 5 from version 1?

A 5

B 4

C 3

D 1

💡 Hint

Count how many times the implementation must be changed to go from version 1 to 5.

To move from version 1 to 5, you must upgrade 4 times: 1->2, 2->3, 3->4, 4->5.