长推：Web3产品经理如何清晰理解ERC规范？

注：本文来自@SiliconLuoDAO 推特，其是 @0xCreatorDAO联合创始人，原推文内容由MarsBit整理如下：

Web3产品经理，如何一次性清晰理解ERC规范？

Web3产品经理可以不懂代码，但是必须要精确理解ERC协议的接口概念。（这是一篇从产品经理视角下的ERC协议技术科普贴）

一、Web3 PM的关键是构思资产逻辑

Web2的PM，梳理清楚数据逻辑是非常关键的；类似的，做Web3产品，就一定需要梳理清楚资产逻辑，而要做到这一点，一定要对ERC协议有精准的概念理解。同时我之前看到了太多模糊的比方，这样的比方短期内可以让你觉得自己理解了，长期却会影响你的理解和产品设计。

要理解ERC，首先要明白：ERC本身是一种代码规范，它尽可能从最底层的视角去抽象想刻画的事物的通用属性，并且对应的在合约代码中，用接口（函数）去刻画这些属性，这样子规范就可以起到让大家广泛的使用，在实现自己特异功能的同时，还可以互相通信认可的目的。（只要大家都按照规范去写的代码）

二、聊聊ERC20的设计思路

个人暴论：ERC20可以被认为是其他资产规范之根基，把ERC20的精神理解清楚了，其他的都是类似的套路，只不过多了一些小细节不同而已。

ERC20的核心是描述同质化代币。我们来想想，做减法做到极致，同质化代币有哪些最根本的属性？首先最核心的是需要一个账本，记录每个地址有多少数量代币，后续的一切其他属性都是围绕这个点来展开的。这个账本一般在合约代码里是通过一个map格式的数据来实现，map就是一个从地址到数量的映射。

当然了，这个是藏在代码里面的，没有通过接口暴露在外面。

那么基于这个账本，FT有哪些基本属性呢？查询余额这个肯定有，所以我们有了balanceOf(address _owner)接口，输入是地址，输出就是资产数量。

具体代码内部实现的话，基本操作就是调取合约内部的map账本数据，即：mapping(address => uint256) private _balances，获得输入地址对应的数量；

当然如果你要搞骚操作，也可以写其他返回的逻辑，比如返回真实数量的两倍。。。（其实接口的实现非常自由）

转账动作是一个关键的属性，围绕这个属性我们可以延伸出几个相关联的接口。先看看概念，什么是转账？就是一个账户的数字+a，另外一个账户的数字-a；同时转账必须需要一个发起方，并且发起方能发起的转账指令肯定是受限制的，其中一个必有的限制是：他只能发起转出特定的地址的资产。

比如你只能发起转移自己的资产给其他人，或者你获得了某个地址A的授权，你可以代表A发起指令，转移这个地址特定数量的资产。所以就出现了两个核心的接口：transferFrom(address _from, address _to, uint256 _value)，即转账指令本身，以及approve(address _spender, uint256 _value)，即授权指令

具体在代码实现的话，transferFrom内部，一般会做一个检查，看看发起这个transaction的地址，是不是有address _from本身，或者有没有address _from的相应授权。如果有，那么就会让合约里记录资产所有信息的map变量的address _from的资产数量减去uint256 _value。

对应的address _to资产数量+uint256 _value；对应的，合约里肯定有个变量，用来储存谁给谁授权了多少额度的信息，即mapping(address => mapping(address => uint256)) private _allowances；同时这个变量又可以被approve接口来写入。

如果你要搞骚操作，也可以不这么内部实现。虽然接口在这里，但是你可以改，比如你要当庄家，你可以改动transferFrom的内部代码检查逻辑，让onwer地址可以操作所有地址的资产...

三、理解完接口概念后，如何设计产品？

如果你现在明白了ERC20是如何通过接口，抽象出通用的属性后，你就会发现，你可以基于此定义很多自己的产品逻辑了。

比如你希望设计一款社交App，你希望用户只能接受来自好友的转账，那么你就可以在Tranfer这个接口的实现里做文章。

接口本身的输入输出不要动，但是你可以在接口函数内部实现代码中，增加一个对“转装接受地址”的检查，检查这个地址是否和转出方存在好友关系。（所以你还需要用一个map或者其他的数据格式，来记录好友关系）

再比如你想学习usdt，设置一个黑名单，黑名单的地址就无法转入准出了。那么这个本质上也是在对Tranfer过程做文章。同样不要动接口本身的，保持和其他合约通讯的通用能力；

但是你可以在内部实现过程里，加一个检查，只要是转入/转出地址在某个黑名单地址里，就统一报错。这个黑名单变量你也可以用单独另外一个变量在合约里储存好。

四、基于ERC20的概念，去理解721，1155，以及其他高阶资产合约呢

回头看，任何资产的核心基本面就是三个：描述资产的数据结构、描述资产所有信息的数据结构，以及资产转移动作相应接口。从这三个基本面出发，你可以自上而下推导出所有的应当拥有的标准接口。

FT的资产数据结构很简单，因为是同质化，就是一个数字就够了。随后就可以推导出上述的内部账本数据结构，以及相应的转账接口设定。

如果变得更加复杂一些，比如资产本身不是一个数字，而是一个ID，并且只有ID，不在意ID的具体数量（或者每个ID总量就是1），那么就变成了721。

照着上述的逻辑推导，你可以第一性原理推导出721应该如何内部储存资产关系，又应该哪些接口来去刻画这种资产数据结构。另外你单独加个接口，让ID和一个图片链接产生映射关系，这个NFT就有了图片可以显示。如果这个ID是和音乐链接产生映射关系，就可以代表音乐。

如果你希望同时有ID，以及每个ID有数量。。。那就是1155，也是类似的逻辑。。。

关于高阶资产的变种规范，如何沿着「资产数据结构 - 资产所有信息 - 资产转移」的方法论去第一性推导，以及在各种应用场景下进行具体的设计。我可以后面再专门写一篇来分享

五、为什么作为web3 PM，精准理解合约逻辑很重要

产品经理可以不懂代码细节，但是产品经理要搞明白产品逻辑。对于web3产品来说，资产一定是一个非常重要的主角。我的暴论是，未来好的web3产品，一定要有好的资产逻辑。而资产很重要，一些微妙的资产逻辑不同，都会带来很大的区别。

要想精确的描述资产逻辑，你就必须要去学习ERC背后对资产的哲学抽象。

绝对不是说因为我要写代码，我才需要看ERC规范。而是恰恰相反，ERC规范的提出者，为了提出精妙的规范，他们大量思考了各种概念背后的哲学本质，抽象出了最关键的几个属性。

这个属性不仅可以帮助大家设计出代码上的规范，它同样也可以帮助你去拆解思考清楚资产逻辑本身。

避免一切模糊的概念，理解清楚关键细节后，你会发现世界是如此的清晰。