智能合約與 Solidity

Solidity 遵循一種稱為語意化版本的版本模型，版本號由三個以點分隔的數字組成：MAJOR.MINOR.PATCH。有重大且不向下相容的變更時，「主要」版本號就會遞增；在兩個主要版本之間加入向下相容的功能時，「次要」版本號會遞增；修正向下相容的錯誤時，「修補」版本號會遞增。

在撰寫本書時，Solidity 的版本是 0.8.26。主要版本 0 是專案的初期開發階段，規則不太一樣：任何東西都可能隨時改變。實務上，Solidity 把「次要」版本號當成主要版本，把「修補」版本號當成次要版本。因此，在 0.8.26 中，8 被視為主要版本，26 則是次要版本。你在第 2 章看過，Solidity 程式可以包含一個 pragma 指令，指定與程式相容、可以用來編譯合約的 Solidity 最低與最高版本。由於 Solidity 演進得很快，通常最好安裝最新的版本。

依照你的作業系統與需求，有好幾種方法可以下載並安裝 Solidity：下載二進位發行版，或從原始碼編譯。你可以在 Solidity 文件中找到詳細且最新的說明。

以下示範如何在 Ubuntu／Debian 作業系統上，使用 apt 套件管理工具安裝最新的 Solidity 二進位發行版：

安裝 solc 之後，執行下列指令確認版本：

雖然完全可以只用簡單的文字編輯器開發 Solidity 智能合約，但善用 Hardhat 或 Foundry 之類的開發框架，能大幅提升你身為開發者的效率與成效。這些框架提供了一整套工具，能簡化並改善開發流程。例如，它們提供完善的測試環境，讓你撰寫並執行單元測試，驗證合約的行為；它們也提供分叉功能，在本機建立主網的實例，模擬真實的測試情境。透過進階的除錯與追蹤功能，你可以輕鬆地逐步追蹤程式碼的執行，快速找出並解決問題，節省時間、減少錯誤。此外，這些框架還支援腳本與自動化部署、能擴充功能的外掛生態系，以及在不同環境之間無縫切換的網路管理。把這些功能整合進你的工作流程，就能確保更高的程式碼品質與安全性，這是只用簡單的文字編輯器很難達到的。

除了框架之外，採用 VS Code 這類現代的 IDE 也能進一步提升生產力。VS Code 提供各式各樣的 Solidity 擴充套件，包括讓程式碼更容易閱讀的語法突顯；幫助你組織與瀏覽複雜專案的進階註解與書籤工具；以及能讓你深入了解程式碼結構與潛在問題的視覺化分析工具。此外也有網頁版的開發環境，例如 Remix IDE。

這些工具結合起來，不僅能提升程式碼品質，也能加快開發流程，讓我們更快速、更安全地打造並部署智能合約。

我們在第 2 章寫了第一個 Solidity 程式。當時第一次建立 Faucet 合約時，我們用 Remix IDE 編譯並部署合約。本節會重新檢視 Faucet，並加以改善、充實。

我們第一次嘗試寫出的合約如範例 7-1 所示。

我們在第 2 章看過，註解中的 SPDX 授權識別碼表示這個智能合約採用 GPL-3.0 授權，告知使用者與開發者在使用與散布這份程式碼時的法律權利與義務。

現在，我們要在命令列上使用 Solidity 編譯器，直接編譯我們的合約。Solidity 編譯器 solc 提供了各種選項，傳入 --help 引數就能看到。

我們使用 solc 的 --bin 與 --optimize 引數，為範例合約產生最佳化的二進位檔：

solc 產生的結果是一段以十六進位序列化的二進位資料，可以提交到以太坊區塊鏈上。

首先，我們來看看 Solidity 提供的一些基本資料型別：

布林值（bool）

布林值，也就是 true 或 false，可以使用邏輯運算子 !（not）、&&（and）、||（or）、==（等於）與 !=（不等於）。

整數（int、uint）

有號（int）與無號（uint）整數，從 int8 到 uint256，以 8 位元為間隔宣告。沒有加上大小後綴時，會使用 256 位元的數值，以配合 EVM 的字組大小。

定點數（fixed、ufixed）

