ERC721主合约一共引用了7个合约：

import "./Address.sol";
import "./Context.sol";
import "./Strings.sol";
import "./IERC721.sol";
import "./IERC721Receiver.sol";
import "./IERC721Metadata.sol";
import "./ERC165.sol";

他们分别是：

• 3个库合约：Address.sol, Context.sol和Strings.sol

• 3个接口合约：IERC721.sol, IERC721Receiver.sol, IERC721Metadata.sol

• 1个EIP165合约：ERC165.sol

所以在讲ERC721的主合约之前，我们会花两讲在引用的库合约和接口合约上。

ERC721相关库

Address库

Address库是Address变量相关函数的合集，包括判断某地址是否为合约，更安全的function call。ERC721用到其中的isContract()：

    function isContract(address account) internal view returns (bool) {
        return account.code.length > 0;
    }

这个函数利用了非合约地址account.code的长度为0的特性，从而区分某个地址是否为合约地址。

ERC721主合约在_checkOnERC721Received()函数中调用了isContract()。

    function _checkOnERC721Received(
        address from,
        address to,
        uint256 tokenId,
        bytes memory _data
    ) private returns (bool) {
        if (to.isContract()) {
            try IERC721Receiver(to).onERC721Received(_msgSender(), from, tokenId, _data) returns (bytes4 retval) {
                return retval == IERC721Receiver.onERC721Received.selector;
            } catch (bytes memory reason) {
                if (reason.length == 0) {
                    revert("ERC721: transfer to non ERC721Receiver implementer");
                } else {
                    assembly {
                        revert(add(32, reason), mload(reason))
                    }
                }
            }
        } else {
            return true;
        }
    }

该函数的目的是在接收ERC721代币的时候判断该地址是否是合约地址；如果是合约地址，则继续检查是否实现了IERC721Receiver接口（ERC721的接收接口），防止有人误把代币转到了黑洞。

Context库

Context库非常简单，封装了两个Solidity的global变量：msg.sender和msg.data

abstract contract Context {
    function _msgSender() internal view virtual returns (address) {
        return msg.sender;
    }

    function _msgData() internal view virtual returns (bytes calldata) {
        return msg.data;
    }
}

这两个函数只是单纯的返回msg.sender和msg.data。所以Context库就是为了用函数把msg.sender和msg.data关键词包装起来，应对solidity未来某次升级换掉关键字的情况，没其他作用。

Strings库

String库包含两个库函数：toString()和toHexString()。toString()把uint256直接转换成string，比如777变为”777”；而toHexString()把uint256先转换为16进制，再转换为string，比如170变为”0xaa”。ERC721调用了toString()函数：

    function toString(uint256 value) internal pure returns (string memory) {
        if (value == 0) {
            return "0";
        }
        uint256 temp = value;
        uint256 digits;
        while (temp != 0) {
            digits++;
            temp /= 10;
        }
        bytes memory buffer = new bytes(digits);
        while (value != 0) {
            digits -= 1;
            buffer[digits] = bytes1(uint8(48 + uint256(value % 10)));
            value /= 10;
        }
        return string(buffer);
    }

这个函数先确定了传入的uint256参数是几位数，并存在digits变量中。然后用循环把每一位数字的ASCII码转换成bytes1，存在buffer中，最后把buffer转换成string返回。

ERC721主合约在tokenURI()函数中调用了toString()：

    function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {
        require(_exists(tokenId), "ERC721Metadata: URI query for nonexistent token");

        string memory baseURI = _baseURI();
        return bytes(baseURI).length > 0 ? string(abi.encodePacked(baseURI, tokenId.toString())) : "";
    }

这个函数把baseURI和指定的tokenId拼接到一起，返回ERC721 metadata的网址，你花几十个ETH买的的jpeg就是存在这个网址上的。

总结

这一讲是ERC721专题的第一讲，我们概览了ERC721的合约，并介绍了ERC721主合约调用的3个库合约Address，Context和String。

异常

写智能合约经常会出bug，solidity中的异常命令帮助我们debug。

Error

Error是solidity 0.8版本新加的内容，方便且高效（省gas）的向用户解释操作失败的原因。人们可以在contract之外定义异常。下面，我们定义一个TransferNotOwner异常，当用户不是代币owner的时候尝试转账，会抛出错误：

error TransferNotOwner(); // 自定义error

在执行当中，error必须搭配revert（回退）命令使用。

    function transferOwner1(uint256 tokenId, address newOwner) public {
        if(_owners[tokenId] != msg.sender){
            revert TransferNotOwner();
        }
        _owners[tokenId] = newOwner;
    }

我们定义了一个transferOwner1()函数，他会检查代币的owner是不是发起人，如果不是，就会抛出TransferNotOwner异常；如果是的话，就会转账。

Require

require命令是solidity 0.8版本之前抛出异常的常用方法，目前很多主流合约仍然还在使用它。他很好用，唯一的缺点就是gas随着描述异常的字符串长度增加，比error命令要高。使用方法：require(检查条件，”异常的描述”)，当检查条件不成立的时候，就会抛出异常。

我们用require命令重写一下上面的transferOwner函数：

    function transferOwner2(uint256 tokenId, address newOwner) public {
        require(_owners[tokenId] == msg.sender, "Transfer Not Owner");
        _owners[tokenId] = newOwner;
    }

Assert

assert命令一般用于程序员写程序debug，因为他不能解释抛出异常的原因（比require少个字符串）。他的用法很简单，require(检查条件），当检查条件不成立的时候，就会抛出异常。

我们用assert命令重写一下上面的transferOwner函数：

    function transferOwner3(uint256 tokenId, address newOwner) public {
        assert(_owners[tokenId] == msg.sender);
        _owners[tokenId] = newOwner;
    }

三种方法的gas比较

我们比较一下三种抛出异常的gas消耗，方法很简单，部署合约，分别运行写的transferOwner函数的三个版本。

1. error方法gas消耗：24445

2. require方法gas消耗：24743

3. assert方法gas消耗：24446

我们可以看到，error方法gas cost最少，其次是assert，require方法消耗gas最多！因此，error既可以告知用户抛出异常的原因，又能省gas，大家要多用！

总结

这一讲，我们介绍solidity三种抛出异常的方法：error，require和assert，并比较了三种方法的gas消耗。结论：error既可以告知用户抛出异常的原因，又能省gas。

库函数

库函数是一种特殊的合约，主要是为了提升solidity代码的复用性和减少gas fee而存在。库合约一般都是一些好用的函数合集（库函数），由大神或者项目方创作，咱们站在巨人的肩膀上，会用就行了。

库合约：站在巨人的肩膀上

他和普通合约主要有以下几点不同：

• 不能存在状态变量

• 不能够继承或被继承

• 不能接收以太币

• 不可以被销毁

String库合约

String库合约是将uint256类型转换为相应的string类型的代码库，样例代码如下：

library Strings {
    bytes16 private constant _HEX_SYMBOLS = "0123456789abcdef";

    /**
     * @dev Converts a `uint256` to its ASCII `string` decimal representation.
     */
    function toString(uint256 value) public pure returns (string memory) {
        // Inspired by OraclizeAPI's implementation - MIT licence
        // https://github.com/oraclize/ethereum-api/blob/b42146b063c7d6ee1358846c198246239e9360e8/oraclizeAPI_0.4.25.sol

        if (value == 0) {
            return "0";
        }
        uint256 temp = value;
        uint256 digits;
        while (temp != 0) {
            digits++;
            temp /= 10;
        }
        bytes memory buffer = new bytes(digits);
        while (value != 0) {
            digits -= 1;
            buffer[digits] = bytes1(uint8(48 + uint256(value % 10)));
            value /= 10;
        }
        return string(buffer);
    }

    /**
     * @dev Converts a `uint256` to its ASCII `string` hexadecimal representation.
     */
    function toHexString(uint256 value) public pure returns (string memory) {
        if (value == 0) {
            return "0x00";
        }
        uint256 temp = value;
        uint256 length = 0;
        while (temp != 0) {
            length++;
            temp >>= 8;
        }
        return toHexString(value, length);
    }

    /**
     * @dev Converts a `uint256` to its ASCII `string` hexadecimal representation with fixed length.
     */
    function toHexString(uint256 value, uint256 length) public pure returns (string memory) {
        bytes memory buffer = new bytes(2 * length + 2);
        buffer[0] = "0";
        buffer[1] = "x";
        for (uint256 i = 2 * length + 1; i > 1; --i) {
            buffer[i] = _HEX_SYMBOLS[value & 0xf];
            value >>= 4;
        }
        require(value == 0, "Strings: hex length insufficient");
        return string(buffer);
    }
}

他主要包含两个函数，toString()将uint256转为string，toHexString()将uint256转换为16进制，在转换为string。

如何使用库合约

我们用String库函数的toHexString()来演示两种使用库合约中函数的办法。

1. 利用using for指令：

指令 using A for B; 可用于附加库函数（从库 A）到任何类型（B）。添加完指令后，库A中的函数会自动添加为B类型变量的成员，可以直接调用。注意：在调用的时候，这个变量会被当作第一个参数传递给函数：

    // 利用using for指令
    using Strings for uint256;
    function getString1(uint256 _number) public pure returns(string memory){
        // 库函数会自动添加为uint256型变量的成员
        return _number.toHexString();
    }

2. 通过库合约名称调用库函数：

    // 直接通过库合约名调用
    function getString2(uint256 _number) public pure returns(string memory){
        return Strings.toHexString(_number);
    }

我们部署合约并输入170测试一下，两种方法均能返回正确的16进制string “0xaa”。证明我们调用库函数成功！

成功调用库函数

总结

这一讲，我们用ERC721的引用的库函数String为例介绍solidity中的库函数（Library）。99%的开发者都不需要自己去写库合约，会用大神写的就可以了。我们只需要知道什么情况该用什么库合约。常用的有：

1. String：将uint256转换为String

2. Address：判断某个地址是否为合约地址

3. Create2：更安全的使用Create2 EVM opcode

4. Arrays：跟数组相关的库函数

抽象合约

如果一个智能合约里至少有一个未实现的函数，即某个函数缺少{}中的内容，则必须将该合约标为abstract，不然编译会报错；另外，未实现的函数需要加virtual，以便子合约重写。拿我们之前的插入排序合约为例，如果我们还没想好具体怎么实现插入排序函数，那么可以把合约标为abstract，之后让别人补写上。

abstract contract InsertionSort{
    function insertionSort(uint[] memory a) public pure virtual returns(uint[] memory);
}ERC

接口

接口也是一种合约，跟抽象合约类似，都是为了设立标准和减少代码冗余，但是接口的要求更加严格：

1. 不能包含状态变量

2. 不能包含构造函数

3. 不能继承除接口外的其他合约

4. 所有函数都必须是external（接口与合约的ABI等价）

我们看一个ERC721接口的例子，所有NFT都使用了这个接口：

interface IERC721 is IERC165 {
    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);
    
    function balanceOf(address owner) external view returns (uint256 balance);

    function ownerOf(uint256 tokenId) external view returns (address owner);

    function safeTransferFrom(address from, address to, uint256 tokenId) external;

    function transferFrom(address from, address to, uint256 tokenId) external;

    function approve(address to, uint256 tokenId) external;

    function getApproved(uint256 tokenId) external view returns (address operator);

    function setApprovalForAll(address operator, bool _approved) external;

    function isApprovedForAll(address owner, address operator) external view returns (bool);

    function safeTransferFrom( address from, address to, uint256 tokenId, bytes calldata data) external;
}

