EVM Opcode 執行成本數學推導深度解析：從基礎理論到 Gas 優化實戰

概述

開發以太坊智能合約的時候，你是不是常常遇到合約部署或執行時 Gas 費用爆表的問題？我自己早期寫 Solidity 的時候也是，每次看到交易失敗加上 "out of gas" 的錯誤，整個人都傻了。後來深入研究了一下 EVM 的 Gas 計算模型，發現這玩意兒其實有著非常漂亮的數學結構——每一個 Opcode 的 Gas 消耗都不是隨便拍拍脑袋訂出來的，背後藏著一堆密碼學和系統設計的考量。

這篇文章我打算把 EVM Gas 成本的數學推導從頭到尾講清楚。從最基礎的內存訪問成本模型，到複數操作碼的複雜度分析，再到實際的 Gas 優化技巧都會涵蓋。目標讀者是對以太坊有基本了解、想進一步搞懂底層運作原理的開發者。

數據來源與截止日期：本文所有 Gas 成本數據基於 2026 年 3 月的 EIP-1559 時代規範，請以 Etherscan 上的 Gas Tracker 和以太坊官方黃皮書（Yellow Paper）為準。

一、Gas 的本質：為什麼要有這玩意兒

在動手算數學之前，咱們得先搞清楚一個根本問題：Gas 到底是什麼，為什麼以太坊要設計這套機制？

答案說起來也簡單：區塊鏈是個共識系統，每筆交易都需要網路上的每個節點執行一遍。如果不收費，那麼有心人士就可以發一堆無意義的交易把整個網路塞爆。以太坊聰明的地方在於，它設計了一個「計算量」的標準化單位——Gas，讓交易的複雜度和費用直接掛鉤。

Gas 本質上是一種「資源使用量」的度量。你可以把它想像成你開車時消耗的汽油——路越難走（計算越複雜），消耗越多。

黃皮書（以太坊的技術規格文件）定義得很清楚：每個 Opcode 都有一個基礎成本，這個成本反映的是執行該操作所需的「工作量」。工作量怎麼衡量？主要看三個維度：

1. CPU 計算複雜度：執行這個操作需要多少次基本運算
2. 內存讀寫成本：訪問 RAM 和磁盤的代價
3. 狀態存儲成本：修改區塊鏈狀態的代價

這三個維度在數學上都有對應的成本模型，下面咱們一個個拆解。

二、Opcode Gas 成本的數學基礎

2.1 內存成本模型：線性與二次方的交鋒

EVM 的內存模型是個巨大的、未初始化的字節陣列。訪問內存的成本有兩套公式，適用於不同的訪問模式。

內存擴展成本（Memory Expansion Cost）

當你第一次訪問某個內存位置時，如果這個位置超出了當前已分配的內存範圍，合約需要「擴展」內存。擴展的成本是二次方的：

Cmem(new_size) = Gmemory × new_size + floor(new_size² / 2097152)

其中：
- Gmemory = 3（每字節基礎成本）
- new_size 單位是字節（Byte），但計算時轉換成 32 字節的「字」（Word）
- 2097152 = 2^21，是縮放因子

這公式看著有點暈，咱們實際帶幾個數進去算算：

當 new_size = 1 word (32 bytes) 時：

Cmem = 3 × 1 + floor(1² / 2097152) = 3 + 0 = 3 Gas

當 new_size = 64 words (2048 bytes) 時：

Cmem = 3 × 64 + floor(64² / 2097152) = 192 + 0 = 192 Gas

等等，這數字怎麼感覺線性的？別急，關鍵在於 newsize 本身是隨著你訪問的位置動態變化的。假設你訪問了第 k 個字節，那麼 newsize = ceil((k+1) / 32)。

真正有趣的發生在訪問模式跳躍的時候。假設你一開始只訪問 32 bytes，然後突然跳到訪問 2048 bytes：

初始：size = 1, C = 3

跳躍後：size = 64, C = 192

這個跳躍產生的額外成本是 192 - 3 = 189 Gas。你看出問題了嗎？這個額外成本是「階梯式」的，而不是連續的。

為什麼用二次方而不是線性模型？

這就要扯到 EVM 的實現層面了。以太坊節點通常用 Go、Rust 或 Rust 實現內存管理。擴展內存時，操作系統需要分配新的頁面（Page），頁面分配的成本在理論上與分配的頁面數量成正比。但實際上，訪問新頁面會觸發 TLB（Translation Lookaside Buffer）未命中，這種 penalty 在某些負載下會呈現非線性特徵。

