BTCからSui、ADA、Nervosへ:UTXOモデルとエクステンション

ビットコインのコア設計原則の1つとして、UTXOモデルは、その開始以来、ブロックチェーンドメインにおける重要な技術パラダイムとなっています。 これは、トランザクションのセキュリティとトレーサビリティを確保する上で重要な役割を果たし、従来の口座残高モデルを超えた代替パスを提供します。 近年のブロックチェーン技術の継続的な進化と拡大に伴い、UTXOモデル自体は、eUTXO、セル、ストリクトアクセスリストなど、絶え間ない進化と拡張を経ています。

この記事では、UTXOモデルの概要とBTC、Sui、Cardano、Nervos、Fuelの実装方法を簡単に説明し、UTXOモデルを平易な言葉で紹介します。

UTXOとは?

UTXOモデルを説明するために、例を使用します。

Alice と Bob という 2 人の個人が、最初はそれぞれ $5 を持っているとします。その後、争いが起こり、アリスはボブに2ドルを奪われました。 それぞれの最終的な保有額は次のとおりです。

アリスが最終的に3ドルになり、ボブが最終的に7ドルを持っていることは明らかです。 この初歩的な算術のような会計方法は、銀行システムで一般的に見られ、「勘定/残高モデル」と呼ばれます。 このモデルでは、勘定科目の残高は 1 つの数値として存在します。

アリスとボブの間の富の移転をUTXOで表現するなど、アカウントモデルとは異なるアプローチを採用すると、イラスト図は異なる外観になります。

この時点では、Alice はまだ $3 を持っていて、Bob はまだ $7 を持っていますが、これらの $7 は 1 つの数値で表されていません。 代わりに、「$5」と「$2」に分類されます。 この型破りなアプローチは、やや馴染みがないと感じますか? これは、UTXOとして知られる独自の会計方法です。

英語の頭字語UTXOは、未使用のトランザクション出力の略です。 このアカウンティングアプローチでは、各オンチェーントランザクションはUTXOの変更と転送として現れます。 たとえば、前述のトランザクションイベントでは、アリスが最初に所有していた「$5」が入力パラメータとして機能し、UTXO_0とラベル付けされ、使用済みとしてマークされます。同時に、出力パラメータとして「$2」(UTXO_1)と「$3」(UTXO_2)が生成されます。 UTXO_1はボブに譲渡され、UTXO_2はアリスに返還され、アリスとボブの間の富の移転が完了します。

UTXOモデルでは、「アカウント」と「残高」の明確な概念はありません。 UTXOは、トランザクションの実行を支援するデータ構造として機能し、それが表す金額や関連するトランザクションインデックスなどの情報を記録します。 各UTXOは、指定された所有者を持つ未使用のトランザクションインプットを表します。 トランザクションが発生すると、特定のUTXOをインプットとして使用でき、破棄されると、新しいUTXOがトランザクションアウトプットとして生成されます。

これはビットコインがアカウントを保持する方法です:各トランザクションで、古いUTXOは破棄され、新しいUTXOが作成されます。 破壊されたUTXOの総量は、新しく作成されたUTXOの量と等しくなります(一部はマイナーへの取引手数料として割り当てられます)。 これにより、資金を恣意的に増やすことができなくなります。

UTXOモデルとアカウント/バランスモデルの比較

ユーザーのグループが多数のトランザクション要求を同時に開始するとします。 UTXOモデルを使用すると、アカウント/バランスモデルと比較して、状況はどのように処理されますか?

アカウント/残高モデルでは、各ユーザーは残高情報が記録されたアカウントを持っています。 トランザクションが発生すると、対応する口座残高を更新する必要があり、「読み取り」操作と「書き込み」操作の両方が含まれます。 ただし、2 つのトランザクションに同じアカウントが含まれる場合、読み取りと書き込みの競合が発生することが多く、状態の競合が発生するため、回避する必要があります。