这个接口里面共定义了3个events和9个function，为所有ERC721函数设立了标准：所有ERC721合约都要实现这些function。

ERC721接口的Events

接口中事件的定义和正常合约里一样。ERC721接口里面的events包括：

1. Transfer（转账事件）：记录发起地址，接收地址，和tokenId

2. Approve（批准事件）：记录持有地址，批准地址，和tokenId

3. ApproveForAll（批量批准事件）：记录持有地址，批准地址，和一个代表批准与否的bool值。可以看到，接口中的事件和正常合约里的事件一样。

ERC721接口的Function

接口中所有function都必须带有external标签（不需要写virtual标签，因为默认为virtual）。ERC721接口里面的function包括：

1. balanceOf：查询某个地址的NFT持有量

2. ownerOf：查询某个tokenId的持有人

3. safeTransferFrom：安全转账（如果接收方是合约地址，会要求实现ERC721的接收接口）。

4. transferFrom：普通转账

5. approve：批准另一个地址使用你的NFT

6. getApproved：查询NFT被批准给了哪个地址

7. setApprovalForAll：将全部NFT批量批准给某个地址

8. isApprovedForAll：查询全部NFT是否批准给了某个地址

9. safeTransferFrom：安全转账，与7.不同的地方在于参数里面包含了data

什么时候使用抽象合约和接口？

1. 写大工程的时候打草稿用

2. 大神写标准的时候

总结

这一讲，我介绍了solidity中的抽象合约（abstact）和接口（interface），他们都可以写模版并且减少代码冗余。我们还讲了ERC721接口合约，以后会更详细的讲一下ERC721代币标准。

继承

继承是面向对象编程很重要的组成部分，可以显著减少重复代码。如果把合约看作是对象的话，solidity也是面向对象的编程，也支持继承。

规则

virtual: 父合约中的函数，如果希望子合约重写，需要加上virtual关键字。

override：子合约重写了父合约中的函数，需要加上override关键。

简单继承

我们先写一个简单的爷爷合约Yeye，里面包含3个function: hip(), pop(), yeye()，返回值都是”Yeye”。

contract Yeye {
    // 定义3个function: hip(), pop(), man()，返回值设为A。
    function hip() public pure virtual returns (string memory){
        return("Yeye");
    }

    function pop() public pure virtual returns (string memory){
        return("Yeye");
    }

    function yeye() public pure virtual returns (string memory){
        return("Yeye");
    }
}

我们再定义一个爸爸合约Baba，让他继承Yeye合约，语法就是contract Baba is Yeye，非常直观。在Baba合约里，我们重写一下hip()和pop()这两个函数，加上override关键字，并将他们的返回值改为”Baba”；并且加一个新的函数baba，返回值也是”Baba”。

contract Baba is Yeye{
    // 继承两个function: hip()和pop()，返回值改为B。
    function hip() public pure virtual override returns (string memory){
        return("Baba");
    }

    function pop() public pure virtual override returns (string memory){
        return("Baba");
    }

    function baba() public pure virtual returns (string memory){
        return("Baba");
    }
}

我们部署合约，可以看到Baba合约里有4个函数，其中hip()和pop()的返回值被成功改写成”Baba”，而继承来的yeye()的返回值仍然是”Yeye”。

Baba合约成功重写了hip()和pop()

多重继承

solidity的合约可以继承多个合约。规则：

1. 继承时要按辈分最高到最低的顺序排。比如我们写一个Erzi合约，继承Yeye合约和Baba合约，那么就要写成contract Erzi is Yeye, Baba，而不能写成contract Erzi is Baba, Yeye，不然就会报错。

2. 如果某一个函数在多个继承的合约里都存在，比如例子中的hip()和pop()，在子合约里必须重写，不然会报错。

3. 重写在多个父合约中重名函数时，override关键字后面要加上父合约名字，例如override(Yeye, Baba)。

例子：

contract Erzi is Yeye, Baba{
    // 继承两个function: hip()和pop()，返回值改为B。
    function hip() public pure virtual override(Yeye, Baba) returns (string memory){
        return("Erzi");
    }

    function pop() public pure virtual override(Yeye, Baba) returns (string memory){
        return("Erzi");
    }
}

我们可以看到，Erzi合约里面重写了hip()和pop()两个函数，将返回值改为”Erzi”，并且还分别从Yeye和Baba合约继承了yeye()和baba()两个函数。

Erzi合约继承了baba()和yeye()

修饰器的继承

Solidity中的修饰器（Modifier）同样可以继承，用法与函数继承类似，在相应的地方加virtual和override关键字即可。

构造函数的继承

子合约有两种方法即成父合约的构造函数。举个简单的例子，父合约A里面有一个状态变量a，并由构造函数的参数来确定：

// 构造函数的继承
abstract contract A {
    uint public a;

    constructor(uint _a) {
        a = _a;
    }
}

1. 在继承时声明父构造函数的参数，例如：contract B is A(1)

2. 在子合约的构造函数中声明构造函数的参数，例如：

contract C is A {
    constructor(uint _c) A(_c * _c) {}
}

总结

这一讲，我们介绍了solidity继承的基本用法，包括简单继承，多重继承，以及修饰器和构造函数的继承。

事件

Solidity中的事件（event）是EVM上日志的抽象，它具有两个特点：

1. 响应：应用程序（ether.js）可以通过RPC接口订阅和监听这些事件，并在前端做响应。

2. 经济：事件是EVM上比较经济的存储数据的方式，每个大概消耗2000-5000 gas不等。相比之下，存储一个新的变量至少需要20,000 gas。

规则

事件的声明由event关键字开头，然后跟事件名称，括号里面写好时间需要记录的变量类型和变量名。以ERC20代币合约的Transfer事件为例：

event Transfer(address indexed from, address indexed to, uint256 value);

我们可以看到，Transfer事件共记录了3个变量 from，to和value，分别对应代币的转账地址，接收地址和转账数量。同时from和to前面带着indexed关键字，表示很重要，程序可以轻松的筛选出特定转账地址和接收地址的转账事件。每个事件最多有3个带indexed的变量。

我们可以在函数里释放事件。在下面的例子中，每次用_transfer()函数进行转账操作的时候，都会释放Transfer事件，并记录相应的变量。

    // 定义_transfer函数，执行转账逻辑
    function _transfer(
        address from,
        address to,
        uint256 amount
    ) external {

        _balances[from] = 10000000; // 给转账地址一些初始代币

        _balances[from] -=  amount; // from地址减去转账数量
        _balances[to] += amount; // to地址加上转账数量

        // 释放事件
        emit Transfer(from, to, amount);
    }

在etherscan上查询事件

我们尝试用_transfer()函数在Rinkeby测试网络上转账100代币，可以在etherscan上查询到相应的tx：

点击Logs按钮，就能看到事件明细：

Event明细

Topics里面有三个元素，[0]是这个事件的哈希，[1]和[2]是我们定义的两个index变量的信息，即转账的转出地址和接收地址。Data里面是剩下的不带index的变量，也就是转账数量。

总结

这一讲，我们介绍了如何使用和查询solidity中的事件。很多链上分析工具包括Nansen和Dune Analysis都是基于事件工作的。

构造函数

构造函数（constructor）是一种特殊的函数，每个合约可以定义一个，并在部署合约的时候自动运行一次。它可以用来初始化合约的一些参数，例如初始化合约的owner地址：

   address owner; // 定义owner变量

   // 构造函数
   constructor() public {
      owner = msg.sender; // 在部署合约的时候，将owner设置为部署者的地址
   }

修饰器

