以太坊可升级智能合约开发求助：求合约实例及数据访问方法

Hey there! Let's break down upgradeable Ethereum smart contracts for you—they're a game-changer when you need to fix bugs, add features, or iterate on your contract without losing existing state. Below I'll share a practical example using OpenZeppelin's industry-standard upgradeable tools, plus explain exactly how data access works in this setup.

We'll use the UUPS (Universal Upgradeable Proxy Standard) pattern here—it's lightweight and gives you more control over upgrade logic compared to the Transparent Proxy pattern.

Step 1: V1 实现合约 #

This is your initial contract, with core functionality. Note that we use an initializer instead of a constructor (critical for upgradeable contracts).

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// Import OpenZeppelin's upgradeable base contracts
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

contract MyUpgradeableContractV1 is Initializable, UUPSUpgradeable, OwnableUpgradeable {
    // State variables: NEVER reorder or remove these in future versions—only add new ones at the end
    uint256 public value;

    // Disable initializers in the constructor to prevent accidental initialization of the implementation contract
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    // Initializer replaces the constructor—runs once when the proxy is deployed
    function initialize(uint256 initialValue) public initializer {
        // Initialize inherited contracts first
        __Ownable_init(msg.sender);
        __UUPSUpgradeable_init();
        // Set initial state
        value = initialValue;
    }

    // Required for UUPS: Controls who can trigger upgrades (only the owner here)
    function _authorizeUpgrade(address newImplementation) internal override onlyOwner {}

    // Core business functions
    function setValue(uint256 newValue) public onlyOwner {
        value = newValue;
    }

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

Step 2: V2 升级合约 #

When you need to add features or fix bugs, create a new contract that inherits from V1. You can add new state variables and functions, or override existing ones.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "./MyUpgradeableContractV1.sol";

contract MyUpgradeableContractV2 is MyUpgradeableContractV1 {
    // New state variable: Added AFTER existing variables to preserve storage layout
    uint256 public anotherValue;

    // New business function
    function setAnotherValue(uint256 newValue) public onlyOwner {
        anotherValue = newValue;
    }

    function getAnotherValue() public view returns (uint256) {
        return anotherValue;
    }

    // Optional: Override an existing function to add new logic
    function setValue(uint256 newValue) public override onlyOwner {
        // Add a validation check that wasn't in V1
        require(newValue > 0, "Value must be positive");
        value = newValue;
    }
}

Step 3: 部署与升级脚本（Hardhat示例） #

Use Hardhat's @openzeppelin/hardhat-upgrades plugin to deploy the proxy and handle upgrades safely.

const { ethers, upgrades } = require("hardhat");

async function main() {
  // Deploy V1 and initialize the proxy with an initial value of 42
  const MyUpgradeableContractV1 = await ethers.getContractFactory("MyUpgradeableContractV1");
  const proxy = await upgrades.deployProxy(MyUpgradeableContractV1, [42], { initializer: "initialize" });
  await proxy.waitForDeployment();
  console.log("Proxy deployed to:", await proxy.getAddress());

  // Upgrade the proxy to V2 (preserves all existing state from V1)
  const MyUpgradeableContractV2 = await ethers.getContractFactory("MyUpgradeableContractV2");
  const upgradedProxy = await upgrades.upgradeProxy(await proxy.getAddress(), MyUpgradeableContractV2);
  await upgradedProxy.waitForDeployment();
  console.log("Proxy successfully upgraded to V2!");
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

The key to upgradeable contracts is separating state storage and business logic:

• Proxy Contract Holds All State: The proxy is the contract users interact with directly, and it stores every piece of state data (like value and anotherValue).
• Implementation Contract Is Logic Only: The V1/V2 contracts are just "logic blueprints"—they don't hold any user state themselves.
• Delegatecall Magic: When you call a function on the proxy, it uses delegatecall to forward the call to the current implementation contract. This means:
  • The function runs in the context of the proxy contract, not the implementation.
  • Any SLOAD (read) or SSTORE (write) operations target the proxy's storage slots, not the implementation's.

Critical Storage Rules to Avoid Data Corruption #

• Never reorder existing state variables: EVM stores data in sequential storage slots. If you swap the order of variables in a new version, the proxy's existing data will map to the wrong variables.
• Never delete existing state variables: This leaves empty storage slots that could cause conflicts if you add new variables later.
• Only add new state variables at the end: New variables get assigned to the next available storage slots, so they don't interfere with existing data.

Example of Data Access #

When you call proxy.getValue():

1. The proxy forwards the call to the current implementation (V1 or V2) via delegatecall.
2. The implementation's getValue() function reads from storage slot 0 (since value is the first state variable in V1).
3. The storage slot 0 lives in the proxy contract, so it returns the value that was set via the proxy—even after upgrading to V2.

If you call proxy.getAnotherValue() after upgrading to V2:

• The function reads from storage slot 1, which was added in V2 and is stored in the proxy's storage.

Let me know if you need clarification on any part—happy to help!

内容的提问来源于stack exchange，提问作者GPC