避免一切模糊的概念，理解清楚关键细节后，你会发现世界是如此的清晰。
作者：阿 Kang，Silicon 说
封面：Photo by Philippe Oursel on Unsplash
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 规范的提出者，为了提出精妙的规范，他们大量思考了各种概念背后的哲学本质，抽象出了最关键的几个属性。这个属性不仅可以帮助大家设计出代码上的规范，它同样也可以帮助你去拆解思考清楚资产逻辑本身。
避免一切模糊的概念，理解清楚关键细节后，你会发现世界是如此的清晰。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