定點數，以 (u)fixedMxN 宣告，其中 M 是以位元為單位的大小（以 8 為間隔，最大 256），N 是小數點後的位數（最多 18 位），例如 ufixed32x2。

地址

20 位元組的以太坊地址。address 物件有許多實用的成員函式，主要的有 balance（回傳帳戶餘額）與 transfer（把以太幣轉到這個帳戶）。

位元組陣列（固定大小）

固定大小的位元組陣列，以 bytes1 到 bytes32 宣告。

位元組陣列（動態大小）

大小可變的位元組陣列，以 bytes 或 string 宣告。

列舉

使用者定義的型別，用來列舉離散的值：enum NAME {LABEL1, LABEL 2, ...}。列舉的底層型別是 uint8，因此成員不能超過 256 個，而且可以明確地轉換成所有整數型別。

陣列

任何型別的陣列，可以是固定大小或動態大小：uint32[][5] 是一個固定大小的陣列，包含五個動態陣列，每個動態陣列的元素都是無號整數。

結構

使用者定義的資料容器，用來把多個變數歸為一組：struct NAME {TYPE1 VARIABLE1; TYPE2 VARIABLE2; ...}。

mapping

由鍵 ⇒ 值配對構成的雜湊查詢表：mapping(KEY_TYPE ⇒ VALUE_TYPE) NAME。

除了這些資料型別之外，Solidity 也提供各種數值常值，可以用來計算不同的單位：

時間單位

全域變數 block.timestamp 表示區塊發布並加入區塊鏈的時間，以秒為單位，從 Unix epoch（1970 年 1 月 1 日）起算。seconds、minutes、hours 與 days 等單位可以作為後綴使用，換算成基本單位 seconds 的倍數。

以太幣單位

wei 與 ether 等單位可以作為後綴使用，換算成基本單位 wei 的倍數。以前還可以使用 finney 與 szabo 這兩種面額，但 Solidity 0.7.0 版已經移除了。

在我們的 Faucet 合約範例中，withdrawAmount 變數使用的是 uint（也就是 uint256 的別名）。我們也間接使用了一個 address 變數，並用 msg.sender 設定它的值。^[13]在本章其餘的範例中，我們會用到更多這類資料型別。

我們用其中一種單位乘數，來改善範例合約的可讀性。在 withdraw 函式中，我們限制了最大的提領金額，並以以太幣的基本單位 wei 來表示這個上限：

這不太容易閱讀。我們可以使用單位乘數 ether 來改善程式碼，改以以太幣而不是 wei 來表示這個值：

在 Solidity 中，定義變數與函式的語法和其他靜態型別語言類似：我們為每個變數指定型別、名稱，以及可選的初始值。對於狀態變數，我們還可以指定它們的可見性。預設的可見性是 internal，表示只有在合約本身及其衍生合約中才能存取這個變數。要讓其他智能合約也能存取，就必須使用 public 可見性。

Solidity 智能合約的變數有三種作用域：

狀態變數

狀態變數把值記錄在區塊鏈上，藉此在智能合約中儲存永久的資料，也就是所謂的持久狀態。狀態變數定義在智能合約之內、任何函式之外。例如：uint public count;

區域變數

區域變數是計算過程中使用的暫時資料，只會短暫地保存資訊。區域變數不會儲存在區塊鏈上；它們存在於函式之中，在定義它們的作用域之外無法存取。例如：uint count = 1;

全域變數

全域變數由 Solidity 自動提供，不需要明確宣告或匯入就能使用。它們提供區塊鏈環境的相關資訊，也包括可以在程式中使用的工具函式。下一節會完整列出所有預先定義的全域變數。

前面簡單提過，宣告狀態變數時可以指定它們的可見性。Solidity 提供三種不同的可見性層級：公開變數會自動產生 getter 函式，讓外部合約可以讀取它們的值，但不能修改；內部變數只能在合約本身及其衍生合約中存取；私有變數和內部變數類似，但連衍生合約也無法存取。

合約在 EVM 中執行時，可以存取一小組全域物件，包括 block、msg 與 tx 物件。此外，Solidity 也把一些 EVM 操作碼以預先定義的函式形式提供出來。本節要探討在 Solidity 智能合約中可以存取的變數與函式。

