原文： 【源碼解讀】你買的NFT到底是什麼？

內容概要

如果你是WEB3加密界的新手，面對眾多概念無從入手，那麼歡迎你，來對地方了！ ！

本文圍繞標準 ERC721協議，描述了Mint、 safeMint、 transfer等是如何實現資產管理的，並通過解讀代碼來了解它的安全性設計和以太坊數據上鍊成本構成。

目錄大綱

  • 1.所謂NFT資產是什麼？

  • 2.Mint和safeMint的差別

  • 3.交易時會發生什麼？有哪些細節設計

  • 4.NFT哪些數據也存儲在鏈上？

  • 5.以太坊上存儲有多貴？

面向對象

  • Web3新手，有無技術背景均可：

  • 研發——可無障礙閱讀，理解精美的合約設計

  • 非研發——可能讀不懂列舉的代碼，但能體會標準協議的設計思路

1.所謂NFT資產是什麼？

在opensea上，可看到每個NFT都有個唯一的編號。

比如azuki系列中第4132號，在頁面的Details欄目可以看到其合約地址，ID編號，部署所在公鏈等信息，而Properties欄目則是其設定的具備各種屬性，對應的稀有度（非azuki本身攜帶，而是opensea整合計算的）。

源碼解讀：你買的NFT到底是什麼？

1.1 資產在標準ERC721協議裡是什麼？

而咱們回顧到源代碼（此處取ERC721標準庫openzepplin代碼），會發現程序記錄了全局性的兩個字典類型的變量，通過_owners中用數字映射地址的方式記錄每一個ID 當前對應的所有者，同時也附帶用_balances 記錄了當前所有者總計持有的NFT數量

mapping(uint256 => address) private _owners; mapping(address => uint256) private _balances;

並且由於ERC721創新性的賦予了一個ID對應地址的變量_owners，從而與ERC20僅_balances 進行地址與餘額的管理，區分出了FT（同質化）與NFT（非同質化）的差別。

2.Mint和safeMint的差別

2.1 Mint是如何進行的

Mint 意思為鑄造，即每個NFT的創造過程，例如之前的

爱死机NFT 《当奈飞的NFT忘记了web2的业务安全》

Mint 獲取到該NFT的資產證明。

從源代碼中可以看到，Mint 主要是進行了安全判斷：

  • 判斷1：確保轉入的不是0x00地址（黑洞地址無法轉出，轉入則資產損失）
  • 判斷2：確保此交易所操作的NFTID是不存在的

最終代碼執行的操作是：

  • 操作1：將轉入地址的_balances 所持有總數加1

  • 操作2：將對應 NFTID 的所有者修改為轉入的地址

  • 操作3：完成交易則發出emit 事件，可以讓鏈下監聽到這次交易的數據

/** * @dev Mints `tokenId` and transfers it to `to`. * Emits a {Transfer} 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); }

中間有_beforeTokenTransfer和_afterTokenTransfer 屬於虛函數，作為標準，是讓項目方可以再不修改標準協議的情況下增加一些特定的邏輯代碼用的。

2.2 為何safeMint更安全

safeMint 意為安全的鑄造，從代碼實現中可以看到他本身也是調用了MInt 但是他額外增加了_checkOnERC721Received 的判斷，這點是屬於ERC165的標準，相當於在完成轉入操作後，則判斷對方地址，是否是黑洞地址（即無法發起交易NFT操作的地址）是防止轉入對象為合約地址時候，其合約沒有預設置好轉出的函數，導致資產在內無法被轉走，從而造成永久損失。

 /** * @dev Same as {xref-ERC721-_safeMint-address-uint256-}[`_safeMint`], with an additional `data` parameter which is * forwarded in {IERC721Receiver-onERC721Received} to contract recipients. */ function _safeMint(address to,uint256 tokenId,bytes memory _data) internal virtual { _mint(to, tokenId); require( _checkOnERC721Received(address(0), to, tokenId, _data), "ERC721: transfer to non ERC721Receiver implementer" ); }

2.3 ERC165是如何防止資產轉入黑洞的？

設計初衷可見： https://eips.ethereum.org/EIPS/eip-165

是讓合約接口標準化的提案，在編程語法中interface 是接口的意思，在其中定義的函數可以不實現僅僅放上函數名字相關參數，在程序複雜的時候，相當於目錄一般告訴別人我都有什麼功能。

但是接口的寫法各有千秋，名字定義參數類型，甚至是否存在都有不同，