修饰器（modifier）是solidity特有的语法，类似于面向对象编程中的decorator，声明函数拥有的特性，并减少代码冗余。它就像钢铁侠的智能盔甲，穿上它的函数会带有某些特定的行为。modifier的主要使用场景是运行函数前的检查，例如地址，变量，余额等。

钢铁侠的modifier

我们定义一个叫做onlyOwner的modifier：

   // 定义modifier
   modifier onlyOwner {
      require(msg.sender == owner); // 检查调用者是否为owner地址
      _; // 如果是的话，继续运行函数主体；否则报错并revert交易
   }

代有onlyOwner修饰符的函数只能被owner地址调用，比如下面这个例子：

   function changeOwner(address _newOwner) external onlyOwner{
      owner = _newOwner; // 只有owner地址运行这个函数，并改变owner
   }

我们定义了一个changeOwner函数，运行他可以改变合约的owner，但是由于onlyOwner修饰符的存在，只有原先的owner可以调用，别人调用就会报错。这也是最常用的控制智能合约权限的方法。

OppenZepplin的Ownable标准实现：

总结

这一讲，我们介绍了solidity中的构造函数和修饰符，并举了一个控制合约权限的Ownable合约。

该项目分为两个NFT系列，一个是MyPunks Face（以下简称Face），一个是MyPunks Item（以下简称Item，就是眼镜、头发、口红、衣服等各种traits），貌似两个系列的所有元素均为Crypto Punks的设计元素。

鄙人本着对Crypto Punks的热爱，并且对该项目如何实现可定制化NFT这一目标十分好奇，故关注并购买了该项目的两个系列NFT，并自己定制的两个MyPunks。本文记录并分享一下该项目从技术上是如何实现定制NFT这一目标的。

中年大叔style

东北二人转Style

NFT的定制过程

首先你需要购买至少各一个Face和Item。Face当初是每个地址可以免费mint 2个，而1个Item的公售价格是0.035E，截止到目前为止，Face已经全部mint完了，而Item还未mint完（就目前行情来说项目方可能会考虑降价）。

在拥有了Face和Item之后，即可登陆MyPunks官网定制页面进行定制，整个定制过程你需要做的就是：

1. 选择一个Face

2. 选择最多七个Item

3. 确认效果后进行确认即可（确认操作需要上链，上链之后发生什么见后文）

定制界面

这里需要说明几点：

• Face NFT是一个独立合约，Item NFT也是一个独立合约，所以两者都可以独立买卖

• 定制好的NFT实际上还是那个Face NFT，只不过将Item与Face绑定在一起了

• 定制好NFT后，你在OpenSea或者钱包里将看不见你那些已被使用了的Item，但你能看见这些Item在你的Face NFT上

• 定制好的NFT可以转移和卖出，但是卖出后已经装饰的Item也会一并转移，所以如果你准备给你的Face装饰多个Item的话，一定要挂高一些的价格

• 定制好的NFT也可以拆分（拆分也是一个上链操作），拆分后你又能在OpenSea或者钱包里看见你的Item NFT，然后根据自己的喜好重新组装

如何实现

定制NFT

上文所述用Item去装饰Face这个操作需要上链，而整个上链过程从Item的合约来看，就是将Item NFT转到Face NFT合约地址的一个过程。

Item合约片段

当你用Item去装饰Face的时候就是调用上图中Item合约里的stakeItem这个方法 ，该方法会将传入的所有Item NFT转移到Face这个合约中去（相当于质押），这些Item的Owner将会变成Face的合约地址，所以你从你的钱包里将看不到这些Item。

当调用Item合约中的safeTransferFrom方法发送Item到Face合约地址时，会去调用Face合约中的onERC721Received这个方法，该方法触发了Face合约去记录被装饰的Face都绑定了哪些Items。

Face合约片段

上图中“items”这个map变量就记录了faceId对应绑定的itemId列表。这个“items”非常重要，相当于Face合约中不仅仅记录了你拥有哪些Face，并且还可以根据你拥有的Face得到你拥有了哪些Item。Item是与Face绑定的，这也就是为什么当你卖出或者转移了Face之后，所有已经绑定了的Item也会跟着被转移的原因。

以上过程就完成了NFT的定制：将Item从你的钱包转移至Face合约地址，同时在Face合约中记录该Face绑定了哪些Item。

之前我们见到的大多数NFT的Metadata信息基本上都是存在IPFS上的（关于Metadata信息的科普建议看看鄙人这篇文章），因为所有的Metadata信息都预先知道，所以提前制作好上传到IPFS上，与此同时项目方一般会在合约里保留设置baseURI的权利以实现开盲盒等操作。

但对于MyPunks这种需要根据用户定制动态生成Metadata的情况，项目方的解决方案是采用HTTP方式通过中心化服务器生成，也就是说Face和Item的所属权上链，而定制NFT的Medata信息采用中心化方式动态返回。

调用tokenURI方法

如图所示，调用Face合约查询1172这个Face的tokenURI返回的是一个HTTP的API地址，MyPunks的中心化服务器可以根据链上1172这个Face绑定了哪些Item动态地返回相应的Metadata信息，从而让用户从OpenSea可以看到对应的图片及属性。

OpenSea展示该Face NFT的Metadata信息

同时Face合约还提供了修改名字方法，除了可以定制自己NFT的样子之外，你还可以给自己的NFT定制专有的名字。

实际上鄙人不太喜欢HTTP方式去存储NFT的Metadata，因为这样项目方可以更容易且毫无察觉地修改Metadata。目前大多数NFT合约几乎都用IPFS，虽然去中心化存储不可以修改已存储的Metadata，但大多NFT合约也都会有留有Admin权限，只要Admin操作一次setBaseURI实际上也可以修改NFT指向的Metadta信息，从而修改NFT的Metadata（如果修改了可以在链上查到）。

MyPunks这个项目为了实现可定制化的NFT，将NFT的所有权上链，而metadata采用服务器动态生成的方式，鄙人认为还是可以接受。鄙人一贯的观点是，完全去中心化和完全中心化都是偏激的，重要的是需要达成的目标，具体实现目标的方式可以灵活调整。

如果非要使用去中心化方式存储，鄙人能想到的方案就是穷尽所有Face+Item组合的可能，将所有组合的metadata放到IPFS上，然后合约中根据Face+Item的组合去拼IPFS的tokenURI拿到Metadata，但是各种各样组合的数量实在是太多了。

抑或是像鄙人之前这个文章中说Pak的Censored项目方案一样，将Face和Item的图片数据存储到链上，然后根据Face+Item的组合在合约里动态地去拼装一个SVG图片，这个难度实际上也不小，同时存储的成本费用也不低。。。

这里同时也希望下一个定制化NFT的项目能有更好的Metadata动态生成的解决方案。

拆分NFT

定制好的NFT因为有了上述的“items”变量存在，因此拆分也就变得容易了。拆分的过程实际上就是根据“items”存储的Face和Item的绑定信息，将Item从Face的合约地址转回到该Face的Owner钱包地址去。

Face合约中的拆分代码

拆分是调用Face合约中的withdraw方法，在维护好“items”这个变量状态之后，最终Item的转移实际上又是去调用的是Item合约的“unstakeItem”方法

Item合约中的解除质押代码

上图是Item合约中“unstakeItem”方法，该方法就是将这些Item转到这个Face的owner钱包地址去。

所以拆分后，你就可以在你的钱包地址里重新看见这些Item，并且开始新的定制再创作了。同时如果市场上没有你喜欢的Item出售，你也可以考虑购买一个包含你喜欢Item的MyPunk，买来整个MyPunks将其拆分，它上面的所有Item也就都属于你了。

最后

目前在NFT熊市，且项目同质化非常严重的市场环境下，MyPunks的创新和探索是值得鼓励和认可的。但目前看来市场的接受度并不是太高，很便宜的价格、很低的交易量，并且连Item都没mint完。即便如此鄙人还是觉得需要各个NFT项目方从更多方面去突破创新，来丰富NFT的生态以及扩宽NFT的边界，而不是一味地在10K形式的PFP上内卷。

利益相关：MyPunks这个项目比较新颖，所以鄙人购买了一些，已被深深套牢，虽然价格不贵钱也不多，但建议我的读者朋友们就别入坑了。如果是不差钱的大佬想尝试玩玩，也欢迎为鄙人接盘，哈哈。

控制流

Solidity的控制流与其他语言类似，主要包含以下几种：

1. if-else

    // if else
    function IfElseTest(uint256 _number) public returns(uint256){
        if(条件){
            ...;
        }else{
            ...;
        }
    }

2 for循环

        for(uint256 i = 0; i < n; i++){
            ...;
        }

3. while循环

        while(i < n){
            ...;
        }

4. do-while循环

        do{
            ...;

        }while(i < n);

另外还有continue（立即进入下一个循环）和break（跳出当前循环）关键字可以使用。

用solidity实现插入排序

写在前面：90%以上的人用solidity写插入算法都会出错。

插入排序

排序算法解决的问题是将无序的一组数字，例如[2, 5, 3, 1]，从小到大一次排列好。插入排序（InsertionSort）是最简单的一种排序算法，也是很多人学习的第一个算法。它的思路很简答，从前往后，依次将每一个数和排在他前面的数字比大小，如果比前面的数字小，就互换位置。示意图：

插入排序

python代码

我们可以先看一下插入排序的python代码：

# Python program for implementation of Insertion Sort
def insertionSort(arr):
    for i in range(1, len(arr)):
        key = arr[i]
        j = i-1
        while j >=0 and key < arr[j] :
                arr[j+1] = arr[j]
                j -= 1
        arr[j+1] = key

改写成solidity后有BUG！