従来のデータベースシステムでは、通常、読み取り/書き込みの競合に「ロック」メカニズムで対処します。 このようなシナリオでは、同じデータの競合を引き起こすトランザクションをキューに入れる必要があることが多く、同時実行が妨げられ、トランザクション処理の効率が低下します。 処理を待っているトランザクションが多数ある場合、競合中のトランザクションは迅速な処理なしで長時間の待機時間に直面し、パフォーマンスの大きなボトルネックが生じる可能性があります。

口座残高モデルとは対照的に、ビットコインのUTXOモデルは、データ競合の問題を処理するための設備が整っています。 このアプローチでは、各トランザクションの直接処理エンティティは、もはや特定の「アカウント」ではなく、個別の独立したUTXOです。 異なるUTXOは互いに干渉しないため、ビットコインネットワーク内の各トランザクションは独立して動作します。 その結果、ビットコインネットワークノードは「ロック」を必要とせずに複数のトランザクションを同時に処理できるため、システムのスループットと同時実行のパフォーマンスが大幅に向上します。

さらに、UTXOモデルでは、暗号化されたウォレットは通常、トランザクションの開始後にユーザーの新しいアドレスを生成します。 このアプローチにより、プライバシーが強化され、トランザクションを特定の個人に関連付けることがより困難になります。 対照的に、固定アドレスを利用する勘定/残高モデルは、アソシエーション分析の影響を受けやすくなります。

ただし、UTXOモデルには制限があります。 当初は単純な通貨送金を容易にするために設計されており、複雑なビジネスロジックの処理には適していません。 マルチシグやタイムロックなどの基本的な機能はスクリプト言語を使用して実装できますが、ビットコインのUTXOが記録できる最小限の状態情報により、より複雑な操作を処理する能力が低下します。

ビットコインのUTXOの制限は、間接的に「イーサリアム」の出現に貢献しました。 ビットコインマガジンへの初期の寄稿者の1人であるヴィタリックは、ビットコインの欠点をよく知っていました。 ほとんどの人にとって理解しやすいアカウント/残高モデルは、リッチステートアプリケーションを処理する際にUTXOが直面する課題に対処します。 ヴィタリックはイーサリアムのホワイトペーパーで次のように述べています。

UTXOは、使用済みまたは未使用のいずれかです。多段階のコントラクトやスクリプトは、それ以上の内部状態を保持する機会はありません。 これにより、多段階のオプション契約、分散型取引所のオファー、または2段階の暗号コミットメントプロトコル(安全な計算報奨金に必要)を作成することが困難になります。 また、UTXOは単純な1回限りのコントラクトの構築にのみ使用でき、分散型組織などのより複雑な「ステートフル」コントラクトには使用できないため、メタプロトコルの実装が困難になります。 二元論状態と価値盲目性が組み合わさると、もう一つの重要な適用である引き出し制限が不可能であることも意味します。

UXTOモデルの適用、最適化、拡張

UTXOモデルのさまざまなアプリケーションや最適化を掘り下げる前に、その利点を維持しながら改善すべき領域を分析してみましょう。 これらをまとめると、次のようになります。

1. UTXOに格納された状態の意味を抽象化します。

2. 状態の所有権を抽象化します。

3. UTXOを共有する際の状態競合の問題を解決します。

BTCでは、状態の唯一の意味はトークンの数量であり、所有権は通常公開鍵を使用して定義され、BTCはdApps用に設計されていないため、状態の競合は広く対処されません。

隋

Sui は、OwnedObject と SharedObject の 2 種類のオブジェクトを開発者に提供します。 前者はUTXO(具体的には拡張版)に似ており、後者はアカウント/バランスモデルに相当します。 両方を同時に使用できます。

オブジェクトは共有できるため、誰でもそのオブジェクトを読み書きできます。 変更可能な OwnedObject (ライターが 1 つしかない) とは異なり、SharedObject では、読み取りと書き込みの順序付けにコンセンサスが必要です。

