创作者经济是指通过支持创作者的方式来促进经济增长和发展的一种经济模式。在这种模式下，创作者通过创作内容（如音乐、文章、视频等）来获得报酬，从而为经济增加价值。创作者经济的核心理念是通过支持创作者来激发创造力和创新，并从中获益。

创作者经济可以通过多种方式来实现，比如通过版权保护和支付创作者的费用来支持创作者，或者通过提供便利的工具和平台来帮助创作者分发和出售自己的作品。

随着互联网的发展，创作者经济也变得越来越重要。互联网提供了一个全球性的平台，让创作者可以将自己的作品展示给更多的人，并获得更多的支持。同时，互联网也为创作者提供了更多的工具和平台，让他们可以更加轻松地创作和分发作品。

总之，创作者经济是一种支持创作者，促进创新和经济增长的经济模式，它在当今数字化时代具有越来越重要的作用。

创作者如何获得收益

创作者获得收益的方式有很多种，常见的方式有：

• 通过版权保护和版税来获得报酬。在这种情况下，创作者通过登记版权，并与出版商或其他机构签订合同，在其作品被使用或复制时获得报酬。

• 通过提供付费内容来获得报酬。在这种情况下，创作者可以通过提供付费内容，让用户通过支付费用来访问或下载内容。

• 通过广告收入来获得报酬。在这种情况下，创作者可以通过在其作品中植入广告，或者将其作品提供给广告商，通过广告收入来获得报酬。

创作者获得的净收益=创作收益-创作成本-分发成本

创作成本

创作者的创作成本可以分为两类：直接成本和间接成本。

直接成本是指创作者在创作过程中必须支付的费用，包括材料费用、工具费用、劳务费用等。例如，一个音乐家在创作一首歌曲时，必须购买乐器和录音设备，支付工作室的租金，以及雇佣录音师等人员，这些费用都属于直接成本。

间接成本是指创作者在创作过程中必须支付的非物质性费用，包括时间成本、精力成本、压力成本等。例如，一个音乐家在创作一首歌曲时，必须花费大量的时间来调试乐曲、录制歌曲、宣传歌曲等，这些费用都属于间接成本。

抖音的出现使得创作者可以轻松地利用手机拍摄短视频，而无需投入太多的成本。例如，在传统的电视制作中，制作一部短片需要拍摄设备、灯光设备、道具、服装等大量的物质成本，这对创作者来说是一笔巨大的投入。但在抖音上，创作者只需要拥有一部手机，就可以进行短视频创作。

此外，抖音还提供了丰富的编辑工具，让创作者可以通过手机轻松地剪辑视频。抖音的编辑工具包括滤镜、音乐、动效等多种功能，可以帮助创作者快速制作出专业水平的短视频。因此，抖音的出现降低了创作者的成本，使得创作者可以轻松地制作出高质量的短视频。

分发成本(交易成本)

创作的分发成本是指创作者在将作品分发给消费者时所需支付的费用。这些费用可能包括推广费用等。例如，一个音乐家在将作品提供给唱片公司时，必须支付推广费用，抖音创作者希望被更多人看到需要投放抖加等，这些费用都属于创作的分发成本。

创作的分发成本对创作者来说是一笔不可忽视的投入。如果创作者支付的分发成本过高，则可能会影响作品的销售收益，甚至导致创作者无法获得合理的报酬。因此，创作者应该选择合适的分发渠道，并优化分发成本，以确保自己的作品能够获得最大的收益。

随着互联网的发展，创作的分发成本也在不断降低。互联网提供了大量的分发渠道，让创作者可以通过网络将作品分发给消费者，而无需支付过多的分发成本。

MCN为什么会出现

MCN机构是一种专门为在线视频作者提供联合运营服务的机构。MCN机构通常由大量的在线视频作者组成，通过联合运营，为作者提供技术支持、内容创作、推广服务等。

MCN机构之所以会出现，是因为在线视频作者面临着许多挑战。例如，在线视频作者通常独立运营自己的频道，缺乏专业的技术支持和内容创作能力，难以提高作品的质量和受众群体。此外，在线视频作者还面临着激烈的竞争，难以吸引到足够的观众，并获得足够的收益。

为了解决这些问题，在线视频作者可以通过加入MCN机构，获得专业的技术支持和内容创作服务，提高作品的质量和吸引力。通过MCN机构的联合运营，在线视频作者还可以共享流量和广告收益，从而获得更多的收益。因此，MCN机构会出现，是为了为在线视频作者提供更好的服务，并帮助他们解决创作过程中遇到的困难。

引入MCN后创作者收益应该是 净收益=(创作收益-创作成本-分发成本) x 分成比

创作者加入MCN是希望增加创作收益，降低创作成本和分发成本，但最终净收益需要与MCN机构分成。

web3如何赋能创作者经济

Web3技术可以通过两个角度来帮助创作者获得更多的经济收益。

首先，Web3技术可以通过NFT和分成协议来改善创作者创作初期负担成本过高的问题，NFT持有者将与创作者共担成本。而分成协议则可以用来保证创作者和NFT持有者之间能够获得更公平、更透明的收益分配。

其次，Web3技术还可以通过DAO来帮助创作者更好地组织多人共创。DAO可以让创作者们通过区块链技术来制定和执行共识规则，可以让创作者更好地协作、沟通和组织，从而提高创作效率和质量。通过DAO，创作者还可以更好地组织自己的社区，与粉丝和支持者进行互动，建立更牢固的创作生态。

分成协议+NFT

可以想象作品NFT的持有者通过持有NFT可以获得创作者作品的收益分成，这一切都是公开透明的。那么，创作者将在创作前期获得更多的成本投入，产生优质内容的可能性也大大增加。这种方式和众筹的本质区别是NFT持有者是通过对创作者做投资，而非单纯的为爱发电，更加符合市场规律。

NFT持有者投资收益由NFT的分红属性和流动性决定。

分红属性

NFT的分红属性指的是，NFT持有者可以从作品产生的收益中获得分成。通常情况下，NFT的分红属性会通过智能合约来实现，这样可以确保分红过程的公平性和透明度，并且可以避免人为操作带来的错误和滥用。例如，在创作者的作品获得收益时，创作者和NFT持有者都可以从中获得一定比例的收益。这样就可以保证创作者能够从作品的成功中获得持续的收益，而NFT持有者也能够从投资的价值增长中获得回报。

流动性

NFT的流动性指的是，NFT可以在市场上流通，并且可以被不同的持有者购买和出售。NFT的流动性取决于市场需求和供给，以及NFT的价格波动程度等因素。如果NFT市场需求较大，流动性就会更高，这意味着NFT持有者可以更快速和方便地将NFT出售给其他投资者，从而获得相应的收益。反之，如果NFT市场需求较小，流动性就会较低，这意味着NFT持有者可能需要花费更长的时间才能找到愿意购买NFT的投资者。因此，NFT的流动性对于投资者而言是非常重要的，可以帮助他们评估投资风险并做出决策。

分成协议

智能合约可以用来实现分成协议，允许创作者与NFT持有者之间进行自动化的分配。智能合约使得分配过程更加快捷、透明、安全。在这种协议下，创作者可以指定分配比例，并且智能合约会自动按照规定的比例将收益分配给相应的参与者。这样可以确保分配过程的公平性和透明度，并且可以避免人为操作带来的错误和滥用。

下面是1个分成协议的简单例子

pragma solidity ^0.5.0;

contract Split {
    // 存储参与方的地址
    address[] public participants;

    // 存储总收益
    uint public total;

    // 存储每个参与方获得的分成比例
    mapping (address => uint) public shares;

    // 新增一个参与方，并分配分成比例
    function addParticipant(address _participant, uint _share) public {
        // 将参与方的地址添加到数组中
        participants.push(_participant);
        // 存储参与方的分成比例
        shares[_participant] = _share;
    }

    // 添加资金
    function addFunds(uint _amount) public {
        total += _amount;
    }

    // 分配收益，简单演示，智能合约分收益一般要自己取
    function distribute() public {
        // 计算每个参与方应该获得的金额
        for (uint i = 0; i < participants.length; i++) {
            // 获取参与方地址
            address participant = participants[i];
            // 计算参与方应该获得的金额
            uint share = total * shares[participant] / 100;
            // 发放金额
            participant.transfer(share);
        }
    }
}

DAO

在DAO中，创作者可以根据自己的需求和意愿来参与创作过程，并且通过智能合约来实现贡献的评估和激励。这种方式可以有效地促进创作者之间的协作和交流，并且可以为创作者提供更多的自主权和参与感。此外，DAO还可以通过共同持有NFT来实现更高效的分配和激励，这样就可以保证创作者能够从作品的成功中获得持续的收益。DAO也可以通过提供项目信息、交易历史、投票记录等内容来增强透明度，从而为创作者和投资者提供更多的信息参考。

如果一群电影制作人想要使用DAO的形式进行创作，他们可以创建一个智能合约来管理项目的资金和决策流程。成员可以通过投票来决定电影的故事情节、演员阵容和制作细节，并可以通过智能合约来监督执行情况和跟踪资金使用。这样，制作人就可以在去中心化的环境中实现协作和决策，而无需依赖于中心化的组织机构。

但创作需要构思的完整性，如何在创作构思主线时运行DAO仍然是1个比较大的挑战，现在更多的应用是在分支剧情上引入DAO进行投票选择或创作。

结尾

越来越多的人会成为创作者，而web3为我们带来了很多无需信任即可合作的基础设施，这也使得合作更容易产生，而更多的合作，将会产生相比1个人更加优质的内容。这是我所坚信的。

现在各大电商平台都有着各种各样的优惠券，合理的发放优惠券可以达到2个目标：

1. 促进用户进行消费，提高GMV。

2. 通过优惠券作为奖励可以促进用户完成一些任务，带来DAU，留存以及时长的增长。

相比发放优惠券，直接发放货币应当有更加明显的效果，但成本也会相应增加,优惠券的优势主要体现在3个方面:

1. 使用范围收窄，一般而言优惠券的使用会增长诸多限制，比如某个平台，某种品类，满X减Y等等。这就使得优惠券促进用户购买指定商品的能力大大提升。

2. 流通性大幅降低，货币的流通性无疑是非常高的，但优惠券默认具有不可转让属性，以及因为不同用户具有不同的消费需求，所以优惠券几乎没有流通性，这就使得优惠券只有在购买商品时才具有价值。

3. 成本滞后性，发放优惠券的成本发生在用户使用优惠券购买商品时，而发放货币的成本发生在发放时。

当然，在NFT场景下增加优惠劵，和NFT本身是消费商品还是投资品也有关系，作为投资品的NFT，本身流通性较高，消费劵本身没有流通性，但购买完成投资品NFT时就被关联了流通性。

此外，优惠券还分为平台发放和卖出方发放:

• 平台发放优惠券时优惠行为对卖出方无感知，卖出商品后卖出方还是会收到原始售价的货币，购买者使用优惠券减价的部分由平台补齐。

• 卖出方发放优惠券时，卖出商品后卖出方收到的货币是使用过优惠券后价格的货币。成本由卖出方自行承担 。

NFT场景下融入优惠券

NFT的流转主要分为2个阶段

1. 项目方发布NFT阶段，也就是mint阶段，此时用户直接和NFT合约进行交互，用户mint时给予NFT合约链上货币，NFT合约将NFT发放给用户的钱包地址。

2. 交易市场交易阶段，在这个阶段NFT持有者和交易市场合约进行交互，暂时授予交易市场合约NFT的转让权，购买者通过与交易市场合约交互获取NFT。

• 在mint阶段融入优惠券，NFT发行方可以通过优惠券作为奖励促进项目前期的宣发。也可以通过优惠券来促进更多用户去mint。此时NFT发行方的成本是减少收入而不会额外支出。

• 在交易市场交易融入优惠券，会复杂一些。此时共有3方可以发放优惠券

  • NFT发行方,因为此时NFT并不归属于NFT发行方而归属于当前NFT持有者，所以需要发行方设置1个特定钱包为优惠券买单。(卖出NFT的持有者收到的货币不会发生变化，优惠券发放钱包需补差额=NFT售出价格-买方使用优惠劵后的价格)。此时NFT发行方需要额外支出。

  • NFT持有者, NFT持有者发放优惠券时，需要NFT交易市场支持设置优惠券合约信息。在购买时校验优惠券直接进行优惠。不过目前来看专业NFT卖家很少，所以这种方式我们不做讨论。

  • NFT交易市场，交易市场需要设置特定钱包为优惠券买单。和NFT发行方基本一致。不过交易市场的优惠券可以做到覆盖整个交易市场中的所有NFT。此时NFT交易市场需要额外支出。

从上面的论述可以看出mint阶段NFT发行方发放优惠券不需要额外支出，而在交易市场交易阶段，NFT发行方或NFT交易市场发放优惠券时需要进行额外支出。当需要额外支出时，就需要仔细计算成本和收益。

• 市场交易时NFT发行方发放优化劵，成本是所有发放的优惠券总额 x 优惠券使用率，收益是完成获得优惠券的任务以及该NFT更大的流通性。

• NFT交易市场发放优惠券，带来的成本是所有发放的优惠券总额 x 优惠券使用率，收益是完成获得优惠券的任务以及平台产生更多的交易金额。交易市场更多的交易金额这个收益在传统电商平台很重要，因为交易市场通过吸引大量的用户可以获得卖家投放广告的收益。但在目前NFT交易市场来看，大家并不会逛NFT交易市场，更多的是目标明确的直接购买。另外上面也说到专业的NFT卖家很少，所以NFT交易平台也无法获得广告收益。

结论

综上所述，在mint阶段NFT发行方发放优惠券，是比较合适的做法。目前NFT发行方前置宣传很多是通过社交平台抽奖+白名单的形式，引入优惠券后可以打破单一的概率性玩法。在市场交易阶段NFT发行方发放优惠券需要评估好成本和收益。而NFT持有者以及NFT交易市场发放优惠券看起来并不合适。

后续

本文是将优惠券引入NFT的一次产品层面上思考，后续会写一篇文章介绍如何完成优惠券合约以及修改当前的NFT合约以支持优惠券(当然前提是本人还认为这一产品思路可行，如果产品思路不可行，技术也不必实现)。

不要使用warp(至少目前阶段不要使用)

因为starknet使用了新的开发语言cairo，所以对以太坊solidity合约无法直接迁移。新语言cairo不仅仅是开发语言的转变，而且整个开发工具链都发生了变化，其原因是cairo属于python体系所以工具链都采用了python,而solidity的工具链大都使用js。所以开始想到的是，是否存在办法可以将solidity合约直接转为cairo，这样dapp的迁移成本会大大降低。https://github.com/NethermindEth/warp正是这样一个项目。但经过尝试发现warp转换过的编译产物体积会膨胀非常严重，比如原来较为简单的nft项目将无法部署。此外由于cairo不支持msg.value等(后面会介绍不支持的原因)以及对字符串的不友好导致我们无法通过简单的转换工具来迁移合约变得不可行，所以目前阶段建议大家不要通过warp转换solidity的方式进行迁移，而是直接使用cairo进行重写。

使用docker搭建纯粹的开发环境

在官方指导中使用python venv来创建python的虚拟环境，venv主要用于依赖包的隔离，但并未解决python版本本身的问题，如果没有使用python3.7可能会在开发中遇到各种各样的问题，有什么办法可以获得较为纯粹的开发环境呢？这里建议使用容器化方案docker,首先我们创建1个Dockerfile，内容如下所示:

FROM python:3.7

RUN mkdir cairo-contracts
WORKDIR cairo-contracts

Dockerfile非常简单，因为我们后续将在docker中进行开发，所以核心只需要From python:3.7即可(代表指定1个安装python3.7的基础镜像)其余命令都可以在进入这个容器后执行。vscode安装Remote - Containers插件后可以支持打开docker中的文件

此时的开发环境就像是1台纯净的标准化Linux系统一样。

可以打开命令行对该容器进行一切Linux操作。 比如我们使用pip安装cairo-lang or nile-cairo (建议使用nile其依赖cairo-lang但更加好用)

pip install nile-cairo
or
pip install cairo-lang

这就是容器化的力量，docker这种容器化的方案减少了很多维护工作，前端开发同学可能接触比较少，但在后端docker和k8s已经成为标准。这里不再详细介绍，对docker和k8s有兴趣的可以自行查阅相关资料。

了解cairo的核心类型felt

felt是1个-P/2<felt<P/2的整数。目前P是252位的整数。

uint256

cairo中felt的取值范围和solidity中最常用的uint256不一致。在cairo中也为我们提供了uint256的结构，定义如下所示, cairo中的uint256是使用2个felt组合表示，分别表示高低128位。

struct Uint256:
    # The low 128 bits of the value.
    member low : felt
    # The high 128 bits of the value.
    member high : felt
end

OpenZeppelin ERC721不支持baseURI以及tokenURI13个字符限制的原因

在cairo中并未直接提供string类型。

首先可以回顾string在计算机中的存储方式，一般而言string需要进行ascii encode变为二进制，每个字符由8位二进制来表示，这是因为计算机只能存储0 1。我们平时因为各个开发语言都已经在底层帮我们封装完成所以不需要关注这一过程，但cairo并未做这样的封装，所以需要开发者来完成string的 decode 和encode。

在cairo中不能直接使用string，我们需要在string数据上链前进行ascii encode变为整数，然后在读取链上string数据的时候进行ascii decode变回string。这也使得在链上进行字符串拼接变得比较麻烦。

比如我们可以看到OpenZeppelin提供的ERC721实现中就不支持使用baseUri+tokenid的方式去设置我们的tokenUrl，其原因就是在使用felt存储为整数时进行字符串拼接不是那么方便（只能使用<<方式,但同时又要避免felt溢出的问题，处理起来会很麻烦）。

此外使用felt表示string 还需要注意每个flet只能表示252/8=31个字符，如果超过31个字符，则需要使用flet数组。在OpenZeppelin ERC721的文档https://github.com/OpenZeppelin/cairo-contracts/blob/main/docs/ERC721.md中提到toknURI只支持31个字符，没有使用flet数组的原因是不符合ERC721规范，个人认为这里不太合理，因为31个字符很难表示1个tokneURI(除非使用短链接，但又会涉及到中心化服务的问题)。

搭建与合约交互的python脚本

cario提供了cli交互方式，但直接使用命令行交互，对于很多入参的前置处理会比较麻烦，比如上面说到cairo不支持string，如果我们需要存储1个string(比如nft的链接或合约name)就需要提前转换好之后再复制到命令行手动成本较高。所以我们使用python脚本去完成与合约的交互。下面分别就是进行部署1个nft合约以及mint操作时的pyhton脚本，内部还是使用了官方提供的cli。

import os
from utils import (str_to_felt)

name=str_to_felt("nft-web3-explorer-starknet")
symbol=str_to_felt("nft-web3-explorer-starknet")
account_address="合约账户地址"
contract_abi="./artifacts/abis/nft-web3-explorer-starknet.json"
os.system("starknet deploy  --contract %s --inputs %s %s %s" % (contract_abi, name, symbol, account_address))

import os

contract_address="合约地址"
contract_abi="./artifacts/abis/nft-web3-explorer-starknet.json"
function_name="mint"
mint_account_address="mint合约账户地址"
//因为定义token是uint256 所以要传2个值
token="1 0"
os.system("starknet invoke  --address %s --abi %s --function %s --inputs %s %s  --account xxxxx" % 
(contract_address, contract_abi, function_name, mint_account_address, token))

了解自己的私钥存储在哪里

在https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/starknet/wallets/open_zeppelin.py中可以看到这个代码是在我们创建合约账户时指定的钱包，其作用就是来管理我们的账户。其实无论合约账户还是EOA都需要有私钥、公钥、地址这些必要组成。但在我们部署完合约账户时只在命令行中返回给我们地址，那其他信息存储在哪里呢？ 我们可以查看 https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/starknet/cli/starknet_cli.py 内的相关逻辑

def get_account_dir(args) -> str:
    """
    Returns the directory containing the wallet files. By default, DEFAULT_ACCOUNT_DIR is used.
    """
    value = get_optional_arg_value(
        args=args, arg_name="account_dir", environment_var="STARKNET_ACCOUNT_DIR"
    )
    if value is None:
        return DEFAULT_ACCOUNT_DIR
    return value

可以看到如果我们在部署账户合约时没有指定--account_dir参数会使用默认值DEFAULT_ACCOUNT_DIR

DEFAULT_ACCOUNT_DIR = "~/.starknet_accounts"

在部署完成合约账户后我们可以使用命令查看我们合约账户的相关信息

cat ~/.starknet_accounts/starknet_open_zeppelin_accounts.json 
{
    "alpha-goerli": {
        "账户名字": {
            "private_key": "私钥",
            "public_key": "公钥",
            "address": "合约地址"
        }
    }
}

真正理解转账，消失了的msg.value

我们在查看OpenZeppelin的ERC20合约以及ERC721合约时，会发现1个问题，这些合约之前的转账操作全部没了(所以OpenZeppelin的ERC721不能直接使用)，这样让我们对starknet上如何转账有了疑问。要回答这个问题，我们就必须了解L2的货币从哪里来，L2的流通token也是eth，使用bridge的方式进行转换。如下图所示:

L1和L2是可以通过发消息来进行异步交互的，具体可见 https://starknet.io/docs/hello_starknet/l1l2.html

bridge的完整代码大家可以查看https://github.com/starkware-libs/starkgate-contracts

可以看到通过bridge，L1转到L2的ETH被存储到1个特定地址的ERC20中，我们进行转账操作就是对该ERC20合约调用transfer()方法。每个网络中都会有1个唯一的ERC20合约地址，我们需要通过这个合约地址来访问网络中通用token的相关信息。合约地址位于https://github.com/starkware-libs/starknet-addresses。

通过上面的分析可以看到在starknet中的转账是通过操作1个特定地址的ERC20完成，自然也就没有msg.value了。

一些参考链接:

• https://voyager.online/

• https://github.com/starkware-libs/cairo-lang/

• https://github.com/starkware-libs/starkgate-contracts

• https://github.com/starkware-libs/starknet-addresses

• https://github.com/OpenZeppelin/cairo-contracts

• https://github.com/NethermindEth/warp

Arweave

Arweave实现了什么

Arweave 实现了数据的永久存储。即一次进行付费存储，数据将会永久存储在Arweave网络中。

Arweave如何实现

适度冗余

与 filecoin 链下存储的思路不同，Arweave 采用链上存储。在常规的区块链如以太坊中，每个全节点都会下载所有区块。这样来看链上存储可以解决之前提到 filecoin 没有冗余性的设计问题。但如果采用这种方式做去中心化存储也带来大部分节点存储不够的问题，因为每个节点将存储所有的数据，换句话说这样冗余度太高了，我们需要适度冗余即可。

每个节点存储部分区块

如何实现适度冗余呢？Arweave 为了解决这一问题设计了不同的区块链数据结构以及证明方式。每个节点只存储一部分区块。

Arweave使用2张表解决了节点必须存储所有区块的问题

1. 区块哈希列表

2. 钱包列表

有了块哈希列表，我们不需要下载所有区块进行逐个验证，而是在区块生成过程中持续验证。

有了钱包表，Arweave可以在当前区块即可查到任何一个账户的状态。其原因和以太坊中为何状态树不和交易树一样只存储当前区块涉及到的账户一样。即假设要给1个没有发生过交易的账户转账，则需要遍历到初始块中。以太坊的设计是为了提高效率，而Arweave则是为了实现只存储部分区块的目标。

冗余实现-POA和blockwave

如果只是这样Arweave解决了每个节点只存储部分区块，但无法保证区块的冗余性，因为极限情况下Arweave永远只需要存储最近的一个区块即可。Arwave采用POA服务证明来解决这一问题。

POA访问证明

Arweave中采用POW+POA的方式确定出块权，POW我们之前的文章多次提过不再重复，POA是为了实现每个区块在不同节点的冗余性，其要求是节点出新块的时候需要证明存储了之前随机的某个区块-recall-blockk。

如上图所示，区块4生成的时候要求包含之前链上区块1的部分数据data2。这使得区块4需要存储区块1才可以参与后续挖矿。

blockweave

由于上面POA的方式，Arweave的区块链结构变成了图，当前区块不仅与前一区块连接并且和历史某个随机区块相连接。如图所示

我们将上面这样的结构称之为blockweave。