一共8行python代码就可以完成插入排序，非常简单。那么我们将它改写成solidity代码，将函数，变量，循环等等都做了相应的转换，只需要9行代码：

    // 插入排序 错误版
    function insertionSortWrong(uint[] memory a) public pure returns(uint[] memory) {
        
        for (uint i = 1;i < a.length;i++){
            uint temp = a[i];
            uint j=i-1;
            while( (j >= 0) && (temp < a[j])){
                a[j+1] = a[j];
                j--;
            }
            a[j+1] = temp;
        }
        return(a);
    }

那我们把改好的放到remix上去跑，输入[2, 5, 3, 1]。BOOM！有bug！改了半天，没找到bug在哪。我又去google搜”solidity insertion sort”，然后发现网上用solidity写的插入算法教程都是错的，比如

1. Sorting in Solidity without Comparison

2. Solidity Insertion sort for sorting less than 10 items with reference

正确的solidity插入排序

花了几个小时，在Dapp-Learning社群一个朋友的帮助下，终于找到了bug所在。solidity中最常用的变量类型是uint，也就是正整数，取到负值的话，会报underflow错误。而在插入算法中，变量j有可能会取到-1，引起报错。

这里，我们需要把j加1，让它无法取到负值。正确代码：

    // 插入排序 正确版
    function insertionSort(uint[] memory a) public pure returns(uint[] memory) {
        // note that uint can not take negative value
        for (uint i = 1;i < a.length;i++){
            uint temp = a[i];
            uint j=i;
            while( (j >= 1) && (temp < a[j-1])){
                a[j] = a[j-1];
                j--;
            }
            a[j] = temp;
        }
        return(a);
    }

运行后的结果：

输入[2,5,3,1] 输出[1,2,3,5]

总结

这一讲，我们介绍了solidity中控制流，并且用solidity写了插入排序。看起来很简单，但实际很难。这就是solidity，坑很多，每个月都有项目因为这些小bug损失几千万甚至上亿美元。掌握好基础，不断练习，才能写出更好的solidity代码。

映射Mapping

在映射中，人们可以通过键（Key）来查询对应的值（Value），比如：通过一个人的id来查询他的钱包地址。

声明映射的格式为 mapping(_KeyType => _ValueType)，其中_KeyType和_ValueType分别是Key和Value的变量类型。例子：

    mapping(uint => address) public idToAddress; // id映射到地址
    mapping(address => address) public swapPair; // 币对的映射，地址到地址

映射的规则

规则1：映射的_KeyType只能选择solidity默认的类型，比如uint，address等，不能用自定义的结构体。而_ValueType可以使用自定义的类型。下面这个例子会报错，因为_KeyType使用了我们自定义的结构体：

    // 我们定义一个结构体 Struct
    struct Student{
        uint256 id;
        uint256 score; 
    }
     mapping(Student => uint) public testVar;

规则2：映射的存储位置必须是storage，因此可以用于合约的状态变量，函数中的stoage变量。不能用于public函数的参数或返回结果中。

规则3：如果映射声明为public，那么solidity会自动给你创建一个getter函数，可以通过Key来查询对应的Value。

规则4：给映射新增的键值对的语法为var[_Key] = _Value ，其中是映射变量名，分别_Key和_Value对应新增的键值对。例子：

    function writeMap (uint _Key, address _Value) public{
        idToAddress[_Key] = _Value;
    }

总结

这一讲，我们介绍了solidity中哈希表——映射（Mapping）的用法。至此，我们已经学习了所有常用变量种类，之后我们会学习控制流if-else, while等。

数组 array

数组（Array）是solidity常用的一种变量类型，用来存储一组数据（整数，字节，地址等等）。数组分为固定长度数组和可变长度数组两种：

• 固定长度数组：在声明时指定数组的长度。用T[k]的格式声明，其中T是元素的类型，k是长度，例如：

    // 固定长度 Array
    uint[8] array1;
    byte[5] array2;
    address[100] array3;

• 可变长度数组：在声明时不指定数组的长度。用T[]的格式声明，其中T是元素的类型，例如（bytes比较特殊，是数组，但是不用加[]）：

    // 可变长度 Array
    uint[] array4;
    byte[] array5;
    address[] array6;
    bytes array7;

创建数组的规则

在solidity里，创建数组有一些规则：

• 对于memory可变长度数组，可以用new操作符来创建，但是必须声明长度，并且长度不能改变。例子：

    // memory可变长度 Array
    uint[] memory array8 = new uintUnsupported embed;
    bytes memory array9 = new bytes(9);

• 数组字面常数是写作表达式形式的数组，并且不会立即赋值给变量，例如 [uint(1),2,3]（需要声明第一个元素的类型，不然默认用存储空间最小的类型）

• 如果创建的是dynamic array，你需要一个一个元素的赋值。

        uint[] memory x = new uintUnsupported embed;
        x[0] = 1;
        x[1] = 3;
        x[2] = 4;

数组成员

• length: 数组有一个包含元素数量的length成员， 内存数组的长度在创建后是固定的。

• push():可变长度数组 和 bytes拥有 push() 成员，可以在数组最后添加一个0元素。

• push(x): 可变长度数组 和 bytes拥有 push(x) 成员，可以在数组最后添加一个x元素。

• pop: 可变长度数组 和 bytes拥有 pop 成员，可以移除数组最后一个元素。

结构体 struct

Solidity 支持通过构造结构体的形式定义新的类型。创建结构体的方法：

    // 结构体
    struct Student{
        uint256 id;
        uint256 score; 
    }

    Student student; // 初始一个student结构体

给结构体赋值的两种方法：

    //  给结构体赋值
    // 方法1:在函数中创建一个storage的struct引用
    function initStudent1() external{
        Student storage _student = student; // assign a copy of student
        _student.id = 11;
        _student.score = 100;
    }

     // 方法2:直接引用状态变量的struct
    function initStudent2() external{
        student.id = 1;
        student.score = 80;
    }
  

总结

这一讲，我们介绍了solidity中数组（array）和结构体（struct）的基本用法。下一讲我们将介绍solidity中的哈希表——映射（mapping）。

引用类型(Reference Type)：包括数组（array），结构体（struct）和映射（mapping），这类变量占空间大，赋值时候直接传递地址（类似指针）。由于这类变量比较复杂，占用存储空间大，我们在使用时必须要声明数据存储的位置。

数据位置

solidity数据存储位置有三类：storage，memory和calldata。不同存储位置的gas成本不同。storage类型的数据存在链上，类似计算机的硬盘，消耗gas多；memory和calldata类型的临时存在内存里，消耗gas少。大致用法：

1. storage：合约里的状态变量默认都是storage，存储在链上。

2. memory：函数里的参数和临时变量一般用memory，存储在内存中，不上链。

3. calldata：和memory类似，存储在内存中，不上链。与memory的不同点在于calldata变量不能修改（immutable），一般用于函数的参数。例子：

    function fCalldata(uint[] calldata _x) public pure returns(uint[] calldata){
        //参数为calldata数组，不能被修改
        // _x[0] = 0 //这样修改会报错
        return(_x);
    }

不同类型相互赋值时的规则：

在不同存储类型相互赋值时候，有时会产生独立的副本（修改新变量不会影响原变量），有时会产生引用（修改新变量会影响原变量）。规则如下：

1. storage（合约的状态变量）赋值给本地storage（函数里的）时候，会创建引用，改变新变量会影响原变量。例子：

    uint[] x = [1,2,3]; // 状态变量：数组 x

    function fStorage() public{
        //声明一个storage的变量 xStorage，指向x。修改xCopy也会影响x
        uint[] storage xStorage = x;
        xStorage[0] = 100;
    }

2. storage赋值给memory，会创建独立的复本，修改其中一个不会影响另一个；反之亦然。例子：

    uint[] x = [1,2,3]; // 状态变量：数组 x
    
    function fMemory() public view{
        //声明一个Memory的变量xMemory，复制x。修改xMemory不会影响x
        uint[] memory xMemory = x;
        xMemory[0] = 100;
    }

3. memory赋值给memory，会创建引用，改变新变量会影响原变量。

4. 其他情况，变量赋值给storage，会创建独立的复本，修改其中一个不会影响另一个。

总结

在第4讲，我们介绍了solidity中的引用类型和数据位置，重点是storage, memory和calldata三个关键字的用法。他们出现的原因是为了节省链上有限的存储空间和降低gasfee消耗。下一讲我们会介绍引用类型中的数组。

solidity官方文档里把函数归到数值类型，但我觉得差别很大，所以单独分一类。我们先看一下solidity中函数的形式：

function (<parameter types>) {internal|external} [pure|view|payable] [returns (<return types>)]

看着些复杂，咱们从前往后一个一个看（方括号中的是可写可不写的关键字）：

1. function：声明函数时的固定用法，想写函数，就要以function关键字开头。

2. ()：圆括号里写函数的参数，也就是要输入到函数的变量类型和名字。

3. {internal|external|public|private} ：函数可见性说明符，一共4种。没标明函数类型的，默认internal。

• public: 内部外部均可见，并且自动给stoage变量生成 getter 函数 。

• private: 只能从本合约内部访问，继承的合约也不能用。

• external: 只能从合约外部访问（但是可以用this.f()来调用，f是函数名）

• internal: 只能从合约内部访问，继承的合约可以用。

4. [pure|view|payable]：决定函数权限/功能的关键字。payable很好理解，带着它的函数，运行的时候可以给合约转入ETH。pure和view的介绍见下一节。

5. [returns ()]：函数返回的变量类型和名称。

到底什么是Pure和View？

