代理模式原理：Delegatecall的工作原理，存储布局与指针，代理合约与逻辑合约的分离

好，咱们今天聊代理模式。这是智能合约升级里最核心的一块，说白了就是“怎么让合约能升级”。

我刚开始接触这个模式时，也觉得有点绕。但搞懂了 delegatecall 和存储布局，后面就一通百通了。咱们一步步来。

Delegatecall 的工作原理

先问个问题：普通 call 和 delegatecall 有什么区别？

普通 call 就像你打电话给朋友，让他帮你办事。他用自己的资源、自己的状态。而 delegatecall 呢？就像你借朋友的手，但用的是你的身体、你的钱。代码在朋友那里跑，但修改的是你的状态。

看个例子就明白了：

// 逻辑合约
contract Logic {
    uint public num;
    
    function setNum(uint _num) public {
        num = _num;
    }
}

// 代理合约
contract Proxy {
    address public logic;
    uint public num;
    
    function upgrade(address _logic) public {
        logic = _logic;
    }
    
    function delegateSetNum(uint _num) public {
        (bool success, ) = logic.delegatecall(
            abi.encodeWithSignature("setNum(uint256)", _num)
        );
        require(success);
    }
}

这里的关键是：delegateSetNum 调用后，修改的是 Proxy 合约里的 num，而不是 Logic 合约里的。代码在 Logic 里执行，但存储读写都在 Proxy 上。

存储布局与指针

嗯，这里有个大坑。我当年第一次写代理合约时，就踩过这个雷。

Solidity 的存储布局是线性的，每个变量按声明顺序占据一个 slot（槽位）。从 slot 0 开始，依次递增。

看这个例子：

// 代理合约的存储布局
contract Proxy {
    address public implementation;  // slot 0
    address public owner;           // slot 1
    uint256 public value;           // slot 2
}

// 逻辑合约的存储布局
contract LogicV1 {
    address public implementation;  // slot 0
    address public owner;           // slot 1
    uint256 public value;           // slot 2
    
    function setValue(uint256 _v) public {
        value = _v;
    }
}

为什么必须一致？因为 delegatecall 执行时，逻辑合约的代码会直接操作代理合约的存储槽位。如果布局不一致，就会发生“存储碰撞”——变量读到错误的数据。

那怎么保证布局一致呢？我个人的习惯是：

• 所有合约都继承同一个存储基类
• 使用 OpenZeppelin 的 StorageSlot 库
• 升级时只追加新变量，不删除、不插入

代理合约与逻辑合约的分离

说白了，代理模式就是把“数据”和“逻辑”拆开。代理合约负责存数据，逻辑合约负责跑代码。

这种分离带来了几个好处：

1. 可升级性：换掉逻辑合约，数据还在
2. 节省 gas：逻辑合约可以复用，多个代理共享一份代码
3. 模块化：逻辑和存储解耦，各自独立演进

但分离也带来了新问题——谁来管理升级？

常见的做法是加一个 onlyOwner 修饰符：

contract Proxy {
    address public implementation;
    address public owner;
    
    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }
    
    function upgrade(address _newImpl) public onlyOwner {
        implementation = _newImpl;
    }
}

不过这里要注意：owner 本身也存储在代理合约里。如果逻辑合约里也有 owner 变量，必须保证 slot 一致，否则升级权限可能被篡改。

避坑指南

最后分享几个我踩过的坑：

• 构造函数问题：逻辑合约的构造函数不会在代理中执行。初始化逻辑要单独写一个 initialize 函数，用 initializer 修饰符保证只调用一次。
• selfdestruct 风险：逻辑合约里如果有 selfdestruct，代理合约也会被销毁。我建议永远不要在逻辑合约里用这个。
• fallback 函数：代理合约通常需要 fallback 函数来转发所有调用。记得用 assembly 实现高效的 delegatecall。

嗯，代理模式就聊这么多。说白了就是三件事：delegatecall 怎么转发、存储布局怎么对齐、数据逻辑怎么分离。搞懂了这些，升级合约就不再是玄学了。

下一章咱们聊聊透明代理和 UUPS 模式，看看这两种主流实现有什么区别。