UTXOモデルとアカウントモデル

残高はどこにあるのか

ブロックチェーンの中核は「誰がいくら持つか」という**状態（state）**をどう表現するかにあります。ここには大きく2つの流派があり、その選択が並列性・プライバシー・スマートコントラクトの扱いまで連鎖的に決めます。ビットコインの UTXOモデルと、イーサリアムの アカウントモデルです。

直観に反しますが、ビットコインの台帳には「アドレスXの残高は1.5 BTC」という行はどこにも存在しません。存在するのは、過去の取引が生んだ未使用の受取りの断片だけです。残高とは、自分が使える断片を全部かき集めた合計を、ウォレットがその場で計算した派生値にすぎません。

UTXOモデル：コインは消費され再生成される

UTXO は Unspent Transaction Output（未使用取引出力）の略です。台帳の状態は、まだ使われていない出力の集合（{UTXO_a, UTXO_b, ...}）として保持されます。各 UTXO は「金額」と「ロック条件（誰が使えるか＝ scriptPubKey）」を持つ、いわば封をした硬貨です。

トランザクションは、既存の UTXO を入力として指定し（＝その封を開けて消費し）、新しい UTXO を出力として生成します。ここで鉄則は、入力の UTXO は分割できず丸ごと消費されることです。1.5 BTC の UTXO で 1.0 を送るなら、0.5 は「おつり」として自分宛ての新 UTXO を作って回収します。

入力（消費される既存UTXO）        出力（新たに生成されるUTXO）
  UTXO#1 : 1.0 BTC  ──┐
  UTXO#2 : 0.7 BTC  ──┼──►  受取人宛て : 1.5 BTC
                      │      自分宛て(おつり): 0.15 BTC
  合計 1.7 BTC        └──►  差額 0.05 BTC = 採掘者への手数料

検証ルールは局所的で明快です。(1) 入力に挙げた UTXO が状態集合に実在し未使用か、(2) 各入力のロック条件を解錠する署名（scriptSig）が正しいか、(3) 入力合計 ≥ 出力合計か。これだけで二重支払いを防げます。消費された UTXO は集合から削除され、新出力が追加されます。状態遷移が「削除と追加」の差分だけで表せる点が UTXO の本質です。

アカウントモデル：残高を直接書き換える

アカウントモデルの状態は、アカウント（口座）から状態への写像です。各アカウントは残高を持ち、さらにコントラクトなら永続ストレージとコードを持ちます。送金は銀行口座の帳簿更新に近く、「送信者の残高を x 減らし、受信者の残高を x 増やす」というその場書き換えで表現されます。

状態（グローバルな口座表）
  Alice : balance = 5.0,  nonce = 12
  Bob   : balance = 3.0,  nonce =  4

Tx: Alice → Bob 2.0  (nonce=12 を明示)

適用後
  Alice : balance = 3.0,  nonce = 13   ← 残高を減算・nonceを+1
  Bob   : balance = 5.0,  nonce =  4    ← 残高を加算

ここで nonce（アカウントごとの取引連番）が要になります。UTXO は「一度使えば消える」ので二重使用が構造的に不可能でしたが、アカウントモデルの取引は残高への操作であり、同じ取引を再放送すればもう一度成立してしまう（リプレイ攻撃）。これを防ぐため、送信者アカウントは単調増加する nonce を持ち、取引は自分の現在 nonce に一致するものだけが受理されます。実行のたびに nonce が +1 され、順序と一意性が保証されます。

状態管理と検証コストの違い

両者の差は、状態の格納構造と検証の局所性に表れます。

イーサリアムは全アカウント状態を Merkle Patricia Trie に格納し、その根ハッシュ（stateRoot）を各ブロックに刻みます。任意時点の状態全体が1つのハッシュに要約され、あるアカウントの残高やストレージ値を軽量な証明付きで参照できます。コントラクトが「他アカウントの現在残高」を実行中に読む、といった操作が自然に書けるのはこの集約構造のおかげです。

一方 UTXO では状態が無数の出力に散らばるため、「アドレスXの残高」を知るにはそのアドレス宛ての UTXO を横断的に集める必要があり、任意アドレスの状態参照は本質的に不得手です。この非対称性が、次のスマートコントラクト適性を分けます。

並列性・プライバシー・契約適性

同じ「送金」でも、モデルの違いは実行効率とプライバシーに効いてきます。

プライバシーでも差が出ます。UTXO では受取りごと・おつりごとに新しいアドレスを使い捨てるのが標準的で、残高が1つの識別子に紐づきにくく、資金の追跡を難しくします。アカウントモデルは残高が固定アドレスに集約されるため、そのアドレスの全活動が公開台帳上で一望でき、追跡や名寄せが容易です（ただしUTXOも入力の束ね方から関連性を推定するチェーン分析で追跡されうる点は同じく残ります）。

スマートコントラクト適性は、アカウントモデルが明確に優位です。コントラクトは呼び出しをまたいで残高やマッピングを保持し続ける永続的な状態を必要とします。アカウントモデルはストレージがアカウントに直接ぶら下がるためこれを素直に表現できます。UTXO で複雑な状態を持つには、状態をコイン片へ分散して符号化する必要があり、開発モデルが煩雑です。

BitcoinとEthereumの設計思想

この分岐は偶然ではなく、それぞれの目的から導かれた帰結です。

ビットコインは「検証可能で改ざん困難な電子現金」を狙いました。求められたのは、誰でも軽量に検証でき、二重支払いが構造的に起きず、追跡されにくい価値移転です。UTXO は現金の直観（硬貨を渡し、おつりを受け取る）に忠実で、二重支払い防止が状態からの削除で自動化され、並列検証にも向く——送金という単機能を堅牢かつ検証容易にするという設計思想にきれいに合致します。

イーサリアムは「任意の状態遷移をプログラムできる世界計算機」を狙いました。中心はコントラクトが保持する永続状態と、それを書き換える汎用的な計算です。アカウントモデルは「現在状態を読み、条件で分岐し、複数アカウントの残高やストレージを更新する」という任意の状態遷移関数を素直に記述でき、開発者にとっての心的モデルも単純です。並列性やプライバシーを一部犠牲にしてでも、表現力を取ったといえます。

まとめ

• UTXOモデル（Bitcoin）は残高を持たず、未使用出力の集合として状態を表す。取引は既存UTXOを丸ごと消費し新UTXOを生成する「削除と追加」で、二重支払いは構造的に防がれる。
• アカウントモデル（Ethereum）は口座ごとに残高・nonce・ストレージ・コードを保持し、送金は残高のその場書き換え。再放送は nonce の単調増加で拒否する。
• UTXOは依存しない取引を並列検証でき、アドレス使い捨てでプライバシーを取りやすいが、状態が分散し複雑な契約に不向き。アカウントは状態が集約されスマートコントラクトに強いが、同一口座は直列実行が要る。
• 分岐の源泉は目的の違い。Bitcoinは検証容易な電子現金、Ethereumは任意の状態遷移をプログラムできる計算機——その要求が状態表現の選択を決めた。