生成新块

我们来描述Arweave生成1个新的区块的具体流程

1. 当面末尾区块是区块5，节点A存储了区块2和3

2. 生成区块6的需要携带区块2的数据，节点A进行POW

3. 通过比拼节点A POW竞争中胜出，获得记账权

4. 节点A打包事务并按照要求存入区块2的部分数据，整体打包生成新的区块

5. 节点A将新的区块和recall block广播给其他节点

6. 其他节点验证新的区块是否有效，有效包含区块的随机数符合POW以及区块中是否包含recall block的部分数据。

上面的过程，为什么要将recall block也一并广播给其他节点呢？Arweave每个节点只存储部分区块，所以很多节点并没有该recall block，但很多都包含recall block的hash值，这样我们可以确认传输过来的recall block的正确性，并用该recall block去验证新的区块中包含的数据是否正确。

Arweave通过POA的方式可以实现均匀的将块分布在不同节点上，每次新块需要的recall block是随机的，一旦某个区块有较少节点存储那么拥有这个区块的节点获得记账权的概率就会变大，从而其他节点也来存储该区块。而如果按照均匀分布计算，某个区块丢失的概率为 (1-平均每个节点存储的区块数/网络中所有区块)^网络中节点数，由于网络中节点数不断增加，区块丢失概率非常之低。

由此可见，Arweave的永久存储还是比较靠谱的，真正从机制上实现了存储冗余。

分发机制

存储的问题基本解释清楚了，之前说过存储系统有2个事情需要解决1个是存数据 1个是分发数据，我们简单看看Areave的数据分发如何

数据访问 Arweave使用了wildfire系统来保障数据更快分发，wildfire是一个排名系统，每个节点都会维护起对等点的排名，排名根据对等点的请求响应耗时来决定，会根据排名顺序来进行顺序交互，这样性能不佳的节点由于在每个节点排名都较差，最终没有节点与之交互从而被踢出网络。

Arweave vs filecoin

同样作为去中心和的存储方案，我们来看看Arweave和filecoin有什么区别，这里不再对比ipfs，之前文章已经论述过ipfs是更侧重数据分发的协议而非存储方案,并且filecoin就是基于ipfs搭建的。

这两种方式整体上看目前Arweave要相对更实用一些。filecoin核心问题在于其分发机制一直被诟病，基本上无法单独满足用户体验。

至此，我们对去中心化的存储讨论告一段落，但文中既然提到了Arweave，我们就来继续看看Arweave为区块链运行机制提出的另外一种思路-链下计算。

Arweave不只于存储

SmartWeave

SmartWeave是Arweave的智能合约平台，其机制是在链下执行合约调用，然后将状态存储在Arweave中。是不是似曾相识,我们之前介绍过Layer2的Rollup也是这种机制。SmartWeave规定合约的执行是由调用者完成。

在之前Layer2一文中我们了解过，受限于不可能三角，为了提升L1的TPS将执行过程放在单独一层L2，而L1只进行状态的存储，但就L2的方案需要解决的1个核心问题就是如何证明L2向L1发布的状态是正确的，L2的实现方案之前一文已经讨论过，这里不再赘述。我们看到SmartWeave也是将Arweave只作为存储，而交易执行(状态转移过程)放在链下。那在SmartWeave中是否需要证明发布到Arweave的状态的正确性呢？

SmartWeave并不需要发布者证明其发布的状态正确性，而是采用惰性评估，即每次合约调用者在调用合约的时候，需要将合约相关的交易全部执行一次进行状态转移。相当于将状态的正确性交由下一次合约的调用者来验证。这种方式极大地释放了链上计算量，使得SmartWeave TPS (吞吐量)大幅优于其他L1链。

理论美好，但实际落地遇到了很多问题，目前看SmartWeave并未对发布错误状态的用户做任何惩罚机制。这势必会导致大量用户可以发起很多无效调用来增加后续每次合约调用者的耗时，也就是DDOS攻击。

就目前而言，Arweave还是以永久存储为主要作用，而SmartWeave这种机制还有不少问题有待解决。

结尾

本文介绍了去中心化存储的另外1种解决方案Arweave的实现，通过钱包列表和哈希列表实现了每个节点只存储部分区块，通过POA和blockweave结构实现了数据冗余，从而达成永久存储的目标。文中还对比了filecoin和Arweave的优劣，目前来看Arweave落地的更好一些。最后我们通过Arweave的smartweave引出了一种基于存储的共识范式。

由于合约和资产的强关联以及合约不可修改的特性，合约漏洞会对项目发起者和参与项目的用户带来财产损失以及信任危机。所以我们要尽可能地避免发生合约被攻击的情况。本文主要分为3个部分:

1. 介绍常见的合约漏洞，在开发阶段避免一些可能被攻击的写法。

2. 介绍一些自动化合约漏洞检测工具，在测试阶段更加快捷地发现漏洞。

3. 介绍合约上链后通过合约暂停，合约监控以及合约升级的方式来避免合约漏洞带来的损失。

合约漏洞

数值溢出

较为典型的是if(a - b > 0)的判断，其实无符号整数溢出在C语言也存在，对于无符号整数而言永远无法通过相减得到小于0的数，(0-1)会获得取值范围内最大的数，就像循环一样。

pragma solidity ^0.6.0;

contract Token {
  mapping(address => uint) balances;
  uint public totalSupply;
  constructor(uint _initialSupply) public {
    balances[msg.sender] = totalSupply = _initialSupply;
  }
  function transfer(address _to, uint _value) public returns (bool) {
    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];
  }
}

上面的合约大家可以尝试调用transfer函数传入1个比自己余额大的值，是否可以完美通过。

避免此类问题，有2种方案，其原理都是在计算前后进行判定:

1. 使用openzeppelin提供的SafeMath

import '@openzeppelin/contracts/math/SafeMath.sol';
using SafeMath for uint256;

2. solidity版本使用8.0以上

pragma solidity ^0.8.0;

私有变量可读取

private作用只是无法直接让其他合约调用，但并不代表通过private存储的值无法被获取，从计算机的基础理论也容易想到，值都是存在内存或磁盘中的，只要我们了解存储规则，private是没有任何作用的。这一点其他编程语言中也是一致的，变量的权限修饰符从来都是为了代码设计，而不是加密。 如同下面的合约

pragma solidity ^0.6.0;
contract Vault {
  bool public locked;
  bytes32 private password;

  constructor(bytes32 _password) public {
    locked = true;
    password = _password;
  }

  function unlock(bytes32 _password) public {
    if (password == _password) {
      locked = false;
    }
  }
}

之前文章智能合约升级详解时介绍过合约存储是按照槽位存储的，我们只需要指定存储槽位即可读取到相应变量的值:

const res = await provider.getStorageAt("合约地址", 1);
 console.log(`res is: ${res}`);

链上随机数不随机

链上没有随机数可言，因为链上代码都是开源的，链上制造随机数的操作，都可以使用另外1个合约执行相同的操作得到。不要希望使用block相关变量得到随机数，模拟者放到同1个区块内执行即可。

权限设置

权限设置更多的是合约设计的考量，我们这里主要介绍一个经典的问题。

使用 msg.sender 而不是 tx.origin 做权限校验

tx.origin是指整个交易链路的首位发起者，而msg.sender才是真正调用合约者，如果是外部账户->合约的简单调用时,其获取的地址是一致的，除此之外这2种方式获取的地址均不相同。 如下合约使用tx.origin进行校验权限

contract TxUserWallet {
    address owner;
    constructor() {
        owner = msg.sender;
    }
    function transferTo(address dest, uint amount) public {
        require(tx.origin == owner);
        dest.transfer(amount);
    }
}

当被攻击合约向攻击合约转账时，攻击合约fallback函数被调用，此时被攻击合约通过tx.origin获得的是整个交易的最初发起者也就是被攻击合约的owner，校验通过。

interface TxUserWallet {
    function transferTo(address dest, uint amount) public;
}

contract TxAttackWallet {
    address payable owner;

    constructor() {
        owner = payable(msg.sender);
    }

    function() public {
        TxUserWallet(msg.sender).transferTo(owner, msg.sender.balance);
    }
}

对于权限控制建议使用openzeppelin contracts包下提供的工具合约。一般使用onlyOwner即可，如果需要较为复杂的角色控制，可以使用AccessControl。

拒绝访问攻击

拒绝访问一般出现在合约循环对外转账的场景下，如果对外转账的对象是1个合约账号，其在fallback函数中抛出错误，那么合约循环将无法继续。所以通常情况下要避免循环对外转账，尽量使用满足条件的账户自提的方式，这样可以避免恶意账户埋雷导致其他账户资产受到影响。

重入攻击

重入比较常见的是利用被攻击合约向攻击合约转账时会调用攻击合约的fallback函数，攻击合约一般会在fallback函数中再次调用被攻击合约以达到重新执行函数的目的。

contract Fund {
    mapping(address => uint) shares;
    function withdraw() public {
        if (payable(msg.sender).call.value(shares[msg.sender])())
            shares[msg.sender] = 0;
    }
}

攻击者只需要在合约的fallback函数中继续调用该函数即可耗尽合约资金。

interface Fund {
    function withdraw() external;
}
contract Attack {
    address payable owner;
    constructor() {
        owner = payable(msg.sender);
    }
    function attck(address addr) public {
        Fund f = Fund(addr);
        f.withdraw();
    }
    fallback() external payable{
        Fund f = Fund(msg.sender);
        f.withdraw();
    }
}

为了避免重入，我们需要践行“检查-生效-交互”的设计模式，检查-生效-交互是指，应该先进行条件满足的判断，然后修改合约中的状态，最后再与外部账户进行交互，这样如果外部合约发动重入攻击也是在状态修改之后，重入时会被条件判断拦截。上面的合约应做如下修改:

contract Fund {
    mapping(address => uint) shares;
    function withdraw() public {
        var share = shares[msg.sender];
        if(share > 0) {
          shares[msg.sender] = 0;
          payable(msg.sender).transfer(share);
        }
    }
}

重入锁

此外openzeppelin还为我们提供了重入锁来帮助我们解决重入问题。重入锁的实现如下所示,也是使用了“检查-生效-交互”模式:

pragma solidity ^0.8.0;
abstract contract ReentrancyGuard {
    uint256 private constant _NOT_ENTERED = 1;
    uint256 private constant _ENTERED = 2;
    uint256 private _status;
    constructor() {
        _status = _NOT_ENTERED;
    }

    modifier nonReentrant() {
        //如果状态是初始状态则进入函数
        require(_status != _ENTERED, "ReentrancyGuard: reentrant call");
        //将状态置为访问中
        _status = _ENTERED;
        //执行函数
        _;
        //将状态置为初始状态
        _status = _NOT_ENTERED;
    }
}

条件错误锁死

在一些关键的操作，我们对于条件判断的一定要仔细考虑，编写足够多的测试用例进行测试。

Akutar合约条件错误导致3400万美元资金永久被锁

在这个例子中取回合约中的资金claimProjectFunds函数有3个条件。其中refundProgress >= totalBids条件，大家可以观察refundProgress和totalBids赋值的地方。应该不难发现只要有1次调用_bid函数时amount>1，则refundProgress >= totalBids的结果不可能被满足，这也直接导致该合约内3400万美元被锁死。同时该合约在processRefunds函数存在上文中提到的循环对外转账的操作，非常容易引入拒绝访问攻击。

function claimProjectFunds() external onlyOwner {
        require(block.timestamp > expiresAt, "Auction still in progress");
        require(refundProgress >= totalBids, "Refunds not yet processed");
        require(akuNFTs.airdropProgress() >= totalBids, "Airdrop not complete");

        (bool sent, ) = project.call{value: address(this).balance}("");
        require(sent, "Failed to withdraw");        
  }

  function processRefunds() external {
      require(block.timestamp > expiresAt, "Auction still in progress");
      uint256 _refundProgress = refundProgress;
      uint256 _bidIndex = bidIndex;
      require(_refundProgress < _bidIndex, "Refunds already processed");

      uint256 gasUsed;
      uint256 gasLeft = gasleft();
      uint256 price = getPrice();

      for (uint256 i=_refundProgress; gasUsed < 5000000 && i < _bidIndex; i++) {
          bids memory bidData = allBids[i];
          if (bidData.finalProcess == 0) {
            uint256 refund = (bidData.price - price) * bidData.bidsPlaced;
            uint256 passes = mintPassOwner[bidData.bidder];
            if (passes > 0) {
                refund += mintPassDiscount * (bidData.bidsPlaced < passes ? bidData.bidsPlaced : passes);
            }
            allBids[i].finalProcess = 1;
            if (refund > 0) {
                (bool sent, ) = bidData.bidder.call{value: refund}("");
                require(sent, "Failed to refund bidder");
            }
          }

          gasUsed += gasLeft - gasleft();
          gasLeft = gasleft();
          _refundProgress++;
      }

      refundProgress = _refundProgress;
    }

    function _bid(uint8 amount, uint256 value) internal {
        require(block.timestamp > startAt, "Auction not started yet");
        require(block.timestamp < expiresAt, "Auction expired");
        uint80 price = getPrice();
        uint256 totalPrice = price * amount;
        if (value < totalPrice) {
            revert("Bid not high enough");
        }

        uint256 myBidIndex = personalBids[msg.sender];
        bids memory myBids;
        uint256 refund;

        if (myBidIndex > 0) {
            myBids = allBids[myBidIndex];
            refund = myBids.bidsPlaced * (myBids.price - price);
        }
        uint256 _totalBids = totalBids + amount;
        myBids.bidsPlaced += amount;

        if (myBids.bidsPlaced > maxBids) {
            revert("Bidding limits exceeded");
        }

        if(_totalBids > totalForAuction) {
            revert("Auction Full");
        } else if (_totalBids == totalForAuction) {
            expiresAt = block.timestamp; //Auction filled
        }

        myBids.price = price;

        if (myBidIndex > 0) {
            allBids[myBidIndex] = myBids;
        } else {
            myBids.bidder = msg.sender;
            personalBids[msg.sender] = bidIndex;
            allBids[bidIndex] = myBids;
            bidIndex++;
        }

        totalBids = _totalBids;
        totalBidValue += totalPrice;

        refund += value - totalPrice;
        if (refund > 0) {
            (bool sent, ) = msg.sender.call{value: refund}("");
            require(sent, "Failed to refund bidder");
        }
    }

签名重放

NBAXNFT签名重放白名单被耗尽

在这个例子中NBAXNFT合约本意是想为白名单用户提供mint，但由于verify函数校验白名单时没有校验msg.sender的地址和参数info中的地址是否相同，任何人在传入info时都可以使用已经通过验证的签名信息，合约代码中真正mint发放的时候又使用msg.sender。这里会导致2个问题，第1个问题是非白名单用户也可以通过重放签名进行Mint，第2个问题是白名单用户可以重复mint，因为对于1个地址签名是确定的。

function mint_approved(
        vData memory info,
        uint256 number_of_items_requested,
        uint16 _batchNumber
    ) external {
        require(batchNumber == _batchNumber, "!batch");
        address from = msg.sender;
        require(verify(info), "Unauthorised access secret");
        _discountedClaimedPerWallet[msg.sender] += 1;
        require(
            _discountedClaimedPerWallet[msg.sender] <= 1,
            "Number exceeds max discounted per address"
        );
        presold[from] = 1;
        _mintCards(number_of_items_requested, from);
        emit batchWhitelistMint(_batchNumber, msg.sender);
    }

function verify(vData memory info) public view returns (bool) {
        require(info.from != address(0), "INVALID_SIGNER");
        bytes memory cat =
            abi.encode(
                info.from,
                info.start,
                info.end,
                info.eth_price,
                info.dust_price,
                info.max_mint,
                info.mint_free
            );
        // console.log("data-->");
        // console.logBytes(cat);
        bytes32 hash = keccak256(cat);
        // console.log("hash ->");
        //    console.logBytes32(hash);
        require(info.signature.length == 65, "Invalid signature length");
        bytes32 sigR;
        bytes32 sigS;
        uint8 sigV;
        bytes memory signature = info.signature;
        // ecrecover takes the signature parameters, and the only way to get them
        // currently is to use assembly.
        assembly {
            sigR := mload(add(signature, 0x20))
            sigS := mload(add(signature, 0x40))
            sigV := byte(0, mload(add(signature, 0x60)))
        }

        bytes32 data =
            keccak256(
                abi.encodePacked("\x19Ethereum Signed Message:\n32", hash)
            );
        address recovered = ecrecover(data, sigV, sigR, sigS);
        return signer == recovered;
    }

• 第一个问题我们可以通过增加msg.sender == info.from来避免非白名单用户mint，但这样会限制委托mint，我们其实只需要保证校验的地址和最终mint的地址一致即可。

• 第二个问题需要通过引入nonce来解决，在进行签名时加入nonce值, 然后在合约中记录每个地址使用过的nonce,如果已经使用则交易无效，下面是EIP-712避免签名重放攻击的示例

function transferWithSignature(
    address recipient, 
    uint256 amount, 
    address sender, 
    bytes32 nonce, 
    bytes memory signature
  ) public returns (bool) {

    // Hash of structured data as defined according to the TYPEHASH
    bytes32 hashStruct = keccak256(abi.encode(
      TRANSFER_TYPEHASH,
      sender,
      recipient,
      amount,
      nonce
    ));

    // Signed hash as defined by EIP-712
    bytes32 hashed = keccak256(abi.encodePacked(
      "\x19\x01",
      domainSeparator,
      hashStruct
    ));

    address recovered = ECDSA.recover(hashed, signature);
    require(recovered == sender, "Signature mismatch");

    require(!nonces[sender][nonce], "Repeated nonce");
    nonces[sender][nonce] = true;

    _transfer(sender, recipient, amount);
  }

合约漏洞自动化检测工具

编写完合约代码后我们需要经过严格的测试，如果较大的项目需要进行专业的合约审计。下面介绍2款自动化漏洞检测工具能够对我们的人工测试进行有效补充。

slither

slither是Solidity代码的静态分析工具，可以在不执行代码的情况下对代码进行静态分析。 分析命令:

官方链接: https://github.com/crytic/slither

echidna

echidna为我们提供状态分析，我们在聊一聊智能合约介绍过可以将智能合约执行的过程理解为状态机状态变化的过程。echidna帮助我们分析状态的可达性。如果某些状态无论如何执行都符合我们预期则测试通过，如果有些执行路径不满足预期，则会输出不满足预期情况下的调用情况。

echidna要求我们编写状态检测函数

function echidna_check_balance() public returns (bool) {
    return(balance >= 20);
}

执行合约检查

chidna-test 合约地址

官方链接: https://github.com/crytic/echidna

合约监控修复方案

合约可暂停&链上合约监控

合约可暂停

当我们发现线上合约存在漏洞时，我们需要第一时间暂停合约的正常运行来避免合约被攻击即只保留个别函数可以被正常调用，其余函数均无法被调用，openzeppelin为我们提供了Pausable工具合约来帮助我们有效实现这一目标。如下所示，当发现合约存在问题时我们调用_pause将合约暂停

pragma solidity ^0.8.0;

import "../utils/Context.sol";
abstract contract Pausable is Context {
    event Paused(address account);
    event Unpaused(address account);
    bool private _paused;
    constructor() {
        _paused = false;
    }
    function paused() public view virtual returns (bool) {
        return _paused;
    }
    modifier whenNotPaused() {
        require(!paused(), "Pausable: paused");
        _;
    }
    modifier whenPaused() {
        require(paused(), "Pausable: not paused");
        _;
    }
    function _pause() internal virtual whenNotPaused {
        _paused = true;
        emit Paused(_msgSender());
    }
    function _unpause() internal virtual whenPaused {
        _paused = false;
        emit Unpaused(_msgSender());
    }
}

链上合约监控

上面我们介绍了如何在发现漏洞时暂停合约，如何及时发现漏洞也有较多方案，我们在之前使用TheGraph实现Dapp的万倍速度优化介绍了TheGraph的使用。我们对链上一些异常的监控也可以使用TheGraph,在发现链上数据有异常时及时报警。

合约可升级

当合约暂停后，我们期望最好的结果肯定是进行修复后合约能够继续正常运转。合约虽然上链之后代码不可更改，但我们可以通过代理合约的方式实现合约的动态升级，在之前智能合约升级详解中已经进行了详细介绍。通过合约升级可以将我们发现存在风险的链上合约进行升级修复。但这里再次强调一次，使用合约升级时需要配合升级治理，否则项目参与者对合约的信任度会降低。

结尾

本文向大家介绍了常见的合约漏洞，自动化监测合约漏洞的工具以及链上漏洞的应对方案。这些内容不仅仅对大家更好保护资产有帮助而且也有助于更加深入理解智能合约的运作流程。合约漏洞是web3安全的一个重要组成，但不是唯一因素。此外还包含链下钓鱼、跨链安全(跨链桥合约的安全)等等。希望大家能写出更加安全的合约代码。

相关链接:

• https://github.com/OpenZeppelin/

• https://github.com/crytic/echidna

• https://github.com/crytic/slither

• https://ethernaut.openzeppelin.com/

极慢的前端体验

如图所示，我们需要不断循环请求获取tokenId对应的tokenURI，然后通过tokenURI请求获取metadata来解析数据，每次循环都是2次http通信 按照较低时延http通信耗时300ms，每次循环将消耗600ms, 而且这个数字将随着NFT数量增加线性增加，我们的页面耗时5、6s是因为我们的NFT只mint了10个左右，正常上线的NFT一般会有接近1万个toknId，那么整体耗时将达到 100分钟，这样的速度没有任何用户可以容忍。所以我们一定需要其他方案来优化这一流程。

理想状态下前端页面只需要1次请求获取所需要的数据即可，而不是进行多次请求。这就需要1个链下的后端服务帮我们去做类似的逻辑并存储数据，待前端页面需要展示时请求这个后端服务中存储的数据，而TheGraph就是这样的一种服务，与我们自行搭建的后端服务不同，TheGraph是去中心化的，这极大的避免了我们单节点的中心化风险。

TheGraph工作原理简介

以太坊事件event

之前在以太坊技术系列-以太坊数据结构 中介绍过以太坊中有3棵树，状态树，交易树，收据树。以太坊的事件存储在了收据树中。在智能合约中写入1个事件的方式为使用event关键字定义，使用emit关键字发送。

//定义事件
event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);

//发送事件
emit Transfer(owner, address(0), tokenId);

GraphQL简介

GraphQL主要为我们提供了较为细粒度的与服务端交互方式，相比之前的REST API，有如下几个优点:

1. 减少字段冗余，只返回查询中需要的字段。

2. 避免多次请求数据，如第一次请求获取id 第二次请求通过id获取其他属性的场景可以一次返回。

3. 更有利于前后端分离，前端只需要在请求中增加字段即可获得新增字段，不需要后端配合。

1个GraphQL请求-响应如下所示 请求:

{
  metaDatas(first:1) {
    id
    name
    image
    owner
  }
}

响应:

{
  "data": {
    "metaDatas": [
      {
        "id": "0",
        "name": "nft-web3-explorer",
        "image": "ipfs://xxx/0.png",
        "owner": "0xxxx"
      }
    ]
  }
}

目标梳理

接下来介绍我们如何通过TheGraph来优化NFT列表展示的。具体我们分为如下3步:

1. 确定合约中需要使用的事件, 因为TheGraph是基于以太坊中的事件触发的，所以我们需要在合约中合适的位置发送事件。

2. 完成后端代码-TheGraph对于事件的处理并进行存储，我们需要定义数据的存储结构，并编写处理函数在接受到事件的时候进行处理，将数据按照定义结构进行存储。

3. 完成前端代码，请求获取TheGraph的数据，我们通过GraphQL的方式从存储中获取需要的数据。

合约中加入事件

既然触发源是以太坊中的event，那么我们肯定需要在合适的时机发送event，由于我们采用ERC721的实现，查看代码会在mint的时候会发送Transfer event，event中带有mint地址以及tokenId，符合我们的需求，所以我们选择使用该event做为我们的触发源。

function _mint(address to, uint256 tokenId) internal virtual {
        require(to != address(0), "ERC721: mint to the zero address");
        require(!_exists(tokenId), "ERC721: token already minted");

        _beforeTokenTransfer(address(0), to, tokenId);

        _balances[to] += 1;
        _owners[tokenId] = to;

        emit Transfer(address(0), to, tokenId);

        _afterTokenTransfer(address(0), to, tokenId);
    }