Solidity 最主要的資料型別是 contract；我們的 Faucet 範例就只是定義了一個 contract 物件。就像物件導向語言中的任何物件一樣，合約是一個包含資料與方法的容器。

Solidity 還提供了另外兩種與合約類似的物件型別：

interface

介面定義的結構和合約完全一樣，只是其中的函式都沒有定義，只有宣告。這種宣告通常稱為存根（stub）；它告訴你函式的引數與回傳型別，但沒有任何實作。介面規定了合約的「形狀」；當介面被繼承時，子合約必須定義介面所宣告的每一個函式。

library

函式庫合約是指只部署一次、供其他合約透過 delegatecall 方法使用的合約（見「地址物件」一節）。

我們在合約中定義可以被 EOA 交易或其他合約呼叫的函式。在 Faucet 範例中，我們有兩個函式：withdraw 與 receive。

在 Solidity 中宣告函式的語法如下：

我們逐一來看這些組成部分：

FunctionName

函式的名稱，用來在來自 EOA 的交易中、從另一個合約，甚至在同一個合約內呼叫這個函式。

parameters

在名稱之後，我們指定必須傳給函式的引數，包括它們的名稱與型別。在 Faucet 範例中，我們把 uint withdrawAmount 定義為 withdraw 函式唯一的引數。^[15]

接下來這組關鍵字（public、private、internal、external）指定函式的可見性：

public

public 是預設值；這類函式可以被其他合約或 EOA 交易呼叫，也可以在合約內部呼叫。在 Faucet 範例中，兩個函式都定義為 public。^[16]

private

私有函式和內部函式類似，但不能被衍生合約呼叫。

internal

內部函式只能在合約內部存取——它們不能被其他合約或 EOA 交易呼叫。衍生合約（也就是繼承這個合約的合約）可以呼叫它們。

external

外部函式和公開函式類似，差別在於除非明確地加上關鍵字 this 作為前綴，否則不能在合約內部呼叫。

請記住，內部與私有這兩個詞有點誤導人。合約裡的任何函式或資料，在公開的區塊鏈上永遠都是看得見的，也就是說，任何人都能看到這些程式碼或資料。這裡介紹的關鍵字只會影響函式可以如何、以及何時被呼叫。

第二組關鍵字（pure、view、payable）會影響函式的行為：

pure

pure 函式既不讀取、也不寫入儲存空間中的任何變數。它只能對引數進行運算並回傳資料，不參照任何已儲存的資料或區塊鏈狀態。pure 函式的用意，是鼓勵沒有副作用、沒有狀態的宣告式程式設計風格。

view

標示為 view 的函式不會修改任何狀態。編譯器並不強制使用 view 修飾；它只會在可以使用時產生一個警告。

payable

payable 函式是可以接受轉入款項的函式。沒有宣告為 payable 的函式會拒絕轉入的款項。由於 EVM 的設計決策，有兩個例外：即使 fallback 函式沒有宣告為 payable，coinbase 支付與 SELFDESTRUCT 的遺留款項仍然會轉入；不過這很合理，因為這些支付本來就不涉及程式碼的執行。

現在我們來探討兩個特殊函式 receive 與 fallback 的行為：

receive()

receive 函式讓我們的合約能夠接收以太幣。當合約收到一個 calldata 為空的呼叫時，它就會被觸發，通常是在單純轉帳以太幣的時候（例如使用 .send() 或 .transfer() 轉帳）。它以 receive() external payable { ... } 宣告；雖然它不能有任何引數，也不能回傳值，但它可以是 virtual、可以覆寫（override）其他函式，也可以有修飾符。

fallback()

當合約被呼叫時所帶的資料不符合任何其他函式簽章（function signature）時，就會執行 fallback 函式。我們可以用 fallback() external [payable] 或 fallback(bytes calldata input) external [payable] returns (bytes memory output) 宣告它。如果 fallback 函式包含輸入參數，這個參數會包含送到合約的全部資料（相當於 msg.data）。和 receive 函式一樣，fallback 函式可以是 payable、可以是 virtual、可以覆寫其他函式，也可以有修飾符。現在，它主要用來實作代理模式：一種讓智能合約可以升級的設計模式。

