Chris Impey is a writer based in New York City. He's interested in all things tech, science, and photography related, and likes to yo-yo in his free time.


Follow him [on Twitter](https://twitter.com/chris-impey).

Chris Impey

Emma Hazel is a writer based in New York City. He's interested in all things tech, science, and photography related, and likes to yo-yo in his free time.


Follow him [on Twitter](https://twitter.com/emma-hazel).

Emma Hazel

Frank, 居住在香港, 從事 IT 行業，並為這個行業投身了大半生的精力。 沒事喜歡寫寫程式，看看書，玩 Instagram，玩貓。可他並不是一個『宅男』，他很喜歡旅行，遠的去過約旦，近的去過深水埗，每到一個地方，都讓他對這個世界有不同的認識。他也很喜歡寫網誌，認為寫作不僅能夠加深對知識的積累和認知，亦能夠讓人靜下心，坦誠面對自己。

Frank

Thomas Macaulay is a writer based in New York City. He's interested in all things tech, science, and photography related, and likes to yo-yo in his free time.


Follow him [on Twitter](https://twitter.com/thomas-macaulay).

Thomas Macaulay



首先看看我做的[這個 demo](https://testnets.opensea.io/collection/onchainnft-demo): [https://testnets.opensea.io/collection/onchainnft-demo](https://testnets.opensea.io/collection/onchainnft-demo)

![](/image/blog/5qqss.png)

這些 NFT 的特別之處在於，每個 NFT 的圖案都不一樣（ ID 不一樣），所有 NFT 的資料都是保存在區塊鏈上，沒有用到任何的伺服器或者 IPFS。 

我在[製作 ERC721 智能合約那篇文章](https://www.frank.hk/blog/nft-smart-contract)中說過，NFT 之所以會顯示圖案，是因為根據 NFT 的標準，每一個 NFT 都有一個 json 格式的 metadata 與之對應， metadata 中有一個參數是指定 NFT 的圖案，所以只要訪問這個 NFT 的 metadata，然後再得到圖像地址，就可以顯示出 NFT 的圖案了。

![](/image/blog/oxypa.png)

一般的 NFT，metadata 和 NFT 的圖案都是保存在非區塊鏈上，例如伺服器，或者是去中心化的 IPFS。這樣做其中有一個問題就是有可能會導致資料遺失。中心化伺服器自然不用多說，而即便是 IPFS 也是不能保證資料永遠在線（如果對 IPFS 有興趣，可以參考我之前寫的 [IPFS 問與答](https://www.frank.hk/blog/ipfs-q-and-a)）。如果所有資料都保存在區塊鏈上，則能夠完美解決這個問題。但是，在區塊鏈上保存大量數據非常昂貴，所以想要這樣做，必須盡量減少儲存的數據量，那我們今天就來看看可以怎麼做。

首先我們不可能將所有 NFT 的圖案都「原封不動」的保存在區塊鏈，這樣成本太高。如果有辦法能「即時產生」圖案，則可以大大降低成本。這時我們想到了 SVG 圖案檔。SVG 的本質其實就是一段文字，因此我們可以根據一定的要求隨時「拼湊」出來。

查看 [OpenSea  metadata 的標準](https://docs.opensea.io/docs/metadata-standards)，除了 `image` 欄位，還有一個 `image_data` 可供使用，這個`image_data` 則為我們「即時產生」圖案提供了可能性。

![](/image/blog/gooaq.png)

既然 NFT 的圖案可以做到「即時產生」，那純文字的 NFT  metadata 更不在話下，我們也可以按照這個思路，讓 `tokenURI()` 直接返回 NFT 的 metadata JSON， 而不是一個 http 或 ipfs 連接。

好了廢話不多說我們看看程式怎麼寫吧。  

`tokenURI()`  我們做如下處理，拼湊出符合要求的 metadata JSON ，用 Base64 編碼之後直接返回。 注意對 `string` 進行拼接需要用到 `abi.encodePacked` ， Base64 編碼使用到一個公用 library，文後會給出源碼。 

```Solidity
function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721)
        returns (string memory)
    {
        require(
            _exists(tokenId),
            "ERC721Metadata: URI query for nonexistent token"
        );
        
        string memory json = Base64.encode(
            bytes(
                string(
                    abi.encodePacked(
                        '{"name": "On Chain NFT #',
                        uint2str(tokenId),
                        '",',
                        '"image_data": "',
                        onChainSVG.getSvgImage(tokenId),
                        '"',
                        "}"
                    )
                )
            )
        );
        return string(abi.encodePacked("data:application/json;base64,", json));
    }
```

留意到上面拼接 json 時有一句 `onChainSVG.getSvgImage(tokenId)`  這個 function 的作用是根據傳入的 tokenId ，即時「產生」一個 SVG 數據。**產生 SVG 的邏輯我們調用了另外一個智能合約進行處理，而不是寫在同一個智能合約中。 原因是根據 2016 年實施的 EIP-170 標準，每張智能合約的大小不能夠超過 24.576 kb。所以如果寫在同一張智能合約中會導致智能合約超出要求而無法發佈。**

合約部署後，調用 `tokenURI()` 我們會看到合約直接給出了 metadata 的完整 JSON (Base64 編碼)
 ![](/image/blog/iloveyou.png)

如果想測試一下的話，可以到 etherscan 上，連接錢包（Rinkeby 測試網路），調用 mint function mint 一個 NFT 給你自己哦。 

![](/image/blog/ikw6g.png) 



兩張智能合約的原始碼:<br/>
[https://gitlab.com/0x0016/smart-contract-demo/-/tree/main/contracts/nft](https://gitlab.com/0x0016/smart-contract-demo/-/tree/main/contracts/nft)

OpenSea:<br/>
[https://testnets.opensea.io/collection/onchainnft-demo](https://testnets.opensea.io/collection/onchainnft-demo?search%5BsortAscending%5D=true&search%5BsortBy%5D=CREATED_DATE)

EtherScan:<br/>
[https://rinkeby.etherscan.io/address/0x5b97a3663d6a9be5ef6a21fb2108b93f93f8b2e5#writeContract](https://rinkeby.etherscan.io/address/0x5b97a3663d6a9be5ef6a21fb2108b93f93f8b2e5#writeContract)


這篇文章探討下怎樣製作連圖案都完全保存在區塊鏈的 NFT，沒有伺服器，沒有 IPFS，一切 On Chain！

教你製作完全 On-Chain 的 NFT 



[Zombie Club NFT](https://zombieclub.io/) 最近可謂紅的不得了。這個有潮流明星余文樂站台的項目一開始就引人關注。技術上個人感覺項目的技術處理還是很不錯的，白名單，公售都基本順暢，對於其智能合約的處理網路上已經有了很多技術分析文，這裡就不贅述。 

寫這篇文章的初衷，是因為昨天晚上聽了他們團隊的一個技術 AMA，聽到了來自官方團隊對技術上的一些分析和解釋。兩個多小時的 AMA，在最後的聽眾問答環節被推上高潮， 過程有聽眾對於智能合約的處理發出了質疑，問答的重點是關於公售時期幾百筆 out of gas 的原因追問。官方也花了很長時間解釋。但坦白講對於官方的回答有些地方我也不是十分認同。我也多次想發言可惜一直沒有被選中（事實上只有三個人被選中發言）。 星期日沒什麼事那這裡我們就來聊一聊這個 out of gas 是怎麼個回事。

![](/image/blog/ieeh5.png)

在討論關鍵問題之前，首先我們要理解幾個概念， **Gas Limit**，** Max Priority Fee** 和  **Max Fee**。

![](/image/blog/fmkxf.png)

### Gas Limit 

Gas Limit 指的是你最多允許這個交易消耗**多少單位**的 Gas。 注意這裡指的是 Gas 單位，**不涉及到金錢**。用平民化的例子來說，比如我要從元朗開車到中環，Gas Limit  就是指我允許這個旅程最多消耗多少升汽油。一般而言，傳入相同參數的智能合約 function 調用，如果智能合約中沒有特別的邏輯(下面會講)，其消耗的 gas 應該基本固定，這也是 metamask 進行 gas 預估的原理。用上面汽車的例子，同一架汽車從元朗開車到中環，行駛相同的路徑，每次消耗的汽油應該基本固定。

### Max Priority Fee

首先有個 「Fee」 字的都是和錢相關的概念。這個數值和最後我們支付的 gas fee 息息相關。 Max Priority Fee 是 [EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) 升級後新出的概念。 原本劃一收費的 gas price 現在會分為兩個部分， 一個是 **Base Fee**（基礎費用），這個費用可以理解為海鮮價，整個以太坊網路會根據網路繁忙程度自動計算，不可更改， 每個區塊內的所有交易 Base Fee 都相同。另一個是 **Priority Fee**（礦工小費）， 這個數字用戶可以自行設定，直接支付給礦工作為小費。Priority Fee 設置越高，該筆交易則會擁有越高的優先級，更快完成。**這個 Priority Fee 也是在 NFT 限量搶購等需要「鬥快」的交易中充當重要角色的參數**。同樣用汽車的例子，Priority Fee 可以理解為，想象有一堆人在加油站等待加油出發，而加油站的汽油卻有限，你願意為每升汽油多花多少錢給小費，給的小費越多，你便可以越快的速度被服務，加滿油開始你的旅程。

### Max Fee

Max Fee 和Max Priority Fee 一樣，都是關於「錢」的概念。 Max Fee 的概念是指你願意為每一單位的 Gas 支付的最大費用。 **Max Fee 必須大於或者等於 Base Fee + Max Priority Fee** 。看到這裡，不知大家會不會有疑問， 為什麼會有 Max Fee 的存在？ 直接 Base Fee + Priority Fee 不就好了？ 其實仔細想想就會知道， Max Fee 的存在是為了保障我們對交易的費用控制， 上面說了 Base Fee 是會網路狀況變動的「海鮮價」，如果沒有 Max Fee 的控制則可能會導致當網路突然異常繁忙時的 Gas 失控。

對於 Max Fee 的估算，EIP-1559 也給出了建議：

```Solidity
Max Fee = (2 * Base Fee) + Max Priority Fee
```

之所以會乘 2 是為了防止 Base Fee 在下一個 Block 增加而導致費用不足而交易失敗， 根據EIP-1559 對於 Base Fee 的約定， Base Fee 乘 2  可以保證在連續 6 個滿載區塊的情況下你的交易都可以順利執行。**絕大多數情況下， 真正的 Gas 消耗要比 Max Fee 少。**

了解了上面的概念後，我們就可以聊聊 Zombie Club NFT 公售時的這個小插曲了。 公售開始時[有大量的 Trx 出現 out of gas 的錯誤](https://etherscan.io/tx/0x6e82115917a4450dd280dbb6e83111480762824adb57201868c3db1397b7157a)。所謂 out of gas，就是指整個交易已經用盡了 Gas Limit  中指定的上限，因此礦工會放棄執行餘下的工作，該筆交易會立即失敗，並且因為礦工已經耗費了算力，因此消耗掉的 Gas 不會退回（但是交易中夾帶的 ETH 會返還）。所以說，**即便你的 Priority Fee 給的再高， 但只要 Gas Limit 設置的不夠，則最終依然會失敗，而且損失的錢會比因為  Priority Fee 不夠而最後失敗的那些交易還要多很多**。就好像[這個交易](https://etherscan.io/tx/0xafa6f551a1ce1e939d914960791828b2e69c26135e2d634e8bfa54a2f439d7a6)，Priority 已經設置到驚人的 11,111 Gwei，可惜還是因為 Gas Limit 不夠，而導致最終失敗。

我們可以發現， 出現 out of gas 的錯誤，集中發生在 1440443， 1440444， 1440445 這幾個區塊，也就是公售剛開始的前後幾個區塊中。昨晚官方 AMA 中的解釋，這是因為 Metamask 錯誤的估算了 Gas Limit 導致，可能是 Metamask 版本太舊，可能是用了其它的錢包等原因導致。 


### Gas 估算

**好了，那問題來了。 MetaMask 是怎麼估算 Gas Limit 的呢？**

如果做過 ethereum 區塊鏈開發的人大概都知道， 在 web3 等常用的工具中都有 `estimateGas` 這個 function，estimateGas 估算 gas 用量的方法是使用完全相同的參數，模擬真實情況透過 RPC 調用智能合約的 function，然整個交易模擬執行一次，從而計算出整個調用所需要的 Gas 用量。這個模擬調用，不會提交到區塊鏈，因此不會真正被礦工記錄，不會真正消耗 gas，但這個模擬調用，卻能夠較為精準的估算 Gas 用量，也可以發現可能遇到的錯誤。這也是有時候我們會見到 MetaMask 告訴我們 「This trx is expected to fail」的原因。

**那為什麼 MetaMask 會估算錯誤呢？**

首先上面講到， MetaMask 對 gas 的估算是傳入相同的參數，模擬執行智能合約，從而得出 Gas 用量。因此，如果智能合約的處理不當，在傳入相同參數的情況下兩次執行會出現不同的程式邏輯，則會導致估算的結果和實際的 gas 用量不符的情況。

舉個例子，假如智能合約使用 block number 或者 block timestamp 來決定執行邏輯，例如，如果區塊時間 > 22:00:00 則進行 public mint， 如果區塊時間 < 22:00:00 則進行 whitelist mint， 這裡因為區塊時間是一個變量，即便傳入的參數一樣，因為區塊時間的不同，因此會導致智能合約運行的邏輯不一樣，因此導致所謂「Gas 估算錯誤」。

再比如，如果調用的 function 中含有 for loop， 即便傳入的參數一樣，但 for loop 因為某些原因提早或延遲終止，也會導致 Gas 的消耗出現明顯差異。

回到 Zombie Club 的 Case， AMA 中官方有說明，智能合約中的確運用了 Block Timestamp 來進行某些邏輯判斷，如果我沒有理解錯就是根據 Block Timestamp 來區分目前是白名單 mint 還是公售 mint。而公售 mint 因為某些原因需要記錄 signature 而導致消耗的 gas 比白名單要多。所以不難想象出現 「Gas 估算錯誤」的原因就是 MetaMask 估算時，因為 timestamp 的不同而用白名單 mint 的邏輯進行了估算，但實際執行時卻是使用了 public mint 的邏輯，因此導致實際 gas 消耗要比估算高。


### Zombie Club的做法有問題嗎

不能說有問題，但我覺得應該有更好的處理方式。

首先，官方說他們的前端沒有去建議 Gas Limit，而是將之交給用戶去設定。作為一個源碼沒有公開的智能合約，作為用戶其實是沒有可能能夠預測 gas 的用量，更何況是在秒殺那種分秒必爭的情況下。因此說交給用戶去設定 gas limit，這個說法多少有點勉強。我覺得對於 mint 這種邏輯簡單的 function，前端網頁其實應該給出 gas limit 而不是靠 metamask 去估算。昨天的 AMA 中官方有提到這個問題，他們的說法是希望將這個控制權交給用戶去決定，就好像設置 Gas Price 一樣，而不是由官方決定。對於這個觀點，我持有保留態度。 gas limit，不同於 gas fee，只要合約沒有類似 for loop 等的會嚴重影響 gas 用量的不確定因素，每次合約調用的用量基本都是固定的，完全可以通過在測試網測試等方法提早得知。 網頁前端在提交 trx 給 metamask 時，完全可以根據測試網的 gas 用量， 再加上一個足夠的 buffer，例如測試得出的 gas 用量是 21,000， 那麼可以建議 gas limit 是 21,000+(21,000 x 0.5) = 31,500 ， 提交給 metamask，這樣基本可以避免出現 out of gas 的問題。 

另外就是官方有提到智能合約會根據 block timestamp 去決定當前是公售還是白名單， 這樣做的原因是為了「更加去中心化」，防止被懷疑「官方作弊」。 對於這個觀點我也持保留態度。首先對於 block timestamp 這個全局變量，solidity 社區應該都有共識，不應該用它來參與一些重要的邏輯，因為礦工對於這個參數有一定的控制力。如果一定要在智能合約中加入一個標記來決定，那也完全可以透過一個參數，例如 state = 1 是白名單， state = 2 是公開發售來控制。 再者，在 Zombie Club NFT 這個例子中，官方引入了中心化伺服器 API 簽名認證（這個做法本身非常棒），但這已經和官方「更加去中心化」的說法有違背。 既然有了 API 的簽名參與，整個邏輯已經完全可以由 API 控制，那麼加入 block timestamp 的驗證則顯得畫蛇添足，也因此導致了 metamask 的估算錯誤，出現幾百個 out of gas 的問題。


### 結語

這次的 out of gas，嚴格來講並不能說是完全是官方的責任，究其原因的確是因為 block timestamp 導致 MetaMask 對 gas limit 的估算錯誤，儘管這個問題開發者如果再考慮仔細一點本來應該是可以避免。作為開發者我想我們在設計程式的時候應該要考慮到區塊鏈上的不確定性，特別是對於 block timestamp 這類變量的控制。而作為參與者或許也應該在 MataMask 做出的 Gas Limit 估計上再增加一定的額外額度。 畢竟，秒殺這種東西，本來就風險很高，更何況當時的 NFT 存量只有少得可憐的 1000 多個，既然願意參與，那麼應該也要知道可能發生的風險。

我本人覺得 Zombie Club NFT 這個項目是一個非常棒和有潛力的項目。不難看出，項目方為了它花費了大量心血。技術上，智能合約對於 gas 的用量控制，以及機器人的防範，都做的非常好。儘管公開發售出現了 out of gas 的問題算是有點不完美。 一個項目的成功與否，技術是基石，但團隊後續的態度，對項目的經營，社區的維護和發展，對項目的成敗會更為重要。從項目的 discord 社群很容易能夠看出，社群裡面的參與者們，非常積極的出謀獻策，參與討論，這在其他的項目中是很少見的。 

衷心希望這個項目能夠成為藍籌之一。 







Zombie Club NFT 最近可謂紅的不得了。這個有潮流明星余文樂站台的項目一開始就引人關注。寫這篇文章的初衷，是因為昨天晚上聽了官方團隊的一個技術 AMA，聽到了來自官方對技術上的一些分析和解釋。兩個多小時的 AMA，在最後的聽眾問答環節被推上高潮， 過程有聽眾對於智能合約的處理發出了質疑，問答的重點是關於公售時期幾百筆 out of gas 的原因追問。官方也花了很長時間解釋。但坦白講對於官方的回答有些地方我也不是十分認同。 星期日沒什麼事那這裡我們就來聊一聊這個 out of gas 是怎麼個回事。

聊一聊 Zombie Club NFT 的技術八卦



有人說以太坊的 gas fee， 動輒幾十，幾百美金，這似乎是一道避不過的坑。 參與 NFT 的鑄造亦是如此，mint 一個 NFT，少說也要幾十美金上下，如果一次 mint 多過一個 NFT，gas 的消耗更是成倍上漲。

目前流通中的 NFT 項目，大多數都是基於 [OpenZeppelin](https://openzeppelin.com/) 的 ERC721 實現版本來進行。 稍微解釋一下， ERC721 是[一個標準](https://eips.ethereum.org/EIPS/eip-721)，這個標準規定了作為一個 ERC721 的智能合約必須做到什麼事情。 實現這個標準有很多不同的做法(implementation)， 只要智能合約能夠滿足ERC721的標準要求，則被視為是一個有效的 ERC721 智能合約。而 [OpenZeppelin](https://openzeppelin.com/) 的 ERC721 實現，則是目前市面上最廣為使用的一個 ERC721 實現。

因此， [OpenZeppelin](https://openzeppelin.com/) 的 ERC721 實現，當然不是 ERC721 的唯一做法，你，我，都可以自己去實現 ERC721 標準。 今天要介紹的 ERC721a，就是一個新的 ERC721 實現，對比 [OpenZeppelin](https://openzeppelin.com/) 的 ERC721 實現， 其 mint NFT 特別是 mint 多個 NFT 所需要的 gas 成倍減少。

ERC721a 實現是由 [Azuki](https://www.azuki.com/erc721a) 研發的新的 ERC721 實現。這個 ERC721a，已經運用到了他們發行的 [Azuki NFT Collection](https://opensea.io/collection/azuki) 中。根據他們的[網站介紹](https://www.azuki.com/erc721a)，鑄造一個 NFT 所消耗的 gas fee，相比 OZ ERC721，節省了一倍還多，如果是一次鑄造 5 個，節省的 gas 甚至達到 7 倍。

![](/image/blog/vv9ft.png)

換算成美金，鑄造一個 NFT 節省 $82 美金，鑄造 5 個則節省驚人的 $650 美金。

![](/image/blog/mhcrw.png)

光看沒用，自己實際測試一下才可以。 我對比 OZ ERC721 和 Azuki ERC721a 做了實際測試，結果如下：

**鑄造1個 NFT：**

ERC721 Gas 消耗: 229,528
[https://rinkeby.etherscan.io/tx/0xe8f0ee22f0d1f027f7c9a11db5088fe91c1ab63b0d2bb25694901e5175b96d12](https://rinkeby.etherscan.io/tx/0xe8f0ee22f0d1f027f7c9a11db5088fe91c1ab63b0d2bb25694901e5175b96d12)

ERC721A Gas 消耗: 156,382
[https://rinkeby.etherscan.io/tx/0xa8062804800150b03ba1172ceee64d4b3d6da9720f254d595a67bfdac6752aab](https://rinkeby.etherscan.io/tx/0xa8062804800150b03ba1172ceee64d4b3d6da9720f254d595a67bfdac6752aab)

**鑄造4個 NFT：**

721 Gas 消耗: 559,900
[https://rinkeby.etherscan.io/tx/0x7db57fd064723326140558dfa84757535c309e9576965db132a6d0d19cd85ef9](https://rinkeby.etherscan.io/tx/0x7db57fd064723326140558dfa84757535c309e9576965db132a6d0d19cd85ef9)

721A Gas 消耗: 126,906
[https://rinkeby.etherscan.io/tx/0x3013fb6ba02c86086e27a2f167ce56ed87fc6cde97b8b304f9e73ac9e225e729](https://rinkeby.etherscan.io/tx/0x3013fb6ba02c86086e27a2f167ce56ed87fc6cde97b8b304f9e73ac9e225e729)

明顯見到， ERC721a 在 gas 的用量上明顯節省很多。

### Why

Gas 節省這麼多，Why？ 

這裡要再說說另外一個接口 **ERC721Enumerable**。 為了讓我們能夠更容易的讀取 ERC721 NFT 智能合約關於發行總量，持有者等情況，大多數 NFT 智能合約都會實現另外一個標準，即 ERC721Enumerable，這個標準要求智能合約提供以下功能：

```js
totalSupply(): 該函數返回合約發行的未銷毀的 NFT 總數。此外，每個 token 都需要有一個不是 address(0) 的有效持有者地址。
tokenByIndex(): 該函數返回指定位置的 NFT 的 tokenId。
tokenOfOwnerByIndex(): 該函數返回指定的地址所擁有的 NFT token 中特定索引位置的 NFT 的 tokenId。
```

上面的解釋聽起來比較拗口，簡單講就是要求智能合約需要保存總共發行了多少 NFT，發行的次序，多少沒有被銷毀，持有者的情況等等。聽起來比較簡單，但深入想想，若是要實現這些功能則需要數據存儲，而在區塊鏈上存儲數據則需要花費金錢，這也是為什麼鑄造一個 NFT 需要花費大量 gas 的原因之一。

#### ERC721a 做了什麼優化？

**首先 ERC721a 對 ERC721Enumerable 中的實現做了優化，去除了一些不必要的存儲。**

我們看看 `totalSupply()` 這個例子：

OZ  ERC721Enumerable: 
```solidity
// Array with all token ids, used for enumeration
uint256[] private _allTokens;

/**
  * @dev See {IERC721Enumerable-totalSupply}.
  */
function totalSupply() public view virtual override returns (uint256) {
   return _allTokens.length;
}
```

Azuki ERC721a:
```solidity
uint256 private currentIndex = 0;

/**
  * @dev See {IERC721Enumerable-totalSupply}.
  */
function totalSupply() public view override returns (uint256) {
    return currentIndex;
}
```

可以看到相比 OZ ERC721Enumerable，  Azuki ERC721a 沒有使用昂貴的 array 存儲空間來保存 allTokens， 而是直接用 `currentIndex` 來返回（之所以能這樣做是因為 Azuki ERC721a 的所有 tokenID 都是從 0 開始，逐個增長）。

**然後，對於 mint function，Azuki ERC721a 也做了優化。**

OZ ERC721 的實現中並沒有提供批量鑄造的功能，換句話說如果我們要鑄造4個 NFT，那就必須循環調用 mint 4 次。因此這也就是為什麼 OZ ERC721 智能合約一次性鑄造 N 個 NFT 的 gas 消耗會隨著 N 的增加而成比例增加的原因。

對於這個問題， Azuki ERC721a 做出了優化，`_safeMint` 提供了 `quantity` 參數， 因此我們要鑄造多個 NFT，只需要傳入需要鑄造的數量，一次調用就可以完成。 

```solidity
function _safeMint(address to, uint256 quantity) internal {
    _safeMint(to, quantity, "");
}
```

不要小看這個參數的加入， 假設小明要鑄造 4 個 NFT， 如果用 OZ 的實現，我們要循環調用 `_safeMint` 4 次， 而每次 `_safeMint` 都會去更新小明擁有的 NFT 總數，當前總共發行的 NFT 總數等資料。所以為了把小明擁有的 NFT 總數從 0 變到4，OZ ERC721 會循環四次， 從 0 增加到 1， 再從 1 增加到2， 然後從2 增加到3，最後從 3 增加到 4。  而每次區塊鏈資料的更新，必然需要消耗 gas。 而 Azuki ERC721a ，則是直接將小明擁有的 NFT 總數從 0 變到4，這樣只需更新區塊鏈一次，即可達到效果，節省了3次不必要的更新。

```solidity
function _safeMint(
    address to,
    uint256 quantity,
    bytes memory _data
) internal {
    uint256 startTokenId = currentIndex;
    
    ...

    AddressData memory addressData = _addressData[to];
    _addressData[to] = AddressData(
        addressData.balance + uint128(quantity),
        addressData.numberMinted + uint128(quantity)
    );
    _ownerships[startTokenId] = TokenOwnership(to, uint64(block.timestamp));

    uint256 updatedIndex = startTokenId;

    for (uint256 i = 0; i < quantity; i++) {
        emit Transfer(address(0), to, updatedIndex);
        require(
            _checkOnERC721Received(address(0), to, updatedIndex, _data),
            "ERC721A: transfer to non ERC721Receiver implementer"
        );
        updatedIndex++;
    }

    currentIndex = updatedIndex;
    _afterTokenTransfers(address(0), to, startTokenId, quantity);
}
```

**最後，對於 `ownerOf()` 這個 function，Azuki ERC721a 也做了優化。 **

假設小明鑄造了 4 個 NFT，然後小強又鑄造了 4 個 NFT，OZ 的 ERC721 會將 8 個 NFT 每一個都標記各自的持有者，也就是會存儲 8 個持有者資料。 而 Azuki ERC721a ，只會在第一個 NFT 標記持有者為小明，第五個 NFT 標記持有者為小強。而其餘的 NFT 則不標記。這樣就可以節約大量的存儲空間。

那我們怎麼知道中間的沒有標記持有者的 NFT 是屬於誰？ 

其實不難，因為 tokenId 是連續增長，所以只要找到比這個 tokenId 小的最接近持有者，即可以認為該持有者亦擁有當前的 NFT。

### 問題

總體來說，經過多次測試，我覺得 Azuki ERC721a 的確可以節省大量的 gas 成本，特別是一次過鑄造多個 NFT ，其花費的 gas 和鑄造一個 NFT 相差不大。

然而 Azuki ERC721a 也不是沒有問題。

因為 Azuki ERC721a 中的主要邏輯都和 tokenId 必須要保持連續為基礎，所以目前的 Azuki ERC721a 並沒有提供 burn token 的功能。所以如果要使用類似銷毀 NFT 的功能，Azuki ERC721a 則不適用。 而且，如果你需要 NFT tokenId 不是連續增長，Azuki ERC721a 也不適用。

另外，偶然還發現 Azuki ERC721a 部署到 polygon mainnet 中後，如果一次過鑄造超過 4 個NFT，則該組 NFT 在 OpenSea 上無法看到（在 polygon scan 上看到智能合約的執行完全正常， 所有NFT，持有者資料都正確無誤）。 

例如 [這個 #16 號 NFT](https://opensea.io/assets/matic/0x4e6cc29436ceb11411202440f4e8aee482e8840a/16)， 在 OpenSea 上顯示 Not Found， 而這個 [\#22 號 NFT](https://opensea.io/assets/matic/0x4e6cc29436ceb11411202440f4e8aee482e8840a/22)，則可以正常顯示。因為我一次過鑄造了 14-18 號 NFT，超過了 4 個， 因此 14-18 號 NFT 都無法正常顯示， 而 19-22 號 NFT 則因為沒有超過 4 個，則可以正常顯示。** 奇怪的是，同樣的智能合約部署在 Rinkeby 測試網則完全沒有問題**， 所以我也不清楚究竟是 OpenSea 的問題還是 Polygon 的問題。

關於這個問題我已經聯絡了官方開發者，等待他們的回覆中。








鑄造以太坊的 NFT，動輒幾十，幾百美金。這是作為官方或者用家都不願意看到的。然而最近出了一個新的 ERC721 實現 (ERC721a)，能夠成倍節省 gas fee，特別是當鑄造多個 NFT 的時候，消耗的 gas fee 和鑄造一個 NFT 相若。這麼神奇？如何做到？想用，有沒有什麼問題？這篇文章就來分析一下。

大量節省 Gas Fee 的 ERC721A NFT 智能合約



這篇文章假設大家使用 [hardhat](https://hardhat.org/) 來進行智能合約開發。關於 hardhat 我有時間再詳細寫一寫懶人教學 😅。



大家如果常去 Etherscan 上查看智能合約 Smart Contract， 大概會看到兩種情況，第一種是如下這樣，在 Contract 下面看到是一堆「亂碼」，這堆「亂碼」其實是編譯過後的智能合約 ByteCode （字節碼），這明顯不是給人類閱讀的。

![](/image/blog/1mgva.png)

另一種則是如下圖所示，在 Contract Tab 旁邊能夠看到一個綠色的✓，下面能夠看到智能合約的原始代碼，並且可以直接在 Etherscan 上讀取，調用智能合約的 function。

![](/image/blog/riwuc.png)

明顯第二種合約給人的感覺會自信很多， 因為所有人都能夠清楚看到智能合約具體的運行邏輯，一切公開透明，不怕「黑箱作業」。

#### 那麼如何做到在 Etherscan 上「開放原始碼」呢？

一種方法是手動在 Etherscan 上提交原始碼，透過提交智能合約的地址，選擇編譯器版本，上載智能合約的原始碼等等一系列步驟之後便可以做到。

![](/image/blog/wfvhd.png)
![](/image/blog/bkzwe.png)

但這種方法的壞處是非常麻煩，要確保選對編譯器版本，上載所有需要上載的檔案，包括一些第三方的 library。一旦上載的原始碼檔案出現錯漏，則無法完成認證。 

有沒有更好的方法呢？

#### 隆重介紹  @nomiclabs/hardhat-etherscan 

使用 @nomiclabs/hardhat-etherscan  這個 npm package，能夠超級簡單的完成智能合約認證。這個 package 集成了 Etherscan 的 API，透過 API 的形式自動完成原始碼認證，免去了繁瑣的手動步驟。

### 第一步

首先我們需要在 Etherscan 上有一個賬戶，然後免費申請一個 API key。 [按此前往](https://etherscan.io/myapikey)。

![](/image/blog/8d80c.png)

在上述頁面中按下「ADD」即可申請一個全新的 API Key。得到這個 API Key 之後，將它放入你的 .env 檔案中。（假設你用 .env 檔案來保存環境變數）

```js
API_URL = xxx
PUBLIC_KEY = xxx
PRIVATE_KEY = xxx
ETHERSCAN_API_KEY = 這裡填上你上面得到的 API Key 
```

### 第二步

安裝  `@nomiclabs/hardhat-etherscan`‌ ， 使用 npm 或者 yarn 的方式安裝。這個應該不用多說了吧，是人都會了。

```bash
yarn add @nomiclabs/hardhat-etherscan‌ -D
```

### 第三步

現在我們需要設定 `hardhat.config.js` 。

首先，要在 `hardhat.config.js` 頂部引入這個 package 

```js
require("@nomiclabs/hardhat-etherscan");‌
```

然後，在 `hardhat.config.js` 添加如下設定：

```js
module.exports = {
  solidity: "0.8.4",
  networks: {
    rinkeby: { xxx }, // xxx 是省略的意思哦，你應該不會照抄吧 😒
  },
  etherscan: {
    // 下面這個就是 Etherscan 的 API Key 哦 
    // 和上面第一步中 .env 檔案中的對應
    apiKey: process.env.ETHERSCAN_API_KEY
 }
};
```

### 第四步

在完成智能合約編譯後，透過以下指令即可驗證智能合約原始碼：

```bash
npx hardhat verify --network rinkeby <你的已發佈智能合約地址>
```

舉例：

```bash
frank@MacBook demo % hh compile
Compiling 1 files with 0.8.4
Compilation finished successfully


frank@MacBook demo % npx hardhat run --network rinkeby scripts/DeployDemo.js                     
Deploying demo contract ... 
Waiting for 2 confirmations...
Contract deployed to:  0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88


frank@MacBook demo % npx hardhat verify --network rinkeby 0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88
Nothing to compile
Compiling 1 file with 0.8.4
Successfully submitted source code for contract
contracts/Demo.sol:Demo at 0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88
for verification on Etherscan. Waiting for verification result...

Successfully verified contract Demo on Etherscan.
https://rinkeby.etherscan.io/address/0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88#code


```

至此，打開 [Etherscan](https://rinkeby.etherscan.io/address/0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88#code) ，就可以看到我們的智能合約已經認證成功啦。


DeployDemo.js 參考：

```js

const { ethers } = require("hardhat")

async function main() {

  console.info(`Deploying demo contract ... `)
  const Demo = await ethers.getContractFactory("Demo");
  const demo = await Demo.deploy();
  
  console.info(`Waiting for 2 confirmations...`)
  let transcation = demo.deployTransaction
  const receipt = await transcation.wait(2)
  const { gasUsed } = receipt
  console.log("Contract deployed to: ", demo.address);
  console.info(`Gas used           : ${gasUsed} `)

}

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


```


大家如果常去 Etherscan 上查看智能合約 Smart Contract， 有些智能合約會看到一堆「亂碼」，而有些智能合約則會看到很漂亮的原始碼，並且能夠直接在 Etherscan 上和智能合約交互。明顯第二種開放原始碼的智能合約給人的感覺會自信很多，那究竟怎樣才能完成原始碼認證呢？

在 Etherscan 上提交智能合約原始碼認證




不是標題黨哦，真的只要兩分鐘就可以發行你自己的 ERC20 Token。 

ERC20 Token，就是和 USDT，USDC 一樣的基於以太坊的一種代幣。任何人都可以在以太坊，或者是基於以太坊的區塊鏈上建立 ERC20 代幣。

### 構建 ERC20 智能合約
首先，我們使用 [OpenZeppelin 提供的在線工具](https://wizard.openzeppelin.com/)來輕鬆構建 ERC20 智能合約。前往 [https://wizard.openzeppelin.com/](https://wizard.openzeppelin.com/)：

![](/image/blog/srchc.png)
  
左上角選擇「ERC20」， 然後在 Name， Symbol，Premint 等輸入框內填上你自己 Token 的資料。
  
**Name**： Token 的名稱；
**Symbol**： Token 的符號；
**Premint**： 預先挖掘的數量， 這個數目的 Token 在智能合約發佈的時候會自動挖出，並且發送給部署智能合約的賬戶。

選中 Feature 中的選框後，會為智能合約添加對應的功能，例如 Mintable 可以允許 Token 在合約發佈之後可以再繼續發行，而不是固定的發行數量。這些功能在旁邊的小問號有詳細的解釋，這裡就不再贅述。


### 使用 Remix 發佈你的 ERC20 Token 到區塊鏈上

在設定好你的 ERC20 智能合約之後，就可以準備發佈到區塊鏈上了。

![](/image/blog/ueklo.png)

按下右上角的 「Open in Remix」， 就可以神奇的打開 Remix 在線 IDE。

![](/image/blog/erzhl.png)

Remix 打開之後你的智能合約已經在裡面了。

第一步，切換到 Deploy 窗口(上圖 1 所示按鈕 )；
第二步，選擇發佈的環境，如果要發佈到公共區塊鏈上，我們選擇「Injected Web 3」，這會要求你連接 MetaMask，根據你 MetaMask 所選擇的網路(Mainnet, Testnet， BSC 等等)，會發佈到對應的區塊鏈上。
第三步，在 「Contract」 中選擇當前畫面顯示的智能合約，我上面的例子就是 FrankToken 這個智能合約。
第四步，按下「Deploy」按鈕，這時會彈出 MetaMask 讓你簽名部署智能合約。

![](/image/blog/qeclm.png)

確認無誤後，按下 「Confirm」，稍作等待，就可以看到我們的 ERC20 Token 已經成功建立了。

![](/image/blog/e06fk.png)

### 在 MetaMask 中添加新建立的 Token

MetaMask 預設不會顯示自定義 Token，要想讓我們的 token 在 MetaMask 中顯示，我們需要講 Token 添加到 MetaMask 中。 

首先我們找到剛才部署的 ERC20 智能合約的地址。這個地址在 Remix ， 以及 MetaMask 的交易記錄中都可以找到。 然後，在 MetaMask 中的 Asset 畫面，最底部有一個 Import Token，按下之後，輸入剛才的合約地址，即可。 具體可參考下面的影片：


<div class="video-container" style={{paddingTop: "58%"}}>
<iframe
  src="https://player.cloudinary.com/embed/?cloud_name=dxuoive6n&public_id=Blog/import-token&fluid=true&controls=true&source_types%5B0%5D=mp4"
  allow="autoplay; fullscreen; encrypted-media; picture-in-picture"
  allowfullscreen
  frameborder="0"
></iframe>
</div>


大功告成，就是這麼簡單哦。








不是標題黨哦，真的只要兩分鐘就可以發行你自己的 ERC20 Token。 不需要寫代碼哦。

2 分鐘建立你自己的 ERC20 Token



如果玩過 NFT，相信你對「白名單」制度不會陌生。NFT公開發售之前，都會讓一小部分被授權的地址，可以提前購買。因為能夠保證取得購買資格，無需與其他人瘋搶，所以往往大家都非常想擠進這個白名單中去。

本文不討論 marketing 的策略，而是說說 NFT 智能合約如何更優雅的處理白名單。 

聰明的你肯定想到，可以用一個 mapping，來儲存所有 whitelist 的地址，當 presale 時檢查這個 mapping 中是否有這個地址即可。

```js
//SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.4;
import "@openzeppelin/contracts/access/Ownable.sol";

contract Whitelist is Ownable {
    mapping (address => bool) userAddr;

    function addToWhitelist (address[] calldata users) external onlyOwner {
        for (uint i = 0; i < users.length; i++) {
            userAddr[users[i]] = true;
        }
    }

    function preSale() external payable 
    {
        require(whiteList[msg.sender] == true, "STOP: not in whitelist");
        ...
    }

}
```

當然，這個方法絕對沒錯。很多 NFT 專案都是使用這個方法。 可是，這種的做法的一大問題就是成本太貴。 我做了[一個實驗](https://rinkeby.etherscan.io/tx/0xc1bf9bb1e6e9c055f9058c9e9a4a7f1e633d7d6e831f79c314640affda463b49)，假如按照 gas price 89 gwei 計算， 一次過儲存 1,000 個白名單地址，消耗 502,774 gwei gas， 需要支付 2.06 ETH，約合 67,885 港幣的費用。如果分開多次存儲，花費更高。

當然如果你「不差錢」，那麼就可以不要再看下去了。但如果不捨得這六萬元，我們可以看看有沒有更好的方法。

答案當然是有的。我們看看下面一段 solidity 程式：

```js
   function presale(
        bytes memory _ticket, // 伺服器發出的「票據」
        bytes memory _signature // 伺服器發出的「簽名」
    ) public payable {
         
        // 如果你想的話，我們可以在智能合約中檢查「票據」是否被使用過。
        require(!_ticketUsed[_ticket], "FRANK: ticket has already been used");

        // 驗證「票據」和「簽名」是否有效
        require(
            isAuthorized(
                msg.sender,
                _ticket,
                _signature,
                signerAddress
            ),
            "FRANK: ticket is invalid"
        );
    
        _mint();
    }
```

相信聰明的你看完後已經有點頭緒了。 這個做法就是引入了一個「票據」和「簽名」的概念。當用戶在你的網頁上 mint NFT 時，不僅僅是直接同智能合約互動，而是需要預先從 web 伺服器憑藉自己的地址，取得一個授權，這個授權包括一個「票據」和一個「簽名」。

從伺服器的角度來看，伺服器保管有一個簽名私鑰，可以根據用戶的地址，加上一個隨機生成的有意義或無意義數據，即「票據」，組合後進行數位簽署，從而得到一個「簽名」。

然後，用戶可以憑藉「票據」和「簽名」，向智能合約發起購買請求。當智能合約收到購買請求後，會對「票據」和「簽名」進行認證。

認證的步驟，我們會使用 solidity 的 ecrecover 方法。ecrecover 可以根據「簽名」，得出簽名者的公鑰地址。因此，在知道簽名者的公鑰地址的前提下，我們就可以透過核對這個地址，來判斷「簽名」是否由簽名者發出。

我們附帶一個「票據」，則某種程度上是為了防止「回放攻擊」( replay attack )。我們可以在智能合約中檢查該 「票據」是否已經被使用過，從而執行不同的邏輯。

```js
  function isAuthorized(
    address sender, // 發起 trx 人的地址；
    bytes memory ticket, // 伺服器發出的「票據」
    bytes memory signature, // 伺服器發出的「簽名」
    address signerAddress // 簽名人的地址
  ) private pure returns (bool) {
    bytes32 hash = keccak256(abi.encodePacked(sender, ticket));
    return signerAddress == hash.recover(signature);
  }
```

這種簽名認證的方法，好處非常明顯。我們完全不需要在智能合約中花費大量成本存儲任何白名單地址，就可以優雅的做到白名單效果，而且也可以隨時增加或減少白名單的數量。

不僅如此，使用這個方法，我們亦可以讓智能合約能夠輕易做到一些邏輯驗證。比如，一個購物的智能合約，需要驗證傳入的 ETH 是否和商品價格符合，一個做法是在智能合約中存儲一個商品ID和價格的列表，每當交易時進行比對。而使用簽名認證，則可以使用上述相同邏輯，透過傳入一個「簽名」，智能合約則可以驗證數據的真確性，而無需在智能合約中保存海量昂貴數據。





如果玩過 NFT，相信你對「白名單」制度不會陌生。NFT公開發售之前，都會讓一小部分被授權的地址，可以提前購買。可是作為智能合約開發者，你知不知道一次過儲存 1,000 個白名單地址， 竟然需要支付 2.06 ETH，約合 67,885 港幣的費用。那麼有沒有更優雅，更省錢，更靈活的白名單做法呢？進來看看吧。

如何更優雅的實現 NFT 智能合約的白名單功能






之前有寫過一篇文章教大家<Link href="/blog/nft-smart-contract">自己15分鐘寫 ERC721 智能合約</Link>，這篇文章則說一說 ERC721 的升級版，ERC1155 智能合約。建議大家先看看關於 <Link href="/blog/nft-smart-contract">ERC721</Link> 的那篇文章。

### ERC1155 和 ERC721 有什麼區別

開始介紹 ERC1155 智能合約的寫法之前，我覺得先要說說 ERC1155 和 ERC721 到底有什麼區別。
簡單來說，ERC1155 是 ERC721 的升級版，ERC1155 在 ERC721 的基礎上，主要增加或改善了如下功能：

- 同時支持可替換代幣(同質化代幣)和不可替換代幣(非同質化代幣)；
- 批量轉賬: 僅需要一次智能合約調用，就可以轉賬多種代幣資產；
- 批量查詢餘額：一次智能合約調用可以查詢多種代幣餘額資料；
- 批量授權：一次智能合約調用可以向指定地址授權多種代幣的使用權；

用再簡單一些的人話來講，就是一張 ERC1155 智能合約，裡面可以同時包含類似 USDT 這種代幣，和類似 [MekaVerse](https://opensea.io/collection/mekaverse) ，[無聊猿](https://opensea.io/collection/boredapeyachtclub)等這種獨一無二的 NFT 代幣。 另外，傳統的 ERC721 合約，如果要轉移 NFT，必須一個一個操作，沒有辦法做到批量轉賬。而 ERC1155，則宛如加入了類似「購物車」的概念，可以一堆代幣一次過轉移。不要小看這個「批量」功能，要知道每次和區塊鏈交互，都要消耗 gas，如果有某些應用場景需要大量，頻繁轉移資產，那 ERC1155 相比 ERC721 則能節約大量的 gas 成本。

我們可以試想一下，假如現在想要創作一款區塊鏈遊戲，裡面有類似 USDT 的可替換同質化代幣以進行金融操作，也需要有各種遊戲裝備，英雄角色等獨一無二不可替換代幣來進行遊戲，這兩種代幣也需要透過一定的機制進行交易互換，這個場景，使用 ERC1155 則可以完美實現。

我們不妨對比一下 ERC721 和 ERC1155 合約的規範接口：  
  
ERC721
```js

function balanceOf(address _owner) external view returns (uint256);
function ownerOf(uint256 _tokenId) external view returns (address);
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
function approve(address _approved, uint256 _tokenId) external payable;
function setApprovalForAll(address _operator, bool _approved) external;
function getApproved(uint256 _tokenId) external view returns (address);
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
```

ERC1155
```js
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;
function balanceOf(address _owner, uint256 _id) external view returns (uint256);
function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);
function setApprovalForAll(address _operator, bool _approved) external;
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
```

可以明顯看到，ERC1155 在原有 ERC721 基礎上增加了很多 batch 的接口。再看看 OpenZeppelin 中的 ERC1155 實現，其中的 mint function 增加了 `amount` 參數， 不難想象，如果 `amount = 1`， 則代表這個代幣總共只發行一個，那這個代幣就是類似 ERC721 的 NFT 了。 

```js
function _mint(
    address account,
    uint256 id,
    uint256 amount,
    bytes memory data
) internal virtual {
    require(account != address(0), "ERC1155: mint to the zero address");
    address operator = _msgSender();
    _beforeTokenTransfer(operator, address(0), account, _asSingletonArray(id), _asSingletonArray(amount), data);
    _balances[id][account] += amount;
    emit TransferSingle(operator, address(0), account, id, amount);
    _doSafeTransferAcceptanceCheck(operator, address(0), account, id, amount, data);
}
```

說完了基本概念，下面我們就來 get your hands dirty，親手嘗試一下寫一個 ERC1155 智能合約，你會發現，其實遠比你想象的簡單。
 

### 15分鐘快速建立 ERC1155 智能合約

#### OpenZeppelin 
我們這個示例，依舊使用 OpenZeppelin 的合約為範本。[OpenZeppelin](https://openzeppelin.com/) 是一個開源的智能合約倉庫，上面已經有許許多多各種各樣的智能合約範本，包括 ERC721，ERC1155 等智能合約。因此我們只需要基於 OpenZeppelin 的現有合約，擴展我們自己特定的功能即可。

#### 安裝 OpenZeppelin Contracts

確保已經安裝最新版的 NodeJS，運行下面的指令：

```bash
npm install @openzeppelin/contracts
```

之後在當前目錄下就會安裝好 OpenZeppelin Contracts 的檔案。

#### 使用 Remix IDE

[Remix](https://remix.ethereum.org/) 是 Ethereum 官方提供的 IDE 。包含完整的編譯器、執行合約、發布合約等等的功能。無須安裝，只要用瀏覽器開啟 [https://remix.ethereum.org/](https://remix.ethereum.org/) 即可。

Remix 默認情況下會將所有資料存儲在瀏覽器的 Local Storage 中，所以當你清除瀏覽器緩存快取，或者在另外一台電腦打開 Remix，你的資料便會丟失。 Remix 也提供了使用本地文件系統來進行存儲的功能，但需要安裝一個 remixd 本地程式，具體方法可以[參考這裡](https://remix-ide.readthedocs.io/en/latest/remixd.html)。

當你安裝好 remixd 後，便可以透過運行下面的指令來建立 Remix 和本地檔案的連結：

```bash
remixd -s <absolute-path-to-the-shared-folder> --remix-ide <your-remix-ide-URL-instance>
```

#### 撰寫智能合約

完成上面的步驟後，我們便可以開始建立自己的 ERC1155 合約了。

![](/image/blog/qy2tu.png)


```js
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC1155/presets/ERC1155PresetMinterPauser.sol";


contract Marvel1155 is ERC1155PresetMinterPauser {
    
    uint256 public constant CAPTAIN_AMERICA = 0;
    uint256 public constant THOR = 1;
    uint256 public constant IRON_MAN = 2;
    uint256 public constant SPIDER_MAN = 3;
    
    constructor() ERC1155PresetMinterPauser( "https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json") {
        _mint(msg.sender, CAPTAIN_AMERICA, 10**18, "");
        _mint(msg.sender, THOR, 1, "");
        _mint(msg.sender, IRON_MAN, 5, "");
        _mint(msg.sender, SPIDER_MAN, 10, "");
    }
    
}

```

以上的代碼便是利用 OpenZeppelin 的 ERC1155 合約建立，我們只需要非常簡單的幾行代碼，便可以完成一個 ERC1155 智能合約。

簡單解釋一下以上代碼的意思：  

```js
uint256 public constant CAPTAIN_AMERICA = 0;
uint256 public constant THOR = 1;
uint256 public constant IRON_MAN = 2;
uint256 public constant SPIDER_MAN = 3;
```

上面這段代碼，是定義了這個合約中有幾種「類型」的代幣。（當然，直接在 mint 的時候傳入自定義類型也是可以的😂)

```js
constructor() ERC1155PresetMinterPauser( "https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json") {
    _mint(msg.sender, CAPTAIN_AMERICA, 10**18, "");
    _mint(msg.sender, THOR, 1, "");
    _mint(msg.sender, IRON_MAN, 5, "");
    _mint(msg.sender, SPIDER_MAN, 10, "");
}
```

上面這段代碼，則是「構造器」，在智能合約發佈的時候會被調用，挖掘了4款不同的代幣，每個代幣的發行總量分別是 10 <sup>18</sup>，1，5，10。因此可以理解為，THOR 這個代幣，就是一個 NFT，而其他的代幣，則是類似 ERC20 的同質化代幣。

「構造器」中傳入的 `https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json` 是代幣對應的 URI，這個和 ERC721 的概念是一樣的，OpenSea， Rarible 等 NFT 市場，會訪問這個 URI，去取得代幣的 metadata，下面我們會再講到。


#### 編譯，發布智能合約

編輯完成後， 就可以切換到 Compile 面板進行編譯。留意要選擇正確的編譯器版本，編譯器版本要和你合約中聲明的版本相符合，否則無法編譯。

![](/image/blog/cjoqp.png)

編譯完成後，便可以準備發布（deploy）了。切換到 Deploy 面板。此時我們要在左上角的 Environment 中選擇【Injected Web 3】，此時便會彈出 MetaMask 進行連結。如果還沒有安裝 MetaMask，可以先在 [Chrome Web Store](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn) 中安裝。

我們開始嘗試時一般都會選擇在測試網路（testnet）中進行，測試網絡和 Ethereum 主網在技術上沒有區別，但在測試網路中不需要花費真實的 ETH ，而是使用測試網路中的 ETH。一般我們開發的 Blockchain 程式，都要先在測試網路上做全面測試，之後才在主網中上線。要知道 Ethereum 主網的 Gas Fee 可高的驚人。

Ethereum 的測試網路有很多，例如 Ropsten， Rinkeby，Goerli 等等。為了能在 OpenSea 上測試，我們選擇 Rinkeby 測試網路（OpenSea 的testnet 預設為 Rinkeby 測試網路）。

使用測試網路，記得要在 MetaMask 中選擇 Rinkeby Test Network。

![](/image/blog/dmybz.png)

在 Ethereum 網路上任何導致更改數據的動作都需要花費 ETH，因此發布智能合約自然需要 ETH。如果沒有 testnet 的 ETH 可以在網上找到很多 testnet faucet 可以免費獲得 testnet 的 ETH ，例如[這裡](https://faucet.rinkeby.io/)。一切就緒後，就可以按下 【Deploy】，開始發布你的智能合約，中間會彈出 MetaMask 進行付款確認。

發布完成後，Remix 會顯示對應的 Transaction Hash，例如我自己上面的例子，對應的 Transaction 可以在 [https://rinkeby.etherscan.io](https://rinkeby.etherscan.io) 上看到，裡面亦可以看到我們建立的 ERC1155 智能合約地址。

![](/image/blog/vnoyw.png)

因為我們的示例合約中在構造器( constructor ) 中已經 mint 了4 種代幣，因此當合約發佈後，[在 OpenSea 中已經可以即時看到](https://testnets.opensea.io/collection/unidentified-contract-73ffvqbzsk)。

![](/image/blog/rcv3n.png)

#### Mint NFT

回到 Remix，可以看到 Deployed Contracts 中已經有我們剛才發布的智能合約，點開他之後可以看到裡面有一個 mint 的 Function，現在我們就可以調用這個 Function 來 Mint NFT 了。這個 mint function 需要傳入四個參數，分別是`擁有者地址`，`token id`，`發行數量`和`附加數據`。附加數據在 ERC1155 規範中並沒有指定用途，因此這個參數可以根據自己的需要來傳遞任何數據，如果沒有的話傳遞空值即可。

![](/image/blog/5bytu.png)

![](/image/blog/kkkmu.png)

當 mint 完成後，稍等一段時間便可以在 [OpenSea 中看到對應的 NFT](https://testnets.opensea.io/collection/unidentified-contract-73ffvqbzsk) 已經誕生了！

![](/image/blog/jzair.png)
 
到這裡其實我們已經完成了一個最基本的 NFT 的建立。

如果你是照抄我上面的例子😏，你 mint 出的 NFT 應該已經有圖案，名稱了。但你可能會問假如我要改 token 的名稱，圖像，屬性要怎麼做呢？

原來 NFT 對應的圖像以及其他屬性是由 NFT 的 Metadata 決定，要想 NFT 在 OpenSea 等平台 中顯示圖像和其他屬性，還需要指定該 NFT 的 Metadata。

我上面的例子之所以會有圖像，因為  `https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json` 這個地址會對應傳入的 `token id` 返回該 token 的 metadata，  而裡面則包括了 token 的圖像，名稱，描述等資料。

#### ERC721 Metadata

根據 OpenSea 上的 [Metadata 標準](https://docs.opensea.io/docs/metadata-standards)，OpenSea 會調用我們智能合約中的 `uri`  function，並傳入 tokenID，而這個 function 需要返回一個 HTTP 或 IPFS URL，這個 URL 則必須返回一個 JSON 格式的數據，例如[我例子中的這個](https://api.frank.hk/api/nft/demo/1155/marvel/1.json)，而這個 JSON 則定義了我們 NFT 的各種屬性。

![](/image/blog/uiaaw.png)

![](/image/blog/df4uq.png)

用我們上面寫的智能合約為例，留意我們在 constructor 中有如下寫法：

```js
constructor() ERC1155PresetMinterPauser( "https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json") {
    ...
}
```

其中 `https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json` 便是指定了我們 token 的 URI，當調用 `uri`  function 時，我們的合約就會 return `https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json`。`{id}` 是一個「變數」， NFT 市場會將這個變數替換為對應的 token id 。

當這個 Metadata 設置好後，再 mint 出的 NFT 就會帶有圖像等屬性了。

![](/image/blog/nhhyf.png)


上面說過， ERC1155 和 ERC721 最大的不同，就是 ERC1155 可同時支援可替換代幣(同質化代幣)和不可替換代幣(非同質化代幣)，這點我們可以在 OpenSea 中清楚的看到。

![](/image/blog/zg8rf.png)

上面這個例子，因為 Iron Man 這個 token ， mint 時發行量輸入了 5 ， 而 Thor 這個 token 發行量僅為 1，所以我們看到 OpenSea 上的顯示會有不同。Thor 的顯示，則和 ERC721 的 NFT 類似。

在出售的時候，也會多出了數量選擇。

![](/image/blog/gatdv.png)


以上就是一個超級簡單的自己寫代碼製作 ERC1155 NFT 的教學了。如果有任何討論，或是錯誤指正，歡迎聯絡我不吝賜教。

感謝閱讀。



ERC1155 是 ERC721 的升級版，ERC721 和 ERC1155有什麼不同？如何用代碼快速寫一個屬於你自己的 ERC1155 NFT 智能合約並發佈到 OpenSea 上？進來看一看吧。

使用 Remix，OpenZeppelin 15 分鐘建立 NFT ERC 1155 智能合約



最近有留意一些 NFT 的項目專案，發現絕大多數都是採用了「盲盒模式」來玩，即購買的時候並不知道裡面是什麼，等到了一定的時間後，盲盒會開啟，才會知道你買的 NFT 具體的屬性，是否稀有等。

![MekaVerse 盲盒](/image/blog/xzyot.png)

這裏我們不討論 Marketing 的做法，純粹從技術角度探討一下「盲盒模式」要怎麼做到。

我<Link href="/blog/nft-smart-contract">之前寫過一篇文章</Link>講怎樣輕鬆編寫 ERC 721 智能合約，裡面有說過 NFT 在 OpenSea 等市場中顯示的名稱，圖像，屬性等資料，完全是由 NFT 的 metadata 決定，而 metadata 則是靠調用 NFT 智能合約中的 `tokenURI` function 而得到。因此，這個 metadata 並不是像大家想像的一樣不可更改，只要能夠讓智能合約返回不同的 `tokenURI`, 則在市場中顯示的圖像以及屬性就會隨之更改。

聰明的你可能想到，如果 `tokenURI` 是一個 http 連接，即 metadata 是存放在傳統伺服器中，則非常容易做到這個效果。只要修改伺服器程式，返回完全不同的 metadata 即可。沒錯，但如果 `tokenURI` 是一條 IPFS 連結，那要如何處理？ IPFS 不是不可更改嗎？ 哈哈，是的 IPFS 連結是不能更改，但是 `tokenURI` 可以呀。只要對智能合約的代碼做一點更改，便可以輕鬆做到效果。

我們的大概思路是，有一個開關參數控制盲盒開啟與否，如果 true，則 `tokenURI` 將返回一條盲盒專用的 metadata IPFS 連結，裡面的 name，image 等都是固定的名稱和圖像。另外我們還需要有兩個 function ，供授權的地址調用，一個用以改變上述開關參數的狀態，另一個用以設定盲盒開啟後新的 `baseURI`。等到開啟盲盒的神聖日子來臨，被授權的地址調用這兩個 function，即可揭開盲盒的神秘面紗。

(當然，聰明的你也應該想到，不使用開關參數，完全依靠更改`baseURI` 也是可以的。只是我覺得有個開關更容易操作一些)

以下是參考的代碼：

```bash
abstract contract BaseERC721BlindBox is BaseERC721 {
    using Strings for uint256;
    bool private _blindBoxOpened = false;
    string private _blindTokenURI =
        "ipfs://QmexqcLDvoP6HCTtSGumG3yzhZdH8guvV3z3kReCvf2QKn";

    function _isBlindBoxOpened() internal view returns (bool) {
        return _blindBoxOpened;
    }

    function setBlindBoxOpened(bool _status) public {
        require(
            hasRole(DEFAULT_ADMIN_ROLE, _msgSender()),
            "BaseERC721BlindBox: only admin can do this action"
        );
        _blindBoxOpened = _status;
    }

    // this function controls how the token URI is constructed
    function tokenURI(uint256 tokenId)
        public
        view
        virtual
        override
        returns (string memory)
    {
        require(
            _exists(tokenId),
            "ERC721Metadata: URI query for nonexistent token"
        );

        if (_blindBoxOpened) {
            string memory baseURI = _baseURI();
            return
                bytes(baseURI).length > 0
                    ? string(
                        abi.encodePacked(baseURI, tokenId.toString(), ".json")
                    )
                    : "";
        } else {
            return _blindTokenURI;
        }
    }
}
```

當盲盒沒有開啟時，進入 OpenSea 看到的會是[這樣](https://testnets.opensea.io/collection/cute-marvel-characters-v3)：
![](/image/blog/1wyst.png)

當盲盒開啟後，進入 OpenSea 看到的會是[這樣](https://testnets.opensea.io/collection/cute-marvel-characters-v4)：
![](/image/blog/gqqyq.png)


最近 NFT 很火爆，留意到絕大多數 NFT 項目專案都是採用了「盲盒模式」來玩，即購買的時候並不知道裡面是什麼，等到了一定的時間後，盲盒會開啟，才會知道你買的 NFT 具體的屬性，是否稀有等。本文純粹從技術角度探討一下「盲盒模式」要怎麼做到。