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


這次我們來說說關於 MetaMask 的簽名問題。

所謂簽名，就是用你保存在 MetaMask 中的 Private Key 去對某樣東西做簽署，從而認證「你就是你」，這和我們日常生活中簽署文件類似。

MetaMask 在不消耗 Gas Fee 的情況下（即簽名資料不上鏈），也是可以進行簽名認證的，這種簽名多用於網站登入，或者 Gasless MetaTransaction 等。例如 OpenSea 登入，會要求你對一段信息進行簽名認證，簽名後會得到一個 Hash，伺服器則可以根據這個 Hash 和你的 Public Key 即錢包地址去驗證這段 hash 是否由你簽署，從而完成「你就是你」的身分驗證。

目前 MataMask 提供的簽名方法大致有三種，不同的方式有不同的應用場景。

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

#### Personal Sign

Personal Sign 可以用於簽署一段 UTF-8 編碼的文字，因此可以清楚顯示被簽名的內容，這種方式常見於網站登入。

#### eth_sign

eth_sign _是早期的簽名方法，這個方法必須傳入一個 32 byte 的 message hash 以供簽名，message hash 可以是任何內容的 hash，因此，僅憑 message hash，簽名者不會知道自己正在簽署什麼內容，可能是一個交易資料，又或者其它任何內容，因此有潛在的被釣魚的風險，現在 MetaMask 已經開始對這類的簽名請求彈出紅色警告。

#### EIP712 Sign

EIP712 簽名是一種更安全的簽名標準，是根據 EIP712 標準為 signature 加入了如domain，contract address 等資訊，從而提高簽名的安全性。

EIP712 簽名標準規定了簽名數據的結構，也加入了對數據的作用域限制，如 domain，verify contract address 等。這個標準的好處是，簽名者可以清楚看到自己在簽署的內容，很大程度上降低被釣魚的風險。

ERC712 簽名經常會被用在執行 metatransaction 等合約執行中，例如 OpenSea NFT 上架，降低價格等過程都會出現 EIP712 簽名請求。