有一種特殊的函式只會使用一次。合約被建立時，如果有建構子函式，就會一併執行它，以初始化合約的狀態。建構子與建立合約在同一筆交易中執行。建構子函式不是必要的；你會注意到，我們的 Faucet 範例就沒有建構子。

建構子可以透過 constructor 關鍵字指定，寫法如下：^[17]

合約的生命週期從 EOA 或合約帳戶發出的建立交易開始。如果有建構子，它會作為建立合約的一部分執行，在合約建立的同時初始化合約的狀態，之後就被捨棄。

Solidity 提供一種特殊的函式，稱為函式修飾符。只要在函式宣告中加上修飾符的名稱，就能把修飾符套用到函式上。修飾符最常用來建立適用於合約中許多函式的條件。我們的 destroy 函式裡已經有一個存取控制的陳述式。^[18]我們來建立一個表達這個條件的函式修飾符：

這個名為 onlyOwner 的函式修飾符，會對它所修飾的任何函式設下一個條件：儲存為合約 owner 的地址，必須與交易的 msg.sender 地址相同。這是存取控制的基本設計模式，只允許合約的擁有者執行任何帶有 onlyOwner 修飾符的函式。

你可能已經注意到，我們的函式修飾符裡有一個奇特的語法「佔位符號」：一個底線後面接著一個分號（_;）。這個佔位符號會被替換成被修飾的函式的程式碼。基本上，修飾符就像「包」在被修飾的函式外面，把函式的程式碼放進底線字元所標示的位置。

要套用修飾符，就把它的名稱加到函式宣告中。一個函式可以套用多個修飾符；這些修飾符以空白分隔列出，會依照宣告的順序套用。

我們來定義一個使用 onlyOwner 修飾符的 changeOwner 函式：

函式修飾符的名稱（onlyOwner）寫在關鍵字 public 之後，告訴我們 changeOwner 函式受到 onlyOwner 修飾符的修飾。基本上，你可以把它讀成「只有擁有者才能設定新的擁有者地址」。實際上，產生的程式碼就相當於把 onlyOwner 的程式碼「包」在 changeOwner 外面。

函式修飾符是極為實用的工具，因為它讓我們能為函式撰寫前置條件，並一致地套用，讓程式碼更容易閱讀，也因此更容易進行安全審計。修飾符最常用於存取控制，但用途相當廣泛，也可以用於其他各種目的。

Solidity 的 contract 物件支援繼承，這是一種為基礎合約（base contract）擴充額外功能的機制。要使用繼承，就用關鍵字 is 指定父合約：

透過這種寫法，Child 合約會繼承 Parent 的所有方法、功能與變數。Solidity 也支援多重繼承，只要在關鍵字 is 之後列出以逗號分隔的合約名稱即可：

要呼叫繼承鏈中較上層的函式，可以像 Parent1.functionName() 這樣明確指定合約；如果只想呼叫在攤平後的繼承階層中高一層的函式，則可以使用 super.functionName()。

合約繼承讓我們撰寫合約的方式能達到模組化、可擴充性與重複使用。我們先從簡單、實作最通用功能的合約開始，再透過在更專門的合約中繼承這些功能來加以擴充。

在 Faucet 合約中，我們引進了針對擁有者的存取控制，擁有者在建構時指定。這項功能相當通用：許多合約都會有。我們可以把它定義成一個通用的合約，再用繼承把它擴充到 Faucet 合約。為了讓範例更豐富，我們在存取控制之外，再加上可暫停的功能。

我們先定義一個基礎合約 Owned，它有一個 owner 變數，並在合約的建構子中設定這個變數：

接著，我們定義一個繼承 Owned 的基礎合約 Pausable：

如你所見，Pausable 合約可以使用定義在 Owned 中的 onlyOwner 函式修飾符。它也間接使用了定義在 Owned 中的 owner 地址變數與建構子。繼承讓每個合約都更簡單，專注於各自特定的功能，讓我們能以模組化的方式管理細節。

現在，我們可以進一步擴充 Owned 合約，在 Faucet 中繼承它的功能：^[19]

Faucet 合約繼承了 Pausable，而後者又繼承了 Owned，因此它現在可以使用 whenNotPaused 修飾符，而這個修飾符的結果，可以由透過 Owned 合約建構子定義的擁有者控制。這些功能就和把那些函式直接寫在 Faucet 裡一樣，但多虧了這種模組化的架構，我們可以在其他合約中重複使用這些函式與修飾符，不必重寫。程式碼重複使用與模組化讓我們的程式碼更簡潔、更容易閱讀，也更容易審計。