Vitalik 和核心開發團隊最終選擇二次方模型，是因為它在「阻止內存濫用」和「不過度懲罰正常應用」之間取得了很好的平衡。

2.2 狀態讀寫成本：冷門與熱門的差異

EIP-2929 引入了一個革命性的概念：訪問列表（Access List）。這個提案把 EVM 的存儲訪問分成兩類：

1. Cold Access（冷訪問）：首次訪問某個帳戶或存儲槽，代價高昂
2. Warm Access（暖訪問）：在交易中已經訪問過的，代價較低

數學定義如下：

Cold SLOAD:   2100 Gas
Warm SLOAD:    100 Gas

Cold SSTORE: 22100 Gas
Warm SSTORE:  100 Gas

等等，這數字差得也太誇張了。讓我解釋一下背後的邏輯。

SSTORE（存儲寫入）的 Cold 成本是 22100 Gas，其中：

• 20000 Gas：用於將新值寫入持久化存儲（這是真正的磁盤 I/O）
• 2100 Gas：實際上是「首次訪問合約」的成本（簡稱 COLDACCOUNTACCESS）
• 100 Gas：Warm SSTORE 的基礎成本

數學推導的話，整個成本模型可以表示為：

Csstore(access_type, is_cold) = 
    Gcoldaccountaccess × 1{cold} + 
    Gsstore + 
    Gsstore_clean + 1{needs_cleaning}

其中：

• 1{condition} 是指示函數（為真則為 1，否則為 0）
• Gcoldaccountaccess = 2600（冷帳戶訪問基礎成本）
• Gsstore = 20000（寫入成本）
• Gsstore_clean = 2900（如果需要清除舊值）

讀到這裡你可能會問：為什麼要把「首次訪問合約」的成本也算進去？因為 EVM 的實現中，無論你是讀還是寫，第一次接觸一個合約的存儲時，節點必須執行一整套 MPT（Merkle Patricia Trie）遍歷操作。這是一個 O(log n) 的操作，其中 n 是狀態樹的節點數。對於典型的以太坊狀態，這個代價大約是 2100 Gas。

2.3 運算碼成本的層次結構

EVM 定義了幾十種操作碼，它們的成本可以分成幾個層次：

第一層：極低成本操作（1-3 Gas）

這些是最基礎的棧和算術操作：

你注意到一個規律了嗎？加法和減法只要 3 Gas，乘法和除法要 5 Gas。這個比例（約 1.67x）反映了現代 CPU 的ALU設計：乘法單元通常比加法單元複雜得多，需要更多的晶體管和更長的執行週期。

第二層：內存操作（3-6 Gas + 擴展成本）

MLOAD 和 MSTORE 的基礎成本只有 3 Gas，但真正的成本隱藏在內存擴展公式裡：

// 假設我們有以下合約片段
function memoryExample(uint256[] calldata arr) public pure {
    // 訪問 arr[0]
    arr[0];  // 這裡需要 MLOAD
    
    // 訪問 arr[31] - 會導致內存擴展嗎？
    arr[31]; // 不會，因為都在同一個 word 內
    
    // 訪問 arr[32] - 觸發內存擴展
    arr[32]; // 會！
}

第三層：密碼學操作（30-600 Gas）

這是成本最高的一類操作，因為它們涉及真正的密碼學計算：

Keccak-256 的成本模型特別有趣：

Csha3 = 30 + 6 × ceil(len(message) / 32)

這個公式的推導過程是這樣的：Keccak-f1600 內部有 24 輪，每輪需要一堆置換操作。但實際上，硬件實現中哈希函數的成本主要取決於「分塊」的數量——每個 32 字節的塊需要額外的 6 Gas 來處理。

三、Gas 成本的進化：EIP 歷史與數學原理

3.1 從靜態成本到動態成本

早期的以太坊（2015-2019年）採用的是靜態 Gas 成本——每個 Opcode 的成本是固定寫死在規範裡的。這種設計簡單，但有個致命問題：容易受到攻擊。

2016 年的 Shanghai Attacks 就是一個典型案例。攻擊者發現某些 Opcode 的實際計算成本遠高於其 Gas 成本，導致區塊可以塞入極少量的交易就把整個網路搞癱瘓。

為了解決這個問題，以太坊經歷了多次 EIP 升級，每次都伴隨著更複雜的數學模型。