他のブロックチェーンでは、すべてのオブジェクトが共有されます。 ただし、Sui 開発者は通常、OwnedObject、SharedObject、またはその両方の組み合わせを使用して、特定のユースケースを実装できます。 この選択は、パフォーマンス、セキュリティ、および実装の複雑さに影響を与える可能性があります。

Suiでは、所有オブジェクトはUTXOに似ており、所有者のみが操作できます。 オブジェクトにもバージョン番号があり、オブジェクトのバージョンは、その所有者が一度しか使用できません。 したがって、オブジェクトのバージョンは基本的にUTXOに対応します。

状態の競合の問題に関して、Sui は SharedObjects の特別な処理 (Fuel に似たローカル順序付け) を通じて対処します。

カルダノ

カルダノは、eUTXOと呼ばれる拡張UTXOモデルを利用しています。 eUTXOは、ビットコインUTXOモデルの利点を維持しながら、プログラマビリティの向上をサポートします。

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

1. eUTXOモデルには、より一般化されたアドレスが含まれています。 これらのアドレスは、公開鍵のハッシュのみに基づいているのではなく、eUTXOを使用できる条件を指定する任意のロジックに基づいて定義することができ、州の所有権のプログラマビリティを可能にします。

2. アドレスと値に加えて、出力は(ほとんど)すべてのデータを運ぶことができ、スクリプトを介して状態の意味をプログラミングできます。

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

さらに、カルダノでのトランザクションは、償還者と呼ばれる特定のユーザーに関連するパラメーターを運ぶことができます。 Redeemerは、トランザクションのイニシエーターがUTXOの利用方法を定義することを可能にし、dApp開発者が様々な目的で使用することができます。

トランザクションが検証されると、検証スクリプトは、データム、リディーマー、およびトランザクションデータを含むコンテキストを使用して動作します。 このスクリプトには、条件が満たされた場合にUTXOを使用するためのロジックが含まれています。

注目すべきは、eUTXOは依然としてスクリプトを通じて拡張タスクを実現し、従来の「スマートコントラクト」の概念とは大きく異なることです(創設者のチャールズ・ホスキンソンはこれを「プログラム可能なバリデーター」と呼ぶことを提案していますが、「スマートコントラクト」という用語の方が市場で広く受け入れられています)。

ネルボス

Nervos (CKB) では、状態の意味は TypeScript によって抽象化され、状態の所有権はロックスクリプトによって抽象化されます。 セルコード形式の単純なUTXO最適化モデルは次のとおりです。

pub struct CellOutput {

    pub capacity: 容量、

pub データ: Vec、

pub lock: スクリプト、

pub type_: オプション、

}

ステートコンテンションの問題としては、現在、ユーザーがトランザクションの目的を明記した部分的なUTXOを提案し、マッチメイカーがそれらを集約して完全なトランザクションに仕上げるオープントランザクションの研究を進めています。

Nervosの細胞モデルはUTXOの「一般化」バージョンであり、Jan氏はNervosフォーラムで詳細な説明を行った。

Layer1 の焦点は状態であり、Layer1 を設計ターゲットとして、CKB は自然に状態に焦点を合わせます。

イーサリアムは、トランザクション履歴と状態履歴を2つの次元に分けており、ブロックとトランザクションは、状態そのものではなく、状態遷移をトリガーするイベントを表します。 対照的に、ビットコインプロトコルはトランザクションと状態を単一の次元にマージします—トランザクションは状態であり、状態はトランザクションです。 州を中心とした建築です。

同時に、CKBは、国家としてのnValueだけでなく、価値があり、コンセンサスで承認されたデータを検証し、保存することを目指しています。 ビットコインのトランザクション出力構造は、この目的には不十分ですが、私たちに十分なインスピレーションを与えてくれました。 nValue を一般化し、整数を格納する空間から任意のデータを保持できる空間に変換することで、より一般化された "CTxOut" または Cell が得られます。

