📘 Academy原文準拠 ｜ Phase 2 · Unit 2 · Lesson 2.2 Account vs UTXO — Why Midnight Uses Both 内容に忠実な日本語版です。原文（英語）・図・動画は公式 Academy（外部リンク・別タブで開きます）を正本に。
どんなブロックチェーンも、まず「だれが何を持っているか」をどう記録するか、を決めなければなりません。
一見かんたんな問いですが、この答えがすべてを左右します。取引のしくみ、プライバシーの扱い、そしてスマートコントラクトが作りやすいか作りにくいか——全部この選び方で変わるのです。代表的なやり方は2つあります。Midnight のアーキテクチャに入る前に、この2つを理解しておくことが欠かせません。
参考動画（公式）：Account vs UTXO の概要（外部リンク・別タブで開きます）
動画で学ぶ（公式）
Account モデル（イメージ：銀行口座）
Ethereum は account モデル を使います。多くのスマートコントラクト基盤も同じです。
考え方はまっすぐです。みんなが残高つきの口座を持っていて、誰かに 10 ETH 送ると、自分の口座は 10 減り、相手の口座は 10 増える。ちょうど銀行口座と同じです。
ブロックチェーンは global state（全体の状態） を保ちます。すべての口座の今の残高を知っている巨大な台帳です。取引のたびに、その状態を直接書きかえます。
このシンプルさこそ、Ethereum がこのモデルを選んだ理由です。
スマートコントラクトは、つきつめれば「状態を読んで書きかえるプログラム」です。状態が1つにまとまっていれば、コントラクト同士が連携し、残高を確認し、記録を更新するのがやさしくなります。コントラクトが別のコントラクトを呼ぶような複雑な DeFi を作るなら、account モデルは直感的です。
ただし、代償もあります。
同じ口座にさわる取引は、順番に処理しなければなりません。 たとえば Alice が自分の口座から支払う取引を2つ出すと、その2つは並行に検証できません。2つめは1つめが終わるのを待つからです。規模が大きくなると、これがボトルネックになります。
プライバシーの問題もあります。あなたの口座は、ブロックチェーン上の公開された身元のようなものです。やることすべてが1つのアドレスにひもづきます。時間がたつと、あなたの金融履歴ぜんぶが「つながったグラフ」になり、誰でも分析できてしまいます。
UTXO モデル（イメージ：財布の中の現金）
これを生み出したのは Bitcoin です。考え方は根本からちがいます。
UTXO は Unspent Transaction Output（未使用の取引出力） の略です。残高つきの口座のかわりに、バラバラの価値のかたまりを持ちます。財布の中のお札みたいなものです。
たとえば 10 BTC 持っているとします。これは「口座に 10 BTC」ではありません。合計して 10 になる、いくつかの未使用出力を持っているのです。たとえばある取引から来た 7 BTC の出力と、別の取引から来た 3 BTC の出力、といった具合に。
誰かに 4 BTC 送りたいとき、残高から 4 を引くわけにはいきません。出力は丸ごと使う必要があります。そこで 7 BTC の出力を使い、4 を相手に送り、3 を「おつり（change）」として受けとる——これは自分あての新しい UTXO になります。
各 UTXO は1回しか使えません。 使ったら消え、そのかわりに新しい UTXO が生まれます。
複雑そうに聞こえますが、利点があります。
- 並行処理（Parallelism）：違う UTXO を使う取引は、同時に検証できます。共有する状態を調整する必要がないので、ネットワークはたくさんの取引を並行にさばけます。これはスケーリング上の利点です。
- プライバシー（Privacy）：取引のたびに新しい出力が生まれます。取引ごとに新しいアドレスを使えば、履歴ぜんぶを結ぶ1つの口座が存在しません。資金が別々の出力に分かれるので、分析しにくくなります。
- 決定性（Determinism）：ブロックチェーン全体の状態を知らなくても、取引が正しいか検証できます。入力が存在し、まだ使われていないことを確認すればよいだけです。これにより light client やオフライン検証がやりやすくなります。
トレードオフは、スマートコントラクトが作りにくくなることです。UTXO は設計上 stateless（状態を持たない） です。ふつうの Bitcoin の出力は複雑なデータを持たず、ただの「価値＋使うための条件」です。純粋な UTXO の上で高度なアプリを組むのは難しい。取引をまたいで状態を持ち続けるのが、簡単にはできないからです。
トレードオフのまとめ
どちらかが客観的に上、ということはありません。Bitcoin のシンプルさには UTXO が、Ethereum のスマートコントラクト重視には account が合います。それぞれが自分の目的に合った正しい選択をしたのです。
Cardano の Extended UTXO
Cardano は、両方のいいとこ取りをねらって Extended UTXO（EUTXO） を作りました。UTXO の並行処理と決定性は保ちつつ、出力にデータ欄を足して、状態を持たせたりスマートコントラクトと連携させたりできるようにする、という発想です。
Cardano の各 UTXO は、出力にひもづく任意のデータ「datum」を持てます。validator と呼ばれるスマートコントラクトは、この datum と取引の入力／出力を見て、使ってよいかどうかを判断できます。
これは機能しますが、別の考え方が必要です。コントラクトが global state を書きかえるのではなく、UTXO の連なりを通して状態を渡していくのです。Ethereum から来た開発者にはなじみにくいやり方です。
Midnight のハイブリッド設計
参考動画（公式）：Midnight のハイブリッド設計（外部リンク・別タブで開きます）
Midnight はこの状況をながめて、別の選択をしました——目的に応じて両方のモデルを使う、というものです。
Midnight にはトークンが2種類あります。
- Ledger tokens（台帳トークン） はブロックチェーンにネイティブで、UTXO モデルを使います。Bitcoin のように、取引のたびに消費され生成される、バラバラの価値のかたまりです。Midnight のトークン NIGHT は、unshielded（非秘匿） 側でこのように動きます。同じしくみでプライバシーを持つ shielded（秘匿） な ledger token も作れます。
- Contract tokens（コントラクトトークン） はスマートコントラクトの中に存在し、account モデルを使います。コントラクトの状態の中で残高を管理する、Ethereum の ERC-20 トークンに似たものです。これも shielded／unshielded のどちらにもできます。
なぜ両方なのか。
- UTXO モデルは価値の移動を効率よく扱います。 ただトークンを動かすだけなら、UTXO の並行性とプライバシーの性質が、まさに欲しいものです。
- account モデルは複雑なアプリのロジックを扱います。 スマートコントラクトが内部状態を追ったり、残高を管理したり、込み入ったやりとりをするなら、account のほうが扱いやすいのです。
このように関心ごとを分けることで、Midnight は、役立つところ（トークン移動）では並行性を、必要なところ（スマートコントラクト）ではシンプルさを、両方得ています。
Shielded と Unshielded：プライバシーの層
参考動画（公式）：Shielded vs Unshielded（外部リンク・別タブで開きます）
ledger token も contract token も、shielded（秘匿） か unshielded（非秘匿） のどちらにもできます。
- Unshielded トークンは、想像どおりに動きます。取引は公開、残高も見え、すべてが透明です。
- Shielded トークンは zero-knowledge proofs（ゼロ知識証明） を使って取引の詳細を隠します。ブロックチェーンは、誰が誰に何を送ったかを明かさずに、取引が正しいことを検証できます。
取引を動かす資源である DUST は shielded です。これにより、たとえ公開のことをしていても、メタデータが守られます。観察者は、あなたの取引パターンを簡単には結びつけられません。
統治と実用のためのトークン NIGHT は unshielded です。取引・コンプライアンス・ガバナンス参加のために、見える必要があるからです。
この組み合わせ——ハイブリッドな ledger モデル＋選べる shielding——が、Midnight の “rational privacy”（合理的なプライバシー） アーキテクチャを生み出します。完全な透明か完全な匿名かを強制されるのではなく、やりとりごとに適切なレベルを選べるのです。
開発でなぜ重要か
Midnight 上で何かを作るなら、このアーキテクチャを理解すると、正しいやり方を選べます。
- シンプルな移転可能トークンを作りたい → UTXO の ledger tokens で効率と並行性が得られる。
- 内部状態を持つ複雑なアプリを作る → account の contract tokens のほうが管理しやすい。
- 特定の操作にプライバシーが要る → shielded の種類を使う。
- コンプライアンスのために透明性が要る → unshielded を使う。
このアーキテクチャは多くのユースケースを支えられるほど柔軟で、しかもプライバシー・性能・コンプライアンスのバランスを取る道具を開発者に与えてくれます。
次のレッスンでは、Midnight のスマートコントラクトがこの2つのモデルとどう協調するか、Kachina protocol を通して見ていきます。そして、UTXO だけでも account だけでも達成できなかった、プライバシーを保つ計算をどう可能にするのかを学びます。
開発者として押さえる点
- Account モデル＝1つの global state を直接書きかえる。複雑なコントラクトに強いが、同じ口座は順番待ち、履歴が単一アドレスにひもづきプライバシーが弱い。
- UTXO モデル＝価値のかたまり（Unspent Transaction Output）を消費・生成する。並行処理・出力分離によるプライバシー・決定的な検証に強いが、stateless なのでアプリは作りにくい。
- Cardano の EUTXO は出力に
datumを足し、validatorがそれと入出力を見て承認する。状態は UTXO の連なりで渡す。 - Midnight は両方：価値移動は Ledger tokens（UTXO）、アプリの内部状態は Contract tokens（account） に分担。両方とも shielded／unshielded を選べる。
- shielding は選べる：DUST は shielded、NIGHT は unshielded。これが “rational privacy” の核心。
- 設計判断の指針：単純な移転→UTXO ledger、内部状態を持つアプリ→account contract、秘匿が要る→shielded、透明性が要る→unshielded。
やさしい版・公式へ
- やさしい版：Account と UTXO のちがい
- 公式：Academy Courses（外部リンク・別タブで開きます）（Phase 2 / Unit 2 / 2.2）
- 関連 docs：Midnight のアーキテクチャ概要（外部リンク・別タブで開きます） ／ トークンの種類（NIGHT・DUST）（外部リンク・別タブで開きます）
つぎに読むページ
➡️ 原文準拠コースの入口へ戻る。このコースについて（次のレッスンは順次追加します）