我刚开始学solidity的时候，一直不理解pure跟view关键字，因为别的语言没有类似的关键字。solidity加入这两个关键字，我认为是因为gas fee。合约的状态变量存储在链上，gas fee很贵，如果不改写这些变量，就不用付gas。调用pure跟view的函数是不需要付gas的。

我画了一个马里奥插画，帮助大家理解。在插画里，我把合约中的状态变量（存储在链上）比作碧池公主，三种不同的角色代表不同的关键字。

WTH is pure and view in solidity?

pure，中文意思是“纯”，在solidity里理解为“纯纯牛马”。包含pure关键字的函数，不能读取也不能写入存储在链上的状态变量。就像小怪一样，看不到也摸不到碧池公主。

view，“看”，在solidity里理解为“看客”。包含pure关键字的函数，能读取但也不能写入状态变量。类似马里奥，能看到碧池，但终究是看客，不能入洞房。

不写pure也不写view，函数既可以读取也可以写入状态变量。类似马里奥里的boss，可以对碧池公主为所欲为🐶。

代码

1. pure v.s. view

我们在合约里定义一个状态变量 _number = 5。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;
contract FunctionTypes{
    uint256 public _number = 5;

定义一个add() function，每次调用，输出 _number + 1。

    // 默认
    function add() external{
        _number = _number + 1;
    }

如果add()包含了pure关键字，例如 function add() pure external，就会报错。因为pure（纯纯牛马）是不配读取合约里的状态变量的，更不配改写。那pure函数能做些什么？举个例子，你可以给函数传递一个参数 _number，然后让他返回 _number+1。

    // pure: 纯纯牛马
    function addPure(uint256 _number) external pure returns(uint256 new_number){
        new_number = _number+1;
    }

如果add()包含view，比如function add() view external，也会报错。因为view能读取，但不能够改写状态变量。可以稍微改写下方程，让他不改写 _number，而是返回一个新的变量。

    // view: 看客
    function addView() external view returns(uint256 new_number) {
        new_number = number + 1;
    }

2. Internal v.s. External

    // internal: 内部
    function minus() internal {
        number = number - 1;
    }

    // 合约内的函数可以调用内部函数
    function minusCall() external {
        minus();
    }

我们定义一个internal的minus()函数，每次调用使得number变量减1。由于是internal，只能由合约内部调用。我们再定义一个external的minusCall()函数，调用minus（）。这样，人们就能通过调用minusCall()来间接调用internal的minus()。

3. Payable

    // payable: 递钱，能给合约支付eth的函数
    function minusPayable() external payable returns(uint256 balance) {
        minus();    
        balance = address(this).balance;
    }

我们定义一个external payable的minusPayable()函数，间接的调用minus()，并且返回合约里的ETH余额（this关键字可以让我们引用合约地址)。我们调用minusPayable()时，往合约里转入1个ETH。

我们可以在返回的信息中看到，合约的余额是1 ETH。

总结

在第三讲，我们介绍了solidity中的函数类型，比较难理解的是pure和view，在其他语言中没出现过。solidity拥有pure和view两种关键字主要是为了节省gas fee和控制函数权限，这两种方程都是不消耗gas的。下一讲我们会介绍引用和映射两种类型，并介绍更复杂的函数。

1. 数值类型(Value Type)：包括布尔型，整数型等等，这类变量赋值时候直接传递数值。

2. 引用类型(Reference Type)：包括数组和结构体，这类变量占空间大，赋值时候直接传递地址（类似指针）。

3. 映射类型(Mapping Type): Solidity里的哈希表。

4. 函数类型(Function Type)：solidity文档里把函数归到数值类型，但我觉得他跟其他类型差别很大，所以单独分一类。

我们只介绍一些常用的类型，不常用的不讲。这篇介绍数值类型，第3讲介绍函数类型，第4讲介绍引用和映射。

数值类型

1. 布尔型：取值是true 或者 false。

    // 布尔值
    bool public _bool = true;

布尔值的运算符，包括：

• ! （逻辑非）

• && （逻辑与， "and" ）

• || （逻辑或， "or" ）

• == （等于）

• != （不等于）

代码：

    // 布尔运算
    bool public _bool1 = !_bool; //取非
    bool public _bool2 = _bool && _bool1; //与
    bool public _bool3 = _bool || _bool1; //或
    bool public _bool4 = _bool == _bool1; //相等
    bool public _bool5 = _bool != _bool1; //不相等

变量_bool的取值是true；_bool1是_bool的非，为false；_bool && _bool1为false；_bool || _bool1为true；_bool == _bool1为false；_bool != _bool1为true。

2. 整型：整数，最常用的包括

    // 整型
    int public _int = -1; // 整数，包括负数
    uint public _uint = 1; // 正整数
    uint256 public _number = 20220330; // 256位正整数

整型的运算符，常用的包括：

• 比较运算符： <= ， < ， == ， != ， >= ， > （返回布尔值）

• 算数运算符： + ， - ， 一元运算 - ， + ， * ， / ， % （取余） ， ** （幂）

代码：

    // 整数运算
    uint256 public _number1 = _number + 1; // +，-，*，/
    uint256 public _number2 = 2**2; // 指数
    uint256 public _number3 = 7 % 2; // 取余数
    bool public _numberbool = _number2 > _number3; // 比大小

大家可以跑一下代码，看看这4个变量分别是多少。答对奖励个POAP？

3. 地址类型：address存储一个 20 字节的值（以太坊地址的大小）。

地址类型也有成员变量，并作为所有合约的基础。有普通的地址和可以转账ETH的地址（payable）。payable的地址拥有balance和tranfer()两个成员，方便查询eth余额以及转账。

代码

    // 地址
    address public _address = 0x7A58c0Be72BE218B41C608b7Fe7C5bB630736C71;
    address payable public _address1 = payable(_address); // payable address，可以转账、查余额
    // 地址类型的成员
    uint256 public balance = _address1.balance; // balance of address

下一讲介绍函数的时候，会介绍如何使用地址类型。

4. 定长字节数组：bytes分两种，一种定长（byte, bytes8, bytes32），另一种不定长。定长的属于数值类型，不定长的是引用类型（之后讲）。

定长bytes可以存一些数据，消耗gas比较少。

代码：

    // 固定长度的字节数组
    bytes32 public _byte32 = "MiniSolidity"; 
    bytes1 public _byte = _byte32[0]; 

“MiniSolidity”以字节的方式存储进变量_byte32，转换成16进制为：0x4d696e69536f6c69646974790000000000000000000000000000000000000000

_byte是_byte32第一个字节，为0x4d。

总结

在第二讲，我们介绍了solidity中4种变量类型，并详细介绍了数值变量（value type)中的布尔型，整型，地址和定长字节数组。之后我们会介绍其他几种类型。

Solidity是以太坊虚拟机（EVM）智能合约的语言。同时，我也觉得solidity是玩链上项目必备的技能：区块链项目大部分是开源的，如果你能读懂代码，能帮你规避很多归钱项目。

Solidity具有两个特点：

1. 基于对象：学会之后，能帮你挣钱找对象。

2. 高级：不会solidity，在币圈显得很low。

开发工具：remix

本教程中，我会用remix来跑solidity合约。remix是以太坊官方推荐的智能合约开发IDE，适合新手，可以在浏览器中快速部署测试智能合约，你不需要在本地安装任何程序。

网址：remix.ethereum.org

进入remix，我们可以看到最左边的菜单有三个按钮，分别对应文件（写代码的地方），编译（跑代码），部署（部署到链上）。我们点新建（Create New File）按钮，就可以创建一个空白的solidity合约。

remix面板

第一个Solidity程序：

很简单，只有1行注释+3行代码：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;
contract HelloWeb3{
    string public _string = "Hello Web3!";}

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

1. 第1行是注释，会写一下这个代码所用的软件许可（license），这里用的是MIT license。如果不写许可，编译时会警告（warning），但程序可以运行。solidity的注释由“//”开头，后面跟注释的内容（不会被程序运行）。

// SPDX-License-Identifier: MIT

2. 第2行声明源文件所用的solidity版本，因为不同版本语法有差别。

pragma solidity ^0.8.4;

这行代码意思是源文件将不允许低于 0.8.4 版本的编译器编译。

3. 第3-4行是合约部分，第3行创建合约（contract），并声明合约的名字 HelloWeb3。第4行是合约的内容，我们声明了一个string（字符串）变量_string，并给他赋值 “Hello Web3!”。

contract HelloWeb3{
    string public _string = "Hello Web3!";}

以后我们会更细的介绍solidity中的变量。

编译并部署代码

在编辑代码的页面，按ctrl+S就可以编译代码，非常方便。

编译好之后，点击左侧菜单的“部署”按钮，进入部署页面。

在默认情况下，remix会用JS虚拟机来模拟以太坊链，运行智能合约，类似在浏览器里跑一条测试脸。并且remix会分配几个测试账户给你，每个里面有100 ETH（测试代币），可劲儿用。你点Deploy（黄色按钮），就可以部署咱们写好的合约了。

部署成功后，你会在下面看到名为HELLOWEB3的合约，点击_string，就能看到我们代码中写的 “Hello Web3!” 了。

总结

第一讲，我们简单介绍了solidity，remix工具，并完成了第一个solidity程序--HelloWeb3。接下来我们会介绍solidity的各种变量类型。

https://github.com/AmazingAng/ERC20Faucet

什么是代币水龙头？

当人渴的时候，就要去水龙头接水；当人想要免费代币的时候，就要去代币水龙头领。代币水龙头就是让用户免费领代币的网站/应用。

