BTCからスイ、ADA、ネルボスまで：UTXOモデルとその関連拡張機能

出典：Geek Web3

ビットコインの中核的な設計原理の1つとして、UTXOモデルはブロックチェーン空間において、その設立当初から重要な技術的パラダイムとなっています。UTXOモデルは、取引の安全性とトレーサビリティを保証する上で重要な役割を果たすと同時に、従来の口座残高モデルに代わる道を提供している。近年、ブロックチェーン技術が絶え間なく更新と反復を繰り返しているため、UTXOモデル自体も進化と拡大を続けています（eUTXO、セル、厳密アクセスリストなど）。

この記事では、UTXOモデルを学び、理解することを目的とし、分かりやすく、BTCからSui、Cardano、Nervos、FuelまでのUTXOモデルとその実装を簡単に説明します。

UTXOとは

UTXOモデルは、例を通して理解することができます：

アリスとボブの2人がいるとします。彼らはもともと5ドルずつ持っていた。その後、争いが起こり、アリスはボブに2ドルを奪われます。二人が最終的に手にした金額は以下の通りです。

アリスが3ドル、ボブが7ドルになったことは簡単にわかります。この小学校の足し算と引き算のような簿記は、銀行システムで頻繁に見られ、「口座/残高モデル」として知られています。このモデルでは、口座の残高は1つの値として存在する。

アリスとボブの間で起こる富の移転を、UTXOのような口座モデルとは異なる方法で表すと、図式は異なって見えます：

この時点で。アリスには3ドル、ボブには7ドルが残っていますが、7ドルは単一の値で表されるのではなく、「5ドル」と「2ドル」に分割されています。この型破りな方法に違和感を覚えないだろうか？これが特殊な簿記、UTXOなのだ。

UTXO English full Unspent Transaction Outputの略で、「Unspent Output」のことです。この記帳方法では、各オンチェーン取引はUTXOの変更と転送として表現されます。例えば、上記のトランザクションイベントでは、アリスが入力パラメータとして最初に所有する「5 bucks」はUXTO_0とラベル付けされ、その後破棄されます。「3ドル」(UTXO_2)が出力パラメータとして生成され、UTXO_1はボブに転送され、UTXO_2はアリスに転送され、アリスとボブの間の富の移動が完了します。

実際、UTXOモデルでは、「口座」と「残高」というものは存在しません。"UTXOはトランザクションの実行を助けるデータ構造に過ぎず、それが表す金額や関連するトランザクションのインデックスなどの情報を記録する。各UTXOは、定義された所有者とともに使用される可能性があるが、使用されないトランザクション入力を表す。トランザクションが発生すると、特定のUTXOは入力として使用することができ、それらの破壊はトランザクション出力として新しいUTXOを生成する。

これがビットコインの簿記の仕組みです。取引が発生するたびに、古いUTXOが破壊され、新しいUTXOが生成されます。破壊されたUTXOの総量は、新しく作成されたUTXOの量に等しい（その一部はマイナーの手数料となる）。このようにして、誰も何もないところから追加の資金を発行することはできません。

UTXOモデルと口座/残高モデルの比較

一度に大量の取引要求を開始するバッチユーザーがいるとします。トランザクションを処理するためにUTXOモデルとAccount/Balanceモデルを使用して別々に処理された場合、どのような状況になるでしょうか？

アカウント/残高モデルでは、各ユーザーは残高情報が記録されたアカウントを持っています。トランザクションが発生すると、対応する口座の残高が更新されます。しかし、2つのトランザクションが同じアカウントを含む場合、読み取りと書き込みの競合、すなわち状態の競合がしばしば発生し、これは避けなければならない状況である。

