避免一切模糊的概念，理解清楚關鍵細節后，你會發現世界是如此的清晰。
作者：阿 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 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
