以太坊帳戶模型 vs UTXO 的設計抉擇：為何以太坊選擇 EOA/合約帳戶模型

摘要

比特幣的 UTXO 模型和以太坊的帳戶模型代表了區塊鏈狀態管理的兩種截然不同的設計哲學。本文將從技術原理、編程模型、安全特性、隱私表現和擴展性等多個維度，深入剖析這兩種模型的優劣，並詳細解釋以太坊為何選擇帳戶模型而非 UTXO 架構。我們將探討帳戶模型如何支撐以太坊的圖靈完整智慧合約生態，並分析這種選擇在實際應用中帶來的權衡取捨。

一、UTXO 模型的基本原理與技術架構

1.1 UTXO 的概念定義

UTXO（Unspent Transaction Output，未花費交易輸出）是比特幣用於追蹤所有權和交易記錄的核心資料結構。在 UTXO 模型中，區塊鏈不直接儲存「帳戶餘額」，而是記錄每一筆交易的輸出狀態。一筆交易消耗若干先前創建的 UTXO，同時產生新的 UTXO。

這個概念可以用生活中的鈔票來類比：假設你有三張 10 元鈔票和一張 50 元鈔票，你並不拥有一个「80 元」的帳戶餘額，而是拥有四張具體的鈔票。當你要支付 25 元時，你拿出 10 元和 10 元两张鈔票（消費），商戶找零給你 5 元，你獲得了新的 5 元鈔票。

UTXO 模型的數學表示可以如下描述：

UTXO Set = { (tx_id, output_index) → Output }
Output = { value: u64, script: Script }

交易驗證：
  Input = (tx_id, output_index, script_sig)
  Output = UTXO[tx_id, output_index]
  verify(script_sig, Output.script) == true
  sum(Input.values) >= sum(Output.values) + fees

1.2 UTXO 的狀態轉換機制

UTXO 模型中的狀態轉換遵循嚴格的規則：每筆交易必須完全消費現有的 UTXO，不能部分消費。這種設計的一個重要特性是狀態轉換的可追溯性——每一個 UTXO 都可以追溯到其完整的創建歷史，一直回溯到創世區塊的 coinbase 交易。

比特幣的腳本語言（Script）用於定義 UTXO 的解鎖條件。最常見的是 P2PKH（Pay to Public Key Hash）和 P2SH（Pay to Script Hash）兩種腳本類型：

// P2PKH 腳本
// 鎖定腳本：OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
// 解鎖腳本：<signature> <pubKey>

// P2SH 腳本
// 鎖定腳本：OP_HASH160 <scriptHash> OP_EQUAL
// 解鎖腳本：<signature(s)> <serialized_script>

UTXO 的另一個重要特性是其「原子性」——一筆交易要么完全成功，要么完全失敗，不存在部分執行的狀態。這使得 UTXO 模型更容易進行形式化驗證和並發處理。

1.3 UTXO 模型的優點分析

UTXO 模型具有多個顯著優點，這也是比特幣選擇這種架構的主要原因：

並行處理潛力：由於每個 UTXO 都是獨立的狀態單元，不同的 UTXO 可以被不同的節點并行驗證。這種天然的可並發性為未來的擴展方案提供了良好的基礎。

簡化的狀態驗證：UTXO 模型的驗證邏輯相對簡單——只需要確認輸入 UTXO 存在且未被消費，簽名有效，總量平衡即可。這種簡潔性降低了客戶端實現的複雜性，減少了漏洞出現的可能性。

更強的隱私保護潜力：UTXO 模型天然支持某些隱私增強技術。例如，CoinJoin 混幣協議可以利用 UTXO 的結構特性，將多筆交易的輸入混合，增加鏈上分析的難度。

優異的簡單支付驗證（SPV）支持：比特幣的 SPV（Simple Payment Verification）錢包不需要下載完整的區塊鏈，只需要下載區塊頭和相關的 UTXO 證明。這種設計使得輕客戶端可以快速驗證支付，而不需要信任全節點。