有時候，我們可能需要改變所繼承合約的某些功能。幸好，Solidity 正好提供了合適的功能：函式覆寫。宣告為 virtual 的函式，可以被繼承鏈中較上層的合約覆寫，讓繼承的做法保有高度的彈性。^[20]

我們來看一個例子。假設我們想讓暫停功能變成單向的：一旦暫停，合約就再也無法解除暫停。要做到這一點，我們需要把 Pausable 合約中的 unpause 函式標示為 virtual，並在 Faucet 合約中以 override 屬性重新宣告 unpause 函式，定義我們想要的新行為，也就是回復：

如你所見，Faucet 中的 unpause() 函式必須以 override 關鍵字宣告。在 Pausable 合約中，為了一致起見，我們把 pause 與 unpause 兩個函式都標示為 virtual，雖然在我們的例子中只需要改變 unpause。

在 Solidity 中使用多重繼承時，Solidity 會依靠一種稱為 C3 線性化的演算法，來決定合約被繼承的順序。這個演算法確保繼承順序嚴格且可預測，有助於避免循環繼承之類的問題。用最簡單的方式來說，它決定的是尋找函式時檢查基礎合約的順序，而這個順序是由右到左。也就是說，最右邊的合約被視為「衍生程度最高」的合約。例如，在合約宣告 contract C is A, B { } 中，合約 B 的衍生程度比合約 A 高。

除了使用 C3 線性化之外，Solidity 還設有其他的防護措施。其中一條關鍵的規則是：如果多個合約有相同的函式，我們就必須明確指出要覆寫哪些合約。我們來看一個例子：

乍看之下，這段程式碼似乎應該能正常運作，因為 C3 線性化應該會處理好一切。但實際上，它無法編譯。Solidity 會拋出一個錯誤，內容是：「TypeError: Derived contract must override function foo. Two or more base classes define a function with the same name and parameter types.」要修正這個問題，我們必須像下面這樣，明確地覆寫 A 與 B 兩者的 foo() 函式：

所以，即使 Solidity 使用 C3 線性化，我們在寫程式時大多不必擔心它，因為 Solidity 會強制我們明確地處理函式的覆寫。

不過，有一個地方 C3 線性化很重要，那就是 Solidity 決定建構子執行順序的時候。建構子會依照 C3 線性化的順序執行，但有個轉折：它們是以相反的順序執行的。仔細想想，這很合理：衍生程度最高的合約，它的建構子應該最後執行，因為它可能會覆蓋先前的建構子所設定的東西。我們來看一個例子：

在這個例子中，y 的值最後會如預期是 2，因為 Derived2 的建構子最後執行，把 x 設為 2。

有一件重要的事要記住：你提供建構子引數的順序，並不會影響執行順序。例如，我們可以像這樣把建構子的呼叫順序對調：

即使我們改變了建構子中的順序，結果仍然相同。y 的值會是 2，因為建構子的執行順序是由 C3 線性化決定的，而不是由我們呼叫建構子的順序決定。

最後提醒一點：Solidity 用 C3 線性化處理多重繼承，可能會讓 super 關鍵字的行為出乎你的意料。有時候，呼叫 super 觸發的可能是兄弟類別的函式，而不是直接父類別的函式。這可能導致一些令人意外的結果：被呼叫的方法，來自一個你甚至沒有列在繼承鏈中的類別。這算是一種邊緣情況，所以我們不會深入探討，但在繼承結構複雜的合約中使用 super 關鍵字時，務必記住這一點。

合約呼叫可能會終止並回傳錯誤。Solidity 的錯誤處理由三個函式負責：assert、require 與 revert。

當合約因為錯誤而終止時，所有的狀態變更（變數、餘額等的變更）都會被回復；如果呼叫了不只一個合約，這種回復會沿著合約呼叫鏈一路往上進行。這確保了交易是 atomic 的，也就是說，交易不是成功完成，就是對狀態沒有任何影響、被完全回復。

