孟斌的小站

在日常开发中，我们经常会遇到高并发的业务场景，比如钱包系统的转账。如何保证并发情况下的数据一致性，是 Go 工程师必须掌握的技能之一。今天我用一个简单的钱包转账例子，带大家看看 Go 中数据竞争是怎么发生的，以及如何用 sync.Mutex 和 sync.RWMutex 来解决。

1、课程目标

在本课中，我们将从零开始实现一个 最小可用的 ERC20 代币合约，并逐步扩展功能，包括铸造（mint）、销毁（burn）、权限控制（owner / onlyOwner）。 通过本课，我们可以：

课程目标

• 理解智能合约的主要 Gas 消耗来源
• 掌握常见的 优化技巧与模式
• 通过 Foundry 对比 优化前后 Gas 成本
• 建立“写出高效合约”的思维框架

1、Gas 的构成

在 EVM 中，Gas 主要分为三类：

课程目标

• 理解 Solidity 编译器的存储布局机制
• 学会识别 存储槽冲突、ABI 混淆攻击
• 掌握 selfdestruct 等低级指令的风险
• 通过 Foundry 测试模拟攻击与验证

1、存储槽冲突（Storage Slot Collision）

Solidity 使用 32 字节为一个存储槽（storage slot）。在继承或代理合约模式下，如果新旧合约的状态变量定义不一致，就可能发生槽冲突，导致关键数据被覆盖。

引言

区块链合约的“代码即法律”带来了强大的确定性，但同时也意味着：

引言

在区块链上，合约一旦部署便不可修改，这是去中心化的根本保障。但对于复杂应用来说，这却成了一把双刃剑：

引言

在区块链合约中，权限管理是核心问题之一。 如果权限控制不当，可能导致：

从这一课开始，我们将会进入实战环节，通过编写测试来学习 Solidity 合约的各种高级用法。

在复杂的智能合约系统中，代码复用与模块化至关重要。Solidity 提供了 库（Library） 机制，用来组织可重用逻辑，避免重复开发与部署，提升合约的可维护性与安全性。

1、可升级的必要性与问题

1. 区块链合约不可变的特性

• 在区块链上部署的合约代码是永久存储的，不可直接更改或删除。
• 这种不可变性保障了去中心化和安全性，但也意味着：
  • 一旦有 bug，无法直接修改。
  • 一旦需要新增功能，只能重新部署一个新版本。

2. 部署新合约迁移 vs 升级逻辑合约

• 部署新合约迁移
  • 需要将旧合约中的状态数据（余额、映射等）迁移到新合约。
  • 迁移过程复杂、易出错、消耗大量 gas。
  • 用户需要更新交互地址，容易引起混乱。
• 升级逻辑合约
  • 通过代理模式保留原有存储，替换逻辑实现。
  • 用户交互地址不变，数据原地保留。
  • 只需在升级时注意存储布局一致性。

2、可升级合约的核心思想

• 问题：合约一旦部署，代码无法更改。
• 解决方案：将合约分为 代理合约（Proxy） 和 逻辑合约（Implementation）。
  • 代理合约：存储状态变量，转发调用给逻辑合约。
  • 逻辑合约：包含可执行代码。
• 关键技术：delegatecall，在代理合约中使用 delegatecall 调用逻辑合约的函数，使得代码在代理的存储上下文中执行。

3、代理模式的工作原理

1. delegatecall 复习

(bool success, bytes memory data) = implementation.delegatecall(msg.data);

• delegatecall 会在当前合约的存储和上下文中执行目标合约的代码。
• 状态变量读写会影响代理合约，而不是逻辑合约。

2. 存储布局一致性

• 代理合约和逻辑合约必须保持相同的状态变量声明顺序和类型，否则会出现数据错位。

4、常见可升级合约模式

1. 透明代理（Transparent Proxy）

• EIP-1967 标准。
• 普通用户调用逻辑合约函数；管理员调用代理的管理函数（升级逻辑合约地址）。
• 优点：简单、被广泛支持（OpenZeppelin Proxy）。
• 缺点：管理逻辑和业务逻辑混在同一个合约中，稍显冗余。

2. UUPS（Universal Upgradeable Proxy Standard）

• EIP-1822 标准。
• 升级逻辑放在逻辑合约自身，由 upgradeTo 函数完成。
• 优点：代理合约更轻量，升级逻辑可定制。
• 缺点：升级安全完全依赖逻辑合约实现，容易被错误实现破坏。

3. Beacon Proxy

• 使用一个 Beacon 合约统一存储逻辑合约地址，多个代理共享升级源。
• 适合多实例共享逻辑的场景。

5、可升级合约的安全陷阱

| 风险点 | 说明 | 解决方案 | | :-------------------- | :------------------------------------------------- | :-------------------------------------------------- | | 存储布局冲突 | 升级后逻辑合约的变量顺序、类型不一致，导致数据错位 | 遵循固定的变量追加规则，避免删除或更改类型 | | 初始化漏洞 | 新逻辑合约的构造函数不会被代理调用 | 使用 initializer 修饰的初始化函数，防止重复初始化 | | delegatecall 风险 | 调用外部不可信合约可能破坏存储 | 严格控制升级权限，禁止不可信代码执行 delegatecall | | 权限丢失 | 升级过程中可能被替换成恶意逻辑 | 使用多签或 Timelock 控制升级 |