创建工程

到TheGrapha官网申请subGraph，需要连接github。 https://thegraph.com/hosted-service

本地工程初始化

//安装graph脚手架
npm install -g @graphprotocol/graph-cli

//初始化工程，选择合约地址，abi文件(会自动从合约地址读取，读取失败可以本地上传)，网络(我们依旧使用rinkeby测试网络)
graph init <GITHUB_USERNAME>/<SUBGRAPH_NAME> <DIRECTORY>

定义存储结构

在schema.graphql中定义我们的存储结构

//记录每次的Transfer事件(非必要)
type QLTransfer @entity {
  id: ID!
  from: Bytes! # address
  to: Bytes! # address
  tokenId: BigInt!
  tokenURI: String!
}

//记录Metadata数据
type MetaData @entity {
  //每条数据需要唯一id，这里我们使用tokenId
  id: ID!
  //持有tokenId的地址
  owner:Bytes!
  //metadata文件中的name
  name: String
  //metadata文件中的image
  image: String
}

通过定义的存储结构生成对应的ts代码以方便逻辑代码中直接调用。

完成事件处理的逻辑处理

在mapping.ts中完成我们的逻辑处理，使用AssemblyScript编写(AssemblyScript是TypeScript的子集，AssemblyScript规范参考)

export function handleTransfer(event: Transfer): void {
  const qlTransfer = new QLTransfer(event.transaction.hash.toHexString());
  qlTransfer.from = event.params.from;
  qlTransfer.to = event.params.to;
  qlTransfer.tokenId = event.params.tokenId;

  const contract = NFT_WEB3_EXPOLRER.bind(event.address);
  //与合约交互获取tokenId对应的tokenURI
  qlTransfer.tokenURI = contract.tokenURI(event.params.tokenId);
  qlTransfer.save();
  log.info('qlTransfer id is {}', [qlTransfer.id]);

  //将http转换为ipfs数据
  const splitstr = qlTransfer.tokenURI.split("/ipfs/");
  if(splitstr.length < 2) {
      return;
  }
  const ipfsPath = splitstr[1];
  log.info('ipfsPath is {}', [ipfsPath]);
  //获取metadata数据
  const data = ipfs.cat(ipfsPath)
  if (!data) {
    return;
  }
  log.error('data is {}', [data.toString()]);
  //转换为json格式
  const value = json.fromBytes(data);
  //新建MetaData结构
  const meta = new MetaData(qlTransfer.tokenId.toString());
  const obj = value.toObject();
  if (obj != null) {
    //解析name
    const name = obj.get("name")
    if (name != null) {
      meta.name = name.toString();
    }
    //解析image
    const image = obj.get("image")
    if (image != null) {
      meta.image = image.toString();
    }
  }
  meta.owner = qlTransfer.to;
  //数据存储
  meta.save();
  log.info('meta id is {}', [meta.id]);
}

完成代码编写后进行编译

部署到TheGraph服务器

//首次部署需要设置key授权
graph auth --product hosted-service {key}

//部署
graph deploy --product hosted-service EXPLORER-OF-WEB3/nft_web3_explorer_subgraph

TheGraph官网会有部署进度，因为要扫描所有区块所以会比较慢，部署完成后我们就有了后端数据，接下来前端展示只要去请求该数据即可。

前端代码实现

我们使用apollo这个库来帮助我们完成GraphQL交互。

添加依赖
npm i @apollo/client graphql

在uitls目录下新建 graphql_utils.js来管理graphql交互

import {
    ApolloClient,
    InMemoryCache,
    gql
} from "@apollo/client";

export const getListData = async () => {
  //建立连接
    const client = new ApolloClient({
        uri: "thegrapha项目地址",
        cache: new InMemoryCache()
    });
  //按照graphql形式请求
    const data =  await client.query({
        query: gql`
        query res {
            metaDatas{
                id
                name
                image
            }
        }`
    });
    const list = data?.data?.metaDatas;
    console.log("getListData" + list);
    return list;
}

获取属于自己NFT

如果我们增加1个功能，展示属于自己的NFT，那么只需要在查询中指定owenr为自己的地址即可，如下所示

{
  metaDatas(where:{owner:"地址"}) {
    id
    name
    image
  }
}

在使用TheGrpha后，我们的NFT列表展示速度稳定控制在500ms左右，极大地提升了用户体验，相对于直接与合约交互耗时降低了1万多倍。

结尾

本文我们从NFT列表展示速度慢的现象开始分析，发现前端展示流程不合理的地方，通过引入TheGraph将NFT列表展示耗时降低了1万多倍，实际中还有很多类似的应用。由于需要尽可能地减少以太坊中存储，我们将部分数据存入链下而且即使在以太坊中的存储也可能没有合适的索引，只能前端拿到所有数据再建立索引(比如属于某个地址的tokenId集合)。这样的情况下我们就需要后端服务来帮助我们建立链上数据的索引并整合链下数据，可以极大地优化用户体验。

在如何发行一款NFT(下)的官方搭建中，我们支持了MetaMask钱包，但如果是一款希望能够"破圈"的应用，目前的钱包(包括MetaMask)覆盖用户程度不高，可能会增加用户的使用门槛，这也是StepN内置钱包的原因(StepN所处的solana链钱包覆盖度更低)，本文将介绍如何在我们的DApp中内置钱包。

钱包基础概念

如上图所示，私钥可以计算出公钥，公钥可以计算出钱包账户地址，每一步都是单向可行，比如，通过公钥是无法计算出私钥的。所以对于钱包账户，我们的核心数据只有1个，那就是私钥，有了私钥我们就可以推导公钥和钱包账户地址。 钱包内的余额等信息均存储于链上，链上存储着钱包账户地址->余额的映射，如果发生转账等操作需要进行私钥签名，公钥验证。

目标规划

1.连接钱包: 用户需要能够连接到我们的内置钱包，同时支持新创建钱包账户并连接或者导入之前已创建的钱包账户并连接两种方式。

2. 展示已连接钱包账户信息，包括钱包账户地址，余额，私钥(默认不展示)，并支持断开已连接的钱包账户。

3.使用已连接钱包账户完成转账，并支持在转账前进行二次弹窗确认。

技术选型

• 基础框架:由于我们是在之前的NFT官网基础上继续完善，所以我们依旧还是使用react+mobx+ether的组合。

• 持久化:由于我们需要持久化保存钱包账户的连接，避免页面刷新连接断开，所以我们使用localStorage持久化已连接的钱包账户。

• 节点代理(管理节点):由于我们不再使用metamask，所以我们需要自己去连接以太坊节点来进行链上操作，在如何发行一款NFT(上)中我们介绍过Infura，我们继续使用Infura作为节点服务代理。本文不再介绍如何申请Key相关，如果有疑问可以参考如何发行一款NFT(上)中的介绍。

连接钱包

创建新钱包账户并连接

在wallet_utils.js中新增创建钱包账户，连接钱包的方法。创建钱包本质就是寻找1个随机数作为私钥，并使用这个私钥生成公钥和钱包地址。

//创建一个新的钱包账户
export const createNewWallet = (): Wallet => {
    const wallet = ethers.Wallet.createRandom();
    return wallet;
}

const NETWORK = "rinkeby"
const API_KEY = "在infura中申请的key"

//连接内置钱包账户
export const connectCustomWallet =  (wallet:Wallet) : Wallet => {
    const provider = new ethers.providers.InfuraProvider(NETWORK, API_KEY);
    const conncetWallet = wallet.connect(provider);
    return conncetWallet;
}

新增内置钱包的组件CustomWalletComponent.js并在App.js中添加，这个组件将会负责管理内置钱包连接页面和展示内置钱包信息页面。

import { Store } from '../Store';
import './wallet-page.css';
import { observer } from 'mobx-react';
import ConnectCustomWalletComponent from './ConnectCustomWalletComponent';
import CustomWalletInfoComponent from './CustomWalletInfoComponent';

//使用observer修饰组件，observable的值发生变化组件重新渲染
const CustomWalletComponent = observer(() => {
    switch (Store.customWalletPageShow.get()) {
        case Custom_Wallet_Page_Show_Type.show_connect_page:
            //内置钱包连接组件
            return <ConnectCustomWalletComponent />;
        case Custom_Wallet_Page_Show_Type.show_info_page:
            //内置钱包信息组件
            return <CustomWalletInfoComponent/>;
        default:
            //默认不展示
            return <div className='display-none'></div>;
    }
});

export default CustomWalletComponent;

//定义组件展示形态枚举
//hidden: 不展示弹窗   
//show_connect_page:展示内置钱包连接页面
//show_connect_page:展示内置钱包信息页面
export const Custom_Wallet_Page_Show_Type = {
    hidden: 0,
    show_connect_page: 1,
    show_info_page: 2
}

在内置钱包连接组件ConnectCustomWalletComponent中新增我们的创建新钱包账户组件CreateNewCustomWalletComponent。

import { Store } from '../Store';
import './wallet-page.css';
import { useState } from 'react';
import { connectCustomWallet, createNewWallet } from '../utils/wallet_utils';
import { Custom_Wallet_Page_Show_Type } from './CustomWalletComponent';

const CreateNewCustomWalletComponent = () => {
    const [address, setAddress] = useState("");
    const [privateKey, setPrivateKey] = useState("");
    const [wallet, setWallet] = useState(null);
    //调用createNewWallet创建新钱包账户，并展示其公钥和私钥，暂存wallet
    const create_wallet_click = () => {
        const wallet = createNewWallet()
        setWallet(wallet);
        setPrivateKey(wallet.privateKey);
        setAddress(wallet.address);
    }
    //调用connectCustomWallet连接钱包账户，并更新全局状态
    const connect_wallet_click = () => {
        const connctWallet = connectCustomWallet(wallet);
        Store.updataCustomWallet(connctWallet);
        Store.customWalletPageShow.set(Custom_Wallet_Page_Show_Type.hidden);
    }
    return (
        <div className='custom-wallet-page-panel-item-create'>
            <h2 >创建新账户</h2>
            <div className='custom-wallet-page-panel-item-button' onClick={e => { create_wallet_click() }}> 创建账户 </div>
            <div className='custom-wallet-page-panel-item-text'>账户地址</div>
            <div className='custom-wallet-page-panel-item-text'>{address}</div>
            <div className='custom-wallet-page-panel-item-text'>私钥:</div>
            <div className='custom-wallet-page-panel-item-text'>{privateKey}</div>
            <div className='custom-wallet-page-panel-item-button' onClick={e => { connect_wallet_click() }}> 连接钱包 </div>
        </div>
    );
};

export default CreateNewCustomWalletComponent;

管理钱包账户状态

钱包账户状态是1个全局状态，而且页面退出再进入也应该保持连接状态，所以我们将钱包账户持久化到本地，并在页面初始化的时候读取本地存储的钱包账户。那么钱包账户里面信息很多，我们是否需要全部存储？按照我们开始介绍的钱包基础概念，钱包账户核心就是私钥，只要有私钥我们就可以计算得到钱包账户的其他信息，所以我们持久化私钥即可。 先在wallet_utils.js中新增通过私钥生成钱包账户的方法

//通过私钥恢复钱包账户其他信息
export const restoreConnectCustomWallet = (privateKey) => {
    const wallet = new ethers.Wallet(privateKey);
    const provider = new ethers.providers.InfuraProvider(NETWORK, API_KEY);
    const conncetWallet = wallet.connect(provider);
    return conncetWallet;
}

我们在Store.js中对本地钱包账户做一次缓存，这样方便页面内状态监听。

const customWallet = observable.box(null);

//初始化方法
const init = () => {
    //判断是否本地有存储内置钱包账户私钥，如果有则恢复连接，没有则开始监听MetaMask
    const privateKey = localStorage.getItem("wallet_private_key");
    if (privateKey) {
            console.log("already connect " + privateKey);
            customWallet.set(restoreConnectCustomWallet(privateKey));
    } else {
        registerAccountChange();
    }
}      

//更新钱包账户，同时更新Store.js缓存和本地存储。
const updataCustomWallet = (wallet) => {
    customWallet.set(wallet);
    localStorage.setItem("wallet_private_key", wallet ? wallet.privateKey : "");
   }

调整合约交互

我们之前构建合约的时候都是默认使用MetaMask，但目前引入了内置钱包，我们需要进行区分构建，在contract_utils.js进行调整

const getContract = () => {
    const address = "合约地址";
    const abi = require("../abi/NFT_WEB3_EXPOLRER.json").abi;
    return new ethers.Contract(address, abi, getProvider());
}

const getProvider = () => {
    //是否有已经连接的内置钱包账号，有则使用Infura节点代理，没有则使用MetaMask
    if (Store.customWallet.get()) {
        return new ethers.providers.InfuraProvider(NETWORK, API_KEY);
    } else {
        return new ethers.providers.Web3Provider(window.web3.currentProvider);
    }
}

导入钱包账户

如果我们已经拥有1个钱包账户需要导入到内置钱包中，这一过程其实和我们页面初始化时从本地读取钱包账户一致，都是需要通过私钥恢复完整的钱包账户。

import { Store } from '../Store';
import './wallet-page.css';
import { useState } from 'react';
import { Custom_Wallet_Page_Show_Type } from './CustomWalletComponent';

const ImportCustomWalletComponent = () => {
    const [inputValue, setInputValue] = useState("");

    //通过用户输入的私钥导入钱包账户，并更新钱包账户的存储
    const import_wallet_click = () => {
        const connctWallet = restoreConnectCustomWallet(inputValue);
        Store.updataCustomWallet(connctWallet);
        Store.customWalletPageShow.set(Custom_Wallet_Page_Show_Type.hidden);
    }

    const handleChange = (event) => {
        console.log("input value is" + event.target.value);
        setInputValue(event.target.value);
    }
    return (
        <div className='custom-wallet-page-panel-item-import' >
            <h2>导入现有账户</h2>
            <h4>请输入已有账户私钥</h4>
            <input type='text' value={inputValue} onChange={handleChange}></input>
            <div className='custom-wallet-page-panel-item-button' onClick={e => { import_wallet_click() }}> 导入账户并连接 </div>
        </div>
    );
};

export default ImportCustomWalletComponent;

展示已连接钱包账户信息

之前我们页面右上角的连接钱包入口在连接完成后设定是无法点击的，现在有了内置钱包，我们将其修改为连接内置钱包账户时点击打开内置钱包账户的信息展示页面，展示钱包账户地址，余额，私钥(默认不展示)，并在该页面中提供断开钱包账户连接的功能。其中按照开始介绍的钱包基础概念，钱包账户余额存在链上，所以获取余额需要请求节点代理是1个异步过程。断开钱包账户连接其实就是清空本地存储的私钥信息。

import { Store } from '../Store';
import './wallet-page.css';
import { useEffect, useState } from 'react';
import { Custom_Wallet_Page_Show_Type } from './CustomWalletComponent';

const CustomWalletInfoComponent = () => {
    const [balance, setBalance] = useState("");
    const [isShowPrivateKey, setShowPrivateKey] = useState(false);

    useEffect(() => {
        //获取当前内置钱包账户的余额，需要请求节点代理
        Store.customWallet.get().getBalance()
            .then((b) => {
                console.log(b);
                setBalance(b?.toString());
            })
            .catch((e) => {
                console.error(e);
            });
    }, []);

    //私钥默认不展示
    const show_private_key = () => {
        setShowPrivateKey(true);
    }

    //断开连接，清空保存的账户信息
    const disconncet = () => {
        Store.updataCustomWallet(null);
        Store.customWalletPageShow.set(Custom_Wallet_Page_Show_Type.hidden);
    }

    console.log("privateKey" + Store.customWallet.get()?.privateKey);
    return (<div className='wallet-page-bg' onClick={() => { cancel_click() }}>
        <div className='custom-wallet-page-panel-info' onClick={e => { panel_click(e) }}>
            <div className='custom-wallet-page-panel-item-info' >
                <h2 >账户信息</h2>
                <div className='custom-wallet-page-panel-item-text'>钱包地址:</div>
                <div className='custom-wallet-page-panel-item-text'>{Store.customWallet.get()?.address}</div>
                <div className='custom-wallet-page-panel-item-text'>余额:</div>
                <div className='custom-wallet-page-panel-item-text'>{balance}wei</div>
                <div className='custom-wallet-page-panel-item-button' onClick={e => { show_private_key() }}> 显示私钥 </div>
                <div className='custom-wallet-page-panel-item-text'>私钥:</div>
                <div className='custom-wallet-page-panel-item-text'>{isShowPrivateKey ? Store.customWallet.get()?.privateKey : ""}</div>
                <div className='custom-wallet-page-panel-item-button' onClick={e => { disconncet() }}> 断开连接 </div>
            </div>
        </div>
    </div>);

};

export default CustomWalletInfoComponent;

使用已连接钱包完成转账

在我们的NFT官网中mint是一种转账操作，该操作需要向合约账户转一定数量的ETH，转账操作会需要私钥的签名，之前我们默认使用MetaMask的Singer，现在在contract_utils.js中新增方法，根据是否连接内置钱包选择不同的Singer。补充一点，Wallet继承自Singer，所以Wallet可以直接作为Singer使用。

const getSigner = () => {
    //已连接内置钱包，则优先使用内置钱包的账户
    if (Store.customWallet.get()) {
        return Store.customWallet.get();
    } else {
        const provider = new ethers.providers.Web3Provider(window.web3.currentProvider);
        return provider.getSigner();
    }
}

转账对用户进行提示

在官网进行转账操作，我们有义务提示用户进行二次确认，避免在用户不知情的情况下发生转账行为给用户带来资金损失，所以修改contract_utils.js中的mint方法，在执行Mint这一转账操作前，弹出弹窗让用户进行确认。

export const mint = async () => {
    const contract = getContract();
    const contractWithSigner = contract.connect(getSigner());
    const price = await contract.PRICE_PER_TOKEN();
    console.log("price is" + price);
    //调用Mint方法前先弹确认弹窗让用户进行确认
    const r = window.confirm("你将向地址: "+ contract.address + "  转账: " + price +"wei");
    if (r) {
        const tx = await contractWithSigner.mint(1, { value: price });
        console.log(tx);
        await tx.wait();
        window.alert("mint成功");
    }
}

至此，我们为我们的Dapp增加了1个功能完整的内置钱包。

结尾

由于以太坊中账户校验规则都是一致的，所以使用该内置钱包生成的账户也可连接到MetaMask, 或者将MetaMask生成的账户导入到内置钱包也可以正常使用。此外，为了减少篇幅没有介绍助记词相关，如果有兴趣，可以了解BIP39在本文基础上很容易拓展支持助记词。内置钱包可以减少用户使用Dapp的门槛，希望各位小伙伴早日探索开发出可以破圈的Dapp。

上篇文章我们介绍了，如何部署NFT的智能合约到链上，这相当于NFT的后端部分完成，但作为NFT的宣发需要1个网站，属于NFT的前端部分。

官网规划

这个网站需要达成下面这几个目标:

1. 项目介绍

2. NFT mint进度展示 以及mint功能

3. NFT 列表展示

4. 联系方式

为了达成这些目标，我们通常会先完成草图的设计，在这里我直接使用项目最后的截图来展示UI架构，大家可以使用figma等工具完成第一步的草图设计。

可以看到，页面可以分为3部分

• 顶部栏: 包含项目名称、主功能tab、连接钱包按钮。

• 内容区: 根据顶部栏所选tab不同分为项目简介页面、mint进度以及mint功能页面、NFT列表展示页面。

• 底部栏: 包含联系方式。

同时点击连接钱包按钮，我们需要1个钱包选择页面(目前只支持MetaMask)进行连接。

其中我们需要重点关注的是连接钱包按钮，钱包选择页面，mint页面, NFT展示页面。其余页面比较简单，为了完整性还是将其余部分代码展现，如果有前端基础的同学只查看上述重点页面实现即可。

技术选型

项目框架: 项目采用Reac框架，页面整体状态由mbox框架来进行管理,我们只使用mbox最简单的用法。

钱包交互: 我们使用MetaMask API

合约交互: 使用ethers.js API

除了上述依赖库外，我们的项目将尽可能减少依赖库的使用

初始化项目

//使用react 官方脚手架初始化我们的项目
npx create-react-app nft-web3-explorer-page
cd nft-web3-explorer-page

//尝试运行项目
npm start

使用vscode打开我们的工程

我们按照页面框架功能区，在src下新建3个目录topbar、content、bottombar，并在3个目录下分别新建组件TopBarComponent.js、ContentComponent.js、BottomBarComponent.js。(css样式大家自行调整,不是本文重点)

TopBarComponent.js

import './topbar.css';

const TopBarComponent = () => {
  return (
    <div className='topbar'>

    </div>
  );
}
export default TopBarComponent;

ContentComponent.js、BottomBarComponent.js代码一致，不再重复。

调整index.js和App.js代码

index.js

import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <App />
);

App.js

import './App.css';
import BottomBarComponent from './bottombar/BottomBarComponent';
import ContentComponent from './content/ContentComponent';
import TopBarComponent from './topbar/TopBarComponent';

function App() {
  return (
    <div className="App">
      <TopBarComponent />
      <ContentComponent />
      <BottomBarComponent />
    </div>
  );
}

export default App;

此时我们的代码运行结果,已经将页面划分为3个区域(topbar因为和文章背景一致所以看不出来)

接下来，我们就去逐步完善每个区域。

TopBar区域完善

从最开始的图中可以看到TopBar可以分为3个区域:项目/社区名称，主功能tabs，连接钱包入口。

项目/社区名称

import './topbar.css';
const TitleComponent = () => {
    return (
        <div className='title'>
            <h1 className='title-text' > Web3探索者 </h1>
        </div>
    )
}
export default TitleComponent;

主功能tab

import './topbar.css';
const MainFeatureTabsComponent = ()=> {
    return (
        <div className="tablist">
            <div className="tablist-item">
                <a href='/' className='tablist-item-a'>简介</a>
            </div>
            <div className="tablist-item" >
                <a href='/mint' className='tablist-item-a'> mint</a>
            </div>
            <div className="tablist-item" >
                <a href='/list' className='tablist-item-a'>
                    NFT列表
                </a>
            </div>
        </div>
    );
}

export default MainFeatureTabsComponent;

每次点击的时候切换子页面，后面Content页面的内容就会监听链接变化，发生变化则Content内部进行页面切换

钱包连接入口

钱包连接入口这里的逻辑有一些复杂。我们需要实现下面的目标

1. 页面初始化的时候判断钱包是否已经连接，如果已连接展示其钱包地址。

2. 中途用户连接钱包或断开钱包连接，需要更新对应状态，如果状态变为连接钱包需要展示钱包地址，如果状态变为未连接则展示连接钱包。

3. 钱包未连接状态下按钮可点击，点击拉起钱包选择面板，连接状态下按钮不可点击。

钱包状态读取

钱包相关状态的读取，我们使用MetaMask提供的API，我们在src目录下新建utils目录，在utils下新建walletUtils.js封装和MetaMask钱包的交互。

//判断钱包是否安装
export const isMetaMaskInstalled = () => {
    const { ethereum } = window;
    return Boolean(ethereum && ethereum.isMetaMask);
};

//请求连接钱包
export const metamaskConnect = async () => {
    try {
        const { ethereum } = window;
        return await ethereum.request({ method: 'eth_requestAccounts' });
    } catch (error) {
        console.error(error);
    }
};
//获取当前已经连接的钱包地址
export const getConnectAccount = async () => {
    const { ethereum } = window;
    const account = await ethereum.request({ method: 'eth_accounts' });
    console.log("getConnectAccount" + account);
    return account;
}

钱包状态管理

由于钱包状态是1个全局状态，并非组件内状态，所以我们使用mobx来进行存储以及其状态变化的通知监听。

添加mobx依赖

npm i mobx

在src目录下新增Store.js来管理全局状态

import { observable } from "mobx";
import { getConnectAccount } from "./utils/wallet_utils";