伝統的なデータベースシステムは、「ロック」メカニズムによって、データのある部分に対する読み取りと書き込みの競合を解決する傾向があります。このシナリオでは、データ競合関係を構成する複数のトランザクションがキューに入れられ、同時に実行できないことが多く、トランザクション処理の効率が悪くなります。処理すべきトランザクションの数が多い場合、上記の状況は深刻な性能ボトルネックにつながる可能性があり、互いにデータ競合関係にあるトランザクションは長い間待ち状態になり、迅速に処理できないことがあります。

ビットコインのUTXOモデルは、アカウントバランスモデルよりもデータ競合の問題をうまく解決します。

UTXOモデルはアカウントバランスモデルよりもデータ競合の問題をうまく解決します。このモデルでは、各トランザクションはもはや「アカウント」によって直接処理されるのではなく、個々のUTXOによって処理され、UTXOは互いに干渉しないため、ビットコインネットワークの各トランザクションは互いに干渉しません。その結果、ビットコインネットワークノードは「ロック」を必要とせずに、保留中の多数のトランザクションを同時に処理することができ、スループットと通貨パフォーマンスを大幅に向上させることができます。

さらに、UTXOモデルの暗号ウォレットは通常、ユーザーがトランザクションを開始した後に新しいアドレスを生成するため、プライバシーが確保されます。-固定アドレスを使用するため相関関係による分析が容易な口座/残高モデルとは対照的に、取引を特定の人物と関連付けることが難しくなります。

しかし、UTXOには限界があります。UTXOはもともと単純な通貨移動を可能にするために設計されたものであり、複雑なビジネスロジックを扱うためのものではありません。 マルチシグネチャやタイムロックのような機能のいくつかの単純な実装はスクリプト言語で行うことができますが、ビットコインのUTXOによって記録できる初歩的な状態情報は、複雑な操作のいくつかを実行することを意図していません。

ビットコインのUTXOの限界は、間接的に「イーサリアム」の創設につながりました。その欠点は、ビットコイン・マガジンの初期の寄稿者の一人であるVitalik氏もよく認識していました。アカウント／バランスモデルは、多くの人にとって理解しやすいだけでなく、リッチステート・アプリケーションを扱う際のUXTOのジレンマも解決してくれる。UTXOは使用することも、使用しないこともできます。多段契約や、他の内部状態を保存するスクリプトの可能性はありません。このため、マルチステージのオプション契約、分散化された取引相場、2ステージの暗号化コミットメントプロトコル（賞金を安全に計算するために必要）を作成することは難しい。また、UTXOは、分散型組織のような複雑な "ステートフル "コントラクトではなく、単純な一回限りのコントラクトの構築にしか使えないため、メタ・プロトコルの実装が難しくなる。バイナリステートとバリューブラインドネスの組み合わせは、もう一つの重要なアプリケーションである引き出し制限の実装が不可能であることも意味します。

UXTOモデルの応用、最適化、および拡張

UXTOのさまざまな応用と最適化を取り上げる前に、UXTOがその利点を維持したまま、どのような改善を行ったかを分析する必要があります。

1.UTXOによって保存された状態の意味の抽象化。

2.状態の所有権の抽象化。

3.共有UTXOの状態競合問題の解決。

BTCでは、状態の意味はトークンの数だけで、所有権は通常公開鍵で定義されます。 状態の競合に関しては、BTCはdapps用に設計されていないので、あまり扱われません。

Sui

Suiは開発者に2種類のオブジェクトを提供します：UTXO（より詳細にはUTXO）に相当するOwnedObjectと、SharedObjectです。前者はUTXO（より具体的にはUTXOの拡張版）に相当し、後者はアカウント/バランスモデルに相当します。

Objectは共有することができます。これは、誰でも読み書きできることを意味します。SharedObjectは、読み書きの順序を決めるためにコンセンサスを必要とします。

他のブロックチェーンでは、すべてのObjectが共有されます。しかし、Suiのプログラマーは、特定のユースケースを実装するために、OwnedObject、SharedObject、またはその両方を組み合わせるという選択肢を持つことがよくあります。この選択は、パフォーマンス、セキュリティ、実装の複雑さに影響を与える可能性があります。