Cell では、nValue は容量とデータの 2 つのフィールドになります。 これらのフィールドは、容量が空間のサイズをバイト単位で示す整数であり、data が状態が格納され、任意のバイト シーケンスに対応できる場所であるストレージ領域を共同で表します。 scriptPubKey は、このコンセンサス空間の所有者が誰であるかを表す名前の変更だけで lock になり、ロックスクリプトを正常に実行するためのパラメーター (署名など) を提供できる人だけが、この Cell の状態を "更新" できます。 CellOutput 全体で占有される合計バイト数は、容量以下である必要があります。 CKBには多数のセルがあり、そのコレクションはCKBの完全な現在の状態を形成し、特定のデジタル通貨だけでなく、共有された知識を保存します。

トランザクションは、引き続き状態の変更/移行を表します。 状態の変化、つまりセルの内容の「更新」は、実際には(元のセルの内容を直接変更することによってではなく)破棄と作成によって行われます。 各トランザクションは、セルのバッチを効果的に破棄すると同時に、新しいセルのバッチを作成します。 新しく作成されたセルには新しい所有者がいて、新しいデータが格納されますが、破棄される合計容量は常に作成された合計容量以上であるため、誰も容量を任意に増やすことはできません。 容量は転送できますが、任意に増やすことはできないため、容量を所有することは、対応する量のコンセンサス状態空間を所有することと同等です。 容量は、CKBネットワークのネイティブ資産です。 セルの破壊は、未使用のビットコインUTXOが使用済みになり、ブロックチェーンから物理的に削除されない方法と同様に、単に「破壊された」とマークされます。 各UTXOが1回しか使用できないのと同じように、各セルは1回しか破壊できません。

このモデルの特徴は次のとおりです。

1. 状態は最も重要です。

2. 所有権は状態の属性であり、各状態には 1 つの所有者がいます。

3. 国家は絶えず破壊され、創造される。

したがって、セルはUTXOの一般化されたバージョンです。

燃料

Fuelは、Contract UTXOの概念に基づくUTXO最適化であるStrict Access Listモデルを採用しています。

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

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

このモデルでは、スマートコントラクトと同様に、Contract UTXOは誰でも呼び出すことができます。

Fuelは、スクリプトよりもスマートコントラクトに近い機能を提供していることに注意する必要があります。 UTXOモデル自体の制限により、VMを使用したアプリケーション開発は、特にUTXOの競合の問題を処理する上で困難になります。 一般的に3つの解決策があります:まず、ロールアップなどのオフチェーンで処理します。第二に、Fuelが採用している事前シーケンシングの追加作業。第3に、CKBにおける上記のオープントランザクションでは、各ユーザーが部分的なトランザクションを提案し、マッチメーカー(シーケンサーのようなもの)がそれらを完全なトランザクションに結合します。 BTCの対応するソリューションはPBSTです。

結論

この記事から、UTXOの基本原理を理解し、イーサリアムのアカウント/バランスモデルと比較したUTXOモデルの長所と短所を認識し、UTXOの概念とそれに関連する拡張機能についてより明確な洞察を得ることができました。

ビットコインのコア設計原則の1つとして、UTXOモデルはトランザクションのセキュリティとトレーサビリティを確保する上で重要な役割を果たします。 ブロックチェーン技術の継続的な進化と拡大に伴い、UTXOモデル(EUTXO、セル、Strict Access Listなど)が開発されており、デジタル資産の取引と管理により多くの可能性を提供しています。 UTXOのコンセプトとそれに関連する拡張の詳細な調査と理解を通じて、ブロックチェーン技術の本質をよりよく把握し、将来のイノベーションとアプリケーションのためのより強固な基盤を築くことができます。

免責事項：

1. この記事は【极客Web3】からの転載ですが、すべての著作権は原作者【0xAyA】に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。