孟斌的小站

1、本课学习目标

• 理解去中心化众筹的业务模型与关键边界条件（目标、截止时间、退款/领取）
• 能从零实现一个支持多 Campaign 的众筹合约（以太币版本）
• 设计安全的资金流（pull-over-push、checks-effects-interactions、重入保护）
• 用 Foundry 写完整测试（创建 Campaign、认购、退回、提取）

2、关键设计点

1. Campaign 状态机
   • Active（正在进行，可 pledging）
   • Successful（达到目标，所有人可领取）
   • Failed（截止且未达到目标，支持退款）
   • Withdrawn（创建者已领取资金）
2. 谁可以做什么
   • 任意地址可以创建 Campaign（或限定为合约 Owner）
   • 任意地址在活动期间可 pledge（支付 ETH）
   • 创建者在活动结束且目标达成后可 claim（提取所有资金）
   • 投资者在活动结束且目标未达成后可 refund（取回自己投入）
3. 资金流安全原则
   • Pull over Push：优先把退款/领取弧度做成可提款模式（用户调用提取），不要把外部合约回调放在自动转账中
   • Checks-Effects-Interactions：先改变合约状态再进行外部调用
   • 重入防护：使用互斥锁或 OpenZeppelin 的 ReentrancyGuard
   • 检查零地址、金额、截止时间合理性
4. 时间处理
   • 使用 block.timestamp；注意矿工可微调时间（可被操纵 ~900s），对大额攻击场景需谨慎
5. Gas / DoS 风险
   • 不要在单笔函数里遍历大量数组（避免被 gas 限制 DOS）
   • 使用 mapping 存储出资详情，避免遍历退款列表

3、简单实现

src/SimpleCrowdfunding.sol：

1、学习目标

• 理解 ERC721 与 ERC1155 的标准接口
• 从零实现一个 最小化 ERC721（NFT）合约
• 扩展功能：元数据管理（BaseURI）、批量铸造 / 批量转账
• 对比 OpenZeppelin 实现
• 使用 Foundry 测试

2、知识点梳理

1. ERC721 核心接口
   • balanceOf(address)
   • ownerOf(uint256)
   • safeTransferFrom(address,address,uint256)
   • transferFrom(address,address,uint256)
   • approve(address,uint256) / setApprovalForAll(address,bool)
   • 事件：Transfer, Approval, ApprovalForAll
2. ERC1155 核心接口
   • 支持 多代币标准（FT / NFT / SFT）
   • balanceOf(address,uint256)
   • safeTransferFrom(address,address,uint256,uint256,bytes)
   • safeBatchTransferFrom(...)
   • 事件：TransferSingle, TransferBatch, ApprovalForAll
3. 应用场景差异
   • ERC721 → 独一无二的资产（头像、土地、艺术品）
   • ERC1155 → 大规模批量资产（游戏道具、门票、盲盒）

3、最小 ERC721 实现

MyERC721.sol：

在前文我们已经用 Mutex 和 RWMutex 解决了竞态问题。但是在实际生产中，锁并不是唯一解，甚至在高并发场景下可能不是最佳解。这里我们来探索更多可能性：

在日常开发中，我们经常会遇到高并发的业务场景，比如钱包系统的转账。如何保证并发情况下的数据一致性，是 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）。在继承或代理合约模式下，如果新旧合约的状态变量定义不一致，就可能发生槽冲突，导致关键数据被覆盖。

引言

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

引言

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

引言

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