EIP-150（2016年）：重定價攻擊緩解

這次升級提高了以下操作的成本：

• EXTCODESIZE, EXTCODECOPY：從 20 增加到 700
• BALANCE 和 SLOAD：從 20 增加到 400（冷）/ 200（暖）

數學解釋：調用 EXTCODESIZE 時，節點需要遍歷合約的代碼樹。如果合約代碼很長，這個操作的時間複雜度會線性增長。舊的 20 Gas 遠低於實際成本，新的定價試圖彌補這個差距。

EIP-1884（2019年）：Trie 費用重定價

這次升級是因為以太坊的狀態規模從 2016 年的幾百萬節點暴增到了數十億節點。SLOAD 的成本從 200 上升到 800（後來在 EIP-2929 中變成了動態成本）。

核心數學原理：MPT 查詢的時間複雜度是 O(log n)，其中 n 是樹中的節點數。隨著 n 增長，每次查詢的平均成本也在增長。新的定價反映的是「2020 年典型狀態大小下的平均查詢成本」。

3.2 現代 Gas 成本的數學框架

現在讓我們用一個統一的數學框架來描述現代 EVM 的 Gas 成本：

交易 Gas 計算公式：

Gtransaction = Gtransaction_base + Gcalldata × data_length + Σ Gopcode(i)

其中：

• Gtransaction_base = 21000（基礎成本，永遠支付）
• Gcalldata = 4 或 16（取決於每個字節是否為零）
• Gopcode(i) 是第 i 個執行步驟的成本

Call 成本的精確模型：

當合約調用另一個合約時，會觸發子調用。成本計算如下：

Gcall = Gcall_base + Gcall_new × is_new_account + Gcall_value × has_value

其中：
- Gcall_base = 700（基礎創建成本）
- Gcall_new = 25000（如果目標是新帳戶）
- Gcall_value = 9000（如果轉移了 ETH）

這個公式有個有意思的地方：如果 call 有 value（轉帳），還需要額外的 2300 Gas 來燒毀（這是 CREATE2 之前防止重入攻擊的設計）。

四、實際案例：Gas 優化的數學推導

4.1 案例一：批量轉帳 vs 循環轉帳

假設你要實現一個「空投」功能，向 100 個地址每個轉 0.01 ETH。

方案 A：循環轉帳（最爛的做法）

function airdropBad(address[] calldata recipients) external payable {
    for (uint256 i = 0; i < recipients.length; i++) {
        (bool success, ) = recipients[i].call{value: 0.01 ether}("");
        require(success, "Transfer failed");
    }
}

每個 recipients[i].call 需要：

• CALL 基本成本：700 Gas
• COLDACCOUNTACCESS：2600 Gas（首次接觸新帳戶）
• VALUE 轉移：9000 Gas
• 內存讀取 recipients[i]：假設 3 + 內存擴展成本

第一次調用：700 + 2600 + 9000 + 假設 100 = 12,400 Gas

後續 99 次（假設都已 warm）：700 + 100 + 9000 + 100 = 9,900 Gas

總成本（不考慮部署成本）：

Cost_A = 12400 + 99 × 9900 = 1,004,300 Gas

方案 B：批量轉帳（較好的做法）

function airdropBetter(address[] calldata recipients) external payable {
    uint256 amount = msg.value / recipients.length;
    
    for (uint256 i = 0; i < recipients.length; i++) {
        (bool success, ) = recipients[i].call{value: amount}("");
        if (!success) {
            // 處理失敗但不 revert
            payable(msg.sender).transfer(address(this).balance);
            break;
        }
    }
}

這個方案的成本結構和方案 A 差不多，但多了一個 break 機制。真正有意義的優化是方案 C。

方案 C：使用低層次內存操作

function airdropOptimal(address[] calldata recipients) external payable {
    assembly {
        let amount := div(msg.value, recipients.length)
        for { let i := 0 } lt(i, recipients.length) { i := add(i, 1) } {
            let recipient := calldataload(add(recipients.offset, mul(i, 32))))
            pop(call(gas(), recipient, amount, 0, 0, 0, 0))
        }
    }
}

在 assembly 中，我們直接使用 calldataload 讀取代碼，這避免了 Solidity 編譯器生成的額外邊界檢查和內存拷貝。

估算節省：

• 每個 recipients[i] 訪問節省約 200-300 Gas（純內存讀取 vs ABI 解碼）
• 100 個地址 × 250 = 25,000 Gas 節省
• 加上 assembly 版本通常更緊湊，額外節省 10-15%