最早的代币水龙头是比特币（BTC）水龙头：现在BTC一枚要$44,000，但是在2010年，BTC的价格只有不到$0.1，并且持有人很少。为了扩大影响力，比特币社区的Gavin Andresen开发了BTC水龙头，让别人可以免费领BTC。撸羊毛大家都喜欢，当时就有很多人去撸，然后变成了BTC的信徒。BTC水龙头一共送出了超过19,700枚BTC，现在价值超过8亿美元！

水龙头合约逻辑

• 合约仅发放一种ERC20代币，在初始化的时候确认，存于tokenContact变量。

  constructor(address _tokenContract) { tokenContract = _tokenContract; // set token contract }

• 用户调用requestToken()函数，就能得到空投代币，并且每个用户只能领一次。

  `//allow users to call the requestTokens function to get tokensfunction requestTokens () external {require(requestedAddress[_msgSender()] == false, "Can't Request Multiple Times!");IERC20 token = IERC20(tokenContract);require(token.balanceOf(address(this)) >= amountAllowed, "Faucet Empty!");

    token.transfer(_msgSender(), amountAllowed); // transfer token
    requestedAddress[_msgSender()] = true; // record requested 
      
    emit SendToken(_msgSender(), amountAllowed); // emit event
  

  }`

。

这篇文章鄙人会先讲一讲NFT的合约（ERC721）以及NFT在OpenSea上是如何实现交易的，这两部分的内容比较偏技术，希望可以耐心看完。

NFT与ERC721

NFT的名词定义就不说了，网上有很多资料大家可以自己搜索。

对于NFT来说，实际上就是Ethereum协会定义的一个规范，也就是ERC721，其作用是与Fungible Token的ERC20规范一样，通过这个规范来统一接口，使得在Token或者NFT上可以衍生出各种各样的DAPP生态，比如各种Swap、借贷等等各类DAPP。

NFT的ERC721规范是从ERC20衍生出来了，有很多相同方法，其下规范方法如下：

// 查询NFT中某个owner拥有的数量
balanceOf(owner)

// 查询NFT中某个编号属于的是哪个人，例如查询某个编号的猴属于哪个owner
ownerOf(tokenId)

// 返回NFT的名字
name()

// 返回NFT的符号
symbol()

// NFT总发行量
totalSupply()

// 返回某个NFT的URI，这个URI就是这个NFT的一切描述信息
tokenURI(tokenId)

// 按index序号返回该owner的所有持有NFT的编号
tokenOfOwnerByIndex(owner, index)

// 按index序号返回NFT的编号
tokenByIndex(index)

// 允许to这个地址可以转移他的tokenId编号的NFT（攸关你的NFT安全！）
approve(to, tokenId)

// 查询tokenId编号的NFT授权给了谁（查询谁可以转走你的NFT！）
getApproved(tokenId)

// 授权或者取消授权operator这个地址转移你这一Collection下的所有NFT（攸关你的NFT安全！）
setApprovalForAll(operator, approved)

// 查询某个operator是否有权转移某个owner的这一Collection中的所有NFT（查询某个地址是否可以转走你这个Collection的所有NFT！）
isApprovedForAll(owner, operator)

// 将from这个地址的tokenID编号的NFT转给to这个地址（需要授权才行）
transferFrom(from, to, tokenId)

以上就是几个主要的ERC721规范的方法，虽然写了注释，但是我猜测大家还是一脸懵。

所以下面给大家通过例子来说明，从NFT的起源Mint开始。

Mint铸造

下面这段代码就是OpenZeppelin上一个简单的如何铸造NFT的代码：

// 铸造NFT的方法，只需要传入铸造给谁，再加上这个NFT的tokenURI即可
function awardItem(address player, string memory tokenURI)
    public
    returns (uint256)
{
    _tokenIds.increment();
    uint256 newTokenId = _tokenIds.current();

    // 将这个新的tokenId与player绑定
    _mint(player, newTokenId);

    // 将tokenURI与这个newTokenId绑定
    _setTokenURI(newTokenId, tokenURI);

    return newItemId;
}

铸造NFT实际上就是往NFT的合约里写入了两个信息：

• tokenId及其owner

• tokenId及其tokenURI

有人说NFT又有图片，又有各种属性，怎么这么简单了就铸造出来了呢？

没错，就这么简单！

接下来我们用CryptoApes这个NFT举例给大家看看我们大家看到的各种眼花缭乱的NFT是怎么展示出来的？

Play with NFT contract

我们先来看看如何通过简单的几行代码查询CryptoApes NFT的基本信息：

截图中可以看到，通过向CryptoApes合约调用上述ERC721规范的方法name()，symbol()，totalSupply()，就能拿到这个NFT的名称、符号和总数分别是：CryptoApes，CRAP，6969。

CryptoApes的合约地址以及NFT编号可以在OpenSea中的URL拿到，见下面截图：

可以看到OpenSea的NFT链接 https://opensea.io/assets/0x29714cafe792ef8b8c649451d13c89e21a0d7f5b/24 ，assets后的第一个地址就是该NFT Collection的合约地址，合约地址后的数字就是该NFT编号。

下面我们还是通过几行简单代码调用合约，查询一下这只编号为24的CryptoApes的信息：

可以看到我们通过ERC721规范中的**ownerOf()**方法，就能查到这只CryptoApes的拥有者（没错，就是本人）。

另外通过**balanceOf()**方法就能查到本人总共拥有了4只CryptoApes。

值得注意的是截图中的**tokenURI()**方法，通过它就能获取这个24号NFT的tokenURI。这个tokenURI非常重要！因为里面存储了关于这只猴的所有描述信息（Metadata）。

24号猴的tokenURI是：ipfs://QmWGAFtzyzB6A6gYMnb6838hysHuT2rcV8B98Gmj4T4pyY/24.json，说明是存储在IPFS这个分布式存储上的json文件，我们继续通过这个IPFS的网关地址（https://ipfs.io/ipfs/QmWGAFtzyzB6A6gYMnb6838hysHuT2rcV8B98Gmj4T4pyY/24.json）访问获取里面的内容：

上面截图中就是这只24号猴的所有信息了，包括名字、图片、描述、编号、创建时间、还有背景颜色、毛颜色、嘴巴衣服等各种各样的属性。（大家点开大图就能看见）

其中的图片信息又指向了另外一个IPFS地址：ipfs://QmZFnUm3bjSyEPrvxEa3fR9eUxnkfQeLmPTzDhAmCWtbMZ/24.png，通过这个地址（https://ipfs.io/ipfs/QmZFnUm3bjSyEPrvxEa3fR9eUxnkfQeLmPTzDhAmCWtbMZ/24.png）就能看到24号猴的图片了，这也是OpenSea平台中给大家展示的图片样子。

大家可以看到NFT的所有关键信息都是存在tokenURI这个链接中的，这个链接中的数据包括了你NFT的编号、属性、图片或视频，所以tokenURI这个链下数据能不能正常访问，会不会被篡改非常重要！！！

这里CryptoApes的TokenURI用的是IPFS协议，IPFS协议可以保证不会被篡改。但如果是HTTP协议则有被篡改的可能，虽然使用HTTP协议可以通过checksum校验数据等方式验证，但这并不优雅，并且也不是ERC721的协议规范。

这里插一句，鄙人原本打算写一篇介绍去中心化存储的文章的，因为感觉这个领域的重要性被大家严重忽视了，它也是区块链生态的基础设施，重要性并不比被热捧的各类公链项目低。使用IPFS协议存储内容虽然不会被篡改，但是IPFS还存在它自身的问题，这里就不展开了。

接着说，上面我们查到了编号24的猴的所有关键信息。那如果想把所有6969只CryptoApes的信息查找出来可以吗？

当然可以！使用上述ERC721规范中的“tokenByIndex()”方法进行遍历就行，有兴趣的朋友可以自行试试。

实际上OpenSea支持所有的ERC721的NFT的信息展示，就是通过上述方法去链上抓取数据，并在OpenSea自己的系统中来建立起来所有资源信息，最后通过Web的形式展现到大家面前，方便大家浏览。

这里需要吐槽的是OpenSea网站的robust及performance做得实在太烂了，经常动不动就挂掉，所以鄙人也正着手搞一个类似的产品，从blockchain上同步NFT数据，以及从OpenSea上同步交易数据，存储后按用户需求展示给用户，提供稳定、高效以及易用的浏览及查询服务。（做得好的话未来想象空间也很大，哈哈）

上面通过脚本调用合约给大家展示的都是“读”方法，“写”方法的话就是在代码中加载钱包，签名之后就可以了。（所以挺简单的吧，大家也别被所谓“科学家”这个名字唬住了。简单学习一下编程，再熟悉下合约的调用，就可以通过程序操作多个钱包，去薅羊毛还是干点别的事情就都可以了）

需要警惕的一些方法

ERC721规范中有两个方法需要大家警惕一下，如果不小心也许就会丢掉你的NFT。

第一个需要警惕的方法是“approve(to, tokenId)”，这个方法是授权“to”这个地址有权利可以转走你这个“tokenId”的NFT。如果你在小狐狸中授权钓鱼网站调用了这个方法，最多会损失一个NFT。

这个方法ERC20规范中也有，ERC20是授权“to”地址最多可以使用多少数量的token。鄙人的去中心化红包项目，就是在你发红包之前要求你使用“approve”授权一下，好让红包合约可以扣你的token并装入红包中给大家去抢。各类Swap的DAPP也是一样，需要先“approve”才可以进行swap。

第二个需要警惕的方法是“setApprovalForAll(operator, approved)”，这个方法是授权“operator”这个地址可以转走你在这个Collection下所有的NFT。如果你在小狐狸中授权钓鱼网站调用了这个方法，则可能丢失这个Collection下的所有NFT。

在OpenSea平台中，如果我们“Sell”一个NFT，小狐狸就会弹出这个方法的授权，见下面截图。

注意红框里的内容，就是向CryptoApes的合约地址调用“setApprovalForAll(operator, approved)”这个方法。授权之后，如果有人出价购买，OpenSea的交易合约则可以把你的NFT直接转给买家，转给买家这个操作调用的是ERC721规范中的方法“transferFrom(from, to, tokenId)”，from是你自己，to是买家，tokenId是这个NFT的编号。

所以大家在小狐狸中进行授权的时候，一定有安全意识，看见approve或者setApprovalForAll方法时一定要注意是不是正规的网站，合约地址是不是正确的地址。如果不小心授权错了，你的NFT就可能被转走。

也许有人会问：我只卖出一个NFT，为什么不单独授权这一个出售的NFT（approve），而是要授权所有的NFT呢（setApproveForAll）？

答：OpenSea的解释是可以省gas费，一次授权后，再次卖出其余NFT的时就不需要因为再次授权而付更多的gas费用了。

也许有人会问：那我授权给了OpenSea所有NFT的转移权限，那OpenSea平台会不会悄悄转走我的NFT呢？

关于这个这个问题可以继续看后面。

OpenSea买卖流程的背后

卖出NFT的背后

下图是在你卖出NFT时候的弹窗截图：

在OpenSea上进行卖出操作时，会弹出窗口第一步让你先初始化钱包（这个是一次性操作），在你付了gas费之后，OpenSea的Registry合约会帮你创建一个钱包合约（实际上就是一个Proxy合约），大家如果在etherscan上查的话，可以看到一个RegisterProxy的操作，实际上调用的就是下面代码去创建了一个属于你个人钱包合约：

function registerProxy()
        public
        returns (OwnableDelegateProxy proxy)
    {
        require(proxies[msg.sender] == address(0));
        // 创建一个新的代理合约
        proxy = new OwnableDelegateProxy(msg.sender, delegateProxyImplementation, abi.encodeWithSignature("initialize(address,address)", msg.sender, address(this)));
        proxies[msg.sender] = proxy;
        return proxy;
    }

为什么需要创建这个合约呢？主要目的是为了安全，因为第二步“Approve this item for sale”时需要授权一个合约地址可以转移你的NFT（也就是上一段落说的setApprovalForAll方法），授权可以转移你NFT的地址，就是“Initialize your wallet”这一步所创建的钱包合约地址。

也就是说OpenSea不能直接转走你的NFT，只有你在OpenSea上初次创建的这个钱包地址才可以转走。

在创建完钱包以及授权NFT之后，如果你去挂出同个Collection下的NFT进行卖出时，不需要额外的手续费，OpenSea仅仅验证你的签名就可以挂出卖单了，这点就是被OpenSea宣传的“gas-free listing”。

所以讲到这里，也许有人又注意到了一个问题：为什么后续挂出卖单仅仅只需要签名，不需要 transaction呢？OpenSea的卖单信息只是存到它自己的中心化服务器上，没有存在链上吗？

答：是的，卖单信息只存在OpenSea的中心化服务器上，没有上链，具体可以参考这里OpenSea的解释。

On OpenSea, most actions are off-chain, meaning they generate orders that are stored in the our system and can be fulfilled by a matching order from another user.

When a user lists an item for sale, they simply sign their intent to swap the item for payment. This intent is stored in the OpenSea system as a sell order, and does not create a transaction.

关于很多评论说OpenSea太过中心化这个问题，之后鄙人也会简单谈谈自己观点。

买入NFT的背后

在OpenSea买入的时候，买卖的撮合其实是发生在OpenSea的中心化系统中，匹配好订单后让用户调用OpenSea交易合约地址的AtomicMatch方法完成交易，这个方法里完成了一系列复杂操作，这里就不展开讨论了。

也就是说成交之后，成交订单的信息会上链，毕竟这涉及到了Token和NFT的转移。

OpenSea使用的交易合约应该是Wyvern协议，实际上如果整个交易过程中只有最终交易数据才上链的话，可以不用这么复杂的合约，不过这应该是历史遗留包袱。

大家只需要知道这次买入交易成功的背后，会完成这两个步骤：

1. 把NFT转给买家

2. 把买家的钱转给卖家和OpenSea（平台手续费）

其它交易方式

关于Offer报价以及Auction拍卖的交易方式鄙人没有试过，不过我认为跟Listing交易一样，在offer或者bid之前approve一下你的WETH就行，而auction拍卖订单和Offer报价订单的创建与撮合也应该还是通过OpenSea的中心化系统完成。

关于OpenSea太过中心化的评论

鄙人在网络上看到很多声讨OpenSea太过中心化的评论，这段时间开始买NFT对OpenSea进行研究了之后才了解这些评论的根本原因，实际上OpenSea也是基于当时条件限制下的产物。

鄙人这里也为OpenSea的部分中心化技术方案辩驳几句：

• 首先它降低了手续费，贵族链绝非浪得虚名的。如果所有数据信息上链那必然会导致交易的成本上升，更加提高了用户的交易门槛。（如果所有信息上链的话，我想唯一的好处就是鄙人不会每天收到批量offer的邮件通知了，毕竟每一次offer都需要燃烧gas）

• 其次Etheruem的performance不足以承载大量的transaction，如果每次挂出卖单、修改卖单价格、每次Offer价格等所有信息都上链的话，那会更加进一步推高Ethereum的gas费用。

• 最后关键信息上链也一定程度上确保了交易的安全和公开。比如你NFT和WETH的授权是给到你的钱包合约的，OpenSea不直接触碰。OpenSea也开放了它的API，所有未上链的订单数据可以通过API获取，好心人可以通过API拿到数据后和链上最终的交易数据进行比对验证。（不过我猜测不存在这样的好心人吧）

最近这一年公链的迅猛发展，gas费过高以及性能的问题以及得到了极大的缓解。如果OpenSea不思进取、不做改进的话绝对会被大多数用户抛弃，最后发展成为贵族NFT市场，比如前几天LooksRare平台也来空投抢用户了。当然这个问题也是Ethereum需要面对的。

关于OpenSea的交易背后本人有两个问题：

1. 本人发现在OpenSea上Cancel一个Listing订单，也是需要写入区块链的。但我觉得直接在OpenSea的中心化系统中直接Cancel就好了，毕竟Listing的订单信息也没上链啊，为什么Cancel Listing订单的操作需要上链呢？这gas费不是白白浪费掉了吗？

2. Listing订单价格的修改，只能往低了修改，不能改高了，如果需要报更高价格的话需要先Cancel Listing订单，然后再重新挂一个，而Cancel的时候又得上链浪费一笔gas费用。同样Listing订单数据没在链上，为什么List price都可以往低了改，而不能直接改高呢？

这两个问题本人没太想明白为什么OpenSea这样做，因为个人觉得在中心化系统上取消订单和随意修改订单价格不是很简单的事情吗？

个人不怀好意的猜测是OpenSea系统做得太烂，不愿意让用户随意取消订单和修改价格，因为这样会导致系统的不稳定。所以Cancel Listing这个操作硬要上链，让用户消耗gas，这样用户在挂卖单的时候就需要慎重考虑要不要挂，以及要挂的价格了。

也希望知道原因的朋友不吝赐教！

上面两个问题的解答（2022-01-25更新）

昨天opensea出现了一个问题，很多人高价的NFT以特别低的价格被出售了，损失惨重。本人今天研究了下，顺便这个问题同步更新一下。

在OpenSea官网中有这么一篇文章教用户如何取消订单的，注意截图里的这段话：

大意是如果你挂出过你NFT的卖单，这时你又把你NFT转到另外一个钱包地址，这种情况不会自动取消你NFT的卖单，所以你应该在转走你NFT之前先把卖单取消掉。

而这次出现损失的用户大部分就是这个原因了。例如几个月前， 用户A把他的NFT挂出10ETH的价格出售，当时价格未成交，这时用户A未取消卖单就直接把NFT转到另外的钱包地址（可能是为了安全转到冷钱包）去了。

过了几个月后发现市场价格不错，就把NFT又转回到之前的钱包地址，准备挂单出售，但当刚转回成功的时候就发现NFT被以之前的卖单价格（10ETH）出售了，当前市场价可能是80ETH，造成了严重损失。

之所以可以被10ETH的卖单价格出售，就是因为之前的卖单信息被人盯上了，所以在转回NFT的时候被人立马以10ETH的低价购买成功。

合约分析

上面说过，opensea的卖单信息是中心化存储的，这个卖单信息中包括了你NFT的信息、价格以及签名，同时这个卖单信息可以通过opensea的API查询到。

科学家可以通过opensea的API找到一些价值比较高的NFT的卖单信息，同时监控该NFT是否又被转回到与该卖单信息一致的钱包地址，当发现转回时，科学家调用前文所述的atomicMatch这个方法即可完成交易。

截图中可以看到，atomicMatch方法里有个requireValidOrder内部方法，该方法会去校验这个卖单信息是否有效，签名是否正确等。这个卖单信息是存在opensea上并通过API开放出来的，任何人拿到这个卖单信息并且提供能与之匹配的买单，就能完成交易。

上面这个截图是购买时，requireValidOrder方法里判断卖单信息是否合法的实现，可以看到有一步是通过cancelledOrFinalized这个map类型变量来判断的。

而之前说的取消订单是一个上链操作，就是通过设置cancelledOrFinalized这个状态来控制卖单信息失效的。

总而言之，就是一个用户之前挂过低价卖单，后来NFT转走了就再也没管过这个卖单，而这个高价值NFT的低价卖单信息（包含签名）又被人盯上了，所以当NFT又转回来的时候就可以以之前的低价成交。

本人之所以有上一节的两个问题，完全是因为没看过opensea的API，没想到opensea这么open，把卖单的签名信息也开放出来了，任何第三方拿到这个卖单信息都可以自己下单进行NFT的购买。

如何避免损失？

对于opensea来说，现在这个交易合约是n年前的产物，我觉得可以重新设计一个，做好迁移过度相关的工作，但这个工作量会比较高，费时比较长。我猜opensea已经在计划了，因为opensea上polygon链的NFT已经不再是当前的交易方式。

另外对于opensea来说更简单粗暴的方式就是卖单信息中的签名别开放出去，为了安全更加中心化一些，防止不知情的用户造成损失。

对于用户来说，记得取消卖单，虽然费一些gas费吧。另外如果曾经挂过卖单且没取消过的钱包，就别把NFT往回转了， 就用新钱包直接卖吧。

最后的最后

最近因为PhantaBear的关系对NFT着迷了，鄙人着迷到什么程度呢？我媳妇告诉我，我小学2年级的孩子都在问她同学有没有爆炸头熊的NFT了。。。

着迷到已经有点动摇BTC Hodl决心，盘算着是不是拿点BTC去换一个CryptoPunks的程度，毕竟有NFT第一的故事加持，非常想搞一枚。

关于NFT的胡思乱想

社会的经济活动实际上就是钱和资产相互兑换的过程。比如用钱购买衣服、鞋、车、房就是用钱购买了资产。同样也可以变卖衣服、鞋、车、房将资产换取钱，这就是基本的经济活动。这个交易过程的顺利执行其实是通过合同保证的（买衣服、鞋这类小商品虽然没有实体合同，但实际上存在虚拟合同），而社会法律强制确保了合同可以按预期执行（你要是收了钱但没给我东西，我就可以起诉你）。

你会看到在区块链的世界中是一模一样的，BTC、ETH等各种币就是钱，而玲琅满目的NFT就是个各类资产。crypto可以购买NFT，NFT可以变卖换成crypto，这样就形成了未来元宇宙中的经济活动。交易通过智能合约来完成，而公链的共识机制又确保了智能合约能够以预期方式执行。

你会发现区块链行业的发展与现实社会极其相似，NFT的出现也许不是偶然吧。

不过比较有意思的是，人类社会最早的经济活动只是以物换物，例如我用羊去换你的牛，因为以物换物的不便才出现了货币作为交换的媒介。所以现实社会是先出现资产，再出现货币。但区块链行业中先出现的是各类加密货币，然后才出现了代表资产的NFT，与现实社会相反。

投资建议声明

以上文章内容全是鄙人胡说八道，不作为任何投资建议。

Try on Remix

杰克逊（J·H·Jackson）译《Water Margin》，1937年首版；

沙博理（Sidney Shapiro)译《Outlaws of the Marsh》，1980年首版。