Suiでは、OwnedObjectは、その所有者であるOwnerだけが操作できるという点で、UTXOに類似しており、Objectは、「オブジェクトの特定のバージョンは、その所有者によって一度しか使用できない」ように、バージョン番号が付けられています。

Cardano

Cardano は、eUTXOと呼ばれる拡張UTXOモデルを使用しています。eUTXOはより高度なプログラマビリティをサポートし、ビットコインUTXOモデルの利点を備えています。

カルダノでは、状態の意味はスクリプトによってさらに拡張され、状態の所有権はより一般的な方法で定義され、UTXOセットを使用して状態の競合を最小限に抑えます。要約すると、eUTXOは2つの点で強化されています:

1.eUTXOモデルにはより一般的なアドレスがあり、公開鍵のハッシュだけでなく、eUTXOを使用できる条件を定義する任意のロジックに基づいて、状態の所有権をプログラムできます。

2.アドレスと値に加えて、出力は（ほぼ）任意のデータを運ぶことができます。

具体的には、eUTXOでは、Datumと呼ばれるJSONのような形式で、ユーザーが任意のデータをUTXOに追加することができます。Datumにより、開発者は、特定のUTXOに関連付けられた状態のような機能をスクリプトに提供することができます。

同時に、カルダノ上のトランザクションは、Redeemerと呼ばれる特定のユーザーに関連付けられたパラメータを持つことができます。 Redeemerは、トランザクションの開始者がUTXOの使用方法を定義することを可能にします。ダップ開発者はこれをさまざまな目的で利用できます。

トランザクションが検証されるとき、検証スクリプトはDatum、Redeemer、およびトランザクションデータを含むコンテキストで動作し、そのスクリプトには条件が満たされたときにUTXOを使用するロジックが含まれます。

eUTXOは依然としてスクリプトによる拡張であり、従来の「スマートコントラクト」（創設者のチャールズ・ホスキンソン氏は、実際には「プログラマブルバリデータ」と呼ぶべきだと考えている）とは大きく異なることに注意することが重要です。")、しかし「スマート・コントラクト」という用語の方が市場に受け入れられやすい。

Nervos

Nervos（つまりCKB）では、状態の意味はタイプスクリプトによって抽象化され、その状態の所有権はロックスクリプトによって抽象化されます。lockscriptの抽象化、シンプルなUTXO最適化モデル - cell コードは以下のようになります:

    pub struct CellOutput {

        pub data: Vec<u8>,

          pub lock: Script,

        pub type_: Option<Script>,      }

また、状態競合の問題については、現在のCKBプッシュ研究はOpen Transactionであり、ユーザはUTXOの一部を前に出すことができますトランザクションの目的を指定します。

NervosのセルモデルはUTXOの「一般化」バージョンであり、その詳細な説明はNervosのフォーラムでJanによって説明されています：

レイヤー1はすべて状態に関するものであり、レイヤー1を念頭に置いて設計されたCKBの設計がすべて状態に関するものであることは当然のことです。イーサリアムは、トランザクションの履歴とステートの履歴を2つの次元に分け、ブロックとトランザクションは、ステートそのものではなく、ステートの移行のトリガーとなるイベントを表現しています。一方、ビットコインのプロトコルは、トランザクションとステートを1つの次元にまとめ、トランザクションはステートであり、ステートはトランザクションであり、ステート中心のアーキテクチャとなっています。

同時に、CKBが検証し、長期的に保存したい状態は、単純な数値（nValue）ではなく、人々が価値を見出すあらゆるコンセンサスデータです。nValueを整数を保持する空間から、任意のデータを保持できる空間に一般化するだけで、より一般的な "CTxOut "を得ることができます。