4.2 案例二：Solidity 循環的代價分析

讓我們量化一下不同循環寫法的成本差異：

// 假設 array.length = 1000
uint256[] public data;

// 方案一：Solidity for 循環
function sumSlow(uint256[] calldata arr) public pure returns (uint256) {
    uint256 total = 0;
    for (uint256 i = 0; i < arr.length; i++) {
        total += arr[i];
    }
    return total;
}

// 方案二：使用 assembly 優化
function sumFast(uint256[] calldata arr) public pure returns (uint256 total) {
    assembly {
        let len := calldataload(add(calldataload(0x04), 0x04))
        for { let i := 0 } lt(i, len) { i := add(i, 1) } {
            total := add(total, calldataload(add(calldataload(0x04), add(0x24, mul(i, 32)))))
        }
    }
}

數學成本估算：

方案一的每次循環迭代成本：

• SLOAD arr[i]：100 Gas（warm） + 內存讀取：假設 100 Gas
• ADD 操作：3 Gas
• i++ 和邊界檢查：約 20 Gas
• 總計：約 223 Gas × 1000 = 223,000 Gas

方案二的每次循環迭代成本：

• calldataload：約 3-5 Gas（這是讀取交易數據，幾乎免費）
• ADD：3 Gas
• 加法和地址計算：約 10 Gas
• 總計：約 20 Gas × 1000 = 20,000 Gas

節省比例：90% 以上！這就是為什麼像 OpenZeppelin 這樣的庫在高性能場景下會使用 assembly。

4.3 案例三：Gas Token 的數學原理

Gas Token（Chi, GST2）利用了這樣一個事實：當網路繁忙時，Gas 價格飆升，但合約存儲擴展的成本是固定的。

數學模型：

Mint Gas Token 時的代價：

Cmint = Gsstore × 2 = 20000 × 2 = 40000 Gas（寫入兩個存儲槽）

這個代價在 Gas 價格低時（約 30 Gwei）約等於：

Cost_mint = 40000 × 30 = 1,200,000 Gwei = 0.0012 ETH

Redeem Gas Token 時的收益：

Credeem = Gsstore × 2（清除操作不收費，但會獲得退款）

等等，清除存儲實際上會獲得退款！這就是 Gas Token 的秘密：

Refund = Gsstore × 1.5 = 30000 Gas

所以淨成本 = 40000 - 30000 = 10000 Gas（相比於直接寫入節省了 75%）

經濟學意義：

當 Gas 價格 > 150 Gwei 時，mint Gas Token 並在之後 redeem 開始有利可圖。因為：

節省的 Gas = 30000 Gas
等價於 30000 × (Gas_price - 150) Gwei > 0
=> Gas_price > 150 Gwei

這個 150 Gwei 的門檻在 2020 年後的以太坊網路上並不罕見，尤其是在 Gas 飆升的時期。

五、Gas 優化實戰代碼庫

5.1 免費的 Gas 優化模式

以下是一些不需要寫 assembly 的純 Solidity 優化技巧：

// ❌ 不好的做法：重複的 SLOAD
function badPattern(uint256 a, uint256 b) public view returns (uint256) {
    if (a > stateVar) {  // 第一次讀取 stateVar
        return stateVar + a;  // 第二次讀取 stateVar
    } else if (b > stateVar) {  // 第三次讀取 stateVar
        return stateVar + b;  // 第四次讀取 stateVar
    }
    return stateVar;  // 第五次讀取 stateVar
}

// ✅ 好的做法：緩存到內存
function goodPattern(uint256 a, uint256 b) public view returns (uint256) {
    uint256 cached = stateVar;  // 一次性讀取
    if (a > cached) {
        return cached + a;
    } else if (b > cached) {
        return cached + b;
    }
    return cached;
}

節省：每次 SLOAD 從 100 Gas 降到 3 Gas（內存讀取）。

// ❌ 不好的做法：多次 emit 事件
function badEvents(uint256[] calldata values) external {
    for (uint256 i = 0; i < values.length; i++) {
        emit ValueUpdated(values[i]);  // 每次 emit 都有 Gas 成本
    }
}

// ✅ 好的做法：批量 emit 或只在關鍵點 emit
function goodEvents(uint256[] calldata values) external {
    // 假設我們只在乎「最終狀態」
    if (values.length > 0) {
        emit ValueUpdated(values[values.length - 1]);  // 只在最後 emit 一次
    }
}