const help = () => {
    // 钱包选择页面板是否展示状态
    const wallet_is_show = observable.box(false);
    // 当前连接的钱包地址，未连接则存储""
    const currentAccount = observable.box("");
    //连接钱包地址发生变化时的处理，更新存储状态
    const handleAccountChange = (accounts) => {
        if (accounts.length === 0) {
            console.log("accounts is null");
            currentAccount.set("");
        } else if (accounts[0] !== currentAccount) {
            console.log("accounts is " + accounts[0]);
            currentAccount.set(accounts[0]);
        }
    }

    //注册钱包状态的监听
    const registerAccountChange = () => {
        console.log("registerAccountChange");
        const { ethereum } = window;

        //注册时先获取一次当前状态
        getConnectAccount().
            then((accounts) => {
                handleAccountChange(accounts);
            }).catch((err) => {
                console.error(err);
            });

       //使用metamask提供的API注册钱包状态监听
        ethereum.on('accountsChanged', (accounts) => {
            handleAccountChange(accounts);
        });
    }

    return {wallet_is_show, registerAccountChange,currentAccount};

};
export const Store = help();

在App.js中增加初始化监听钱包连接变化的调用

useEffect(() => {
    Store.registerAccountChange()
  }, []);

完成钱包入口组件

完成钱包入口组件ToolbarComponent.js

import {Store} from '../Store';
import './topbar.css';
import {useState } from 'react';

 const ToolbarComponent = () => {
     //组件内部定义入口按钮展示文案
    const [text, setText] = useState(Store.currentAccount.get() === "" ? "连接钱包" : Store.currentAccount.get());

    useEffect(() => {
      //使用mobx监听钱包状态的变化
        Store.currentAccount.observe_((newAccount) => {
            if (newAccount.newValue === "") {
                setText("连接钱包");
            } else {
                setText(newAccount.newValue);
            }
        });   
    }, []);  

    return (
        <div className='toolbar'>
            <div className='connect-wallet' > 
                <h2 className='connect-wallet-text' 
                    onClick={() => { onclick_wallet() }}> {text} </h2>
             </div>
        </div>
    );
}

const onclick_wallet = () => {
    if (Store.currentAccount.get() === "") {
        Store.wallet_is_show.set(true);
    }
}
export default ToolbarComponent;

我们点击钱包入口的时候，如果未连接需要展示钱包选择页面。

钱包选择页面

在src目录下新建1个钱包页面目录wallet_page

我们钱包组件有以下能力

1. 打开钱包面板时判断是否已经安装MetaMask，如果未安装，则直接提示请先安装MetaMask

2. 点击钱包面板时发起连接钱包请求

3. 钱包连接成功，自动关闭

4. 点击面板外其他位置时关闭面板

在wallet_page下新建组件WalletComponent.js

import {Store} from '../Store';
import './wallet-page.css';
import { useEffect, useState } from 'react';
import { isMetaMaskInstalled, metamaskConnect } from '../utils/walletUtils';

const WalletComponent = () => {
    //组件内部定义钱包选择页面是否展示的状态。
    const [wallet_is_show, setWalletShow] = useState(false);
    useEffect(() => {
        //如果其他地方打开或关闭钱包选择页面，组件内部状态需要同步
        Store.wallet_is_show.observe_((change) => {
            setWalletShow(change.newValue);
        });
        // 如果账户状态发生改变，需要关闭该页面，比如连接钱包成功应该自动关闭该页面
        Store.currentAccount.observe_((change) => {
            Store.wallet_is_show.set(false);
        });
    }, []);

    if (!wallet_is_show) {
        return <div className='display-none'></div>
    }

    const text = isMetaMaskInstalled() ? "MetaMask" : "请先安装 MetaMask";
    return (
        <div className='wallet-page-bg' onClick={cancel_click}>
            <div className='wallet-page-panel' onClick={(e) => {metaMask_click(e)}}> {text} </div>
        </div>
    );
};

const cancel_click = () => {
    console.log("cancel_click");
    Store.wallet_is_show.set(false);
}

const metaMask_click = async (e) => {
    e.stopPropagation();
    if (isMetaMaskInstalled()) {
        metamaskConnect();
    }
    console.log("metaMask_click");
}

export default WalletComponent;

在App.js中添加WalletComponent组件

注意，在测试钱包连接入口组件和钱包选择页面时，我们可以在metamask中断开已连接的网站，这样就可以进行反复测。

BottomBar区域完善

import './bottombar.css';

const TWITTER_ICON = {图片链接}
const DISCORD_ICON = {图片链接}

function JoinComponent() {
    return (
        <div className='join'>
            <a href="https://twitter.com/twitter链接" target="_blank" className="join_item">
            <img src={TWITTER_ICON} loading="lazy" alt=""/>
            </a>
            <a href="https://discord.gg/discord链接" target="_blank" className="join_item">
                <img src={DISCORD_ICON} loading="lazy"/>
            </a>
        </div>
    );
}
export default JoinComponent;

在BottomBarComponent.js中添加该组件

Content区域完善

Content根据不同的tab将会展示3个页面:项目/社区简介页面, NFT展示页面, mint页面

项目/社区简介页面

在content目录下新建MainPageComponent.js组件

import './content.css';
function MainPageComponent() {
    return (
        <div className='mainpage'>
            <h1 className='overview-title'>
                项目介绍
            </h1>
            <p className='overview-text'>
                白皮书内容
            </p>
        </div>

    );
}
export default MainPageComponent;

NFT展示页面

这个页面将是1个展示所有已经mint NFT的列表。我们这里只展示每1个NFT的图片以及名字。

与合约进行交互

NFT列表展示，需要从合约中读取一些数据，包括

1. TokenID对应的TokenURI, 因为token的image name等信息都存储在TokenURI指向的metadata中

2. 目前已经Mint过的所有tokenID，因为上篇文章我们的mint规则是顺序mint，所以我们只需要获得当前已经Mint的token总数，然后从0遍历即可。

这里使用ethres.js与合约进行交互,添加ethres.js依赖

npm i ethers

另外需要注意，需要将MetaMask网络切换到rinkeby, 因为上篇文章我们是将合约部署在rinkeby测试网络中,只有在该网络从才可以获取到相应的合约信息。

根目录下新建abi目录将我们上篇文章中编译合约生成的NFT_WEB3_EXPOLRER.json 复制进去。

另外还有2点

1. 我们需要解析TokenURI对应的metadata,从中获取到名字、图片等具体数据

2. 因为我们上篇文章中，metadata的image是使用Ipfs存储，浏览器不直接支持ipfs协议，所以我们需要将ipfs协议转换成为https协议，使用的工具库是我们上篇文章上传ipfs的平台https://app.pinata.cloud/提供。

添加pinata/ipfs-gateway-tools依赖

npm i @pinata/ipfs-gateway-tools

在utils目录下新增contractUtils.js, 来实现一系列的封装方法达成上述功能。

// import Web3 from "web3"

import { ethers } from 'ethers';
import IPFSGatewayTools from '@pinata/ipfs-gateway-tools/dist/browser';

const gatewayTools = new IPFSGatewayTools();

//获取tokenID对应的URI
export const getTokenURI = async (tokenID) => {
    const contract = getContract();
    return await contract.tokenURI(tokenID);
}

//获取合约
const getContract = () => {
    //在这里我们使用MetaMask向浏览器注入的provider
    const provider = new ethers.providers.Web3Provider(window.web3.currentProvider);
    const address = "合约地址";
    const abi = require("../abi/NFT_WEB3_EXPOLRER.json").abi;
    return new ethers.Contract(address, abi, provider);
}

//获取已经mint的token总数
export const totalSupplyToken = async () => {
    const contract = getContract();
    return await contract.totalSupply();
}

//获取已mint tokenURI对应的metadata
export const getMetaDataList = async () => {
    const totalSupply = await totalSupplyToken();
    console.log("totalSupplyToken is" + totalSupply);
    const list = []
    for (let tokenID = 0; tokenID < totalSupply; tokenID++) {
        const tokenURI = await getTokenURI(tokenID);
        const res = await parseMetaData(tokenURI);
        list.push(res);
    }
    return list;
}

//通过tokenURI获取metadata
export const parseMetaData = async (TokenURI) => {
    const res = await fetch(TokenURI);
    const json = await res.json();
    return json;
}

//将ipfs地址转为http地址
export const ipfsToHttp = (ipfsURL) => {
    return gatewayTools.convertToDesiredGateway(ipfsURL, "https://gateway.pinata.cloud");
}

接下来在content目录下新建NFTListComponent组件调用上述方法进行展示

import './content.css';
import { getMetaDataList, ipfsToHttp } from "../utils/contractUtils";
import { useEffect, useState } from 'react';

function NFTListComponent() {
    const [metadatalist, setMetadataList] = useState([]);

    useEffect(() => {
        //获取NFT的MetaMata列表
        getMetaDataList()
            .then((arr) => {
                setMetadataList(arr);
            })
            .catch((err) => {
                console.error("err is" + err);
            });
    }, []);

    const items = metadatalist.map((metadata, index) => 
        <div className='nft-list-item' key={index}>
            <img className='nft-list-item-img'  src={ipfsToHttp(metadata.image)} />
            <h4 className='nft-list-item-name'> {metadata.name} </h4>
        </div>
    );
    console.log("items is" + items);

    return (
        <div className='nft-list'>
            {items}
        </div>

    );
}
export default NFTListComponent;

接下来我们来实现最后1个页面NFT的mint页面

NFT mint页面

这个页面有2个功能

1. 展示mint进度

2. 提供mint入口

为了实现这2个功能，我们需要增加一些与合约交互的能力。在contractUtils.js中新增3个函数

//获取最大可mint数量
export const maxSupplyToken = async () => {
    const contract = getContract();
    return await contract.MAX_SUPPLY();
}

//同时返回当前mint总数和最大mint总数
export const getMintInfo = async () => {
    const totalSupply = await totalSupplyToken();
    const maxSupply = await maxSupplyToken();
    return [totalSupply, maxSupply];
}

// mint功能，这里同样是使用metamask进行签名，调用该方法MetaMask会弹出交易确认按钮
export const mint = async () => {
    const contract = getContract();
    const provider = new ethers.providers.Web3Provider(window.web3.currentProvider);
    const signer = provider.getSigner();
    const contractWithSigner = contract.connect(signer);
    const price = await contract.PRICE_PER_TOKEN();
    console.log("price is" + price);
    const tx = await contractWithSigner.mint(1, { value: price });
    console.log(tx.hash);
    await tx.wait();
}

实现MintPageComponent组件

import { useEffect, useState } from 'react';
import { Store } from '../Store';
import { getMintInfo, mint } from '../utils/contractUtils';
import './content.css';

const MintPageComponent = () => {
    const [totalSupply, setTotalSupply] = useState(0);
    const [maxSupply, setMaxTotalSupply] = useState(0);

    useEffect(() => {
        updataMintInfo();
    }, []);

    const updataMintInfo = () => {
        getMintInfo()
            .then((info) => {
                setTotalSupply(info[0]);
                setMaxTotalSupply(info[1]);
            })
            .catch((err) => {
                console.error(err);
            });
    }

    const mintClick = () => {
        if (Store.currentAccount.get() === "") {
            window.alert("请先连接钱包");
            return;
        }
        mint()
        .then(() => {
            //mint成功后更新mint信息
            updataMintInfo();
            window.alert("mint成功");
        }).catch();
    }

    return (
        <div className='mintpage'>
            <div className='mint-info'>当前mint进度 {"" + totalSupply} / {"" + maxSupply}</div>
            <div className='mint-btn' onClick={mintClick}>一键mint</div>
        </div>
    );
}

export default MintPageComponent;

最后我们在ContentComponent增加MainPageComponent、MintPageComponent、NFTListComponent，并设置路由状态变化的监听

import { useEffect, useState } from 'react';
import './content.css';
import MainPageComponent from './MainPageComponent';
import MintPageComponent from './MintPageComponent';
import NFTListComponent from './NFTListComponent';

const ContentComponent = () => {
  const [route, setRoute] = useState("");

  useEffect(() => {
    setRoute(window.location.pathname);
  });

  return (
    <div className='content'>
      {(route != "/mint" && route != "/list") && <MainPageComponent />}
      {(route == "/mint") && <MintPageComponent />}
      {(route == "/list") && <NFTListComponent />}
    </div>
  );
}

export default ContentComponent;

好了，目前为止我们的NFT官网就搭建完成了。基本的功能都已经实现，页面框架也有了。当然如果要进行上线官网的UI还需要进行仔细设计。后面还可以增加查看归属自己的NFT等功能，同时比如mint进度这里我们没有监听其他人在我们浏览页面过程中的mint事件，可能导致更新不及时，篇幅原因这里不再介绍。

结尾

我们通过2篇文章来介绍NFT的发布，第一篇重点讲解如何上链，可以归属于后端逻辑。第二篇讲解官方搭建，可以归属于前端逻辑。希望这些内容可以帮助有发行NFT的小伙伴发行属于自己的NFT。同时这2篇文章也是大家学习DApp开发的一个很好的示例，希望能够帮助到希望进入web3行业的同学。

如何发行一款社区概念的NFT，一般是有4个步骤

1. 发起人完成白皮书

2. 完成NFT设计并编写智能合约代码发布到链上

3. 完成NFT社区官网，一般包含白皮书简介，mint,NFT列表展览等功能

4. 社区运营以及持续为达成白皮书的目标而合作迭代

我们选择技术点涉及较多的2、3步骤和大家讨论。分为上下两篇文章，本文将重点讲解第2点如何完成NFT智能合约的开发、部署、交互以及在交易市场查看自己发行的NFT。下篇文章会重点讲解第3点NFT社区官网的搭建。

合约开发环境选择

目前主流的智能合约开发环境有3个:remix,hardhat, truffle。remix是浏览器IDE，虽然开箱即用，上手简单，但在灵活性和功能完善度上不如hardhat, truffle。hardhat, truffle相比较，truffle是老牌主流框架，hardhat是新起之秀，但目前也足够稳定。 我们最终选择hardhat作为我们的本地合约开发环境。

初始化工程

//创建一款web3探索者的nft
mkdir  nft-web3-explorer

//进入目录
cd nft-web3-explorer

//初始化项目，根据提示填写即可，packname和description填写即可
npm init

//添加hardhat依赖
npm install --save-dev hardhat


/*使用脚手架搭建项目,我们选择Create a basic sample project
可以帮助我们创建1个demo工程并按照所需的依赖*/
npx hardhat

创建完成后，我们看看我们的目录结构

• contracts目录用来存放我们的智能合约代码

• scripts用来存放我们的脚本，比如合约部署就会依赖其中的脚本

• test目录用来存放我们为智能合约编写的测试代码

• hardhat.config.js是关于hardhat框架的一些配置，比如solidity版本等

• package.json是npm的相关配置

使用vscode打开该工程,最好安装vscode的solidity插件。

编写合约代码

目前就可以开始写合约代码了，本文主要是介绍NFT的发行，我们简单来实现一份NFT智能合约代码。

//安装openzeppelin/contracts依赖，内置较多合约协议的实现以及工具代码
npm install @openzeppelin/contracts

我们在contracts目录下创建NFT_WEB3_EXPOLRER.sol的文件。

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";

contract NFT_WEB3_EXPLORER is ERC721, ERC721Enumerable, Ownable {
    string private _baseURIextended;
    //我们设置最多可以mint1000个
    uint256 public constant MAX_SUPPLY = 1000;
    //每个mint的价格是0.01EHT
    uint256 public constant PRICE_PER_TOKEN = 0.01 ether;

    constructor() ERC721("nft_web3_explorer", "NFT_WEB3_EXPLORER") {
    }

    function _beforeTokenTransfer(address from, address to, uint256 tokenId) internal override(ERC721, ERC721Enumerable) {
        super._beforeTokenTransfer(from, to, tokenId);
    }

    function supportsInterface(bytes4 interfaceId) public view virtual override(ERC721, ERC721Enumerable) returns (bool) {
        return super.supportsInterface(interfaceId);
    }

    function setBaseURI(string memory baseURI_) external onlyOwner() {
        _baseURIextended = baseURI_;
    }

    function _baseURI() internal view virtual override returns (string memory) {
        return _baseURIextended;
    }

    function mint(uint numberOfTokens) public payable {
        uint256 ts = totalSupply();
        require(ts + numberOfTokens <= MAX_SUPPLY, "Purchase would exceed max tokens");
        require(PRICE_PER_TOKEN * numberOfTokens <= msg.value, "Ether value sent is not correct");

        for (uint256 i = 0; i < numberOfTokens; i++) {
            _safeMint(msg.sender, ts + i);
        }
    }

    function withdraw() public onlyOwner {
        uint balance = address(this).balance;
        payable(msg.sender).transfer(balance);
    }
}

非常简单，这源于ERC721协议的帮助。该代码不具备上线标准，因为没有白名单，每个地址限制mint多少个等，仅供示意。建议发行NFT前需要好好设计合约，

合约编译

//合约编译
npx hardhat compile

合约部署

修改scripts目录下自动生成的脚本改名为deploy.js并修改内部代码

const hre = require("hardhat");