易於實現無狀態性：從理論上說，UTXO 模型更容易實現無狀態客戶端——客戶端只需要維護當前 UTXO 集合的承諾（如 Merkle Root），而不需要下載完整的狀態歷史。

二、以太坊帳戶模型的技術架構

2.1 帳戶模型的狀態表示

與 UTXO 模型不同，以太坊直接維護每個帳戶的狀態。以太坊的狀態是一個鍵值對映射（Key-Value Map），其中鍵是帳戶地址（160 位元），值是帳戶狀態：

State = Map<Address, AccountState>
AccountState = {
    nonce: u64,
    balance: u256,
    storageRoot: Hash,
    codeHash: Hash
}

這種設計使得查詢任意帳戶的餘額或狀態變得非常高效——只需要一次鍵值查找。相比之下，UTXO 模型要查詢某個地址的總餘額，需要遍歷整個 UTXO 集合並聚合所有相關輸出。

2.2 EOA 與合約帳戶的設計

以太坊的帳戶模型包含兩種類型，這是以太坊區別於比特幣的重要特徵：

外部擁有帳戶（EOA, Externally Owned Account）：由私鑰控制的帳戶，沒有關聯的代碼。EOA 是用戶與以太坊網路交互的入口點，用於發起交易和部署智能合約。EOA 的狀態結構為：

struct EOA {
    uint256 nonce;      // 交易計數器，防止重放攻擊
    uint256 balance;    // ETH 餘額
    bytes32 storageRoot; // 存儲根（對 EOA 為空）
    bytes32 codeHash;    // 代碼哈希（對 EOA 為空字串哈希）
}

合約帳戶（Contract Account）：由智能合約代碼控制的帳戶，沒有私鑰，只能在被 EOA 或其他合約呼叫時才能執行代碼。合約帳戶具有完整的狀態結構，可以儲存任意數據和執行複雜邏輯。

這種雙重帳戶設計是以太坊智慧合約生態的基礎：任何人都可以通過 EOA 部署合約，而合約之間可以互相呼叫，形成複雜的應用邏輯。

2.3 交易模型與訊息呼叫

以太坊的交易模型比比特幣更加豐富，支持多種類型的互動：

外部交易：由 EOA 簽名發起，可以轉移 ETH 或觸發智能合約執行。

內部訊息呼叫（Message Call）：由合約帳戶發起，在合約之間傳遞 ETH 和執行呼叫。

交易結構：
{
    nonce: u64,
    gasPrice: u256,
    gas: u64,
    to: Address,
    value: u256,
    data: bytes,
    v, r, s: u256  // EOA 簽名
}

訊息呼叫結構：
{
    from: Address,
    to: Address,
    value: u256,
    data: bytes,
    gas: u64
}

以太坊的交易執行模型支援嵌套呼叫——一個交易可以觸發多個合約的多層呼叫。這種設計使得複雜的去中心化應用（如 DeFi 協議）成為可能，但也帶來了 Gas 計算和安全性方面的挑戰。

2.4 狀態存儲與 Patricia Merkle Trie

以太坊使用一種特殊的資料結構——Patricia Merkle Trie（MPT）——來組織和儲存狀態。MPT 結合了 Patricia Trie（前綴樹）的高效查找和 Merkle Tree 的可驗證性，為以太坊提供了既高效又可驗證的狀態管理能力。

MPT 的結構可以表示為：

MPT Node Types:
- Branch Node: 16 個子節點 + 1 個值
- Extension Node: 共用前綴 + 下一個節點的哈希
- Leaf Node: 路徑末節 + 值

狀態根 = MPT.Root(State)
狀態驗證：verify(proof, state_root) → state_value

MPT 的設計使得以太坊可以高效地更新和查詢狀態，同時支援狀態證明的生成和驗證。這對於輕客戶端和跨鏈橋等應用場景非常重要。

