UUPS代理合约升级的原理是什么

[leno23]

• Slot 基础
  代理合约是外部看得见的地址，所有 delegatecall 执行都沿用它的上下文，所以变量都写入这个地址的 storage。Solidity 把每个状态变量映射到 32 字节 slot：按照声明顺序分配，从 0 开始；能挤进同一 slot 的小变量会被紧凑打包。

• 复杂类型公式

  • 动态数组：slot p 保存长度；元素从 keccak256(p) 起连续排布。
  • 映射：键值使用 keccak256(abi.encode(key, p)) 作为 slot；同一映射的不同键散布在不同位置，互不干扰。
  • 结构体、嵌套类型按内部顺序继续占 slot。

• UUPS 的固定槽
  升级流程需要“实现合约地址”常量存储槽。为了不和编译器分配的 slot 冲突，OpenZeppelin 用 bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1) 作为 slot；_setImplementation 就是往这个唯一槽里写新逻辑合约地址。

• delegatecall 的作用
  delegatecall 运行逻辑合约代码，但 storage, msg.sender, msg.value 都是代理的上下文。逻辑函数里 s.totalSupply = ... 实际是把值写到代理合约的 slot s 上，因此无论逻辑合约换多少版，数据都保留在代理地址下。

• 验证方式
  在链上用 eth_getStorageAt(proxyAddress, slotIndex) 能直接读。比如读 implementation 槽时传上面常量；读普通变量传对应 slot 编号或 keccak 计算结果，就能看到代理 storage 里的值。