Cellの内部では、nValueはcapacityとdataになり、これらは一緒になって記憶空間の一部を表します。capacityは空間の大きさ（バイト単位）を表す整数で、dataは状態が保存される場所で、任意のバイトを書き込むことができます；scriptPubKey は別の名前を持つロックになり、誰がコンセンサス空間を所有するかを 表す。ロックスクリプトが正常に実行されるためのパラメータ（署名など）を提供でき る人だけが、セル内の状態を「更新」することができる。CKBには多くのセルがあり、その集合がCKBの完全な現在の状態を形成する。CKBの現在の状態は任意の共通知識を保存しており、もはや単なるデジタル通貨ではない。

トランザクションは、依然として状態の変更/移動を表します。状態の変更、つまりセルの内容に対する「更新」は、実際には破棄と作成によって行われます（元のセルの内容を実際に変更するわけではありません）。新しく作成されたセルは新しい所有者を持ち、新しいデータを保持するが、破壊された容量の合計は常に作成された容量の合計より大きくなる。セルの破壊は、ビットコインのUTXOと同様に、未使用から使用済みへと「破壊された」ことを示すだけであり、ブロックチェーンから削除されることはない。セルは一度しか破壊できない。各UTXOが一度しか使用できないのと同じように、各セルは一度しか破棄できません。

このようなモデルの特徴は以下の通りです：

1.状態が第一。

2.所有者は状態のプロパティであり、状態のコピー1つにつき所有者は1人だけです。

3.状態は常に破壊され、創造される。

つまりCellはUTXOの一般化版である。

Fuel

Fuelは、UTXO最適化に基づくStrictアクセスリストモデルを採用しています。

前述したように、BTCのUTXOはコインの数と所有者という2つのプロパティしか持ちませんが、コントラクトUTXOはコインの数、コントラクトID、コントラクトコードハッシュ、ストレージルートなど、より基本的なプロパティを提供します。

ステートレス実行モデルでは、コントラクトコードハッシュとストレージルートは、コントラクトUTXOでのみ必要です。ステートフル実行モデルでは、コントラクトUTXOはこれらのフィールドを省略できますが、別のストレージ要素UTXOタイプが必要です。UTXO ID（各UTXOの一意の識別子で、キーバリューストアデータベースのキーとして使用できます）は、UTXOが生成されたOutput Point、またはそのバリアント（Output Pointとそのフィールドのハッシュなど）です。

このモデルでは、スマートコントラクトのように、コントラクトUTXOは誰でも起動可能です。

Fuelはスクリプトよりもスマートコントラクトに近い機能を提供し、UTXO独自のモデルの制限により、VMに基づくアプリケーションの構築が難しくなっていることに注意することが重要です。特にUTXOの競合は、3つの一般的な方法で解決できます。1つ目は、Rollupのようにオフチェーンで処理する方法、2つ目は、Fuelが行っているような余分なソート作業を事前に行う方法、3つ目は、後者です。Fuelは後者を採用しています。3つ目は、CKBのセクションで言及したOpen Transactionです。つまり、各ユーザーはトランザクションの一部に言及することができ、その後、アグリゲーター（シーケンサーに似ています）が、それを完全なトランザクションに集約します。

< span mpa-is-is-tpl="t">

終了

UTXOの基本原則を理解することを通して、そのモデルとETHのアカウント/バランスモデルの利点と欠点を知り、UTXOの概念とそれに関連する拡張についてより明確に理解することができます。

ビットコインの中核的な設計原理の1つとして、UTXOモデルは取引のセキュリティとトレーサビリティを保証する上で重要な役割を果たしています。 ブロックチェーン技術の継続的な発展に伴い、UTXOモデルも進化・拡大しており（EUTXO、セル、厳格アクセスリストなど）、デジタル資産により多くの取引と管理の可能性を提供しています。UTXOのコンセプトとそれに関連する拡張について深く研究し理解することで、ブロックチェーン技術の本質をよりよく把握し、将来の革新と応用に向けてより強固な礎を築くことができる。