三、為何以太坊選擇帳戶模型

3.1 智慧合約支援的需求

以太坊的核心創新是支援圖靈完整的智能合約。帳戶模型與這種需求高度契合，原因如下：

狀態持久性：在帳戶模型中，合約的狀態可以直接與帳戶關聯，便於管理和持久化。合約可以維護複雜的內部狀態結構，而不需要像 UTXO 模型那樣將狀態編碼到交易的輸出中。

簡化的合約互動：帳戶模型使得合約之間的互動更加直觀。合約可以像調用函數一樣呼叫其他合約，傳遞參數並獲取返回值。這種呼叫棧（Call Stack）機制是實現複雜 DeFi 應用的基礎。

統一的資源模型：帳戶模型允許 Gas 消耗與帳戶狀態直接關聯。合約的存儲讀寫和計算都可以根據統一的 Gas 定價模型進行計算，簡化了開發者的心智模型。

比特幣的 UTXO 模型在設計上就無法很好地支援智能合約。雖然比特幣的腳本語言可以實現某些簡單的條件支付（如多重簽名、哈希時間鎖），但要實現複雜的合約邏輯（如借貸、衍生品）几乎不可能。

3.2 用戶體驗與開發便利性

帳戶模型對於普通用戶和開發者都更加友好：

直觀的餘額概念：用戶只需要知道自己的地址和餘額，不需要理解 UTXO 的概念。這種設計與傳統銀行帳戶類似，降低了學習曲線。

標準化的互動介面：以太坊的 JSON-RPC API 提供了統一的方式來查詢帳戶餘額、發送交易、呼叫合約。開發者可以使用相同的模式來處理 ETH 轉帳和智能合約互動。

開發工具生態系統：帳戶模型催生了 Remix、Solidity、Web3.js 等完善的開發工具生態。這些工具的設計假設了帳戶模型的存在，提供了良好的開發體驗。

3.3 可預測性的交易費用計算

帳戶模型使得交易費用的計算更加可預測。在 UTXO 模型中，交易的費用取決於交易大小（以位元組計算），但由於 UTXO 的結構特性，相同的金額轉帳可能需要不同數量的 UTXO 輸入，導致費用差異很大。

以太坊的 Gas 模型提供了更精細的費用控制：

// 以太坊操作 Gas 成本
SSTORE (存儲寫入): 20,000 gas (冷存儲) / 2,900 gas (熱存儲)
SLOAD (存儲讀取): 2,100 gas (冷讀取) / 100 gas (熱讀取)
CREATE (合約創建): 32,000 gas
CALL (訊息呼叫): 2,300 gas (+ 轉移 gas)

這種基於計算複雜度的 Gas 定價使得用戶可以更準確地估算交易費用，提高了使用體驗。

3.4 原子性與可逆性的設計權衡

帳戶模型在原子性設計上與 UTXO 模型有所不同，這是一個需要深入理解的取捨：

UTXO 模型的原子性是 transaction-level 的：一筆交易要么完全成功，要么完全失敗。但這也意味著複雜的多步操作（如先存款到 DeFi 協議，再進行 swap，再提取）需要拆分成多筆交易，增加了失敗的風險和操作的複雜性。

帳戶模型支援在同一筆交易中執行多個步驟的原子操作。Solidity 的 require/assert/revert 機制允許合約在任何步驟失敗時回滾整個交易：

function atomicSwap(
    address tokenIn,
    uint256 amountIn,
    address tokenOut,
    uint256 minAmountOut
) external {
    // 步驟 1: 從用戶轉入代幣
    IERC20(tokenIn).transferFrom(msg.sender, address(this), amountIn);
    
    // 步驟 2: 在 DEX 上 swap
    uint256 amountOut = swapOnDEX(tokenIn, tokenOut, amountIn);
    require(amountOut >= minAmountOut, "Slippage exceeded");
    
    // 步驟 3: 將輸出代幣轉給用戶
    IERC20(tokenOut).transfer(msg.sender, amountOut);
}