我為三種簽名都做了[一個示例](https://codesandbox.io/s/xpmnzc?file=/src/App.js)，有興趣的讀者可以[去看看原始碼](https://codesandbox.io/s/xpmnzc?file=/src/App.js)，親自嘗試一下。

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



MetaMask 都有哪幾種簽名方式？ 每種方式有什麼不同？為什麼有時候會出現紅色警告？這次我們來說說關於 MetaMask 的簽名問題。

MetaMask 簽名出現紅色警告？


最近 STEPN 是好火爆呀，本人也沒有忍住嘗試了一下，感覺不錯。這篇文章基於自己的實際經驗，以問答形式列出一些大家都會有的疑問，以及新手可能遇到的問題（也是我自己遇到的問題），希望能讓大家對這個遊戲有一個大概的了解。**我寫這篇文章，絕對不是要給讀者任何玩或不玩的建議**，而只是把我常聽到的問題總結寫下來，給大家一些資訊的呈現，方便大家自行評估， Do Your Own Research 決定要不要試試看。建議先看看本文最後一個部分：風險 中的描述。


### STEPN 是什麼

STEPN 是一個運動 App， 和我們平時使用的 Runkeeper， Keep 等運動 app 類似，能夠在跑步的時候記錄運動軌跡，速度等等參數。而它和其它 app 的不同之處在於，STEPN 是一個 Move to Earn 的運動 App，透過運動，玩家可以獲得「GST」代幣，這個代幣可以在兌換成真正的金錢。

### 需要預先投入嗎，要投入多少

要。App 可以免費使用，也可以用來記錄跑步，但是如果不投入的話沒有辦法獲得收益。

遊戲裡面有「鞋子」的東西需要購買，「鞋子」有不同的款式，適用不同的場景。按照撰文當天來看，目前最低價格的跑鞋需要 12.5 Sol，兌換成美金大約 1,200 美金左右。

### 能有多少收益

收益的多少和「鞋子」的品類，級別，屬性息息相關。無法一概而論。普通「慢跑鞋」，在升級到 6 級左右(一天一升級的話需要 5 天時間)，按照目前 GST 價格計算 （GST上面說過是遊戲中獎勵的代幣，好像其它遊戲中的寶石一樣），每天會有大約 30 美金的收入。

### 回本要多久

因為收益的多少和「鞋子」的品類，級別，屬性息息相關。「鞋子」級別越高，屬性越好，收益會越多。另外因為遊戲中獲得的是 GST 代幣，它的市場價格也會波動，所以這裡面有很多不穩定因素（風險）。我們假設 GST 價格維持在 4.5 USD 左右， 每天都出去跑步，回本大約一個多月左右。

不過要留意，所謂回本，是指獲得的收益能夠抵消購買「鞋子」的支出。因為「鞋子」本身可以隨時在市場中出售（官方會收取 6% 的交易手續費），而且目前來看「鞋子」的價格一直在上升。 再加上因為我們會升級自己的「鞋子」，而級別越高的「鞋子」，價格也會更高。所以如果你決定放棄遊戲離場，賣出「鞋子」的話，也是可以將之前的投入拿回來的（如果「鞋子」價格不下跌的話）。

### 如何開始

首先要下載 STEPN App，然後註冊一個賬戶。之後就是要有一個「邀請碼」來激活，這個下面會講。激活之後就可以使用 App 了。 

進入 App 之後需要初始化錢包，**這個步驟至關重要，涉及到錢包的密碼等安全操作，一定要謹慎操作**。這個網路上有很多教學我這裡就不再贅述。錢包設定好後就可以在商店內挑選一對心儀的「鞋子」，然後就可以出去跑步喇。

### 如何獲得 Activation Code

官方為了限制人數，引入了「激活碼」機制。老用戶每消耗 10 點能量會得到一個「激活碼」。可以向老用戶索取，或者到遊戲的官方 Discord， Tg 群組內征求。 大家都很樂意分享。

### 如何買鞋

在遊戲內有跑鞋商城，可以在商城內直接購買。

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

### 鞋子有什麼分類，每種鞋子有什麼不同？

這個問題很重要。遊戲中的這個主要道具其實頗為複雜。

鞋子分為四種，**「步行鞋」**，**「慢跑鞋」**，**「快跑鞋」**，**「全能鞋」**。每種鞋子都有不同的適用速度，**超出或者低於適用速度，不能獲得遊戲代幣**。

顧名思義，「步行鞋」適合走路適用，適用速度 1-6 km/h。 「慢跑鞋」適合快步走或者慢跑，適用速度 4-10 km/h。 「快跑鞋」適合快跑，適用速度 8-20 km/h。而「全能鞋」則全場景通用，適用速度 1-20 km/h，當然他的價格會最貴。

![](/image/blog/9qmcu.png)

而同種類的鞋子也有稀有度之分，分別是**普通**，**罕見**，**稀有**，**史詩**，**傳奇**。稀有度和鞋子的初始能力點數，能量上限，寶石插槽稀有度的差異，「mint」出的鞋子稀有度，升級的點數等直接相關。

另外，每雙鞋都有**「效率」、「運氣」、「舒適」**與**「彈性」**這四種屬性，屬性的不同，也直接導致價格的不同。

#### Efficiency 效率
效率和 GST 收入直接相關，效率值越高，在相同能量下獲得的 GST 會越多。

#### Luck 運氣
這個屬性個人覺得初級玩家不需要太在意。運氣會影響神秘盒空投的頻率和內容。神秘盒會含有寶石等物件，可以用來升級鞋子的屬性。

#### Comfort 舒適
舒適屬性個人覺得初級玩家也不需要太在意，根據官方介紹這個屬性會與 GMT 代幣的收入有關。

#### Resilience彈性
這個屬性和鞋子修復直接相關。每次跑步後鞋子都會有一定的耗損，當耗損度超過鞋子的 50% 時會影響收益。因此，及時修復鞋子也非常重要。彈性屬性值越高，鞋子每次的耗損就越少，修復成本也越低。

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

### 不想玩了，鞋子可以賣出嗎？

可以，在 App 內的商城可以直接賣出鞋子。

### 收益的途徑有哪些？

收益的話我自己覺得至少有三種方式。

**第一種當然是乖乖跑步**，獲得收益。大概的收益上面已經提到過。

**第二種方式是炒賣鞋子**，低買高賣，俗稱「flip」。根據我的觀察因為不斷有人入場，鞋子的價格目前呈現上升趨勢，就算買了鞋子什麼都不做，待其價格上升後再出售也會有收益。

**第三種方式是炒賣鞋子的加強版**，因為鞋子可以升級以增加技能點數，升級後的鞋子價格也會隨之上漲。看下面的例子，同是 Jogger，0級，6級，10級對應的價格分別是 13， 18， 24 Sol，可見如果將鞋子從 0 升到 6級再出售，獲得的差價已經去到 5 sol，即 500 USD。 而升級的成本，從 0 到 6 需要 26 GST，按照當前價格折算約 115 USD。 而這些 GST 完全可以靠跑步獲得，無需額外投入。

![](/image/blog/2k3nv.png)

**第四種方式是鞋子工廠**，因為兩對鞋子可以「mint」出一對新的鞋子，儘管 mint 鞋需要消耗大量 GST，但換算回來還是比直接購買要低很多。因此不斷「mint」新鞋再拿去市場出售也是一個好方法。

但是要留意每「mint」一次鞋，鞋子的「mint」數會增加 1 ，每一對鞋最多只能「mint」7 次，而且每次索要消耗的成本會顯著增加。

### 鞋子升級以及升級成本是多少？

鞋子升級需要花費 GST 和時間成本，具體可以參考下表。

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

### 「能量」的概念

「能量」是遊戲中的一個重要數值。 「能量」的多少直接決定你有多少時間可以獲取收益。跑步的時候，每 1 分鐘會消耗 0.2 能量，也就是說每一個能量點數，可以有 5 分鐘的時間可以獲取收益。 **能量消耗殆盡後，不會獲得任何收益**。

按照香港時間，每天的 3 點，9 點，15 點，21 點會補充你所有能量的 25%，也就是說 24 小時後所有能量會加滿。

獲取更多能量可以靠買更多的鞋子來獲得，但鞋子數量和能量增長並不是線性關係。1 對鞋和 2 對鞋，能量數都是 2 點，3 對鞋能量數會增加到 4 點，再往上就要 9 對鞋，能量數會增加到 9 點。

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


###  GST / GMT 有什麼分別

GST 是遊戲內無限發行的主要功能代幣，也是我們跑步後會收到的獎勵。 GST 類似普通遊戲中的寶石，可以用來升級鞋子，修復鞋子，加速升級， 「mint」新鞋子等操作。

GMT 是遊戲的治理代幣，有發行上限，按照概念理解會和遊戲的發展有關，例如可以參與投票等。 GMT 在某些高等級的操作也需要使用，例如高等級的寶石合成，高等級的升級等。

### GST 的消耗途徑

上面說過，GST 可以用來升級鞋子，修復鞋子，加速升級「mint」新鞋子等操作。

### 沒有鞋子怎麼辦

沒有鞋子依然可以使用 App 記錄運動，只是沒有收益。 日後遊戲亦會推出鞋子租賃的功能，租賃者和放租者共享收益。

### 鞋子產生鞋子

當鞋子升級到 5 級時會解鎖「mint」功能，可以使用兩對鞋子來產生一對新的鞋子。這個過程需要花費 GST 或者 GMT。 每對鞋子最多只能「mint」 7 次，而且隨著「mint」數的增加，所花費的成本會顯著增加。

兩對鞋子所產生的「後代」的稀有度，也和這兩對鞋子的稀有度直接相關。 
- 普通鞋和普通鞋配對，後代 100% 是普通鞋。 
- 普通鞋和罕見鞋配對，出現普通和罕見鞋的幾率大約各自50%，並有極少數 1% 的機會會出現稀有鞋。
- 其它稀有等級配對以此類推。

### 風險

（這裡的風險，我們排除一些極端情況，例如錢包被駭客入侵，跑步的時候不慎造成健康傷害等）

首先入場這個遊戲是需要投入的，而且還不少。

最壞的情況就是遊戲突然「跑路」，你的投入完全清零。

然後就是遊戲內代幣 GST 的價格大幅下降。這個隨著 GST 的產出增多，如果遊戲項目方沒有好的方式去消耗 GST，那麼這個情況有大概率會發生。結合之前 Axie Infinity 的經驗，類似的遊戲代幣 SLP 價格從高峰的 0.35 跌落到現在的 0.01 ，下跌了 35 倍。

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

而再看 STEPN GST 價格，由發行到現在接近 5 個月時間，價格暫時是波動上升中，但這個趨勢能維持多久實在不好說。最近這幾天 GST 的價格也有明顯的波動。

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

對於 STEPN 的經濟模式，需要不斷有新用戶入場才能得以持續。一旦沒有了新用戶，鞋子的需求降低，直接會導致鞋子價格下降。但另一方面，隨著越多人加入， GST 的產出也會越快，GST 的價格亦會隨之下降。雖然相較 Axie Infinity， STEPN 中的 GST 多了很多消耗的方式，但消耗和產出能否平衡這個目前還不好說。


### 我自己的想法

目前來看我對這個遊戲的看法還是相當正面的。拋開每日的收益不說，僅僅是因為這個 App 提供了強大的動力促使我能夠堅持每天跑步，這個轉變對我來說已經彌足珍貴。我本來算是喜歡跑步，但遠沒有能夠達到每天跑的程度。跑步所帶來的的健康上的收穫，相比金錢上的收益來的更加珍貴。

至於投入的成本，目前的入場費大約一台 MacBook 的價格。但因為風險是可以預見的。最壞的情況不外乎全數歸零，這個要看自己是否能夠承受。

最後，嘗試任何新事物之前一定要做好功課，切忌盲目跟風。特別是自己不了解的範疇。參與這個遊戲，需要一定的區塊鏈知識，這個也不是每個人都適合的。**我寫這篇文章，絕對不是要給讀者任何玩或不玩的建議**，而只是把我常聽到的問題總結寫下來，給大家一些資訊的呈現，方便大家自行評估。











最近 STEPN 是好火爆呀，本人也沒有忍住入場嘗試了一下，感覺不錯。這篇文章基於自己的實際經驗，以問答形式列出一些大家都會有的疑問，以及新手可能遇到的問題（也是我自己遇到的問題），希望能讓大家對這個遊戲有一個大概的了解。

STEPN 邊跑邊賺 問與答



首先看看我做的[這個 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 的技術八卦


再見 Codi ， 永遠愛你。

文字無法表達現在的心情。 過去14年，你給我們帶來了太多的歡樂。

再見， Codi。 你會永遠永遠活在我們心中。

![](/image/blog/p78ya.jpg)


文字無法表達現在的心情。 過去14年，你給我們帶來了太多的歡樂。

再見 Codi ， 永遠愛你。



有人說以太坊的 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。 不需要寫代碼哦。

MetaMask 簽名出現紅色警告？

STEPN 邊跑邊賺問與答

教你製作完全 On-Chain 的 NFT

聊一聊 Zombie Club NFT 的技術八卦

再見 Codi ，永遠愛你。

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

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

2 分鐘建立你自己的 ERC20 Token

MetaMask 簽名出現紅色警告？

STEPN 邊跑邊賺 問與答

教你製作完全 On-Chain 的 NFT

聊一聊 Zombie Club NFT 的技術八卦

再見 Codi ， 永遠愛你。

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

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

2 分鐘建立你自己的 ERC20 Token

免費訂閱網誌文章

STEPN 邊跑邊賺問與答

再見 Codi ，永遠愛你。