所以此提案最終形成了ERC165標準，規範了接口的識別規則。

 interface ERC165 { /// @notice 查询合约所实现的接口/// @param interfaceID 参数：接口ID /// @return true 如果函数实现了interfaceID (interfaceID 不为0xffffffff )返回true, 否则为false function supportsInterface(bytes4 interfaceID) external view returns (bool); }

使用流程是：

STEP 1判斷是否存在 supportsInterface 函數，並且其符合165標準

STEP 2通過 supportsInterface 函數，判斷是否具有轉出NFT的函數

（PS：讓合約具備NFT接收轉出功能，可通過引入 IERC721Receiver.sol 拓展包來實現）

3.交易時會發生什麼？有哪些細節？

標準協議設計有兩種轉移方式，transfer 和 transferFrom，作用於兩種場景：

  • transfer 轉移：由用戶調用，將本消息發送的錢包所持有的NFTID轉移到指定地址

  • transferFrom 從轉移：用某機構調用，需要用戶先授權某地址，讓其有權可轉移。

類比一下：

  • transfer 就是現金交易，從自己口袋裡拿錢支付

  • transferFrom 就是掃碼扣款，由店家申請扣款，受制於用戶是否開通小額代扣權限

接下來咱們從代碼來看看，其中可能有會意想不到的細節。

3.1 transfer 是如何進行的

他會檢測當前交易的from 方是否是此NFTID的持有者，並且限制該NFT轉入0x00地址。其次進行from 轉出地址和to 轉入地址的餘額刷新，修改_balances全局變量並且重新設置_owners此NFTID的所有者地址修改為to。

這裡有個防護的細節會先執行_approve(address(0), tokenId); 清空歷史授權，如果沒有這一步，則資產完成了轉移，但是其NFTID的轉移授權依舊在，細思極恐：

 function _transfer(address from,address to,uint256 tokenId) internal virtual { require(ERC721.ownerOf(tokenId) == from, "ERC721: transfer from incorrect owner"); require(to != address(0), "ERC721: transfer to the zero address"); _beforeTokenTransfer(from, to, tokenId); _approve(address(0), tokenId);// Clear approvals from the previous owner _balances[from] -= 1; _balances[to] += 1; _owners[tokenId] = to; emit Transfer(from, to, tokenId); _afterTokenTransfer(from, to, tokenId); }

3.2 transferFrom是如何進行的

這裡的交易本質調用的是_safeTransfer 所以他的核心邏輯是require 部分，

這的一大細節是：_msgSender() 這是openzepplin的標準庫Context.sol 中的方法。

其實就是獲取當前交易的發送者地址，但這裡使用了封裝版本，而不是直接使用msg.sender

是考慮到，可能存在一種交易類型“元交易” ，即交易的付費gas方和交易發起方不相同的情況。

所以一些處於中間環節的，類似library的合約需要考慮這種特殊情況。

其餘部分判斷是確定是否有授權記錄，易於理解，不作贅述

function safeTransferFrom(address from,address to,uint256 tokenId,bytes memory _data) public virtual override { require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721: transfer caller is not owner nor approved"); _safeTransfer(from, to, tokenId, _data);}

4.還有哪些數據可擴展存儲在鏈上？

交易的環節也看完後，其實很多新同學也頓感奇怪，原來我買的NFT只有一個ID的歸屬地址指向了我，從而達成了唯一性。那就算如此，稀有度信息放在哪裡？我的NFT圖像本身在那裡？

這就是涉及到ERC721的元數據拓展IERC721Metadata.sol

要放什麼都可以，但是項目方往往在鏈上只存儲最基礎的ID+ IPFS的地址。

咱們可以通過之前Etherscan教程方法來看看一些項目數據有什麼？

Azuki上合約地址是：0xed5af388653567af2f388e6224dc7c4b3241c544

通過Read Contract可以查閱到，其元數據只存放了ipfs上的指向地址

而近期興起的Metaverse項目元宇宙土地sandbox和**** Decentraland ，以及去年火熱的**** Axie Infinity ，基本鏈上存儲元數據也只是ID+網址。

源碼解讀：你買的NFT到底是什麼？

像mirror那些是專門設計低費用可進行高存儲，一個塊常規都是30M起步，大約是以太坊的1000倍。

5.以太坊上存儲有多貴？

這裡是本文稍難的地方。咱們從源碼來分析鏈上存儲的成本構成以及金額換算

成本產生將有2個方面，按執行流程來看

  • 用戶發起一筆交易，將要寫鏈上數據作為參數傳入，其大小是一筆成本

  • 交易執行合約代碼，依據修改和使用，EVM計算消耗的gas成本。

5.1 交易發起的成本

咱們可以核對下以太坊黃皮書，裡對交易數據大小所消耗gas有清晰的定義

源碼解讀：你買的NFT到底是什麼？

可以看到交易所附帶的參數的價格：

  • 每筆交易都有21000 GAS需要支付

  • 為交易的每個非零字節數據或代碼支付68 GAS

  • 為交易的每個零字節數據或代碼支付4 GAS

所以如果是再 Mint 的時候，登記上若干NFT屬性信息，交易的data部分會將abc等字符轉成2個十六進製表示，而每個字符為一個八位二進制，等於一個byte。所以可以約等於將data的長度除以2作為byte數。

而1kb的數據，如果都是非0的有信息量的文本信息，則等於增加是68*1000=6.8W 的gas消耗。按20gwei的gas價格和2000的eth兌換美元價格，可以估算出，每上鍊1kb數據在交易發起端就要：

20*(21000+68000)*1e9/1e18 * 2000 = 3.5美金

5.2合約存儲的成本

由於交易發起後，還有智能合約上存儲的邏輯，咱們從以太坊go源代碼中（EIP1283），來分析具體的消費量，代碼具體在函數內，太長了不全粘來：

func gasSStore(evm *EVM, contract *Contract, stack *Stack, mem *Memory, memorySize uint64)(uint64, error)

歷史上GAS消耗的估算有經過若干迭代，如果是Petersburg或者Constantinople 未激活的話，則不按下面邏輯進行計算

gas消耗計算，依賴3個種數據的管理形式（增刪改）

  • 從零值地址到非零值（NEW VALUE），每個存儲槽需消耗2Wgas

  • 從非零值地址到零值地址（DELETE），每個存儲槽需消耗5Kgas，但會有獎勵1.5W gas退回

  • 從非零到非零（CHANGE），每個存儲槽需消耗200 gas

注意，上述每一個存儲槽算32byte，1kb存儲則是32個存儲槽。 Mint 的過程是新增存儲，所以如果新增1kb的數據存儲在鏈上代價將是64Wgas，換算成金額則是：

20*(640000)*1e9/1e18 * 2000 = 25 美金

真可謂寸土寸金！