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



[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 上和智能合約交互。明顯第二種開放原始碼的智能合約給人的感覺會自信很多，那究竟怎樣才能完成原始碼認證呢？

聊一聊 Zombie Club NFT 的技術八卦

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

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

免費訂閱網誌文章