前两种都是七十回本，后一种为百回本。

三个版本在百八将绰号的翻译上，各有千秋，翻译界多有研究和讨论。

比如“及时雨”，赛译：The Opportune Rain，杰译：Welcome Rain，沙译：The Timely Rain。

“青面兽”，赛译和沙译都是The Blue-Faced Beast，杰译为Sallow Faced Brute。

天罡

1．及时雨宋江：The Opportune Rain & 黑三郎：Black-faced Third Brother

2．玉麒麟卢俊义：The Jade Ch'i Lin

3．智多星吴用：The Great Intelligence

4．入云龙公孙胜：Dragon In The Clouds

5．大刀关胜：The Great Sword

6．豹子头林冲：The Leopard Headed

7．霹雳火秦明：The Fire In the Thunder Clap

8．双鞭呼延灼：The Double Clubs

9．小李广花荣：Little Li-Kuan

10．小旋风柴进：The Little Whirl Wind

11．扑天雕李应：The Eagle Who Smites The Heavens

12．美髯公朱仝：The Beautiful Bearded

13．花和尚鲁智深：The Tattooed Priest

14．行者武松：The Hairy Priest

15．双枪将董平：Warrior of The Two Spears

16．没羽箭张清：The Featherless Arrow

17．青面兽杨志：The Blue-Faced Beast