assert 與 require 函式的運作方式相同：它們會評估一個條件，如果條件為假，就以錯誤停止執行。依照慣例，assert 用在預期結果為真的時候，也就是說，我們用 assert 測試內部的條件。相較之下，require 用來測試輸入（例如函式的引數或交易的欄位），設定我們對這些條件的預期。失敗的 assert 會以 Panic(0x01) 回復，並保留未使用的 gas。請用 assert 檢查內部的不變條件（invariant），用 require 驗證輸入與前置條件。

我們在函式修飾符 onlyOwner 中使用了 require，用來測試訊息的發送者是否為合約的擁有者：

require 函式扮演前置條件的角色：如果條件不滿足，它就會阻止函式其餘部分的執行，並產生錯誤。它也可以包含一段有用的文字訊息，用來顯示錯誤的原因。這段錯誤訊息會記錄在交易日誌中；建議加上錯誤訊息，讓使用者知道錯誤是什麼、該如何修正，藉此改善使用者體驗。所以，我們可以在 require 函式中加上錯誤訊息，來改善程式碼：

revert 函式會停止合約的執行，並回復所有的狀態變更。它有兩種用法：一種是當作陳述式，直接傳入自訂錯誤（custom error），不加括號；另一種是當作函式，加上括號並接受一個字串引數。就 gas 成本而言，自訂錯誤便宜得多；而錯誤字串與自訂錯誤都會記錄在交易日誌中：

合約中的某些情況，不論我們是否明確檢查，都會產生錯誤。例如，在 Faucet 合約中，我們並沒有檢查是否有足夠的以太幣來滿足提領請求。這是因為如果餘額不足以完成轉帳，transfer 函式就會以錯誤失敗，並回復交易：

不過，明確地檢查，並在失敗時提供清楚的錯誤訊息，或許會更好。我們可以在轉帳之前加上一個 require 陳述式來做到這一點：^[21]

像這樣額外的錯誤檢查程式碼會稍微增加 gas 的消耗，但比起省略它，能提供更好的錯誤回報。過去，由於以太坊主網的成本很高，把 gas 消耗降到最低是必做的功課；但 EIP-4844 的引進已經大幅降低了這項成本，讓 gas 消耗在今天不再是那麼迫切的問題。儘管如此，在 gas 效率與周全的錯誤檢查之間取得適當的平衡，仍然很重要。

Solidity 透過 try/catch 功能，讓我們對錯誤處理有更多的控制。這是一個非常方便的功能，讓我們在呼叫外部合約時，能更從容地處理錯誤。出問題時，我們不必讓整筆交易失敗並回復，而是可以捕捉錯誤，再決定接下來要怎麼做。使用 try/catch 時，基本上就是把外部呼叫包在一個 try 區塊中。如果呼叫成功，try 區塊內的程式碼就會照常執行。但如果出了問題——例如被呼叫的合約 gas 耗盡、未通過 require 檢查，或拋出例外——程式就會跳到 catch 區塊，讓我們在那裡處理錯誤。

下面是一個簡單的例子：

我們可以依照錯誤的類型，用不同的方式捕捉錯誤。基本的 catch 區塊會捕捉所有錯誤，但我們也可以捕捉特定的錯誤。例如，我們可以用 catch Error(string memory reason) 捕捉會回傳錯誤字串的錯誤，或用 catch (bytes memory lowLevelData) 處理不回傳任何資料的低階錯誤。此外，我們也可以用 catch Panic(uint errorCode) 捕捉更嚴重的 panic 錯誤，例如溢位或除以零。

try/catch 只適用於外部呼叫。它對同一個合約內的內部函式呼叫沒有幫助。如果同一個合約中的函式失敗，它仍然會照常回復，我們無法用 try/catch 捕捉。

交易完成時（不論成功與否），會產生一份交易收據。交易收據包含日誌項目，提供交易執行期間所發生動作的相關資訊。事件是 Solidity 用來建構這些日誌的高階物件。

事件對輕客戶端與 DApp 服務特別有用：它們可以「監看」特定的事件，並回報給使用者介面，或改變應用程式的狀態，以反映底層合約中發生的事件。

事件物件接受引數，這些引數會被序列化並記錄在區塊鏈上的交易日誌中。你可以在引數前加上關鍵字 indexed，讓這個值成為索引表（雜湊表）的一部分，讓應用程式可以搜尋或篩選。