這種原子性對於 DeFi 應用至關重要：用戶可以確保自己的多步操作要么全部成功，要么全部失敗，避免了部分執行導致的資金損失。

然而，這種原子性也帶來了一個潛在的問題：帳戶模型的原子性是合約級的，如果合約代碼有漏洞，整個系統可能陷入不一致狀態。以太坊的 Gas 機制（交易執行耗盡 Gas 就回滾）提供了一個保護機制，但無法防止邏輯漏洞導致的問題。

四、帳戶模型的挑戰與改進方向

4.1 狀態增長問題

帳戶模型面臨的一個主要挑戰是狀態增長問題（State Bloat）。隨著網路的發展，以太坊的狀態不斷膨脹：每一個曾經與網路交互的帳戶都會佔用磁盤空間。截至 2026 年第一季度，以太坊的狀態已經超過 100GB，這對節點運營者特別是使用固態硬碟的節點構成了存儲壓力。

為了解決這個問題，以太坊社區正在探索多種方案：

Verkle Tree 遷移：用更高效的向量承諾（Vector Commitment）替代 Merkle Tree，減少狀態證明的大小。

狀態過期機制：讓長期不活躍的帳戶狀態「過期」，需要用戶主動「激活」才能使用。這種設計可以減少活跃狀態的總量，但需要仔細設計以避免影響用戶體驗。

朦朧物（Danksharding）：透過增加 blob 空間來降低 Layer 2 結算成本，間接減少主網狀態增長的壓力。

4.2 隱私挑戰

帳戶模型的透明性帶來了隱私方面的挑戰。與 UTXO 模型可以通過 CoinJoin 等技術混淆交易關聯不同，帳戶模型的交易歷史是直接可追溯的——每個帳戶的每次互動都被完整記錄在區塊鏈上。

以太坊生態系統正在開發多種隱私保護方案：

零知識證明（ZKP）：Aztec Network、Railgun 等隱私協議使用 zk-SNARK 技術來隱藏交易細節。

隱私池（Privacy Pools）：允許用戶證明自己不在某個「犯罪」集合中，同時保護其交易隱私。

帳戶抽象（ERC-4337）：透過將 EOA 功能抽象到智能合約中，實現更複雜的隱私保護邏輯。

4.3 抗審查性考量

帳戶模型的一個潛在弱點是其抗審查性。EOA 是由私鑰直接控制的，這意味著一旦掌握了私鑰就可以完全控制帳戶。相比之下，某些 UTXO 設計可以實現更複雜的訪問控制策略。

然而，以太坊正在通過合約錢包和帳戶抽象來增強抗審查能力。智慧合約錢包可以實現時間鎖、多重簽名、社交恢復等功能，使得即使攻擊者獲得了私鑰，也難以立即盜取資產。

五、UTXO 與帳戶模型的比較框架

5.1 技術特性對比

5.2 應用場景適用性分析

UTXO 模型更適合的場景：

• 簡單的價值轉移和支付系統
• 需要高隱私性的應用
• 需要嚴格事務原子性的場景
• 基於比特幣架構的擴展（如側鏈、Drivechain）

帳戶模型更適合的場景：

• 複雜的智能合約應用（DeFi、DAO、NFT）
• 需要用戶友好的錢包和介面
• 需要狀態持久化的應用
• 需要原子性多步操作的場景

六、以太坊帳戶模型的未來演進

6.1 ERC-4337 帳戶抽象

ERC-4337 是以太坊最重要的帳戶抽象標準之一，它允許用戶使用智能合約錢包而非傳統的 EOA 來控制帳戶。這個提案的核心思想是將「交易驗證」和「交易執行」分離：