18．金枪将徐宁：The Wielder of the Golden Sword

19．急先锋索超：The Swift Vanguard

20．神行太保戴宗：The Magic Messenger

21．赤发鬼刘唐：The Redheaded Devil

22．黑旋风李逵：The Black Whirl-wind

23．九纹龙史进：The Nine Dragoned

24．没遮拦穆弘：He Whom No Obstacle Can Stay

25．插翅虎雷横：The Winged Tiger

26．混江龙李俊：The Dragon Who Roils Rivers

27．立地太岁阮小二：The God of Swift Death

28．船火儿张横：The Boatman

29．短命二郎阮小五：The Short Lived

30．浪里白条张顺：White Stripe In The Waves

31．活阎罗阮小七：The Fierce King of Devils

32．病关索杨雄：The Sick Kwan-SO

33．拼命三郎石秀：The One Who Heeds Not His Life

34．两头蛇解珍：The Double Headed Snake

35．双尾蝎解宝：The Double Tailed Scorpion

36．浪子燕青：The Prodigal

地煞

37．神机军师朱武：The Wily Warrior

38．镇三山黄信：He Who Rules the Three Mountains

39．病尉迟孙立：The Sick Warrior

40．丑郡马宣赞：The Ugly Warrior

41．井木犴郝思文：The Guardian Star God

42．百胜将韩滔：Victor in A Hundred Battles

43．天目将彭玘：The Eye of Heaven

44．圣水将军单廷珪：Swift in Water

45．神火将军魏定国：Warrior of Fire

46．圣手书生萧让：The Magic Scribe

47．铁面孔目裴宣：The Iron Faced

48．摩云金翅欧鹏：Eagle In The Clouds

49．火眼狻猊邓飞：The Red Eyed Lion

50．锦毛虎燕顺：The Five-Hued Tiger

51．锦豹子杨林：The Five-Hued Leopard

52．轰天雷凌振：Thunder That Shaker The Heavens

53．神算子蒋敬：The God of Accounting

54．小温侯吕方：The lesser Duke

55．赛仁贵郭盛：He Who Is Like Jen-Kuei of Old

56．神医安道全：The Magic Physician

57．紫髯伯皇甫端：The Purple Bearded

58．矮脚虎王英：The Dwarf Tiger

59．一丈青扈三娘：The Ten Foot Green Snake

60．丧门神鲍旭：The God of Death

61．混世魔王樊瑞：The King of the Devils Who Roil Earth

62．毛头星孔明：The Curly Haired

63．独火星孔亮：The Lone Fire

64．八臂哪吒项充：The Eight Armed Lo-Chao

65．飞天大圣李衮：The Heaven Flying God

66．玉臂匠金大坚：The Jade Armed Warrior

67．铁笛仙马麟：The Magic Iron Flautist

68．出洞蛟童威：The Crocodile Out of The Hold

69．翻江蜃童猛：The Oyster That Turns The River Over

70．玉幡竿孟康：The Jade Banner Pole

71．通臂猿侯健：The Strong Armed Gorilla

72．跳涧虎陈达：The Gorge Leaping Tiger

73．白花蛇杨春：The White Spotted Snake

74．白面郎君郑天寿：The White Faced Goodman

75．九尾龟陶宗旺：The Nine Tailed Turtle

76．铁扇子宋清：The Iron Fan

77．铁叫子乐和：The Iron Whistle

78．花项虎龚旺：The Spotted Necked Tiger

79．中箭虎丁得孙：The Arrow Wounded Tiger

80．小遮拦穆春：The Lesser One Whom No Obstacle Can Stay

81．操刀鬼曹正：The Dagger Devil

82．云里金刚宋万：The Guardian God in the Clouds

83．摸着天杜迁：Eagle Who Flutters Against the Sky

84．病大虫薛永：The Sick Tiger

85．金眼彪施恩：The Gold Eyed Tiger Cub

86．打虎将李忠：The Warrior Who Wars Against Tiger

87．小霸王周通：The Little Tyrant

88．金钱豹子汤隆：The Gold Spotted Leopard

89．鬼脸儿杜兴：The Devil Faced

90．出林龙邹渊：The Dragon Out of The Wood

91．独角龙邹润：The One Horned Dragon

92．旱地忽律朱贵：The Dry Land Water Beast

93．笑面虎朱富：The Smiling Faced Tiger

94．铁臂膊蔡福：The Iron Armed

95．一枝花蔡庆：The Single Flower

96．催命判官李立：The Pursuing God of Death

97．青眼虎李云：The Blue-Eyed Tiger

98．没面目焦挺：The Faceless

99．石将军石勇：The Stone Warrior

100．小尉迟孙新：The Lesser Yu-Tse

101．母大虫顾大嫂：The Female Tiger

102．菜园子张清：The Gardener

103．母夜叉孙二娘：The Female Savage

104．活闪婆王定六：The Living Female

105．险道神郁保四：The Vanguard God

106．白日鼠白胜：Rat In The Daylight

107．鼓上蚤时迁：Flea On A Drum

108．金毛犬段景住：The Yellow Haired Dog

额外附送编外人员绰号三个：

109．托塔天王晁盖：The Pagoda Moving Heavenly King

110．镇关西：The Bully of Kuangsi

111．蒋门神：The God of the Gate Chiang