カルダノが他のスマートコントラクト実装チェーンと大きく異なる点として、会計モデルの違いがあります。
ブロックチェーンにおける会計モデルとは「トランザクションと台帳記録方式のルール」を指します。カルダノでは「拡張UTxOモデル（Extended UTxO model）」が採用されており、イーサリアムなどほとんどのスマートコントラクト実装チェーンでは「アカウントベースモデル」が採用されています。
カルダノにおける「拡張UTxO」とは、ビットコインで採用されている「UTxOモデル」を拡張し、スマートコントラクトを構築できる（トランザクションにプログラムを導入できる）ようにしたものです。
「UTxOモデル」と「アカウントベースモデル」は、ブロックチェーンの取引処理方法に関する主要なアプローチであり、その違いがそのまま各チェーンの拡張方法に大きな影響を与えています。
各チェーンの将来性について検討する大きな材料として、「UTxOモデル」と「アカウントベースモデル」を比較しながら、なぜカルダノが「拡張UTxOモデル」を独自開発したのかを解説します。
アカウントベースモデルとは？
まずは、比較的シンプルな「アカウントベースモデル」について見ていきましょう。
アカウントベースでは、ブロックチェーン上の各アカウントに対して残高を設定し、トランザクションごとにアカウント間でトークンの送受信を行います。
アカウントベースモデルでは、ユーザーがトランザクションを行う場合に、「送信元アドレスの残高から送信額を減算し、送信先アドレスの残高に加算する」という処理がネットワークに入力されます。
これは銀行口座によく似た仕組みで、「Aさん 100ETH」「Bさん 10ETH」のように記録されています。
そこで、「AさんからBさんに50ETHを渡す」という処理を考えてみます。
【入力】Aさん → Bさん 50ETH
①Aさんの残高から50ETHを減算し、Bさんの残高に50ETH加える
A：100ETH ー 50ETH = 50ETH
B：10ETH + 50ETH ＝ 60ETH
【出力】結果を出力する
Aさん 50ETH
Bさん 60ETH
（*あくまで解説用の簡易モデルであり、実際のプログラムとは異なります）
【アカウントベースモデルのメリット：取引方法がシンプルで扱いやすい】
ネットワークに入力されるデータ量は少なく済むことです。ウォレットデータもシンプルで管理しやすい利点もあります。また、台帳や取引の仕組みがシンプルで、スマートコントラクトなどのプログラムが組み込みやすいというメリットがあります。
【アカウントベースモデルのデメリット：並行処理が難しく】
一方でアカウントベースモデルは「膨大な処理に対応できない」というデメリットがあります。
入力側に検証データが含まれないため「Aさんに残高不足はないか？ 取引後に問題や矛盾が起きないか？」を検証しなくてはいけません。そのため、ネットワーク側でトランザクションの検証を行う必要があり、ネットワークに大きな負荷をかけるほか、取引が成立しないことも少なくありません。また、エラーが起きた場合でも取引手数料がかかります。
アカウントベースモデルの場合「台帳データとトランザクション出力がシンプル」というメリットがある一方で、「検証作業（コンピューテーション）が重く、失敗するリスクがある」というデメリットがあります。
ネットワーク規模が小さく、トランザクション内容が複雑ではない場合には効率的に稼働できますが、一度に複数のトランザクションを処理できないため、スケールが拡大すればするほどネットワークに負荷がかかり、処理能力の問題を抱えることになります。
UTxOモデルとは① UTxO台帳の特徴
UTxOモデルとは、「Unspent Transaction Outputs（未使用トランザクション出力）」の略称で、これがそのまま会計モデルの名称となっています。
ブロックチェーン常に無数の「未使用トランザクション出力（UTxO）データ」を記録しておき、トランザクションの際に特定のUTxOを消費（Spend）して、新たなOutput（出力）データを生み出す方式です。新たに生み出されたOutputは、その時点では未使用（Unspend）のためUTxO（未使用トランザクション出力）と呼ばれます。
以下では、より詳しくUTxOについて説明します。
まず、UTxO台帳では「未使用トランザクション出力だけが記録される」という形式になっています。
UTxOでは「ウォレット残高」という概念は存在せず、次のように「UTxOだけ」がアカウントに紐づけられて記録されます。
———————————————
Aさんのアカウント
addraaaaaa….. 20BTC…①
addraaaaab…. 20BTC…②
addraaaaac…. 10BTC…③
50BTC（UTxO形式） UTxO数→ 3
———————————————
———————————————
Bさんのアカウント
addrbbbbba….. 10BTC…①
addrbbbbbb…. 10BTC…②
addrbbbbbc…. 10BTC…③
addrbbbbbd…. 5BTC…④
addrbbbbbe…. 5BTC…⑤
40BTC（UTxO形式） UTxO数→ 5
———————————————
ここで①～③すべて、UTxO（未使用トランザクション出力）です。「過去に受け取ったADAのデータ（＝UTxO）」が、合計されないまま残されています。
ブロックチェーン上では①～③がバラバラに記録されているため、合計金額を算出するにはプログラムを実行してUTxOを集める必要があります。
UTxOモデルとは② トランザクション処理の特徴
それでは、次にUTxOモデルでのトランザクションの流れをみていきましょう。
わかりやすくするために、
「600ADAを持つAさんが、ウォレットを作成したばかりのBさんに70ADAを送る」
というトランザクションで考えてみます。
【処理１】Aさんのアカウントから使えるUTxOを１つ選ぶ
———————————————
Aさんのアカウント（UTxO形式）
addraaaaaa….. 100ADA…①
addraaaaab…. 200ADA…②
addraaaaac…. 300ADA…③
———————————————
→①のUTxOを消費（Spend）して入力データ（Input）を作成する。
【処理２】選んだ①のUTxOを消費し、「送信する70ADA」と「残った30ADA」という２つのUTxOを出力し、それぞれBさん、Aさんのアカウントに紐付ける。
——————————————-addraaaaaa….. 100ADA…① →入力で消費されると消滅する
↓
addrbbbbba … 69ADA 新たに出力
addraaaaad … 29ADA 新たに出力
tx手数料 … 1ADA 新たに出力
——————————————
↓
addrbbbbba … 69ADA →Bさんのアカウントに紐付ける
addraaaaad … 30ADA →Aさんのアカウントに紐付ける
↓
———————————————
Aさんのアカウント
addraaaaab…. 200ADA…②
addraaaaac…. 300ADA…③
addraaaaad… 69ADA <NEW>
———————————————
:
———————————————
Bさんのアカウント
addrbbbbba … 70ADA <NEW>
———————————————
【トランザクション完了】
UTxOは一度使用されると消滅し、新たに作成されたUTxOに置き換わります。
つまり、UTxOのトランザクション処理を非常にシンプルに説明すると、
「AさんのUTxOを消費して新たにUTxOを出力し、Bさんに追加する」（余剰分も新たにUTxOを作り、Aさんに戻す）
という処理で行われます。
各UTxOを「財布の中に入っている小銭やお札」と考えてみてください。財布の中には1万円札や500円玉などさまざまな単位の小銭やお札が入っています。
ここで1,000円を支払うときに、1万円（①UTxO）を差し出すと、1,000円（②UTxO）が相手に渡り「お釣り」として9,000円（③UTxO）が新たに自分の手元に戻ってきます。
UTxOのトランザクション処理は一見すると複雑ですが、実際には私たちが日常生活で行なっている行為に近い仕組みです。
送信者のUTxOを使用し、互いのアカウントに新たなUTxOを追加するだけで終了します（ウォレットから取り出した「お札」だけに注目するため、財布の合計金額をチェックする必要がない）。
トランザクション後の「Aさんの残高合計」や「Bさんの残高合計」を検証する必要がないため、並行処理も容易にできます（財布から1万円札を何枚も取り出し、複数のお店に同時で支払うイメージ）。
このような形式のため、ネットワークが拡大したとしても複数処理が可能で、効率的にトランザクションを処理することが可能です。
感覚的にわかりやすいのが、江戸時代に銭を束ねていた「銭貫（ぜにつら）」のイメージです。何本もの銭を束ねて所有し、使用する際には一束を分割して、必要な分を渡して残りを戻します。
（本来の使い方は1000枚単位などに揃えるものですが、UTxOを理解しやすい例だと思います）
「コンビニ店員さん」でUTxOを理解する
UTxOとアカウントベースの違いを、さらにわかりやすく理解するために、「コンビニ決済モデル」で考えてみましょう。
「アカウントベース店員」は、決済のたびにレジの金額をチェックする
アカウントベースモデルで支払う場合、支払側と受取側には、「合計金額」という概念しか存在しません。
ここで、「客＝支払側」「レジ＝受取手」「店員＝ネットワーク」として考えてみましょう。
————————————–
ウォレット残高
客 10,000円
レジ 140,000円
————————————–
という状態を仮定すると、このようなやりとりが生まれます。
【1,000円の支払いの場合】——————————-
客「1,000円支払います」
店員「1,000円の支払いですね、では両者ウォレットを出してください」
客「はい、10,000円のウォレット」
レジ「140,000円のウォレットです」
店員「はい。1,000円の支払いなので、お客様の残高は10,000-1,000＝9,000円になります。レジの残高は140,000+1,000円=141,000円となります」
客「はい、9,000円になりました」
レジ「141000円になりました」
——————————————————————–
アカウントベースの場合、このような形で店員さんが「両者のウォレットを確認し、それぞれの残高を計算する」というやりとりが発生します。
どちらのウォレットも「合計金額分のお札だけ」が入っているので、ウォレットの中身はいつもスッキリとスマートです。
「UTxO店員」は、合計金額を気にしない
それでは、UTxOの店員さんの場合を考えてみましょう。UTxOの場合は、ウォレットから取り出されたお金だけに注目します。さらに大きなポイントは、「客が自分で計算する」という点と「店員がお釣りを作る能力を持つ」という点です。
先ほどと同様、「客＝支払側」「レジ＝受取手」「店員＝ネットワーク」として考えてみましょう。
————————————–
ウォレット残高
客 5,000円、2,000円、2,000円、500円、200円、100円、100円、50円、50円
レジ 50,000円、50,000円、20,000円、10,000円、10,000円
————————————–
UTxOの場合、各ウォレットには様々な種類の「紙幣と硬貨」が混在していて、合計金額は計算しないとわかりません。
この場合のやりとりは、次のようになります。
【1,000円の支払いの場合】——————————-
客「では、この2,000円で支払います。このうち1,000円は自分、1,000円はレジに渡してください」
店員「はい。確かに2,000円なので、ご指示通り2000円を2枚に分けて、1,000円をお客様、1000円をレジにお渡しします」
客＆レジ：それぞれお金を受け取ってウォレットに入れて終了（残高は気にしない）。
——————————————————————–
このように、UTxOの場合は「それぞれのウォレットにお金を入れるだけで終了」します。ウォレット全体の残高をいちいち計算しないので、アカウントベースと比較して取引の工数が圧倒的に少なくなります。
そのかわり、各ウォレットにたくさんの紙幣や硬貨が入っているため、自分の残高を調べる場合に手間がかかります。
アカウントベース店員は、行列に対応できない
「アカウントベース店員」と「UTxO店員」の差は、田舎のコンビニではそれほど大きな差にならないかもしれません。
しかし、「都心の一等地にあるコンビニ（特にランチタイム）」では、どのようなことが起きるでしょうか？
アカウントベース店員の場合、
「はい、じゃあ両者残高を見せて！ お客さんの残高は○円で、レジは○円で…」
と、いちいち両者の合計金額を計算します。レジの残高に間違いがあると怖いので、１つのレジに対して１人のお客さんしか対応できません。
【トランザクションエラーが発生する場合】————-
客「1,000円支払います」
店員「1,000円の支払いですね、では両者ウォレットを出してください」
客「はい、10,000円のウォレット」
レジ「140,000円のウォレットです」
店員「はい。1,000円の支払いなので、お客様の残高は10,000-1,000＝9,000円になります。レジの残高は140,000+1,000円=141,000円となります」
客「はい、9,000円になりました」
レジ「えっ？ さっき別のトランザクションがあったから、141000円になりませんよ？」
店員「あ、そうなんですね。お客様、やり直しになるので、もう一度後ろに並んでください」
客「えーっ!? 」
——————————————————————-
このようなエラーを避けるために、アカウントベース店員さんは「1取引ずつ」対応するように心がけます。
UTxO店員は行列でも気にしない
UTxO店員の場合、「お客さん、先にお金とお釣り計算しといてね！」とお願いしておき、「受け取ったお金を指示通りに分割して両者に戻す」だけで終了します。
お釣りはもらったお金から作ることができるので、レジから取り出す必要はありません。レジの残高をまったく気にする必要がないので、複数の店員が同じレジにお金をどんどん入金しても問題が起きません。
都心の一等地のコンビニでは、UTxO店員の方が一度にたくさんの客に対応できる、ということがわかります。
拡張UTxO（EUTxO）が可能性を最大化させる
UTxOモデルはネットワーク拡張に有利な一方で、「台帳の構造が複雑でスマートコントラクトができない」という点がありました。
その一方で、アカウントベースモデルではグローバルなスケールで稼働した場合にトラブルが起きやすいと言う問題がありました。
そこで、InputOutoputでは、その両面を解決する研究を行い、スマートコントラクトが実装可能な「拡張UTxOモデル」を考案しました。
拡張UTxOでは、UTxOアドレスの「鍵と錠」の概念に変更を加えたほか、格納データや出力アドレスのロジック変更などを行うことで、UTxOの機能を拡張しスマートコントラクトの実行に成功しています。
少し難しいですが、拡張UTxOでは下記の３項目が「拡張」されています。
1.【UTxOをスクリプト形式に】「錠（ロック）と鍵（キー）」のアナロジーを用いて「アドレス」の概念を一般化。拡張UTxOモデルでは、アドレスは「錠を公開鍵」「鍵を署名」のように制限することはなく、「スクリプトの形で任意のロジックを含む」ことができます。例えば、ノードがトランザクションを検証するとき、ノードはトランザクションがある出力（アウトプット）を入力（インプット）として使用できるかを判断します。トランザクションは、出力アドレス内のスクリプトを検索し、そのトランザクションが「未使用トランザクション出力（アウトプット）」を「トランザクション入力（インプット）」として使用できる場合に、そのスクリプトを実行します。
2.【格納データの拡張】拡張UTxOでは、従来の「アドレス」と「値」という２つのデータだけでなく、（ほぼ）任意のデータを伝送できるようにしています。これによりスクリプトは「state information（状態情報）」を持つことができ、より強力な使い方が可能になります。
3.【カスタムデータで取引を判断】 拡張UTxOでは、「どのトランザクションがそれらをアンロックできるか」をロジックで決定し、すべてのUTxOにカスタムデータを追加しています。アドレスを検証する際には、スクリプトは、
・「出力（アウトプット）によって運ばれるデータ
・検証されるトランザクション
・「リディーマー（トランザクションの入力データの追加データ）
を使用します。
これらの情報をすべて参照することにより、スクリプトは高度に複雑な状況やユースケースに対して「Yes」「No」の回答を与えることが可能になります。
このように、拡張UTxOでは各データ領域を拡張しロジック変更を加えることで、拡張性の高いUTxOモデル上で複雑なトランザクションに対応できるようにしています。
「UTxO」×「プログラム機能」＝無限の拡張性！
拡張UTxOは、「並行処理が可能なUTxO」と「トランザクションがプログラム可能なアカウントベースモデル」のそれぞれのメリットを兼ね備えたハイブリッドな会計モデルです。
トランザクションは、ブロックチェーン全体を考慮する必要がなくUTxO単位のみで完結するため、ネットワークの負荷を最小限にとどめます。
各トランザクションは他のトランザクションの影響を受けないため、失敗することがありません。入力された取引処理は各UTxOごとに処理されるため、並行して処理することができます。
また、トランザクションの入力前に使用するUTxOのみで検証が可能なため、手数料を正確に予測することができます。
一方、アカウントベースモデルにおいては並行処理が難しく取引エラーが起きやすいほか、予期せぬ高額な手数料が生じることがあります。
また、IOHKの研究では、アカウントモデルにおいて取引エラーが起こりやすいことを利用した攻撃についても指摘しており、拡張UTxOの安全性の高さが確認されています。
拡張UTxOは、単純にL1における処理能力を高めているだけでなく、L2やサイドチェーンとも容易に連携できる特徴もあります。つまり、オフチェーンにおけるスケーラビリティ拡大においても、アカウントベースモデルよりも大きな可能性を秘めているのです。
拡張UTxOモデルこそ、カルダノの根幹にして真髄
会計モデルは、アカウント記録やトランザクションロジックを決定するものであるため、ブロックチェーンの根幹と言えます。そのため、途中で「UTxOからアカウントベースに変更する」ことはほぼ不可能であり、もしできたとしても、それは全く別物のブロックチェーンと言わざるを得ないでしょう。
カルダノでは、「UTxOモデル」と「アカウントベースモデル」を徹底的に研究した結果「UTxOモデルにスマートコントラクトを実装する方が、安全性と拡張性が高い」と結論づけ「拡張UTxOモデル」を開発しました。
ビットコインの場合、1997年に発表されていたUTxOモデルを活用していますが、カルダノの場合、拡張UTxOモデルを新たに開発して採用しました。つまりIOHK（当時）は、ブロックチェーンの根幹部分である「会計モデルの新開発」からプロジェクトをスタートしたのです。
2017年にようやくリリースされ「開発が遅い」と言われたカルダノですが、その理由は世界のどこにも存在しなかった技術が組み込まれていたからです。
その結果、カルダノは2023年において「PoS」「完全な流動性ステーキング」「スマートコントラクト」を次々に実装し、非常に安価な手数料でトランザクションを実行できる環境を維持しています。
もしカルダノが、時間をかけず安易にアカウントベースモデルを採用していたら「イーサキラー」と呼ばれるその他のチェーンの一角にすぎず、埋もれてしまっていたでしょう。
拡張UTxO（eUTxO）こそが、カルダノの出発点であり、将来の拡張性をさらに高める決定的な違いなのです。
参考：https://docs.cardano.org/learn/eutxo-explainer
画像出展：https://ucarecdn.com/3da33f2f-73ac-4c9b-844b-f215dcce0628/EUTXOhandbook_for_EC.pdf
本稿はカルダノステークプール「CoffeePool☕️」「CardanoKissa☕️」が作成しました。
COFFEの活動を応援いただける方はぜひ、委任（Delegate）のご検討をお願いいたします😊
🗳️「DRep ID」もぜひご検討ください！（クリックでコピーできます↓）
CoffeePoolならびにKISSAは、5年以上の安定稼働と1万ブロック以上の生成実績を持つステークプールです。
初心者でも長期ホルダーでも、楽しくカルダノ について語り合える discordスペースを作りました😊☕️
・なりすましやscam対策のためXアカウント認証で運営😊
・初心者ホルダーさん大歓迎！☕️
SPOも続々参加しています！ ぜひお気軽にお立ち寄りください。
参加方法は☟
discord.gg/TNy7QNua7c