• 傳統流程：交易 → EOA 簽名驗證 → 執行
• ERC-4337 流程：UserOperation → Bundler 收集 → EntryPoint 驗證與執行

ERC-4337 帶來的主要優勢包括：

社交恢復：用戶可以設定多個守護者（Guardian），在丟失私鑰時恢復帳戶訪問權。

無 ETH 交易：用戶可以使用其他代幣支付 Gas，降低新用戶的進入門檻。

交易批處理：多個操作可以打包成一筆交易執行，降低費用成本。

自定義驗證邏輯：合約錢包可以實現多重簽名、時間鎖、白名單等安全策略。

6.2 EIP-7702：EOA 臨時合約化

EIP-7702 是另一項重要的帳戶改進提案，它允許 EOA 在特定交易中臨時具備合約功能。這個提案是 EIP-7702 與 ERC-4337 的互補：

// EIP-7702 交易結構（概念）
{
    ...standard_transaction_fields,
    contract_code: ContractCode,
    authorization_list: [Authorization]
}

Authorization = {
    address: EOA_Address,
    chain_id: u256,
    nonce: u256,
    contract_code: ContractCode,
    signature: ECDSA_Signature
}

EIP-7702 的主要應用場景包括：

• 讓傳統 EOA 臨時具備合約錢包功能
• 實現 EOA 的批量操作和代理轉發
• 增強 EOA 的安全性和功能

6.3 長期願景：完全狀態抽象

以太坊的長期願景是實現完全的狀態抽象（Full State Abstraction），使得：

• 帳戶類型可以完全由智能合約定義
• 驗證邏輯可以完全自定義
• 狀態表示可以是任意資料結構

這種完全的抽象將使得以太坊的帳戶模型具有極大的靈活性，同時保持整個網路的統一性和可組合性。

結論

以太坊選擇帳戶模型而非比特幣的 UTXO 架構，是一個經過深思熟慮的設計決策，反映了以太坊作為「世界電腦」的定位和支援圖靈完整智能合約的需求。

帳戶模型提供了直觀的狀態表示、高效的查詢效能、良好的開發者體驗，以及對複雜應用的原生支援。同時，這種模型也帶來了狀態增長、隱私保護等方面的挑戰，這些問題正在通過 Verkle Tree、帳戶抽象、零知識證明等技術方案逐步解決。

UTXO 模型和帳戶模型各有優劣，並非簡單的對錯之分。比特幣選擇 UTXO 是為了最大化安全性和簡潔性；而以太坊選擇帳戶模型則是為了支撐更豐富的應用場景。這兩種模型代表了區塊鏈設計的兩個不同方向，它們各自在不同的應用領域發揮著重要作用。

隨著區塊鏈技術的持續發展，我們可能會看到更多混合架構或創新模型的出現。例如，某些新興區塊鏈正在探索將 UTXO 模型應用於支付場景，同時使用帳戶模型處理應用邏輯的混合設計。以太坊社區也在持續探索如何通過 Layer 2、狀態管理等技術來進一步優化其帳戶模型的效能和功能。

參考文獻

1. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
2. Buterin, V. (2013). Ethereum Whitepaper.
3. Wood, G. (2014). Ethereum: A Secure Decentralised Generalised Transaction Ledger (Yellow Paper).
4. Buterin, V. & Reijsbergen, D. (2022). ERC-4337: Account Abstraction Using Alt Mempool.
5. Paradigm. (2023). Understanding EIP-7702: EOA Contract Authorizations.
6. Ethereum Foundation. (2026). EVM OPCODES Reference.
7. Antonopoulos, A. & Wood, G. (2018). Mastering Ethereum: Building Smart Contracts and DApps.
8. Buterin, V. (2016). On UTXO vs. Account Model.
9. Dang, H. et al. (2019). A Next Generation Smart Contract & Decentralized Application Platform.
10. Buterin, V. (2024). The Why and How of Ethereum's Account Model.