async function main() {
  // Hardhat always runs the compile task when running scripts with its command
  // line interface.
  //
  // If this script is run directly using `node` you may want to call compile
  // manually to make sure everything is compiled
  // await hre.run('compile');

  // We get the contract to deploy
  const Nft_web3_explrer = await hre.ethers.getContractFactory("NFT_WEB3_EXPLORER");
  const nft_web3_explrer = await Nft_web3_explrer.deploy();

  await nft_web3_explrer.deployed();

  console.log("NFT_WEB3_EXPLORER deployed to:", nft_web3_explorer.address);
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

选择节点服务代理

此时，因为我们并不想在本地运行1个以太坊节点，所以我们使用节点服务代理(管理节点)，我们与他们进行api交互，他们会在云上管理的节点中执行对应的节点操作。这里我们选用与MetaMask同一服务代理 https://infura.io/ 注册账号后，我们创建1个项目

测试网络环境搭建

我们首先需要在测试网络中部署，由于很多NFT交易市场只支持rinkeby，所以我们选择rinkeby作为我们的测试网络。

因为在代码执行过程中会用到公钥、私钥、API等数据，但这些数据又不能编码到代码中，因为如果我们使用git来管理项目，信息将会泄露。我们使用dotenv存放部署合约以及和合约交互需要用到的数据。

//添加dotenv依赖
npm install dotenv

//工程根目录下创建变量存储文件
touch .env

为.env增加内容

PRIVATE_KEY=导出你metamask的私钥填在这里
API=找到节点服务代理URL填在这里
PUBLIC_KEY=metamask地址
NETWORK=rinkeby
API_KEY=节点服务代理的ProjectID

• metamask私钥导出:打开钱包-账号详情->导出私钥。

• 服务代理URL:将网络切换到ROPSTEN，复制下面的https链接。

修改hardhat.config.js

require("@nomiclabs/hardhat-waffle");

// This is a sample Hardhat task. To learn how to create your own go to
// https://hardhat.org/guides/create-task.html
require('dotenv').config();
const { API, PRIVATE_KEY } = process.env;

// You need to export an object to set up your config
// Go to https://hardhat.org/config/ to learn more

/**
 * @type import('hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: "0.8.4",
  defaultNetwork: "rinkeby",
  networks: {
    hardhat: {},
    rinkeby: {
      url: API,
      accounts: [`0x${PRIVATE_KEY}`]
    }
  },
};

获取测试网络ETH 因为合约测试需要消耗ETH，我们需要获取一些测试完了的ETH，我们打开https://fauceth.komputing.org/ 选择rinkeby网络，填入我们的钱包地址即可获取。

此时我们将钱包切换到rinkeby测试网络，可以看到钱包中已经有一些ETH了。

执行合约部署

npx hardhat --network rinkeby run scripts/deploy.js

//执行完成后得到提示，代表合约部署完成
NFT_WEB3_EXPOLRER deployed to: {合约地址}

此时我们可以在https://rinkeby.etherscan.io/搜索我们的合约地址找到我们的合约信息

为NFT设置资源

现在的NFT仅仅包含tokenID，我们需要为其设置资源, 在ERC721的实现中我们可以看到tokenURI方法的实现，各个交易市场就是调用该方法来读取NFT资源信息的

    /**
     * @dev See {IERC721Metadata-tokenURI}.
     */
    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拼接来读取tokenURI的，所以我们也按照这种格式来准备资源。

准备资源

//创建资源文件
mkdir res
cd res
//存放图片
mkdir  img
//存放metadata信息
mkdir  metadata

由于本文是示例项目，没有找专门的设计师设计图片，我们网上找了7张图片。将7张图片放入img目录下，依次命名为0.png ~ 7.png

我们将7张图片上传到ipfs中，这里和以太坊网络一样，由于我们不想运行本地ipfs节点，所以我们寻找节点服务提供商进行上传。我们使用https://app.pinata.cloud/选择上传目录进行将img目录上传 上传完成后的图片资源

接下来我们准备metadata文件,在metadata目录下新建7个文件依次命名为0~7，我们看下0号文件信息

{
    "name": "nft-web3-explorer",
    "attributes": [
        {
            "trait_type": "tokenID",
            "value": "0"
        }
    ],
    "description": "nft-web3-explorer image",
    //填入上面刚刚上传完成的图片地址
    "image": "ipfs://QmZ3Y31SwLU77CDfBoL5MphuSmrv414d2ZyunVcbNAJQRQ/0.png"
}

设置BaseURI

我们需要将刚刚上传后的metadata文件地址设置给合约的baseURI，这样各个平台在使用tokenURI获取资源信息才可以获取到。

编写代码与合约交互设置BaseURI，在scripts目录下新建setBaseURI.js文件。

setBaseURI.js

require("dotenv").config()
const hre = require("hardhat");
const PRIVATE_KEY = process.env.PRIVATE_KEY
const NETWORK = process.env.NETWORK
const API_KEY = process.env.API_KEY


const provider = new hre.ethers.providers.InfuraProvider(NETWORK, API_KEY);
//编译完成合约会自动生成
const abi = require("../artifacts/contracts/NFT_WEB3_EXPLORER.sol/NFT_WEB3_EXPLORER.json").abi
const contractAddress = "合约地址"
const contract = new hre.ethers.Contract(contractAddress, abi, provider)
const wallet = new hre.ethers.Wallet(PRIVATE_KEY, provider)
const baseURI = "metadata文件地址"

async function main() {
  const contractWithSigner = contract.connect(wallet);
  //调用setBaseURI方法
  const tx = await contractWithSigner.setBaseURI(baseURI)
  console.log(tx.hash);
  await tx.wait();
  console.log("setBaseURL success");
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

在这里我们与合约交互主要是使用ethers，目前主流封装与合约交互的js库有2个web3.js与ethers.js，此处使用ethers的原因是hardhat默认和ethers配合。

//执行setBaseURI脚本
npx hardhat --network rinkeby run scripts/setBaseURI.js

mint测试

因为只有mint过的tokenID才会展示在交易市场中，所以我们需要编写代码进行mint测试(实际场景，该操作应该由前端页面调用完成)。mint.js

require("dotenv").config()
const hre = require("hardhat");
const PRIVATE_KEY = process.env.PRIVATE_KEY
const NETWORK = process.env.NETWORK
const API_KEY = process.env.API_KEY


const provider = new hre.ethers.providers.InfuraProvider(NETWORK, API_KEY);
const abi = require("../artifacts/contracts/NFT_WEB3_EXPOLRER.sol/NFT_WEB3_EXPOLRER.json").abi
const contractAddress = "合约地址"
const contract = new hre.ethers.Contract(contractAddress, abi, provider)
const wallet = new hre.ethers.Wallet(PRIVATE_KEY, provider)

async function main() {
    const contractWithSigner = contract.connect(wallet);
    //获取mint需要多少ETH
    const price = await contract.PRICE_PER_TOKEN();
    console.log("price is" + price);
    //调用mint方法，支付mint费用
    const tx = await contractWithSigner.mint(1, { value: price});
    console.log(tx.hash);
    await tx.wait();
    console.log("mint success");
}

main()
    .then(() => process.exit(0))
    .catch((error) => {
        console.error(error);
        process.exit(1);
    });

//执行mint脚本
npx hardhat --network rinkeby run scripts/mint.js

查看NFT

此时我们去opensea或looksrare等NFT市场查看我们的NFT即可(个人建议looksrare查看，opensea测试网络速度很慢，而且metadata信息更新也比较慢)

• opensea测试网络地址:https://testnets.opensea.io/

• looksrare测试网络地址:https://rinkeby.looksrare.org/

结尾

本篇文章我们介绍了如何一步步编写合约，部署以及与合约交互完成将NFT发布到链上，下篇文章将介绍如何搭建NFT的官网。

========

往期文章

Layer2: 真正理解 Layer2 Immutable X白皮书(译) 跨链: 关于Cosmos的研究 基础理论: 关于区块链不可能三角的研究 关于零知识证明的研究 以太坊: 以太坊技术系列-以太坊数据结构 以太坊技术系列-以太坊共识机制 以太坊技术系列-钱包-以太坊中的账户 聊一聊智能合约 去中心化存储: 去中心化存储的那些事(上) 去中心化存储那些事(下) 其他公链: Flow白皮书1-共识和计算分离(译) 智能合约实战: 智能合约升级详解

智能合约的特点之一就是部署到链上之后不能修改，这一机制使得合约的交互方都可以信任合约。但也带来了一系列的问题，其一如果已部署的合约发现漏洞，无法修复，其二如果已部署的合约要进行功能升级，很难对使用方无感知。所以我们希望能够想一种办法能够升级合约，解决上述问题。当然合约升级不仅仅是个技术问题，也是治理问题，因为合约如果可以被随意修改那么信任的基石将消失，所以需要有一系列的升级治理方案来对升级合约进行约束。本文主要讨论合约升级的技术实现，升级治理暂不讨论。

目标梳理

先看下我们希望达成的目标。

这是我们的直接目标，之前调用合约V1的调用者全部改为调用合约V2，但这样一来所有调用者都需要更改,只要有1个调用者漏改，那么他就会调用失败。有没有一种方案不需要调用者感知呢？计算机设计中"加一层"的思想又得到了充分应用，我们增加代理合约，调用方只对接代理合约，合约升级代理合约内部解决。

现在我们的目标就是思考如何实现核心的代理合约。

升级原理

升级合约中应该有2个方法:

1. 升级方法，需要每次设置实现合约(包含真正业务逻辑代码的合约)的地址，这个比较简单

2. 代理方法，这个方法是连接调用者和实现合约的桥梁

代理方法需要如何调用实现合约内的方法呢？我们需要先来研究一下合约之间方法调用有哪几种方式然后选择适合这个场景的来使用。

调用合约的方式

直接调用 这种方式我们需要显示指定调用的方式，就像正常的函数调用一样，需要将合约地址传入构造出被调用合约。

/**
    调用者合约
**/
contract A {
    function x(address addr) public {
        B b = B(addr);
        b.y();
    }
}
/**
    被调用者合约
**/
contract B {
    uint public t;
    function y() public {
        t = t + 1;
    }

}

call调用 这种调用方式是使用ABI来对方法进行调用(对ABI不了解的小伙伴可以自行查阅，简单理解为将方法编码成二进制表示)

/**
    调用者合约
**/
contract A {
    function x(address addr) public {
        //获得方法对应的ABI，可以由外部传入
        bytes memory method = abi.encodeWithSignature("y()");
        (bool success, ) = addr.call(method);
    }
}

delegatecall调用 另外一种使用ABI方式来对方法进行调用，不过和call不同的是delegatecall调用不会切换上下文到目标合约中，下面会详细介绍。

/**
    调用者合约
**/
contract A {
    function x(address addr) public {
        //获得方法对应的bytes，可以由外部传入
        bytes memory method = abi.encodeWithSignature("y()");
        (bool success, ) = addr.delegatecall(method);
    }
}

在这个例子中使用delegatecall，我们会发现在调用完x()方法后，B的t状态并没有变化。delegatecall是在本合约的上下文中去执行目标合约的方法逻辑，所以当方法执行寻找状态t时，也是在A合约去寻找而不是在B合约去寻找。

那么合约升级需要选择哪种调用方式呢？我们从2个方面角度考虑:

1. 代理合约到实现合约的调用要足够通用，因为代理合约不可更改,所以应该选用抽象程度较高的方式，不能将调用方法硬编码到合约中。

2. 合约升级后，合约的状态不能丢失，因此合约状态不应该维护在可升级的实现合约中，而应该维护在代理合约中，状态在代理合约中我们的调用时也就不能进行上下切换到实现合约中去。

从这2方面考虑，我们使用delegatecall来作为代理合约调用实现合约的方式。

我们来看一版最简实现代码

pragma solidity ^0.8.0;
/**
    调用者合约
**/
contract Proxy {
    address public impl;
    event log(bytes);
    fallback () external payable{
        //msg.data即是被调用方法的ABI表述
        (bool success, ) = addr.delegatecall(msg.data);
        emit log(res);
    }
    //升级方法，如果需要升级调用该方法设置升级后的合约地址即可
    function setImpl(address addr) public{
        impl = addr;
    }
}

pragma solidity ^0.8.0;
/**
    实现合约 V1
**/
contract ImplV1 {
    uint public t;
    function addT() public payable {
        t = t + 1;
    }
    function getT() public returns (uint res){
        return t;
    }
}

pragma solidity ^0.8.0;
/**
    实现合约 V2
**/
contract ImplV2 {
    uint public t;
    function addT() public payable {
        t = t + 2;
    }
    function getT() public returns (uint res){
        return t;
    }
}

大家可以在remix上部署运行一下这3个合约，会发现1个问题，通过代理合约调用完addT()方法后，再调用getT()并未获得预期结果。这其实是因为代理合约和实现合约之间发生了存储冲突。

存储冲突

不仅会存在代理合约和实现合约的冲突，还会出现实现合约的不同版本之间的冲突。

如何解决存储冲突的问题，这里介绍一种个人比较喜欢的方案: 存储位置预留，如上文所述合约中的存储是按照声明顺序作为编号进行索引寻找的。发生冲突的原因是因为不同合约索引相同，如何能够让不同合约之前的状态的索引编号保证不同呢？使用继承，合约之间进行继承，其中的状态变量也就有了确定的顺序，不会存在重合的问题。

再来看下解决完存储冲突后的合约升级代码

pragma solidity ^0.8.0;
//将存储单独拆1个合约(不需要部署)，方便进行继承
contract ProxyStore {
    address public impl;
    event log(bytes);
}

pragma solidity ^0.8.0;
import "./ProxyStore.sol";
contract ImplV1Store is ProxyStore {
    uint public t;
}

pragma solidity ^0.8.0;
import "./ImplV1Store.sol";
//因为本例中V2暂未新增状态
contract ImplV2Store is ImplV1Store {}

pragma solidity ^0.8.0;
import "./ProxyStore.sol";
/**
    调用者合约，继承自己的存储合约
**/
contract Proxy is ProxyStore{
    fallback () external payable{
        (bool success, bytes memory res) = impl.delegatecall(msg.data);
        emit log(res);
    }
    function setImpl(address addr) public{
        impl = addr;
    }
}

pragma solidity ^0.8.0;
import "./ImplV1Store.sol";
/**
    实现合约 V1，继承自己的存储合约
**/
contract ImplV1 is ImplV1Store{
    // 
    function addT() public payable {
        t = t + 1;
    }

    function getT() public returns (uint res){
        return t;
    }

}

pragma solidity ^0.8.0;
import "./ImplV2Store.sol";
/**
    实现合约 V2，继承自己的存储合约
**/
contract ImplV2 is ImplV2Store{
    function addT() public payable {
        t = t + 2;
    }
    function getT() public returns (uint res){
        return t;
    }
}

至此部分合约函数就拥有了升级能力，为什么是部分呢？fallback()函数是没有返回值的，当调用者调用1个原本有返回值的函数时，由于经过了代理合约的fallback()函数，所以无法将结果返回。我们有没有办法为fallback()也增加返回值呢？

返回值

上层无法实现，但汇编操作可以为我们让我们实现这一能力。Solidity提供了Solidity Assembly让我们更友好地进行汇编操作，并且可以和Solidity语言混合使用。本文主题是合约升级，这部分我们不过多介绍。让我们来看看如何使用底层汇编为fallback()增加返回值。

看下实现代码，下面我们逐一介绍这里涉及到的指令

pragma solidity ^0.8.0;
import "./ProxyStore.sol";
/**
    调用者合约
**/
contract Proxy is ProxyStore{
    fallback () external payable{
        (bool success, bytes memory res) = impl.delegatecall(msg.data);
        emit log(res);
        assembly {
            //分配空闲区域指针
            let ptr := mload(0x40)
            //将返回值从返回缓冲去copy到指针所指位置
            returndatacopy(ptr, 0, returndatasize())

            //根据是否调用成功决定是返回数据还是直接revert整个函数
            switch success
            case 0 { revert(ptr, returndatasize()) }
            default { return(ptr, returndatasize()) }
        }
    }
    function setImpl(address addr) public{
        impl = addr;
    }
}

mload(0x40) //0x40地址会保存下一个可用地址 returndatacopy // 调用call或者delegatecall后其结果数据都会存储在返回值缓冲区中，returndatacopy方法可以将缓冲区的内容copy到指定地址 returndatasize // 返回值缓冲区数据的大小 switch //这里不使用if的原因是 Solidity Assembly的if不支持else return //返回 revert //回滚

其完整过程: 获得可用地址的指针，将返回缓冲区的数据copy到可用地址，根据调用是否成功，如果成功则返回可用地址内的数据，如果失败则进行回滚。

总结

我们通过delegatecall这一方式实现了合约升级，同时通过对合约状态存储的理解明白了为什么会存在存储冲突并采用继承的方式进行规避，最后我们的升级是建立在代理合约的fallback函数之上的，这个函数没有返回值，我们通过Solidity Assembly的方式进行数据返回。合约升级在技术上是不可或缺的手段，较好的使用可以帮助我们修复合约漏洞，对合约进行功能迭代，但如果使用不当则会造成较坏的影响，所以合约升级应该配合有效的升级治理方案。

应用场景

零知识证明在隐私保护、区块链扩容等领域都有非常重要的作用，在之前的文章中提到过零知识证明的有: 真正理解 Layer2 中我们介绍zk-rollup是Layer2一种较好的扩容方式,不需要较长的提款周期 Immutable X白皮书(译) 中介绍Immutable X这一Layer2扩容方案也是使用的零知识证明。 去中心化存储的那些事(上) 中的filecoin需要存储者证明自己确实进行了存储并且未被损坏(复制证明和时空证明)，这个证明过程也是使用零知识证明。 Flow白皮书1-共识和计算分离(译) flow采用了将共识和计算分离的方案，有专门的执行节点和验证节点，验证节点进行验证的时候也是使用知识证明减少计算量。
可见零知识证明在区块链中有着广泛应用，本文重点是介绍零知识证明的实现原理，所以这部分不过多赘述。

简介

我们首先需要把握零知识证明的完整主线，然后各种协议方案在这条主线上进行迭代更替就变换为不同的零知识证明的解决方案。

引入问题

零知识证明是为了达成证明者希望能够证明自己知道某一问题的答案但又不希望透露答案的目标。在这里我们首先引入问题。即如下图，零知识证明需要有1个问题才能够围绕这个问题进行证明。

如果零知识证明需要对接无数种问题，那么方案是不具备通用性的，所以我们希望能够有一种问题可以将其他问题都转化为该问题，这样零知识证明就只针对该问题进行研究即可。

接下来我们就来寻找这类问题。

NP问题和NPC问题

1个问题如果可以多项式时间内求解，我们可以称之为P问题。1个问题如果可以在多项式时间内通过解进行验证那么称之为NP问题。由此可见P问题是属于NP问题的，因为1个问题多项式时间内可以找到解，那么一定可以在多项式时间内验证。

这里简单介绍介绍下多项式时间求解是什么意思，学过数据结构和算法都了解时间复杂度O(n),如果1个算法时间复杂度是O(n) or O(n^2)n在底数位置那么称之为可以多项式时间内求解，如果1个算法时间复杂度O(n!) or O(2^n)等n在指数位置那么称之为不能在多项式时间内求解。

我们需要证明的问题一定是NP问题，否则无法在多项式时间内进行验证，而零知识证明非常重要的一个点计算验证要简单。那么有没有一种问题可以将所有的NP问题都转化为该问题呢？ NPC问题就是这样的一类问题，如果其他NP问题都可以约化为该问题，那么该问题称为NPC问题。

问题描述-电路

如何描述1个NPC问题，电路是1个经常被采用的方案。而且逻辑电路本身就是1个NPC问题。其他的描述方式我们将在后面进行介绍。

注意:这里的画电路不是真正的用绘图方式表达，而是用电路语言进行编写。

数值化-r1cs

接下来，我们的逻辑电路因为是要给计算机进行计算，所以我们希望将其数值化描述。这个数值化的过程通常会采用约束系统。比如常见的r1cs就是一种约束，其要求的约束是 A·s B·s - C·s = 0这个约束如何理解呢？我们看个简单的例子: 25=k * k 这个语句可以用来描述这样一个非常简单的电路

将电路中涉及到的变量组成1个向量s[k,25] 要有一组ABC使得 A·[k,25] B·[k, 25] - C ·[k,25] = 0 等价于 25=k * k 此时我们给出1组符合 A=[1,0] B=[1,0] C=[0,1] 代入 A·s B·s - C·s = 0 后即可求得 25=k * k

这里我们使用了最简单的例子，更复杂一点的例子可以参考V神较为知名的文章 https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649

这里需要重点理解的就是电路是由很多个逻辑门操作组成的，而每个逻辑门操作总是可以转换成为2个输入1个输出。使用 A·s * B·s - C·s = 0 可以较好得通过数值描述每个逻辑门是针对输入做了什么样的变化从而转变成输出的。

当然电路除了r1cs外，还有一些其他的约束如:bacs、tbcs等，这里不再介绍。 我们编写的电路，经过r1cs的编译器，会编译成为符合r1cs规范的约束数值。这组数值就可以描述该电路，这样可以更方便地进行计算。 此时所理解的零知识证明变为:

在使用r1cs的时候问题转换为就是找到1个向量s满足A·s * B·s - C·s = 0，即使获得s，在实际问题中的验证过程我们可能需要验证数万个这样的逻辑运算，非常冗余，有没有办法进行一次运算即可验证呢？在这里我们引入多项式的方案。

问题转化

我们这里通过QAP问题介绍多项式的方案，QAP问题简单来说(这里经过简化)是需要找到p(x)能够整除一个已知的t(x),即可以表示为公式: p(x) = H(x) * t(x) 如何将r1cs转换为QAP呢，还是用我们上面的例子: 将r1cs中求得的向量A=[1,0] B=[1,0] C=[0,1]进行拉格朗日插值,插值方式为依次按照[1,A向量第一组第一个值] [2, A向量第二组第1个值]进行插值计算，求得的方程将系数提取作为A~ 向量组的第一个向量。依次类推A~ 向量的第二组方程是由A向量组的第2个值进行插值获得。关于拉格朗日插值大家可以自行搜索。求得: A~ [0,1] [0,0] B~ [0,1] [0,0] C~ [0,0] [0,1]

此时将s[k, 25]向量和A B C相乘可得: A~·s = [0,k] B~·s = [0,k] C~·s = [0,25]
p(x) = A~·s *B~·s - C~·s = 0 *x + k^2 -25 = k^2 -25
t(x) = x-1 因为无论p(x)的方程系数如何，总是满足x=1时 p(x) = 0 这个原因是因为我们在进行拉格朗日插值时使用了x=1作为插值点

证明者由于知道答案，自然也就知道p(x) = 0 验证者需要验证 符合条件的p(x) 满足 p(x)/t(x) = p(x) /(x-1) 能够整除。

在这里我们举了1个非常简单的例子，为了能够让大家在阅读时不再陷入复杂计算中去，较为复杂的例子还是可以阅读上面推荐的V神的那篇文章

很多算法都有类似QAP转换过程，目的如我们前文所说是为了简化验证。

证明

到了这里我们终于开始进行证明，常用的零知识证明会要求将问题转换为寻找1个满足特定条件多项式的问题(如上述的QAP)。直接将多项式系数给出是最简单的证明，但无法保证零知识。所以我们来讨论如何证明知道1个多项式，以上文中的QAP为例，需要寻找到P(x)能够整除t(x),进行公式化表达即: P(x) = H(x) * t(x)

如上图所示 验证者发起挑战，向证明者发送随机数r，如果证明者可以给出 P(r)和H(r)，验证者进行验证t(r) = P(r)/H(r)，这样进行多次随机挑战降低证明者欺骗的概率从而使得验证者相信证明者的确知道p(x)。

但这里存在1个问题，因为t(x)和r都是公开的，所以此时验证者可以随意构造p(r)和H(r)使得t(r) = p(r) / H(r)。我们需要有一种方式对r进行加密，但因为r要参与计算，所以加密后的r计算结果要能够通过r加密计算求得，这样才可以进行验证，这里就用到了同态加密。

同态加密

同态加密即加密后的运算结果可以和先运算再加密进行转换，比如: g^a * g^b = g^(a+b) 我们暂且使用S(x) = g^x 作为同态加密函数，来看看上面说的r泄露问题如何解决 举个例子: P(x) = 2x^2 -x
t(x) = x
H(x) = 2x-1

验证者依旧随机挑选1个数r，但这次不公开r，而是公开g^r。我们使用的是加法同态: S(x)S(y) = g^(x+y) 也就是说g^(x^2)无法通过g^x运算得到,所以验证者需要将g^(r^2)和g^r都给到证明者。

证明者获取到g^(r^2)和g^r后利用同态性质计算:
g^(p(r)) = g^(2r^2-r) = (g^(r^2))^2 /g^r g^(H(r)) = g^(2r-1) = (g^r)^2 /g
证明者计算出g^(p(r))、g^(H(r))后发送给验证者

验证者拿到g^(p(r))和g^(H(r))后进行验证
g^p(r)= g^(H(r)* t(r)) = (g^H(r))^t(r)

至此，我们通过同态加密解决了，随机数r泄露的问题。

上面的同态加密解决了证明者利用r泄露欺骗验证者的问题，那么验证者是否会通过多轮随机数挑战将多项式系数获取到呢，如果存在这种可能的话就无法保证零知识了，我们先来看看会不会发生这种情况。

零知识

我们假设验证者进行3次挑战给出的随机数是r1，r2, r3那么验证者将会知道 (r1,P(r1)) (r2,P(r2)) (r3,P(r3)),对于2次方程通过3个点可以求得原方程，所以说验证者是可以通过多轮随机挑战来窃取答案的。 那么如何避免这种情况呢？我们这里让证明者生成随机数l，在每次结果中增加随机偏移值。整个过程变为证明者生成随机数L，验证者生成随机数r，证明者计算出结果P(r) H(r)使用l进行变换。注意，这里l依旧需要进行同态加密发送给验证者或者进行计算的时候消除掉这个l。

按照上面例子 我们进行变换，证明者返回 (g^p(r))^l和(g^H(r))^l
那么验证者验证 (g^p(r))^l= (g^(H(r)* t(r))^l = ((g^H(r))^l)^t(r) 即可

现在我们保障了证明者不会欺骗验证者，验证者也不会从证明者获取到原问题有关的知识。但刚刚有没有发现，我们的示例都是基于验证者使用随机数去挑战证明者，这样他们2者之间是有交互的。如果网络中存在大量的验证者，那么证明者需要和每个验证者进行通信，通信成本很大。有没有办法，使得证明者直接给出证明，所有的验证者拿着这个证明就可以对结果进行验证了呢？

非交互式

使用非交互式，这里意味着没有验证者会持有随机数r，因为证明者的这份证明是针对所有验证者的，除非所有验证者都持有r，那这样证明者也大概率会知道r。所以我们不能直接公开r，需要使用避免泄露的方式同态加密R=g^r来进行公开，但需要注意的是上面介绍同态加密的时候我们进行验证的方式是:
g^p(r)= (g^H(r))^t(r)
但此时验证者并不知道t(r),我们只知道加密后的结果g^t(r)。我们需要一个函数能够满足乘法同态，即:
S(a)S(b) = S(a* b)
这样我们验证就可以通过: S(p(r)) = S(H(r) *t(r)) = S(H(r)) * S(t(r)) 来进行验证。

椭圆曲线pairing具备这样乘法同态的性质，具体可以自行查阅资料。

CRS

在上文中，我们介绍非交互式实现的方式是通过将随机数r加密生成R，这一过程需要有可信的第三方完成，并且生成完成需要立马删除原始r。这一过程使用的就是CRS，CRS是指通过一种受信任的方式生成一组可以被公开访问的字符串(一系列值)。这也就是SNARK中经常提到的初始化可信设置，由上面的推导，我们可以思考得出如果原始值r泄露，那么证明者可以随意欺骗验证者。

其它方案

上述我们大部分都是使用zk-SNARK的过程，但这只是1个流程，其中每个阶段都会有其他方案，比如我们会提出以下一些问题

1. 上文我们介绍证明时是通过验证者向证明者发起挑战的方式，为了避免随机挑战数被泄露使用了同态加密，那么有没有其他方式证明呢？

2. NP问题描述方式只有电路这一种？

3. 为什么STARK是抗量子攻击的特性呢？

我们简要回答下这几个问题

1. Q: 上文我们介绍证明时是通过验证者向证明者发起挑战的方式，为了避免随机挑战数被泄露使用了同态加密，那么有没有其他方式证明呢？ A: 除了隐藏询问参数，另外一种方式是多项式承诺，plonk就使用了该方案，很多STARK应进行采用。多项式承诺可以做到不需要设置可信参数，这也是STARK的优势之一。

2. Q:NP问题的描述方式只有电路吗？ A: 描述NP问题的方式一般有这几种 1.电路 2.RAM 3.高级编程语言 RAM描述方式和汇编语言可以认为是类似的表达形式。这几种方式在表达上是越来越好，但底层处理上是越来复杂了。RAM也需要进行数值化，RAM经过数值化后称之为AIR。 一般而言STARK不再使用电路来描述问题(自然也就不会使用r1cs约束)，而是使用RAM(数值化会变为AIR)。

3. Q:为什么STARK是抗量子攻击的特性呢？ A: 因为SNARK大多数采用非对称加密而STARK大部分采用对称加密，对称加密是具备抗量子性的，非对称加密是不具备抗量子性的。

结尾

本文对零知识证明的过程进行分析，希望读者可以对零知识证明的整体流程有所了解，后续讨论零知识证明原理的时候我们都是在放大讨论这篇文章中的某一部分，再去接触一些令人眼花缭乱的技术时，我们能够很清晰的知道，这项技术是解决了零知识证明的哪部分问题，针对哪部分进行了优化，就像文末介绍的较新的STARK中的AIR其实是用来替换r1cs作为另外一种描述NP问题的方式。

参考 https://eprint.iacr.org/2012/215.pdf (介绍QAP问题的论文） https://github.com/scipr-lab/libsnark (实现SNARK的库) https://github.com/iden3/snarkjs (使用js实现SNARK，支持groth16和plonk) https://nakamoto.com/cambrian-explosion-of-crypto-proofs/ (各种证明之间不同维度的对比) https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649 (V神针对ZK-SNARK的介绍)

1. 概述

2. 数字资产所有权的未来

3. 基于以太坊NFT的限制

   • 3.1 吞吐量低

   • 3.2 用户体验差

   • 3.3 开发速度慢

   • 3.4 流动性差

4. Immutable X:以太坊NFT的下一代协议

   • 4.1 ZK-Rollup扩展引擎

   • 4.2 API抽象层

   • 4.3 支持NFT的钱包

   • 4.4 平台SDK

   • 4.5 共享流动性和订单簿

   • 4.6 为世界级合作伙伴提供合规支持

   • 4.7 官方市场和交易历史浏览

5. 协议架构和功能

   • 5.1 Rollup设计

     • 5.1.1 Vault Merkle Tree

     • 5.1.2 STARKs over SNARKS

     • 5.1.3 数据可用性

   • 5.2 资产铸造

   • 5.3 交易签名

   • 5.4 费用

1.概述

Immutable X是以太坊NFT的L2扩展解决方案。具有即时交易，大规模处理，铸造和交易NFT零gas费用的特点，而且不会影响用户或资产的安全性。Immutable X使用StarkWare强大的STARK验证器和rollup技术开发，是迄今为止最先进的NFT扩展技术解决方案。

2.数字资产所有权的未来

NFTs是数字资产所有权的未来。NFT交易总量已经从2020年上半年的13.7亿美元上涨到2021上半年的25亿美元，并且我们仅仅发掘了NFTs表面的一部分。现在，我们看到主流艺术家启动NFT项目，大品牌进入这个领域，现有的Difi项目(eg: Uniswap)将NFTs作为他们产品的核心部分，我们才刚刚开始。 与此同时，以太坊也经历了历史上所有网络中最陡峭的成长曲线。以太坊市场价格从一年前不到500亿美元上升到现在超过3000亿美元。数百万用户现在使用以太坊去中心化应用(DApps)。并且每天数十亿美元的交易在网络上被处理。以太坊在NFT区块链中占据优势，拥有很多不同体量的应用。重要的是，几乎所有区块链和NFT的创新都发生在以太坊上，其他网络只是在复制以太坊的应用生态系统。这个生态系统增长很快-仅在2021年就有数百个NFT项目被启动,他们都在尝试抓住历史上最大的数字化变革。

以游戏这类NFT项目的市场为例，游戏是目前 NFT 开发者的主要方向之一，其理由充分：玩家新技术的早期接受者，游戏是拥有很大的市场。游戏目前是一个价值 3000 亿的产业，并且有望在 2021 年至 2025 年期间每年增长约10%，它的规模超过了体育，电影和音乐产业的总和。自 2018年以来，玩家已经在游戏内资产上花费超过1000亿美元，例如独特的角色皮肤，道具和解锁特定内容。这些内容是NFT的绝佳机会：这些资产如果使用NFT所代表对于用户来说会更有价值。

所有独特且可交易的内容，包括艺术品，游戏内资产和实体商品都将被公链上的 NFTs 所代表。视频，音乐或图片等数字内容可以变成具有稀缺性的数字藏品，从而形成一种新型的创作者-受众关系。独特的实物商品，如钻石、稀有金属，以及房地产或运动鞋等财产也可以被代币化为NFTs。作为NFTs，这些资产将在全球流动性市场上进行交易，并能够使用为NFTs交易构建的所有工具(如租赁、衍生品、交易所、钱包)。

多年来，数字商品相对实体商品有一些不足:没有稀缺性，没有真正的所有权，并且受到诸多限制。随着我们的生活越来越数字化，未来NFTs的所有权是明确的:数字商品不仅等同于实体商品，还会更好。

那么为什么不是每一独特的数字资产都是以太坊NFT呢？

3.基于以太坊NFT的限制

尽管以太坊整体上占据主导地位，而且对NFT有明显的需求，但以太坊要成为将NFT扩展到全球受众的底层平台，还需要克服大量障碍。越来越多的区块链正在竞争NFT交易市场，通常通过牺牲以太坊的安全性来提高其吞吐量和改善其用户体验。以太坊面临的主要挑战是:

3.1 吞吐量低

与传统数据库相比，以太坊为了维护其安全性和去中心化，保持了较低的吞吐量:每秒5到15个事务(TPS)。因此，以太坊上活动的大规模增长导致了网络拥塞和缓慢的交易时间。它还提高了gas费用，导致交易对许多用户来说变得不划算，导致开发商和交易商被定价出局。即使在以太坊2.0迁移完成之后，交易吞吐量也会受到限制，交易成本也会让主流游戏中的小交易望而却步。

3.2 用户体验差

目前，以太坊上 NFT 交易的用户体验还没有为大众采用做好准备。交易需要几分钟或几小时才能确认，而且往往无法成功，从而极大地影响用户满意度、价格发现和整体流动性。现有的解决方案或替代区块链只能通过损害用户资产安全或网络去中心化来改善这种用户体验。此外，NFT钱包体验通常较差——它们令人困惑，恢复机制很差，并且没有显示必要的信息来帮助用户做出明智的购买决定。

3.3 开发速度慢

目前，NFT应用程序或市场开发人员将大部分开发时间花在构建和配置项目的区块链组件上。这让他们忽视了真正重要的东西:围绕真正的资产所有权为用户创造奇妙而独特的体验。开发人员需要学习新的编程语言和范例，然后立即使用它们编写对安全性至关重要的应用程序。他们没有用于创建应用程序的工具——没有简单的api，没有特定平台的sdk，没有预构建的基础设施。这为新项目的进入创造了巨大的障碍，并阻止了许多NFT的启动。

3.4 流动性差

由于其异质性，NFT比可替代的 ERC-20对应物的流动性要低。每个 NFT都必须根据其唯一ID进行买卖。这意味着，要花费1ETH购买每一条“gold dragon”NFT，您可能需要打开数百个买入订单——这些订单甚至不会涵盖新铸造的“gold dragon”。这个问题存在一些解决方案，但它们显着增加了铸币和交易的成本。个别市场在改进这一问题过程中投入了大量资金，但这些方案通常会进一步分散流动性，对价格发现产生负面影响。最终，这不仅会影响个人用户，还会影响整个 NFT 市场，因为交易者无法快速出售资产，也无法获得尽可能好的价格。

4 Immutable X:以太坊NFT的下一代协议

Immutable 认为 NFT 用户和开发人员不应该在以太坊的安全性和吞吐量做出选择，并为他们的用户创造世界级的体验。 Immutable X 是 NFT 的尖端协议，它使项目能够在以太坊的Layer2上构建，并具有出色的开发体验和用户体验。这是通过几个核心组件实现的：

4.1 ZK-Rollup扩展引擎

用以太坊联合创始人 Vitalik Buterin 的话来说，“中短期以太坊生态系统很可能全力以赴rollips以提升吞吐量”。 Immutable X将NFT特定的交换和证明逻辑与StarkWare开发的尖端Rollup技术结合，用于创建有史以来最先进的 NFT 交易工具。 Rollups 允许世界级的可扩展性和用户体验，同时保留以太坊的底层安全性。他们通过批量处理大量交易，为这些交易生成“有效性证明”，然后将该证明提交给 L1 智能合约来做到这一点。 Immutable X 的 rollup 允许每秒超过 9,000 次 NFT 转移、交易和铸币，达到并超过主流 NFT 项目所需的规模。有关 Immutable 的汇总实现的详细信息，请参见第 5 节。

4.2 API抽象层

为了更轻松地构建 NFT 应用程序，Immutable X 将这个扩展引擎封装在一组强大的 REST API 中。在 Immutable X 上，每一次交互，从铸造到交易再到转账，都像 API 调用一样简单。将可能需要几分钟或几小时的复杂异步区块链交互转换为同步RESTAPI 调用，是对现有区块链开发范式的强大升级。无需直接与智能合约交互，该领域的新进入者，例如成熟的游戏和内容公司，可以更快地推出更好的项目。

4.3 支持NFT的钱包

与其他区块链或侧链不同，Immutable X 目前支持所有桌面以太坊钱包，无需强制用户切换网络。该协议提供了一个中间层("Link")可实现特定于NFT钱包的世界级体验。这也使Immutable X 能够支持蓬勃发展的第三方市场生态系统，而不会带来安全风险：用户可以依靠 Immutable X Link 来确保他们不会被他们购买的资产所欺骗。

4.4 平台SDK

平台和特定编程语言的SDK允许合作伙伴更轻松地与 Immutable X 集成。目前，有一个 Typescript SDK的实现可以使用，可用于将协议轻松集成到网站中。 SDK允许对Immutable X API 和 Wallet进行访问。未来，将为所有常见的编程语言以及 Android、iOS、Unity 和 Unreal 等开发平台提供SDK。结合 API，Immutable X SDK 将允许合作伙伴在数小时而不是数周内构建NFT项目。

4.5 共享流动性和订单簿

与其他 NFT 扩展解决方案不同，Immutable X 提供共享的全球订单簿以促进协议流动性。这意味着在一个市场上创建的订单可以在另一个市场上完成，从而促进更有效的市场引导和价格发现。这也意味着 NFT 市场可以建立在 Immutable X 上而无需后端服务。 Immutable 认为，提升NFT流动性的一个关键方法是允许这些NFT在不同市场(针对不同用户)之间交易——我们希望看到在 Immutable X 上发展出蓬勃发展的第三方市场生态系统！

4.6 为世界级合作伙伴提供合规支持

目前，世界上一些大公司正在探索 NFT。然而，他们经常担心 NFT 的监管影响，包括版权保护和 AML/KYC 立法。 Immutable X 将提供一个完全合法的平台，并且能够成为这些大型项目的可信赖合作伙伴，以便将它们保留在以太坊上。我们认为在不牺牲用户安全情况下，购买NFT应该像在传统电子商务中购物一样简单。

4.7 官方市场和交易历史浏览

Immutable X Marketplace 的存在是为了在协议上交易NFT提供官方主页，让用户和开发人员相信总会有交易的地方。 Immutable X Marketplace 还降低了没有资源创建自己交易市场的内容创建者和小型开发者的进入门槛。验证用户的交易历史对于促进区块链生态系统的信任和合法性很重要，Immutable X 也不例外，任何人都可以验证交易和查看历史状态。

5 协议架构和功能

5.1 Rollup设计

Immutable X 的核心是 zk-rollup 扩展引擎，它是与StarkWare合作开发的，使用了他们的StarkEx证明生成器和验证器。首先，让我们概括地讨论一下 rollup：在 zk-rollup 中，用户将资产锁定在链上智能合约中：资产被“存入”L2。这些资产可以在L2进行交易，交易由“操作员”排序成一致的历史序列。然后将交易分组为“批次”或“块”，并为该批次的有效性生成证明。然后，该证明会在链上发布，并由更新链上状态的智能合约进行验证。通过链上状态变更，用户可以解锁他们的资产（从rollup中“提取”）。

为了更好地支持下一代 NFT 的需求，我们做出了几个重要的设计决策：

5.1.1 Vault Merkle Tree

Immutable X 的“资产状态”表示为一棵巨大的 Merkle 树，其中每个叶节点都是一个包含资产的Vault，而其他每个节点都是其两个子节点的哈希值。这棵树的编码在2个地方被使用：

• 首先，在管理存款、取款和状态更新的链上智能合约验证器中。该合约存储了默克尔树的根，并确保只有在存在有效证明的情况下才能更新该根，因此Vault Merkle Tree不可能转换为无效状态。目前，该合约可以通过时间锁进行升级——目的是最终确保合约逻辑不可变。

• 其次，在用 StarkWare 的 Cairo 语言编写的 L2 证明逻辑中，它确定了有效状态转换的要求（例如，验证用户转移的资产是否归自己所有）。

5.1.2 STARKs over SNARKS

Immutable X 使用 STARK 证明，而不是更常见的 SNARK 证明。 STARK 证明是证明技术的最新进展，旨在解决 SNARK-rollups 的关键问题，即：

• SNARK 需要可信设置

• SNARK 不是量子安全的

• SNARK 依赖于极其复杂的密码学，并且容易出现实施错误

STARK 证明更大，在链上发布的成本更高：我们认为这是一个可以接受的权衡，以提高用户安全性。

5.1.3 数据可用性

如果 Immutable 变得完全没有响应并且协议开发停止，用户将需要他们的交易数据可用以提取他们的资产。 Immutable X 支持两种数据可用性模式：rollup 和 validium。在rollup 模式下，每个批次之间的状态变化都会发布到 L1，保证L1的安全性，但会为每个事务增加一个小的线性成本。在validium模式下，数据可用性委员会 (DAC) 会对每个批次进行签名，以表明他们保留了数据的副本。即使只有一名委员会成员诚实，用户也将能够成功退出协议。目前，Immutable 的 DAC 包括：Immutable、StarkWare、Deversifi、Consensys、Nethermind、Iqlusion、Infura 和 Cephalopod。在这两种情况下，系统都是去中心化的：即使 Immutable 消失、被黑客入侵，协议也将能够恢复并且用户资产是安全的。

5.2 资产铸造

Immutable X 的主要优势之一是NFT可以完全在 L2 中铸造，同时保留 L1 的安全性。每个NFT都可以用不可变的元数据铸造，在NFT提取时将传递给 L1 智能合约。该技术已被用于在 Immutable X 上铸造超过 1000 万个 NFT（超过 L1 上的所有 ERC721 NFT）。这些NFT还可以具有“可变元数据”，它将定期从铸币应用程序的服务器轮询，并且每个应用程序都可以选择提供一个“元数据标识符”，它将通知应用程序每个NFT的可变元数据属性的理想表示。不可变元数据和可变元数据的这种组合支持NFT用于表示每种类型的数字资产 - 从体验等级不断变化的游戏资产到基于确定的初始种子叠加不同用户输入的生成艺术品NFT。

5.3 交易签名

在ImmutableX上进行交易，用户需要STARK-friendly椭圆曲线生成的专属密钥对。为了解决这个问题，我们构建了“Link”，作为以太坊钱包和 Immutable X 之间的中间层。用户签署安全消息，该消息用作生成STARK密钥对的种子。这将“委托”ImmutableX 钱包的安全和恢复给用户的以太坊钱包，即使STARK密钥对丢失，用户也可以使用新的以太坊签名重新生成它。在Link内部，这个 STARK 密钥对随后用于交易签名，每个签名的精确编码由交易类型决定。

5.4 费用

费用是Immutable X 协议的主要收入来源。目前，Immutable X 对每笔 NFT 交易收取 2% 的费用（以购买货币计价）。由于我们对 Immutable X 费用的目标是协调应用程序开发人员、市场和交易者之间的激励措施，因此其他生态系统参与者也将能够设定费用：

1.市场还可以为每个订单添加自己的费用。由于 Immutable X 提供了一个可供所有市场访问的共享订单簿，因此在一个市场上创建的订单可以在另一个市场上完成，两者都收取费用。 2.NFT的创造者可以对他们铸造的每个 NFT设置使用费，以便从后续每次购买该资产中收取费用。使用费是NFT出售价格的固定百分比，在NFT铸造后无法调整。

NFT创造者和市场之间的这种激励机制为游戏等企业或艺术家等个人创作者开辟了全新的收入来源。他们之前从未能够从作品的持续升值而受益。这个系统给了创造者巨大的动力，使得创造者让这些NFT对目前持有的人具备价值。

什么是共识机制

分布式系统引入的恶意节点

区块链的特点之一是去中心化。也就是节点会分布在各个地方组成分布式系统。各个节点需要对1个问题达成一致，理想情况下，只需要同步状态即可。

如上图所示 B节点将a=1=> a=2的状态同步给 ACDE四个节点，这时系统中状态变为a=2, 但如果其中有恶意节点 AE 收到通知后把a=1=>a=3修改为错误的节点，这个时候大家的状态就不一致了，此时需要共识机制使系统中得到1个唯一正确的状态。

拜占庭将军问题

如上面说到分布式系统存在恶意节点导致系统中状态不一致的情况有1个比较著名的虚拟问题-拜占庭将军问题。

拜占庭将军问题是指，N个将军去攻打一座城堡，如果大于一定数量的将军同时进攻则可以攻打成功，如果小于则进攻失败。将军中可能存在叛徒。

这个时候有2种情况

1.如果2个叛徒都在BCDE中，那么共识算法需要让其余2个将军听从A的正确决策进攻城堡。

2.如果A是1个叛徒，共识算法需要让BCDE中剩余的3个忠诚将军保持一致。

这个问题有很多种解法，大家有兴趣可以自行查阅(推荐学习PBFT)，我们重点来看看以太坊中目前正在使用的Nakamoto 共识和将要使用的 Casper Friendly Finality Gadget共识是如何解决拜占庭将军问题的。

以太坊共识机制简述

说到Nakamoto共识和Casper Friendly Finality Gadget共识可能大家不太熟悉，但他们的部分组成应该都比较熟悉-POW(工作量证明)和POS(权益证明)。

Sybil抗性

POW或POS称之为Sybil抗性机制，为什么需要Sybil抗性机制呢，刚刚我们说到拜占庭将军问题，应该很容易看出恶意节点越多，达成正确共识的难度也就越大，Sybil攻击就是指1个攻击者可以伪装出大量节点来进行攻击，Sybil抗性是指抵御这种攻击能力。

POW通过让矿工或验证者投入算力，POS通过让验证者质押以太坊，如果攻击者要伪装多个节点攻击则必将投入大量的算力或资产，会导致攻击成本高于收益。在以太坊中保障的安全性是除非攻击者拿到整个系统51%算力或资产否则不可能进攻成功。

最长链规则

在解决完Sybil攻击后，通过选取系统中的最长链作为大家达成共识的链。

很多人平时为了简化将pow和pos认为是共识机制，这不够准确，但也说明了其重要作用，我们接下来分析pow和pos。

pow-工作量证明

工作量证明简述

通过hash不可逆的特性，要求各个矿工不停地计算出某个值的hash符合某一特征，比如前多少位是000000，由于这个过程只能依赖不停的试错计算hash,所以是工作量证明。计算完成后其他节点验证的值符合hash特征非常容易验证。验证通过则成为成为合法区块(不一定是共识区块，需要在最长链中)。

挖矿算法

以太坊中的挖矿算法用到2个数据集，1个小数据集cache,1个大数据集DAG。这2个数据集会随着区块链中区块增多慢慢变大，初始大小cache为16M DAG为1G。

我们先来看这2个数据集的生成过程

cache生成规则为有1个种子随机数seed，cache中第1个元素对seed取hash，后面数组中每个元素都是前1个元素取hash获得。

DAG生成规则为 找到cache中对应的元素后 根据元素中的值计算出下次要寻找的下标，循环256次后获得cache中最终需要的元素值进行hash计算得到DAG中元素的值。

然后我们再看看矿工如何进行挖矿以及轻节点如何验证

矿工挖矿过程

矿工挖矿的过程为，选择Nonce值映射到DAG中的1个item，通过item中的值计算出下次要找的下标，循环64次，得到最终item，将item中的值hash计算得到结果，结果和target比较，符合条件

则证明挖到区块，如果不符合则更换nonce继续挖矿。矿工在挖矿过程中需要将1G的DAG读取到内存中。

轻节点验证过程

轻节点验证过程和矿工挖矿过程基本一致，

将块头里面的Nonce值映射到DAG中的1个item，然后通过cache数组计算出该item的值，通过item中的值计算出下次要找的下标，循环64次，得到最终item，将item中的值hash计算得到结果，结果和target比较，符合条件则验证通过。轻节点在验证过程中不需要将1G的DAG读取到内存中。每次用到DAG的item值都使用cache进行计算。

以太坊为什么需要这2个不同大小的数组进行辅助hash运算呢，直接进行hash运算会有什么问题？

如果只是进行重复计算会导致挖矿设备专业化，减少去中心化程度。因为我们日常使用的计算机内存和计算力是都需要的，如果挖矿只需要hash运算，挖矿设备则会设计地拥有超高算力，但对内存可以缩小到很小甚至没有。所以我们选用1G的大内存增加对内存访问的频率，增加挖矿设备对内存访问需求，从而更接近于我们日常使用的计算机。

ghost协议

我们看看在Nakamoto共识是如何解决拜占庭将军问题的。首先看看区块链中的拜占庭将军问题是什么？

区块链中需要达成一致的是哪条链为主链，虽然采用了最长链原则，但由于分叉问题，还是会带来拜占庭将军问题。

本来以太坊pow目标是抵抗51%以下的攻击，但如上图如果恶意节点沿着自己挖出的区块不断挖矿，由于主链上有分叉存在，恶意节点不需要达到51%算力就可以超过主链进而成为新的主链，为此以太坊使用了ghost协议给上图中的B1和C1也分配出块奖励，尽快合并到主链中，这样主链长度(按照合并后的总长度算，长度只是抽象概念，以太坊中按照区块权重累加)还是大于恶意节点自己挖矿的。

pos-权益证明

权益证明简述

网络中的用户通过质押一定数量的以太坊成为验证者。每次系统从这些验证者从随机选择出区块创建者，其余验证者去验证创建出的区块是否合法。验证者会获得出块奖励，没有被选中的区块不进行验证则会被扣除一定质押币，如果进行错误验证则会被扣除全部质押币。

权益证明过程

如上图，权益证明在每隔一定区块的地方设置一个检查点，对前面的区块进行验证，2/3验证者通过则验证通过，验证通过则该区块所在链成为最长合法链(不能被回滚)。

我们简化地只分析了权益证明本身，在以太坊中权益证明较为复杂的点在于和分片机制结合在一起时的运行流程，这部分会在后面单独将分片机制的一篇文章中详述。

总结

本篇文章主要讨论了共识机制是解决分布式系统中的拜占庭将军问题，以及分析了以太坊中的共识机制一般包括最长链选择和一种sybil抗性机制(pow或pos)。重点分析了pow和pos的流程以及设计思想。

更多web3相关文章 可关注公众号 "web3探索者"

区块链中的不可能三角

这里的"不可能"没有任何理论论证，只是对现有区块链的总结。所以很多人也在探索突破不可能三角的方案，并已经有一定进展，后面会详细讨论。

效率(TPS):每秒处理交易的数量。

去中心化:参与节点门槛足够低，保证系统中有大量分布式的节点。

安全:对区块链发动攻击的难度足够大。

以太坊为例我们看看不可能三角中的每一角是如何保障的。

去中心化: 以太坊中拥有大量的节点，交易被记录在链上需要全节点验证通过，所以达到了去中心化的目的。

安全性: 以太坊目前采用的POW(工作量证明机制) 对发动攻击的要求是聚集整个系统一半以上的算力。后面采用POS（权益证明）对发动攻击的要求是需要质押51%的ETH。无论哪种方式都需要付出巨额代价，并在攻击结束后，币价会大幅下降从而巨额代价无法获得回报来保证安全性。

效率：为了保证去中心化和安全性，即系统中必须拥有大量的节点，每个节点都需要执行区块中的一遍交易过程转移状态，以太坊要求每个区块中不能包含太多的交易，出块时间也要求稳定在高于一定时间之上。

加大区块容量或加速区块时间无法解决不可能三角

将每个区块包含的交易数增大或加快出块时间，我们知道每个节点在验证区块的时候需要将区块中的交易重新执行一次，去同步状态树。无论是增加区块中的交易数量还是加快出块时间都会使得系统中性能较差的节点，无法跟上交易状态转移的速度，从而降低中心化程度。

为什么POW转向POS交易速度不会得到提升？

首先区块链中需要证明机制是一种让记账更加可信的方式。

POW(工作量证明) 是指依赖算力重复计算来获得记账权。如果经过大量计算则证明可以获得记账权，

POS(权益证明)是指依赖之前拥有的资产比例并质押一定资产来获得记账权。

以太坊POW中我们设计的挖矿难度算法是为了稳定出块时间，上面我们说到了如果出块时间过小，会导致系统中节点数量减少，降低去中心化程度。所以这里的挖矿难度是手段不是目标。从而我们知道以太坊切换到pos后为了维持系统中的大量节点也不会大幅降低出块时间。

采用POS之后gas费用依旧会很高

首先需要明确1个概念，gas费用是支付给获得记账权节点运算打包所需的费用。在POW方式中也和挖矿消耗的资源没有关系。

只要系统中节点执行程序消费能源，就会有gas费用。将POW转为POS的过程只是记账权的获取方式发生了变更，节省的是挖矿需要的电能，而不会减少系统中节点执行交易(或合约代码)的消耗，gas费用当然不会降低。

如上图所示，pow转pos节省的是1所消耗的能源，而3所消耗的能源也就是并不会降低，gas费用是用来支付3消耗的能源所以不会因为由pow转换到pos而降低。

那么gas费用和什么有关呢？gas费用由2部分相乘获得 gasPrice * gasUsed gasUsed执行相同的操作是固定值(代表了资源的消耗) gasPrice由发起交易方填写，gasPrice越高矿工越容易优先处理交易(代表了市场竞争)。gas费用较高很大原因是以太坊中交易处理速度较慢，所以导致交易阻塞，市场竞争激烈。想要降低gas费用还是回到需要提升以太坊的交易处理速度。

L2的引入是如何解决不可能三角的

既然暂时无法提升以太坊本身的处理速度，降低其gas费用，那么有没有其他办法呢？

L2的引入就很好地解决了这一问题。既然L1的交易处理速度不好提升，那么我们就在L1的基础上搭建L2，专门提供高速的交易处理，而安全性和去中心化交由L1去保障。

交易在L2上快速进行，L2则按照一定的时机将最终状态同步回L1，这样交易速度得到提升，由于批次写入L1以及智能合约是在L2执行gas费用也会大幅下降。

L2由于不需要处理去中心化以及安全性，原因在于将交易或合约的执行过程与最终状态的保存分离开，过程执行放到了L2，L1只需要去保存最终的状态即可。这样大大减轻了L1的压力。但L2需要保证交易或合约执行过程中是正确性，否则写入L1的状态也是错误的，为此不同的L2也采用了很多不同的方案来保障执行过程的正确性。比如Optimistic采用了欺诈证明的方式来保障。

以太坊的分片机制带来什么变化

除了使用L2这种结构性调整，以太坊本身有没有办法提升TPS呢，目前比较大的进展是分片技术。\

分片机制是指以太坊中拆分出N条分片链，不同的分片链去打包不同的交易。每个节点归属于每个分片链下，只负责验证分片链上交易。由于每个节点计算量变少，出块时间会加快。分片技术带来的问题就是安全性有一些下降，因为验证1个区块的节点数量变少。

这里只是简单描述分片链的机制，实际场景中分片机制会带来，跨分片交易以及智能合约交互的复杂问题，后面会找一篇文章单独讨论。

总结

由于不可能三角，以太坊选择了安全性和去中心化，牺牲了交易处理速度，带来了很多拓展性的问题。由POW到POS的进步不会优化交易处理速度。使用分层的思想很好地解决了在保障安全性和去中心化的情况下大幅提升交易速度。与此同时以太坊作为L1基础设施也推出了分片技术来提升交易处理速度。后续应该很多区块链应用都会建立在L2之上，而和L1的对接则会完全交给L2。

更多web3相关文章 可关注公众号 "web3探索者"

智能合约到底是什么

智能合约概念

从抽象概念上讲，智能合约是一种可以自动化执行的规则，现实生活中的合约，合约制定完成后需要有专门的执行角色，而智能合约将这个步骤自动化，只有满足智能合约中制定的条件就会被执行。

从具体概念上讲，我们之前有一篇文章讲以太坊的数据结构中提到每个账户都有状态树，而智能合约的目的就是通过一系列逻辑执行触发合约账户的状态变化以及通过交易改变外部账户的状态，关于合约账号和外部账户可见"以太坊账户"一文。

编程语言的一些基础概念

变量(广义包括常量)

编程语言中，变量起着重要作用，用来存储内存数据。变量内存储的数据有各种各样的类型，有的是简单的整型，字符串，有的是较为复杂的集合类型，比如列表，映射表或上自定义的类型。变量还有1个很重要的概念就是作用域。

作用域

作用域代表变量的生命周期，是函数级别-函数执行完就销毁，还是对象级别，依附对象销毁就会销毁，或又是全局级别，只有程序在运行就一直都在。在智能合约中合约中声明的变量都是存储在状态树中，所以只要合约账户存在，这个变量就存在。这一点认识非常重要，后面在讲NFT的时候会讲1个误区。

函数

函数代表着逻辑的执行，函数的输入有几种 1。可以访问的内存 磁盘 网络中的输入 2.调用函数者传入的参数，函数的输出也是有2种 1.可以访问的内存 磁盘 网络的输出 2.函数返回值 。

有一种纯函数的概念 即 输入只包含了调用函数者传入的参数，输出只包含了返回值。

在智能合约中，非依赖库所有能够让外部账户或者合约账户调用的函数都不应该是纯函数，否则就是对gas的浪费。

智能合约的结构

智能合约结构示意

如上图，智能合约由外部账户发起调用，合约直接也可以相互调用，每个合约内部执行函数转移状态。

分析个例子

例子来源:

https://learnblockchain.cn/docs/solidity/solidity-by-example.html#id1

分析智能合约分为2块

1.合约变量，即状态每个状态代表了什么含义。

2.函数 即合约中的函数是如何运转的，又是如何影响状态变化。

合约变量

address public chairperson;
 // 这声明了一个状态变量，为每个可能的地址存储一个 `Voter`。 
mapping(address => Voter) public voters;
// 一个 `Proposal` 结构类型的动态数组Proposal[] public proposals;

这3个变量就是这个智能合约的状态

Address

mapping(address => Voter)

Proposal[]

表示了变量的类型 Address代表这是1个地址 mapping(address => Votor)代表是个映射表 其中key是地址 value是Voter Voter是个自定义的类型(就是一组类型的聚合)，Proposal[] 代表是个数组 数组中每个元素都是Proposal Proposal也是个自定义类型

struct Voter {        
    uint weight; // 计票的权重       
    bool voted;  // 若为真，代表该人已投票        
    address delegate; // 被委托人        
    uint vote;   // 投票提案的索引    
}
    // 提案的类型    
struct Proposal {        
    bytes32 name;   // 简称（最长32个字节）        
    uint voteCount; // 得票数
}

合约函数

function开头的代表是一系列函数就是和前面说到的3个状态交互

如上图所示，智能合约中对外可调用的函数围绕着如何修改 或 读取状态而来，如同文章开始所讲到的，智能合约执行的过程就是以太坊中状态树变化的过程。

智能合约的特点

gas费用

智能合约相比于其他编程非常要注意的1点就是运行逻辑需要收取gas费用，这使得合约编写过程要额外注重代码的高效性，尽可能地减少冗余代码。

gas费用存在的原因以及gas费用为什么高昂，之前不可能三角一文中有讲，简单来说gas费用存在是因为计算需要耗费资源，存在gas费用可以避免恶意消耗资源的情况发生。gas费用高昂主要是因为竞争激烈。

gas费用计算可以看这里

https://ethereum.org/zh/developers/docs/evm/opcodes，这里是一些操作码，我们写的代码最终都会编译成字节码指令运行在EVM上。

围绕交易的语言设计

payable 关键字

这是一个函数的修饰符，只有被payable修饰过的函数才可以在调用时附带ETH。

fallback函数

调用到智能合约没有的函数时会走到fallback函数, 如果没有写fallback会抛出异常，如果是涉及到附加ETH，fallback必须被payable修饰，否则也会抛出异常

receive函数

对合约单纯转账会进入这个函数，前提是有这个函数，如果没有会进入被payable修饰的fallback函数，否则会抛出异常。

可以看到合约语言无不透露着对交易属性，这在一般的编程语言中是不会看到的。

常见陷阱

合约一旦发布，即使存在漏洞就不可更改，所以对于逻辑要格外严谨。我们来看看1个常见漏洞

重入攻击

//被调用的合约
contract A {        
    uint money;    /// 提取你的分成。
    function withdraw() public {
          if (payable(msg.sender).send(money))
              money = 0; 
         }
}
//调用的合约
contract B {
        function hack() public {
            A().withdraw();
       }
        fallback external payable {
        A().withdraw();
       }
}

上面的代码中A给B转账会走到B的fallback函数，而B的fallback函数又调用A的转账函数，这样会导致A向B不停转账。

改进办法就是先修改状态再转账

//被调用的合约
contract A {
        uint money;    /// 提取你的分成。
        function withdraw() public {
            uint tmp_money = money; 
            money = 0;
            payable(msg.sender).send(moeny);
        }
}

NFT

NFT是最近比较热门的话题，很多人认为NFT代表了数字化的确权，也有人认为目前就是一张jpg图片，我们这里不讨论他的经济价值，讨论NFT的技术实现。在每一组NFT背后都是一份智能合约。这些智能合约都遵守着相同的规范。

NFT协议

具体见:https://docs.openzeppelin.com/contracts/3.x/api/token/erc721#ERC721

constructor(name_, symbol_)
balanceOf(owner)
ownerOf(tokenId)
name()
symbol()
tokenURI(tokenId)
baseURI()
tokenOfOwnerByIndex(owner, index)
totalSupply()
tokenByIndex(index)
approve(to, tokenId)
getApproved(tokenId)
setApprovalForAll(operator, approved)
isApprovedForAll(owner, operator)
transferFrom(from, to, tokenId)
safeTransferFrom(from, to, tokenId)
safeTransferFrom(from, to, tokenId, _data)
_safeTransfer(from, to, tokenId, _data)
_exists(tokenId)
_isApprovedOrOwner(spender, tokenId)
_safeMint(to, tokenId)
_safeMint(to, tokenId, _data)
_mint(to, tokenId)
_burn(tokenId)
_transfer(from, to, tokenId)
_setTokenURI(tokenId, _tokenURI)
_setBaseURI(baseURI_)
_approve(to, tokenId)
_beforeTokenTransfer(from, to, tokenId)

上面的函数就是NFT智能合约需要遵守的规范- ERC721。

在编程语言中有个概念-接口。之前讲过函数的概念，而接口就是一组函数声明，要实现类似的东西大家都要有个规范，于是乎就有了接口。接口不负责具体实现，只是告诉你要实现什么能力，才能够满足规范。

我们从接口中挑1个大家有过讨论的函数看看。

_setTokenURI(tokenId, _tokenURI)

这个函数目的是给这组NFT某个编号 设置一个url，这个url我们可以简单地理解为是一张图片(先简单理解)。这个接口的出现导致了，如果可以成功调用该接口，那么你高价购买到的NFT将有可能变成另外1张没有任何艺术价值的图片。

有的说法是这个url没有上链,如果上链了就不会有这个问题。所以我们接下来讨论下什么是上链。

当我们讨论上链时，什么是上链

很多人讨论链上的数据不可被更改，那到底什么是上链呢？在之前文章以太坊数据结构中曾经提到以太坊当中的状态树，只要存在这棵状态树里面的数据都是上链了的。而智能合约中每个合约状态都是存在状态树中的，所以只要是合约中声明的变量都可以称为上链 。另外1个问题，链上数据是否不可更改呢？准确回答说按照规则就可以更改，不按照规则就不可以更改。什么是按照规则，按照规则就是如果智能合约中有对应修改这个状态的函数，满足调用函数的条件，就可以改掉它！

回到NFT url的问题，这个url肯定是存到状态树上了，毋容置疑也是上链了的，但就因为暴露了这个接口所以才导致可以被更改。

这里另外提1个NFT url篡改的风险在于同1个url内映射的文件也可能被更改，这里就需要用到不可变更的存储，如ipfs等，后面我们专门有一篇内容来分析分布式存储。

结尾

本篇文章我们简单介绍了智能合约的一些基础概念，并针对没有编程基础的同学介绍了编程中常见的概念。说到学习代码唯有2招最为有效，1.多读代码 2.多写代码 所以我们和大家一起分析了个简易版的智能合约帮助大家了解智能合约的整体结构,并分析了智能合约一些针对交易设计的特点。最后结合智能合约比较热门的应用NFT了解了接口的概念，再次讨论了什么是上链。文中我们多次涉及到之前写的以太坊数据结构一文，可见底层知识的重要性。

更多web3相关文章 可关注公众号 "web3探索者"

为什么需要分布式存储

中心化存储有着内容的访问权利过于集中,依赖中心化服务，中心化服务集群可能故障，导致不可用,重复下载内容多，速度较慢,文件存储时间短等问题，我们知道区块链是去中心化的，但以太坊等主流区块链只能在链上存储较小数据，所以对数据量较大的存储无能为力，所以去中心存储需要解决方案。

我们将介绍去中心化相关的3种技术ipfs，filecoin，arweave。本文先介绍pfs和filecoin，arweave将在下篇文章中介绍。

IPFS

IPFS简介

ipfs有着多重含义，既是文件系统，也是一种传输协议。本文将重点解释器作为传输协议的部分，可以理解其对比对象为http协议。

ipfs可以实现数据内容从多个分布式节点获取，将大的内容切块，使用内容寻址减少重复下载。

我们可以看看获取一份内容，由http变为ipfs的过程有何不同(不包含路由阶段)。

如上图所示，在传统http中我们向单点服务器请求数据dataA,中心化服务器需要完整返回dataA，而在ipfs中会将dataA进行拆分，拆分成几个较小数据集然后向不同节点(就近原则)分别请求这些data,如果节点已有的数据则不需要请求。

上面我们描述ipfs获取数据过程中有2个问题

1.ipfs为什么能够根据内容本身去寻找数据提供者(在http可不是这样, 是根据位置标识符来寻找的)。

2.客户端(需要获取数据的节点) 是如何找到拥有对应数据的节点。

内容寻址

内容寻址简介

内容寻址即根据内容去寻找它所处的位置，我们平时使用的http在浏览器中输入url都属于通过位置去找内容。

通过内容寻址有什么好处呢？当我们访问网络上资源时，如果使用内容寻址这一资源不会发生变化，如果通过地址寻找内容时，可能会出现url未发生变化但资源已经变成另外1个。这也是为什么目前较火的nft很多使用ipfs存储图片信息，如果存储在http服务器中很可能一张高价nft图片过几天就变成另外1张廉价图片。注意:并不意味着存储在ipfs就不会发生更换图片的事件，nft协议有提供更换资源地址接口，但调用合约是链上操作会留下记录。

内容寻址的实现

在ipfs中我们针对每块内容进行hash获得1个cid，这个cid就可以表示这一内容，如果内容发生了变化cid也一定会变化。

那么ipfs中是不是内容每更新一次我们就需要重新换个地址寻找呢，这部分内容可以查阅ipns，本文不详细展开。

在ipfs中针对文件夹这种形式还做了特殊的支持，我们先看看我们常见的文件夹格式是怎么样的。

如上图所示，根目录T1 中包含2个文件夹T2 T3和1个文件D, T2文件夹中包含2个文件A B T3文件夹中包含 文件C。

ipfs使用merkleDAG来组织文件夹形式, merkle tree的结构之前的文章以太坊数据结构已经详细介绍过，merkleDAG并无太大区别，区别只在于非叶子节点可以存储数据。我们看看上面的文件夹是如何组成merkleDAG的。

这样如果目录中的任何1个文件变化，都会影响其父节点hash值的变化从而影响整个目录的hash值。

上面我们回答了第1个问题，为什么ipfs能够进行内容寻址，接下来我们再看看第2个问题如何找到对应数据节点的，也就是如何进行寻址。

DHT(分布式哈希表)

DHT简介

我们直观去想如何在得知内容唯一标识去寻找存储数据的节点。

应该是有1个路由表去存储以内容标识为key，节点信息为value。那这个路由存在哪里呢？最简单的肯定就是存在某个服务器上，也的确有一些p2p是这样的设计，但这与去中心化的模式又有所相悖。也会带来中心化服务器的宕机风险，和访问权限过于集中的问题。

ipfs使用了DHT的方案，目标是希望将集中式地维护hash表变为由网络中的节点各存储hash表的一部分，这样可以解决中心化的风险。

DHT将key的集合拆分成多个子集，每个节点按照一定规则存储一部分子集，中心化的存储路由表到DHT的变化如下图所示。

DHT实现

DHT的解决方案会有1个非常大的挑战，映射CID到存储节点的路由表是分布在网络中的各个子节点的，那么当需要获取某个CID内容的时候第一步如何进行呢？总不能无规律遍历网络中所有节点并遍历其中存储的哈希表，这样效率会非常低。

在ipfs中为每个节点引入了PeerID，注意这个PeerID和cid位数一致。这样每个PeerID就会存储其对应一组cid和存储着其每个数据块节点的映射表。也就是说通过cid就可以计算出存储其路由表的PeerID。

这就为什么从ipfs网络中获取数据需要进行2次查询，第1次的寻找路由表所在节点 第2次寻找存储数据块的节点。

ipfs中获取数据块的完整过程如下

此外ipfs在访问数据过程中使用距离(路由跳数)来选择较近节点优先访问较近的节点，具体实现不再赘述，有兴趣可以自行查阅。

上面描述的ipfs看上去好处多多，但实际过程中ipfs遇到一个问题，ipfs只解决了去中心化的高效分发的问题，但没有解决存储的问题。 ipfs中存储不能依赖网络中的其他人，提供的是"我需要的数据你正好拥有那么我来你这里拿”的协议，协议并未解决将数据持久化存储。所以内容要么本地存储，要么存储在ipfs固定存储服务中。

那么去中心化存储如何解决呢？接下来我们看看filecoin的解决之道。

filecoin

filecoin简介

上面说到ipfs只解决了去中心化高效分发，但未解决去中心化存储，而filecoin专为去中心化存储而设计。

filecoin是一种区块链的设计，具备区块链的大部分特征。所以分析filecoin可以参考之前的以太坊技术相关的几篇文章。

如下图所示，filecoin通过自己的代币FIL和存储提供者提供存储空间进行交易记录到链上，从而形成了一个自由的存储市场。

filecoin核心难点是数据是在链下存储的，而链下操作是无记录不可追踪的，那么如何向链上证明的确存储了客户端数据呢？

复制证明

存储提供商将存储的数据进行编码生成数据副本，然后将数据副本的merkle tree的根hash连同自己的身份标识和存储时间进行hash，获得自己存储了这个数据的证明。这个过程称为密封，证明经过压缩后上传到链上。

使用复制证明可以验证存储提供商上链前的确存储了数据，但因为存储是一个持续的过程，如果存储提供商在证明提交上链后删除本地存储的数据怎么办呢？filecoin使用时空证明来解决这一问题。

时空证明

filecoin在存储期限内，会向存储提供商提出挑战，进行随机访问，存储提供商需要证明自己知道这些随机访问的数据。如何证明呢？这里又用到我们经常提到的merkle树，刚刚论述复制证明时将数据进行编码变成一棵merkle树，给定随机访问的节点数据，如果可以给到能够组成merkle树相同根节点的证明即可。

如上图所示，随机访问红色节点，需要给出绿色节点的证明即可。

同时还需要给出根节点的证明,因为链式并不直接存储根节点，链上验证根节点正确，并且绿色节点和随机访问的节点可以组成给出的根节点则证明成功。

在filecoin中存储提供商需要提供一定的质押，如果时空证明失败，质押将会被扣除。

共识机制

前面一篇文章以太坊共识机制介绍过，分布式系统是需要共识机制的，那么filecoin的共识机制是什么呢？

filecoin的共识机制称为EC共识和以太坊切换成pos后的共识机制类似，都是选举节点生成区块，只不过以太坊中的权益体现在质押的ETH，而filecoin中的权益体现在提供的存储，提供的存储越多被选中生成区块的概率也就越大。

filecoin使用复制证明和时空证明达到链下存储数据的目标，为区块链中存储较大数据提供了一种思路。

filecoin和ipfs

首先 filecoin和ipfs不是竞争关系，而是互补关系。如上文所述，ipfs有着优秀的传输分发机制，但并没有解决存储的问题，filecoin本就为存储而生，希望能够高效利用其大量空置的存储并形成全新的存储市场。

filecoin也是基于ipfs架构，节点类型也都属于ipfs节点，只是在构建ipfs DHC的时候filecoin不参与，在filecoin中寻找数据，filecoin提供了检索交易的方式但比较麻烦。所以很多架构都是二者结合使用，将数据存在ipfs中方便分发，同时也向filecoin存储一份作为冗余备份。

如下图所示,存储数据时先到ipfs查询，找到则直接返回，没有找到则在filecoin中进行检索交易。存储数据时共享数据到ipfs网络中，并进行存储交易备份到filecoin中。

filecoin虽然提供了分布式存储，但本身并未实现存储冗余，让我们试想一下，如果你将数据存储到filecoin中的某个存储提供商中后，如果这个存储提供商机器故障存储丢失了，那么除了扣除这个存储提供商质押之外并无其他办法。而arweave从机制上避免了此类问题，实现了永久存储，下一篇文章我们将介绍arweave相关。

结尾

本文从中心化存储的缺点开始论述，介绍了ipfs和filecoin各自的工作原理以及解决的问题。ipfs解决了去中心化存储的分发问题，filecoin解决了去中心化存储的存储问题。两者并非竞争关系而是互补关系，要进行结合使用。最后提到filecoin是去中心化存储方式，但未从技术方案上避免解决存储丢失的问题。

摘要

现有区块链架构已经被证明吞吐量是受限的，这是其被广泛采用的最大障碍之一。为了应对这一挑战在尝试侧链或Layer2解决方案，包括比特币的闪电网络或以太坊的Plasma网络，它们可以脱离主链工作。解决这个问题的另一技术是分片，即将网络分解为许多相互连接的网络。但是这些扩容方法打破了ACID(原子性、一致性、隔离和持久性)，增加了应用程序开发的成本和时间。 在本文中，我们介绍一种新颖的方法，我们将矿工分为两个不同的节点类型。具体来说，选择、排序工作和执行工作将相互独立。本文的重点将介绍共识和计算分离，并证明这种方法增加了吞吐量但不影响安全性。 与大多数现有方案相比，我们的方法通过分离共识和计算来实现扩展，即更好地利用资源。这种方法使智能合约的编程范式(事务操作原子性)得以保持并且未增加额外复杂度。我们进行模拟网络试验，试验采用相同的共识算法(具有轮换区块提议者的两步提交协议)，区块计算要么在共识节点执行(传统架构)或委托给专门的执行节点(共识和计算分离架构)。共识和计算分离使我们的系统与传统系统相比，在不损失安全性和去中心的情况下吞吐量增加了56倍。

内容

1. 介绍

• 1.1 相关工作

1. 架构概述

2. 理论性能和安全分析

• 3.1 共识节点的特殊作用

1. 进一步的工作

2. 结论

最初的比特币区块链使用称为Nakamoto共识的共识模型。它使用顺序模型，在该模型中节点构建、挖掘和验证一个块，节点们在此之上构建后续的块。虽然POW保障了区块链链的安全性，但相应的计算工作量限制了出块速率和交易吞吐量。这种架构已经被证明吞吐量是受限的，这是其被广泛采用的最大障碍之一。 消除工作量证明开销的主要方案是采用拜占庭容错(BFT) 共识算法。使用POW 的区块链需要巨大的计算量以及电能。相比之下，通过BFT确定区块共识是高效的，但需要一组绝大多数诚实的参与者。 将 BFT 共识与权益证明 (PoS)相结合，可以创建具有强大安全属性网络。在 PoS 下，所有参与节点都必须质押权益(token)，如果违反协议规则，可以将其扣除。赋予每个节点的影响力与其质押数量成正比。此外，存入的权益具有防止 Sybil 攻击的额外好处。 PoS增加链的吞吐量，降低保证链安全性的开销。但即使采用POS增加性能，吞吐量的限制仍然是区块链被广泛采用的障碍。 在本文中，我们探索了一种提升PoS区块链吞吐量的新方法。尽管PoS区块链方案消除了工作量证明，但他们倾向于从上一代的工作量证明系统继承大部分架构。特别是，网络中的每个全节点都需要检查和执行每个提议的区块并更新他们的本地副本以保持状态一致。因为每笔交易都需要被所有全节点处理，向系统添加节点对吞吐量没有好处。反而，添加节点会降低大多数BFT共识协议的吞吐量，因为最终确定一个块的消息复杂度会随着共识节点的数量超线性增加（参见第3.1 了解详情）。因此，大多数 PoS 区块链必须在一个小的共识委员会（削弱安全性）或低出块率（降低吞吐量）之间权衡。 对于不愿妥协安全性或去中心化的网络，解决扩展问题的最常见方法是通过分片或将工作从主 链移走（例如Lightning或 Plasma网络）。不幸的是，这两种方法都将对访问分布在不同地方的状态产生限制。这些限制极大地增加了应用开发者(基于智能合约)的复杂度。 我们提议的Flow 架构通过从根本上改变区块链。 Flow 将交易的选择和排序与其执行分离 这样两个进程就可以并行运行。解耦可以显著提高交易量吞吐量(高于其他区块链架构)，而不会破坏安全性或去中心程度。 传统的区块链架构需要对每个区块状态的更新结果进行确认，作为共识过程的一部分。因此，每个节点都必须在区块确定前进行状态更新计算。我们发现确定区块中交易顺序时才需要共识。一旦该顺序确定，计算结果是确定的。因此，共识部分的计算量将显著减少。一旦交易顺序确定后，就可以委托后续进程执行计算，而不影响系统的去中心化。 我们的主要工作是第3部分，在那里我们讨论和证明我们的中心定理，即可以在不影响安全性的情况下将大部分计算和通信负载与共识分开。 本文的重点是介绍共识和计算的分离，并证明这种方法可以增加吞吐量，同时具备强大的安全保证。围绕本文介绍设计的区块链需要指定各种附加机制包含：

• 用于验证计算结果的完整方案。

• 共识算法的细节。

• 完善的奖励机制和惩罚机制来激励节点遵守规则。 这些主题的介绍和分析留给后续文章。

1.1 相关工作

图灵完备的区块链通常会对一个区块内的计算施加上限，例如以太坊的gas限制。这样的gas限制反过来又引入了吞吐量限制。施加gas限制的一个原因是为了避免验证者的困境。通过将gas限制设置得足够低，验证的时间投入与完成POW中设定的挖掘区块挑战相比，可以忽略不计。因此，gas限制确保执行验证工作不会给节点成功挖掘下一个区块带来影响。 对于PoS区块链，验证者的困境仍然存在。特别是对于高吞吐量的区块链，大量交易的验证会消耗大量的计算资源和时间。通过分离共识和计算，共识节点不再有验证计算结果正确性的验证者困境。块中的最大计算量（块的gas限制）不会受到共识节点的限制。但仍然需要为验证者解决计算问题。解决方案包括zkSnarks、Bulletproofs和TrueBit。对于 Flow，我们开发了专门的知识证明 (SPoCK) 来解决验证者的困境，在后续的文章中有详细描述。 将事务排序问题与计算结果的工作分开的概念之前已经在分布式数据库领域提出过。事务通过共识排序到日志中，每个节点可以独立处理事务。然而，这些系统设计用于维护良好的数据中心，无需担心拜占庭攻击。 在区块链领域，Ekiden论文描述了一个共识与计算分离的系统，其目标是保护隐私。该论文解释了Oasis区块链技术的一部分，并指出这种方法可以提高性能。但它没有量化性能提升效果以及没有证明这种方法构建的系统将能够保证安全性。

2 架构概述

Flow 架构建立在计算和共识分离的原则之上。网络中有专门角色：共识节点和执行节点。这2种节点类型的核心区别是解决客观问题还是主观问题。客观问题是那些有客观的正确答案。任何传统的数学计算都是客观的；你不需要权威或专家确认2+ 2 = 4的正确性。主观问题没有这样的确定性解决方案。大多数人类治理系统（“法律”）通常处理主观问题。在不同社会的不同时期，有关规则可能会非常不同。共识一词的定义意味着在主观问题上达成一致，没有单一的正确答案。 传统的区块链架构要求参与网络的节点同时解决主观问题和客观问题。在 Flow 中，共识节点负责处理所有主观问题，执行节点仅负责完全确定的、客观的问题。我们简要介绍共识节点和执行节点。

共识节点 共识节点通过交易数据形成区块。许多节点就提议区块达成一致需要拜占庭容错(BFT)共识算法，本文的结论适用于任何具有确定终局性的BFT共识算法。 在Flow中，一个块引用它包含的交易并定义它们的执行顺序。但不包含块中交易执行完成后的状态。因此，共识节点不需要维护计算状态或执行交易。 此外，共识节点裁定来自其他节点的惩罚请求，例如执行节点产生了错误的输出。

执行节点 当按照共识节点确定的顺序执行时，执行节点提供确定交易结果所需的原始计算能力。当执行节点的输出结果被验证是错误的时候可以要求惩罚他们。一旦它们被验证是正确的，他们将为区块链当前的状态提供证明。验证过程——错误的结果被拒绝(会惩罚产生错误结果的执行节点)，正确的结果被接受(在网络中被共享)。

图 1：通过共识和执行节点的消息流概览。为简洁起见，仅显示正常操作期间的消息。惩罚请求被裁定期间交换的消息被省略

3 理论性能和安全分析

在本节中我们将进行理论推导，证明可以在不影响安全性的情况下将大部分计算和网络通信从共识节点分离。 Flow的设计确保在由执行节点引入的错误会具备四个关键属性: 可检测的：根据定义确定性过程具有客观正确的输出。因此，即使是网络中只有单个诚实节点也可以检测到确定性错误，并通过指出执行错误的部分来向其他诚实节点证明这个错误。 可追溯的：Flow 中所有确定性的输出必须被生成这个输出的节点进行身份签名。因此，已检测到的任何错误可以清楚地追溯到负责该输出的节点。 可惩罚的：Flow网络中的所有节点，包括执行节点和共识节点，必须进行权益(token)质押，如果被发现具有不利于正确共识达成或输出错误结果的行为，将对这些节点进行权益(token)扣除(因为每个行为都是可检测和可追溯的)。 可恢复：系统必须具有在检测到错误时撤销错误的方法。这将阻止节点进行收益大于被惩罚的恶意行为。 这样的设计一个重要特征是对于系统内部的每个操作都可以找到对应参与者负责。具体来说，除了共识节点之外的操作，从节点中选择一个子集负责执行，另外一个不相交的子集负责验证结果。下面简单介绍工作过程:

• 执行组和验证组都是随机选择的。选择的节点使用可验证的随机函数，这样结果是确定性的。

• 任一组中节点的被包含的概率与其质押的权益(token)成正比。这要求节点必须锁定大量权益(token)，才可能具备影响系统的可能性。这会强化系统对女巫攻击的抵抗力。

• 两个组内节点要求质押的权益(token)要足够高，这样每个组分到全是恶意节点的概率就非常小。

• 只要任一组中至少有一个诚实节点，诚实节点就会检测到错误并标记。

• 如果标记了错误，共识节点将进行裁定，确定是错误后，恶意节点将被惩罚，操作结果将被拒绝。

上述过程保证了恶意执行节点几乎可以肯定被惩罚。此外，恶意节点几乎不可能成功引入错误。 可能出现的一个问题是，为什么 Flow 具有独立的执行者组和验证者组而不是执行者来验证彼此的结果。我们通过这种分离解决验证者的困境。如果没有专门的验证者角色，执行者计算下一个块与验证（重新计算）之前块的结果之间存在利益冲突。在 Flow 中，这种困境通过专门的验证者得到缓解。关于验证协议的技术细节将在后续文章中介绍，其中包括了如何解决验证者不进行计算批准任何结果或验证者恶意标记正确的结果导致网络阻塞等问题。 以下定理介绍了Flow架构的安全保证并证明通过发布或批准错误结果将错误引入系统是经济的不可行。 定理 1（将工作委托给执行组和验证组从攻击成功的概率上看是安全的） 如果按照以下条件约束，则通过故意发布错误结果或验证通过错误结果将错误引入系统在经济上是不可行的。

1. 操作委托给两组随机选择的节点：

• (a) 一组执行者：该组的成员执行操作。

• (b) 一组验证者：该组的成员验证执行的结果。

1. 只要两组同时都选中全部是恶意节点的概率足够低，两个组的节点规模可以相对较小。

2. 执行组在生成执行结果时，验证者组的节点对他们来说是不可知的。

3. 共识节点

• (a) 绝大多数节点对公布的结果做出了承诺，并且参与节点无异议

• (b) 或裁定异议，确定故障节点（可归因），并惩罚它们。

需要强调的是，共识节点只需要检查是否有足够的节点执行并对其验证就足够了,他们不需要检测结果本身。定理1适用于任何具有确定终局性的BFT共识算法。

定理 1 的证明： 我们将证明定理1在符合以下条件时总是可以满足

• 两组中至少有一组从由诚实节点占据多数的大量节点抽取的；

• 恶意节点不能抑制诚实节点之间的通信，即，如果有一个诚实节点反对结果并证明其错误，错误节点将被惩罚。

具体来说，让我们考虑一组N个节点，我们希望从中随机抽取一个具有 n 个节点的子集。此外，我们假设最多有 M < N/3 个恶意节点。在下文中，我们将重点关注所有节点质押权益(token)均等的情况，即它们被包含概率是相同的。选中 m ≤ n 个恶意节点的概率由下式给出超几何分布

其中 Pn,N,M (n) 是正好全部选中恶意节点的概率

(译者注:这里的存在一些公式，简单推导下 Pn,N,M(m)=C(m,M)C(n-m, N-M)/C(n, N),当m=n=k时 Pk,N,M=C(k,M)/C(k,N)=(M!/k!* (M-k)!)/(N!/k! *(N-k)!)= M!/N! (N-k)!/(M-k)! 这里的C(m,n)是大家都学习过的求组合方式，C(m,n)=n!/m! (n-m)!)

上式(4)表明，仅选中恶意节点的概率随着n的增加而严格单调递减。也就是说样本量n越大，只选中恶意节点概率越小。

节点通过发布错误结果或批准错误结果来故意攻击网络，我们假设存在奖励r，如果它的攻击成功，节点会收到这些奖励r。但是如果攻击被发现，该节点将被惩罚ξ。 攻击网络所产生的期望收入为

此外，式(4) 意味着 r/ξ 随着 n 的增加严格单调增加。当 n < N/2 时，r/ξ 随 n 呈指数增长。 式 (7) 的左侧 r/ξ 是安全性度量，因为它代表攻击系统的成本。举个例子，让我们考虑 N = 1000，M = 333，n = 10 的情况。为简单起见，假设对于发布或批准错误结果，该节点质押的全部权益(token)将被扣除。然后，为了攻击在经济上可行，成功奖励 r 需要是节点权益的 65343倍(译者注:由式7计算得来Pn,N,M=M!/N!*(N-n)!/(M-n)!=333!/1000!990!/323!=(333...324)/(1000 *... 991) r/ξ=(1000 ... 991)/(333...324) - 1= 65343)。如果验证者每人质押 1000 美元，攻击者平均需要花费6530万美元覆盖质押被扣除的成本。当进一步增加n到 n = 20，攻击者需要花费 r/ξ = 5.2 * 10^9 倍质押权益(token)来发布错误结果。

总之，我们分析了将执行和验证委托给1个较多节点子集的结果。证明了通过发布或批准错误结果将错误引入系统在经济上是不可行的。这个结果适用于除共识节点外的其他节点。因此，共识节点只需要检查是否有足够的节点执行并对其验证就足够了,他们不需要检测结果本身。

定理1很关键，因为它允许我们：

• 将大部分计算和通信负载与共识分开；

• 根据不同的需求研制专业化的节点(而不是要求节点在所有方面都具有优秀的性能，达不到就降低网络吞吐量)

其他节点以小组的形式相互验证，而共识节点以及共识委员会内部完成验证。

3.1 共识节点的特殊作用

共识节点通过 BFT 共识算法确定事件的相对顺序。我们的结论适用于任何具有确定终局性的 BFT 共识算法，例如:HotStuff、Casper CBC或 Fantômette。

不同于其他节点的操作，共识节点在没有外部验证的情况下生成区块需要共识委员会的通过。区块的内容会被验证，如果发布的区块包含无效内容，共识节点将会被惩罚，但与其他操作不同(译者注：执行或验证)的是区块不会被重建。发布后外部各方可以检查最终确定的区块。但是，如果进行分叉攻击，双花攻击此时可能已经成功。为了提高整个系统的可恢复性，共识节点委员会应由尽可能多的质押节点组成。

对于一个简单的 BFT 算法，每个块的消息复杂度 η（所有 N 个节点发送的消息）为 O(N^2) 。更高级的协议实现O(Nlog N)或 O(c*N)，c是常量。整个共识委员会的总带宽负载 B[MB/s]为 B = β *b * η β是整体网络阻塞率, b为消息大小 MB/s。 对于接收消息m并处理它的节点，增加延迟 L(m) = f(b) + process(m) 其中 f 表示接收 m 的网络传输时间， process(m) 表示处理 m 的计算时间。很明显，B 和 L 都很大程度影响共识算法的吞吐量。这高度依赖于选择的 BFT 协议，以及拓扑结构。其他因素包括延迟或带宽限制在底层网络硬件中。

目前，我们的目标是数千个节点的共识委员会。为了去中心化，应该是使得个人仍然可以运行节点并参与共识。因此，给定所需的网络阻塞率β和环境确定的函数 f，只有减小消息大小 b 或 process(m) 才能增加共识委员会中节点数量。

我们简要介绍如何同时减少 b 和 process(m)。各个过程的详细机制，请读者参考后续文章。

• 我们将计算委托给专门的执行节点。消除了共识节点维护和计算状态的需要，这显著减小了process(m)。

• 共识节点在正常运行期间不需要完整的交易数据。专门的收集器节点从外部客户端接收交易并将它们预打包成为集合。共识节点仅对集合引用（哈希）进行排序，这与处理单个交易数据相比，大大减少了消息大小b。

我们通过将我们的方法与 Vlad Zamfir提出的三角(译者注:这里三角是针对POS系统，因为要进行BFT投票所以低最终确定性延迟、低网络通信开销、多节点数量不能够同时满足，需要进行平衡)进行比较来结束本节(图2)。三角形表达了Zamfir对于POS系统的猜想。Flow通过将共识节点和执行节点进行拆分进行优化

• 共识节点作为共识委员会。为了确保最终区块的安全性和快速生成，我们接受更高的通信开销（三角形左下角的角）。然而，不同于其他区块链，这种共识只决定一个区块内的交易顺序，而不是结果状态。该架构通过使用集合引用而不是完整的单个交易。进一步提高吞吐量并减少通信延迟，所有可能的计算都委托给其他节点类型。

• 执行节点将解包并处理单个事务。在不涉及大量恶意节点情况下，收集器节点可以和执行节点直接完成无需共识节点。此外，任务可以由小组进行并行化处理，小组相互负责以确保正确的结果。只有恶意攻击期间，恶意行为才会报告给共识节点以进行裁定惩罚。

4 进一步的工作

围绕本文设计的区块链需要解决额外的问题，最值得注意的是验证计算输出的机制。一方面，拆分共识和计算工作提高了 Flow 的吞吐量。另一方面，必须关注计算结果状态的正确性，因为共识节点不会重复计算。 此外，在 Flow 中，区块不再包含状态的hash结果。因此，接收数据的节点无法基于已发布区块验证数据有效性。我们将在后续论文中介绍区块验证和保证计算结果的（称为块密封）技术细节。

5 结论

在这个理论证明中，我们证明了共识和计算的分离可以使得PoS区块链网络中的资源利用率显著提高。对于常规PoS网络，一个区块在下一个区块被提议之前完成，吞吐量受到一小部分最慢节点的限制。而共识和计算的分离显著地将计算负载从共识节点转移到最快的节点。定理1中表明，共识和计算分离不会牺牲网络的安全性。在简化的模型中，我们的模拟显示与共识节点包含共识和计算的架构相比，吞吐量增加了56倍。 作为以太坊，一种增加吞吐量的方式是设置算力要求。然而，这将使得新节点更加难以加入系统。在传统的工作量证明区块链中，大量计算资源集中在一小部分挖矿节点，而维护和更新状态在所有全节点上的计算量是一致的。 Flow 架构利用网络中自然的资源不平衡生态系统。少数具有海量计算和带宽能力的数据中心可以质押成为执行节点，以最有效地贡献其资源。相比之下，共识节点不存储或维护状态，因此可以在现有的个人设备上运行。

账户状态树

哈希表 既然是基于账户的模型，我们需要通过账户地址找到账户的状态。就像通过银行卡号可以找到你在银行中的各种信息一样。最简单的想法当然是一个简单的哈希表 key是账户地址 value是账户状态。但这里有个问题解决不了。 轻节点如何校验账户合法性？

上篇文章我们说过，区块链中有2类节点，全节点和轻节点，轻节点只会存储block header，所以轻节点如何才能校验账号是否合法呢？

Merkle Tree（哈希树）

这个思路和我们平时用的md5校验一致，我们会对区块内的信息进行hash运算从而得出区块内信息唯一确定的值，区块链所有节点中这个值都是相同的。

在这个过程中我们用到了一种数据结构Merkle Tree（哈希树），我们先看下Merkle Tree（哈希树）的示意图。

上篇文章说到区块链中的链表(哈希链)和我们平时常见链表不同的是将指针从地址改为了hash指，这里也一样，哈希树和二叉树的区别有2个 1.将地址改为了哈希值

2.只有叶子节点存储数据

回到之前的问题轻节点是如何校验1个账户或交易是否是在链上的呢？

整个流程如上图所示

1.轻节点需要判断1个账号是否合法

2.轻节点由于只存储block header，所以拿到1个账号的时候会向全节点发出请求 3.全节点存储了所有账户状态，将账户路径中的需要计算用到的hash值返回给轻节点

4.轻节点本地进行计算根hash值，如果计算结果和自己存储一致则账户合法，不一致则不合法。

那以太坊中的账户信息的数据结构就是这样吗？ 直接用这样的数据结构来存储账户信息会有2个问题

1.查找困难 2.生成hash值不确定

第1个问题应该比较容易发现，在这个树中寻找1个账号需要的复杂度是O(n),因为没有任何顺序。

第二个问题其实也是因为无序导致的，无序的组合每个节点针对同一批账户生成的hash值不一致，这就导致无法达成共识。

字典树 既然2个问题都和顺序有关，那我们类似二叉排序树一样，使用哈希排序树是不是就可以解决问题了呢？ 使用排序树后会带来另外1个问题 插入困难 因为要维持树是有序的，很可能带来树结构的很大变动。

以太坊中使用了另外一种数据结构字典树。和哈希树不同，字典树应该是很多地方都有使用。我们简单来看下字典树的结构。

字典树能够较好地解决哈希树的2个缺点1.查找困难 2.生成的hash值不确定以及排序二叉树的1个缺点 插入困难。

但字典树我们可以看到可能树的深度可能由于部分元素导致整棵树深度非常深。

压缩字典树

这时我们可以进一步优化，将相同路径进行压缩。这就是压缩字典树。

MPT(哈希压缩字典树, 有专业翻译，但个人认为这样翻译比较易理解) 将哈希树和压缩字典树结合，就可以得到以太坊存储账户的最终数据结构-MPT。

将压缩字典树里面的指针从地址改为指针，并且将数据存储在叶子节点中即可。

状态树存储域 介绍完状态树的数据结构，我们接下来讨论1个问题，区块中存储的账户状态是什么样的范围。有2种选择。

1. 只保存当时区块中产生交易的账户状态。

2. 保存全局所有的账户。

我们可以看下这2种方式，无非就是空间和时间的平衡，只保存当前区块产生的交易意味着是做懒加载(需要的时候才去寻找账户)，在区块链中这个代价是非常大的，因为寻找的账户之前从未交易过，这样会遍历整个区块链。另外一种保存全局的账户方式虽然看起来空间消耗较大，但查找快捷，而且空间的问题我们可以通过其他方式优化。所以最终以太坊选择了第2种每个区块都报错全局所有账户的方式。

我们来看下以太坊中是如何保存状态树的。

可以看到以太坊中虽然每个区块都保存了全部账户，但是会将未发生变化的账户状态指向前1个节点，本身只存储发生变化的状态，这样可以较大程度优化空间占用。

交易树&收据树

介绍完以太坊中比较复杂的状态树后，我们继续来看看以太坊中的另外两棵树，交易树和收据树。 首先介绍一下，为什么需要交易树&收据树。 1.交易树

虽然以太坊是基于账户的模型，但是就像银行不仅会存储银行卡的余额，还会存储卡中的每笔钱怎么来的以及怎么花的。交易树中就存储着当前区块中的包含的所有交易。

2.收据树 由于智能合约的引入增加了不少复杂性，所以以太坊用收据树存储着一些交易操作的额外信息。比如交易过程中执行日志就包含在收据树中方便查询。收据树和交易树是一一对应的。每发生一次交易就会有一次收据。

和状态树不同交易树和收据树只维护当前区块内发生的交易，因为当时区块发生交易时不需要再去查找另外1个交易，也就之前需要可能遍历整个区块链的查找操作了。

由于以太坊中的出块速度较快，我们进行一些查询一些符合条件交易的时候会面临大量数据遍历困难的问题。收据树中引入了布隆过滤器可以帮助我们有效缓解这一困难。

布隆过滤器 布隆过滤器将大集合中每个元素进行hash运算映射到1个较小的集合，这时再来1个元素要判断是否在大集合的时候，不需要遍历整个大集合，而是去进行hash运算去小集合中寻找是否存在，如果不存在，肯定不在大集合中，如果存在则不能说明任何问题。

如上图所示，布隆过滤器只能证明某1个元素不在集合中，不能证明1个元素在结合中。

以太坊中如果我们要在较多区块中寻找某1个交易，则可以利用布隆过滤器，过滤掉肯定不存在目标交易的区块，然后进入收据树内继续利用布隆过滤器筛选，剩下的才是可能的目标交易的交易，进行一一比对即可。

总结 我们介绍了以太坊的核心数据结构，状态树&交易树&收据树，他们都是使用相同的数据结构-哈希压缩字典树。但状态树是维护1颗全局账户树，交易树和收据树则是维护本区块内的交易或收据。

介绍完数据结构后，后面我们会用几篇文章来介绍以太坊中的一些核心算法，比如共识机制，挖矿算法等。

1.区块

图中的每个区块分为 block header 和 block body 两部分

包含着账户信息以及交易信息  具体信息如何存储后面再介绍以太坊中的数据结构h会具体介绍。

2.区块链

区间指针通过链式结构结合而成的就是我们经常说的区块链，只不过这个链表指针中存储的并非我们通常说的地址，而是存储了上一个区块的hash值。

3.全节点和轻节点

区块链是去中心化的。如何体现去中心，整个以太坊网络包含着多个很多个节点。

全节点存储着完整的区块链，每次数据的变更，需要通过共识机制，广播给所有全节点。轻节点存储着区块链中的block header部分(也是区块组成的链，只不过每个区块只包含block header)。

轻节点的作用只是用来查询，不对区块链中数据合法性负责，可以把我们自己的钱包理解为1个轻节点(这种理解在目前的市面上的钱包并不对，但可以先这样理解)。

基于账户模型的以太坊

这个是大部分区块链的通用模型。并没有体现出何为基于账户的模型。那是否还有其他模型？

重点是刚刚有说，我们的区块block body中会存储账户信息。另外一种更著名的区块链应用-比特币并没有采用这种“基于账户的模型”, 而是采用基于交易的模型。

基于交易的模型

如上图所示，比特币并不存储账户余额，而是存储每一笔交易。

我们再看下比特币是如何转账的。

当转账的时候，需要解释钱从何而来。

比特币在转账的时候会要求一次性全部转出，即需要把交易后的余额转入自己的另外1个账户(很多人的比特币因此丢失)。

比特币和以太坊2种不同的设计思路取决于其设计目的: 比特币是纯金融货币属性。所以更注重安全性，每次转账都进行账户切换。

以太坊为了要支持智能合约，合约是1个持续的过程，所以需要稳定的账户。

应对攻击

我们可以看看2种设计在面对一些常见攻击时是如何应对的。

1.双花攻击

双花攻击即一份钱花2次。为什么会出现双花攻击呢？主要原因是数字货币和纸币不同，复制是无成本，不可校验的。

比特币如何解决双花攻击，就是需要每次在花钱的时候说明钱从何而来，这样相当于用交易链去溯源。

以太坊面对双花攻击是自然屏蔽的，因为有了账户的概念，每花一次钱都需要将账户余额减小对应值。

2.重放攻击

重放攻击即将同一次交易多次发布。

比特币中由于使用了基于交易的模型，每次转账完成，钱都会到1个新的账户，所以重放攻击对比特币是无效的。

以太坊由于要维护账户的稳定，所以重放对以太坊是有威胁的，以太坊为了解决这个问题，引入了交易次数，每次交易的时候都会将交易次数一并签名，这样重放攻击者无法修改交易次数攻击无效。

可以看到由于最开始设计理念的不同，在遇到不同的攻击方式时，需要采用不同的策略去应对。

以太坊账户分类

以太坊中包含2种账户

1.外部账户，可以把钱包理解为1个外部账户，里面放着我们每个用户的余额。

2.合约账户，因为以太坊支持了智能合约，所以合约账户里面不仅包含着余额 还包含着代码和需要存储的数据。

我们在调用智能合约的过程，其实就是在和合约账户交互的过程。

常见的钱包

钱包的分类主要分为3类

1.交易所钱包  各大交易所的钱包，这种钱包其实并不能够受区块链保护，其掌控权是在交易所手中，但交易很比较方便。

2.热钱包，独立的钱包APP。

3.硬钱包，硬件钱包，无网络连接。

钱包中的常见术语

私钥(助记词）助记词是私钥的另外一种表现形式，类似ip到网址的转换更方便记忆。

公钥

私钥和公钥使用非对称加密算法来保护大家的钱包。

钱包密码：钱包密码是你为钱包设置的密码，但是钱包的安全性保障来自于私钥不被泄露而不是密码！

钱包地址：钱包地址是由公钥hash计算得到

个人使用较多的热钱包APP是 metamask: https://metamask.io/

结尾

后续会继续用几篇文章来介绍以太坊技术，原因在于以太坊作为web3的基础所在，有必要学习内部原理，帮忙我们去更好地去深入讨论思考web3的后续发展。