LOG 操作的成本大約是：

CLOG = 375 + 8 × num_topics + 8 × data_words

批量操作可以顯著降低這個成本。

5.2 變量打包（Variable Packing）優化

EVM 的存儲槽是 256 位（32 字節）。如果你把多個小於 32 字節的變量塞進同一個槽位，可以減少 SSTORE 的次數。

// ❌ 不好的做法：每個變量一個槽
contract BadPacking {
    uint128 public a;  // 槽 0
    uint128 public b;  // 槽 1
    uint128 public c;  // 槽 2
    uint128 public d;  // 槽 3
    uint256 public e;  // 槽 4（浪費了）
}

// ✅ 好的做法：變量打包
contract GoodPacking {
    uint128 public a;  // 槽 0（與 b 打包）
    uint128 public b;
    uint128 public c;  // 槽 1（與 d 打包）
    uint128 public d;
    uint256 public e;  // 槽 2
}

節省：從 5 個槽位降到 3 個槽位，首次部署節省 2 × 22100 = 44,200 Gas。

六、ZK 電路中的 Gas 成本代數推導

這個章節是給想了解 Layer 2 或 ZK 證明系統的讀者準備的。如果你只關心以太坊主網的 Solidity 開發，可以跳過這一部分。

ZK-SNARK 和 ZK-STARK 的電路複雜度直接影響著 Rollup 的 Gas 成本。讓我們用數學語言來描述這個問題。

約束系統的基本定義：

在 zk-SNARK 中，每個計算步驟都會生成一系列「約束」（Constraints）。約束的數量決定了電路的複雜度。

對於一個電路 C 和輸入 x，zk-SNARK 證明者需要證明：

∃ w: C(x, w) = true

其中 w 是「Witness」（見證人），代表隱私輸入。

約束數量的數學推導：

假設我們要證明一個 hash(x) = y，其中 hash 是 Keccak-256。

Keccak-256 的內部結構有：

• 1600 位狀態（25 × 64 位字）
• 24 輪置換
• 每輪包含 5 個步驟：θ、ρ、π、χ、ι

每個步驟都會生成約束。粗略估計：

• 每個比特操作需要約 1-3 個約束
• 每個 32 位字操作需要約 32-96 個約束
• Keccak-256 總共需要約 15,000-20,000 個約束

這些約束最終會轉化為 Gas 成本：

Czk_proof = Base_Cost + Cconstraints × Cost_per_Constraint

其中 BaseCost 約為 300,000 Gas，Costper_Constraint 約為 0.02-0.05 Gas（取決於具體實現）。

結語：Gas 成本的哲學意義

研究 Gas 成本這麼久，我越來越覺得這不只是一個技術問題，而是一個社會學和經濟學問題。

每一次 Gas 成本的調整，都是核心開發者和整個社區對「公平」這個概念的反覆博弈。為什麼讀取狀態比寫入狀態便宜？因為讀取不會破壞網路的中立性。為什麼密碼學操作這麼貴？因為如果這些操作太便宜，就會有人用它們發動 DDoS 攻擊。

Gas 模型本質上是以太坊的「社會契約」的數字化表達。它告訴你：什麼是便宜的（無害的），什麼是昂貴的（需要謹慎使用的），什麼是禁止的（不存在的 Opcode 或會導致共識失敗的操作）。

下次當你看到 Gas 費用暴漲的時候，不妨想想這背後的數學原理和設計哲學。也許你會對以太坊這套系統有更深的理解。

參考資料

1. Ethereum Yellow Paper (Gavin Wood, 2014-2023) - 以太坊的技術規格
2. EIP-150: Gas Cost Changes for IO-heavy Operations - 2016 年攻擊緩解
3. EIP-2929: Transaction and State Pricing via Access List - 冷熱訪問定價
4. EIP-1559: Fee market change for ETH 1.0 chain - 費用市場改革
5. Ethereum Execution Layer Specs - 最新 Opcode 成本規範（2026年3月）
6. Flashbots MEV-Boost Documentation - MEV 與 Gas 市場的交互
7. Geth Source Code (go-ethereum) - go-ethereum 客戶端的 Gas 計算實現

本篇文章內容僅供教育目的，不構成任何技術建議或投資建議。以太坊的 Gas 機制可能隨著網路升級而改變，請以最新官方文檔為準。