在合約中呼叫其他合約，是一種非常有用、但可能很危險的操作。我們會探討達成這件事的各種方式，並評估每種方式的風險。簡單地說，風險來自於你對自己呼叫的合約，或呼叫你的合約的那個合約，可能所知不多。撰寫智能合約時，你必須記住：雖然你大多預期要打交道的是 EOA，但沒有任何東西能阻止任意複雜、甚至可能惡意的合約呼叫你的程式碼，或被你的程式碼呼叫。

由於 gas 是由發起交易的使用者支付，使用者會避免呼叫 gas 成本高的函式。因此，把合約函式的 gas 成本降到最低，最符合程式設計師的利益。為此，撰寫智能合約時有一些建議的做法，可以把函式呼叫的 gas 成本降到最低：

避免動態大小陣列

任何走訪動態大小陣列的迴圈，只要函式會對每個元素執行操作，或搜尋某個特定元素，就有使用過多 gas 的風險。事實上，合約可能在找到想要的結果之前，或在處理完每個元素之前，就耗盡 gas，白白浪費時間與以太幣，卻得不到任何結果。

避免呼叫其他合約

呼叫其他合約，尤其是在不知道它們的函式 gas 成本的情況下，會帶來耗盡 gas 的風險。避免使用沒有經過充分測試、沒有被廣泛使用的函式庫。一個函式庫受到其他程式設計師檢驗的程度越低，使用它的風險就越高。

避免多餘的儲存空間存取

存取儲存空間變數，不論是讀取還是寫入，花費的 gas 都比使用記憶體變數多得多。所以只要可以，最好避免直接使用儲存空間。例如，如果我們在某些計算過程中需要多次讀取某個儲存空間變數，最好先把它的值複製到一個記憶體變數中。這樣，我們就能重複存取較便宜的記憶體變數，而不必每次都去存取儲存空間，藉此節省 gas 成本。

以太坊剛推出時，估算 gas 成本有點像是在猜拍賣的得標價。這和比特幣處理交易手續費的方式類似：我們自己設定 gas 價格，礦工則會優先處理出價最高的交易。這表示在網路繁忙的時候，我們常常得出更高的價格，才能確保交易很快完成。這個方法行得通，但也代表 gas 價格可能波動得很厲害——網路壅塞時，有時候會高得嚇人。

接著，2021 年出現了改變遊戲規則的 EIP-1559。以太坊不再要我們猜測合適的 gas 價格，而是引進了一種會依照網路活動自動調整的基本費用。這讓 gas 費用變得更容易預測。而且，如果我們趕時間，仍然可以加上一筆小費（稱為優先費用）來加快速度。現在估算 gas 成本變得更直接，我們也比較不會只為了讓交易被處理而多付錢。

我們來詳細探討如何估算交易的 gas 成本。首先，每筆交易的 gas 成本都有兩個主要組成部分：基本費用與優先費用：

基本費用

這是讓交易被納入區塊所需支付的最低 gas 金額。基本費用由網路自動決定，並依照網路的繁忙程度動態調整。如果區塊是滿的，基本費用就會上升；如果區塊沒有被充分使用，基本費用就會下降。

優先費用（小費）

這是我們額外加上的費用，目的是提供誘因，讓礦工（或在權益證明的情境下，讓驗證者）優先處理我們的交易。它就像是為了讓交易更快被處理而給的小費。我們可以自己設定這筆費用，但錢包應用程式會依照我們希望交易被納入的速度，建議適當的數值。

我們交易的 gas 總成本，是以使用的 gas 量（取決於交易的複雜度）乘以實際的 gas 價格計算出來的。實際的 gas 價格就是基本費用與優先費用的總和。

所以，要估算 gas 成本，我們可以依照下列步驟：

例如，如果基本費用是 20 gwei，我們設定的小費是 2 gwei，而交易用了 50,000 gas，那麼估計的 gas 成本就是：

(20 gwei + 2 gwei) × 50,000 = 1,100,000 gwei

所以，也就是 110 萬 gwei，或 0.0011 ETH。

建議你把評估函式的 gas 成本納入開發流程，以免把合約部署到主網時出現任何意外。