Ordinals vs Taro: ビットコイン第2層ネットワークの実現可能性について - 上篇

作者：3P Labs

一、はじめに

Bitcoinは最も古く、最も安全なブロックチェーンであり、使用されているUTxOアカウントモデルにより、Ethereumのようなスマートコントラクト機能をサポートするのが難しく、限られたスクリプト言語に基づく機能しかサポートできませんでした。そのため、Bitcoinが誕生してから15年間、Ethereum上のさまざまな目を見張るようなDeFiプロトコルやNFTを実現するためには使用されず、通常はピアツーピアの送金や価値の保存に使われてきました。

2022年12月14日に正式に開始されたOrdinalsプロトコルは、これを一変させました。これは、ユーザーがチェーン上に保存する必要のあるメタデータをトランザクション入力に挿入し、序数理論[\^1]に基づいてこれらの「刻印（Inscriptions）」を追跡し記録するプログラムを実現しました。このような「刻印」は、Ethereumのスマートコントラクトのように動的に実行されるチェーン上のプログラムではなく、静的なメタデータを記録することを実現しました。これにより、「刻印」は自然にBitcoin上のNFTとなりました。また、序数理論に基づいて、人々はこれらの刻印間の移転や取引を実現するためのトランザクションを構築することも可能になりました。

その後、2023年3月6日に、Ordinalsに基づくBRC-20プロトコルが提案され、Bitcoin上の同質化トークンを実現するために使用され、Ethereum上のERC-20プロトコルに対応しました。このようなOrdinalsに基づくプロトコルは非常にシンプルで、トークンの発行や移転のプロセスをJSON形式で刻印に書き込むことができます。最も象徴的な比喩は、送金記録が書かれた紙の束であり、記帳の作業は第三者機関に任せるというものです。

このようなBRC-20プロトコルは、暴力的な美学の感覚を持ち、さまざまな要因の下での妥協でもあります。以前、Bitcoinではカラードコインの同質化トークンが登場したこともあり、これがBRC-20が失敗したアプリケーションであることを証明するものではありませんが、少なくともそれが長期的なプロトコルではない可能性を示唆しているようです。ここで、本文のテーマである、Lightning Networkに基づく主根資産（Taproot Assets）に入ります。

二、Lightning Network

Lightning NetworkはBitcoin上に構築されたLayer 2ソリューションであり、その目的はBitcoinの支払いシーンにおいてユーザーがコストを節約し、効率を向上させることです。Lightning Networkが依存する考え方も非常にシンプルで、資金プールを構築することです。この資金プールは、取引の両者間のマイクロペイメントチャネルとも呼ばれます。もう少し具体的には、2つのコア概念が関与しています：

* Revocable Sequence Maturity Contract（RSMC）：シーケンス満期の取り消し可能な契約
* Hashed Timelock Contract（HTLC）：ハッシュ時間ロック契約

RSMCは、取引の両者間にマイクロペイメントチャネルが存在することを前提としています。両者は最初にこのチャネルに一部の資金を預け入れ、初期状態では両者の配分計画は事前に預けた金額となります。取引が発生するたびに、両者は取引後に生じる配分結果を確認し、元の配分計画を無効にする必要があります。このプロセスには多くの概念が関与しており、非常に巧妙です。具体的には[A Dive into Lightning Network (Part One)][\^14]を参照してください。その役割は、Lightning Network内での両者間の支払いチャネルを構築することです。

HTLCは、イベントを伴うハッシュロックであり、特定の当事者が一定の時間内にハッシュ値 $h=H(m)$ の原像 $m$ を提出することを要求し、特定のUTxOの使用権を取得します。これはLightning Network内で支払いルーティングを構築するために使用され、具体的な実装プロセスは[Lightning network in depth, part 2: HTLC and payment routing][\^15]を参照してください。

Lightning Networkはこれら2つのメカニズムを統合し、取引がLightning Network内の任意の2つのノード間でオフチェーンで完了できるようにします。

三、Taprootアップグレード

Taprootは、3つのBitcoin改善提案（Bitcoin Improvement Proposal, BIP）[BIP-0340 （Schnorr署名）]、[BIP-0341 （Taproot）]、および[BIP-0342 （TapScript）]の集大成であり、Taro資産が実現できる基盤でもあります。ここでは、Taro資産の実現に関与するMASTについて説明します：

MAST

BIP-0341では、マークル抽象構文木（Merklized Abstract Syntax Tree, MAST）[\^7][\^8][\^9]が導入され、その目的はUTxOの支出条件を隠し、情報のサイズを削減することです。これはTaprootアップグレードの一部であり、Taprootアップグレードは元のP2SH（Pay-to-Script-Hash）とP2PKH（Pay-to-Public-Key-Hash）を統合し、1つの出力を直接プライベートキーで使用できるようにし、支出出力のスクリプトとマークル証明を提供することも可能にします。

MASTは抽象構文木とマークルツリーを組み合わせており、マークルツリーはブロックチェーンで一般的なデータ構造の1つであり、ここでは詳しく説明しません。抽象構文木（AST）は、プログラムを独立した小さなブロックに分割してプログラムを記述する方法であり、これによりプログラムの分析と最適化が容易になります。具体的には[Abstract syntax tree](https://en.wikipedia.org/wiki/Abstractsyntaxtree)を参照してください。MASTはASTの考え方を取り入れ、プログラムを複数の小さなブロックに分割し、それぞれのブロックをハッシュ化し、マークルハッシュツリーの考え方を利用してこれらのハッシュ結果をマークルツリーとして構築します。

次のようなスクリプト[\^9]を考えてみましょう：アリスはいつでも彼女のビットコインを使いたいと考えていますが、もし彼女が3ヶ月間連続して使わなければ、彼女の兄弟ボブとチャーリーがこのUTxOを使うことができます。そのスクリプトの実装は次のとおりです。

OPIF \<アリスの公開鍵> OPCheckSig
OPELSE "3ヶ月" OPCSV OPDROP 2 \<ボブの公開鍵> \<チャーリーの公開鍵> 2 OPCHECKMULTISIG
OP_ENDIF

P2SHの下では、このようなスクリプトは支出時に完全に取引に露出する必要があり、アリスはこのUTxOを支出する際にそのスクリプトを提供し、ボブとチャーリーの公開鍵を含める必要があります。

MASTが導入された後、このスクリプトの2つの条件を分割し、シンプルなMASTを得ることができます。

この時、アリスは支出する際に彼女の公開鍵検証スクリプトとHash2をマークル証明として提供するだけで済み、Hash 2の下の具体的なスクリプトを露出する必要はありません。この部分の情報はオンチェーンには載りません。このようにして、類似の取引のコストもさらに削減されます。これは非常に自然なことで、完全なスクリプトを提供することは、スクリプトのハッシュ値を提供することよりも常にデータ量が多くなります。このような構造は、スマートコントラクトの実現にも可能性を提供します。この方法は、EVMのバイトコードのように、実行前に入力データの最初の4バイトに基づいて呼び出す関数を選択することができます。異なる点は、このようなスクリプトの呼び出しには、ユーザーが具体的なスクリプトとマークル証明を提供して、そのスクリプトが合法であることを証明する必要があることです。

四、主根資産

主根資産（Taproot Assets、以下Taroと略します）[\^2][\^3][\^5]は、Bitcoin上で資産を発行することができる提案段階のプロトコルです。このような資産は、チェーン上の取引を通じてビットコインネットワークを介して移転できます（NFTの取引や移転はOrdinalsによって実現されています）。特に、同質化されたTaro資産は、Lightningチャネルに預け入れた後、Lightning Network上でより低い手数料で、よりプライバシーを保ちながら移転できます。これに類似するのは、Lightning Network上でスマートコントラクトを実行しようとするRGBプロトコル[\^4]です。

TaroはBitcoinメインネットまたはLayer 2のLightning Network上で流通します。まず、Bitcoinネットワークの状況を考えてみましょう。Taroは取引に追加されたハッシュ化メタデータ形式であり、ハッシュ化の目的は取引の占有スペースを削減して手数料を節約することです。このハッシュ化メタデータ形式はTaroの核心であり、この1つのハッシュ値は実際には数百万回の取引を表すことができます。その原理は後で説明します。

次に、TaroがLightning Network上での状況を考えます。Lightning Networkを使用することで、同質化されたTaro資産はより迅速な取引速度を実現できます。これは、Lightning Networkを使用することでビットコインをより早く、コストを低く移転できるのと似ています。Taroの提案では、Lightning Network自体は変更する必要がなく、特定のTaro資産の取引を実現するためには、支払い経路全体の最初のチャネルと最後のチャネルがTaro資産を認識できればよく、中間のルーティングチャネルは通常のLightning Networkの送金方法であり、等価のビットコインを送金します。これにより、Taro資産は通常、ネットワークの端で他の資産と交換されることになります。

Taroプロトコル

Taroがもたらす利点を理解したので、次に紹介するのは、それが何であるか、そしてどのように実現されるかです。BRC-20が第三者機関に記帳を依頼するために書かれた送金記録の紙片の束であるのと同様に、ERC-20がスマートコントラクトによって記録され維持される残高情報の列であるように、Taroはどのように資産の発行や移転を実現するのでしょうか？

資産ツリー

資産ツリーはTaroにおける2層のマークルツリー構造であり、Taro資産を表すために使用されます。第1層はTaro情報を葉ノードとして構成するマークルツリーであり、第2層はMS-SMTによって構成され、各アカウントが持つその資産のツリーを表します。MS-SMTの考え方は非常にシンプルで、マークルハッシュツリーがハッシュに基づいてツリー構造を構成する一方で、各ノードには左右の2つの子ノードの合計も格納されており（ハッシュ計算自体も一種の合計と見なされます）、このような資産ツリーとMS-SMTツリーはTaroのUTxOを構築するために使用されます。

資産葉（Asset Leaf）は資産ツリーの最下層構造であり、資産ツリーの示意図における淡い青色のノードとして表現されます。これはassetScriptKey（assetScriptKeyはP2SH取引における取引スクリプトのハッシュ値に類似）をキーとして使用します。各資産葉はTaro資産の1つのUTxOを表し、資産葉に含まれるオプションについては[Understanding Taproot Assets Protocol]を参照してください。

MS-SMT

マークル総和スパースツリー（Merkle Sum Sparse Merkle Tree）[\^11]は[bip-tap-ms-smt]で定義されたデータ構造であり、スパースマークルツリーの強化版です。現在、bipsの中でまだ受け入れられていない提案です。キー（key）は256ビットの長さであるため、このMS-SMTには$2^{256}$の葉ノードがあり、そのほとんどは空です。したがって、これはスパースマークルツリーです。

各葉には数量が含まれ、各ブランチは上に葉の合計を提出します。これにより、各サブツリーの内容を知らなくても、ブランチに含まれる合計を知ることができます。一般的なマークルツリーと同様に、葉を含むトリミングされたツリーはメンバー存在証明を提供できます（これは暗号累加器の概念であり、集合内の要素を証明するための「証明」です）。MS-SMTはメンバー不存在証明もサポートしています（これは存在しないキーの葉をNoneとして明示的に示すことで実現されます）。つまり、ツリー内にそのようなキーがNoneであることを証明することで、それが存在しないことを証明します。このような構造は、ツリー上に保存された数値や分布が変更されたかどうかを効率的に検証できます。

下の図はマークル総和ツリーとその変更後の構造を示しており、マークル総和スパースツリーはスパースツリーの特徴を組み合わせ、空の要素ノードを削除し、有意義な情報のみを保持し、空のノードはNoneで表されます。

Taro資産の発行

Taro資産の発行には識別子が必要です。ERC-20トークンのスマートコントラクトがアドレスを持つのと同様に、Taroプロトコルは識別子の生成方法を定義しています：ID=SHA256(genesisPoint||assetTag||assetMeta)。これは、資産を鋳造するために使用される取引出力情報、資産タグ（例えば資産名のハッシュ値）、および資産のメタデータ（画像、リンク、または文書）をハッシュ化することで識別子を得ます。

Taro資産の移転スクリプトは、ビットコイン取引の入力出力に類似しており、資産を作成する取引にはTaro資産の入力を含める必要はありません。これにより、Taro資産はビットコインのUTxOモデルを引き継いでいることがわかります。資産の発行は、Taro資産の取引を発行することであり、入力はなく、出力のみがあります。

Taroの入力と出力は資産ツリーに基づいて実現されます。前述のように、資産ツリーの第1層はそのUTxO*（この後もこの書き方を続けます。*はこの構造がTaro資産内にあり、Bitcoin内ではないことを示します）に保存されているTaro資産を表し、Taro資産IDに対応するMS-SMTにはそのUTxO*出力のTaro資産情報が保存されています。

Taro資産の発行取引を構築するプロセスは次の図に示されており、ビットコインのUTxOを入力として使用し、通常のビットコインUTxOと追加のTaro資産AのUTxO*を出力します。**このUTxO*はビットコイン上ではマークルルートの形式で表現され**、オフチェーンでは資産ツリーの形式で表現され、資産ツリーにはTaro資産AのassetIdと資産Aに対応するMS-SMTの記録が記録されています。

Taro資産の移転

前の小節で資産の作成を理解できれば、資産の移転プロセスもより迅速に理解できるでしょう。資産の移転はビットコインの取引に似ており、一連の利用可能なUTxOを入力として選択し、その後一連のUTxOを出力します。Taro資産では、一連の利用可能なUTxO*を入力として選択し、一連のUTxO*を出力します。

この取引では、Aは自分のTaro資産XをすべてBに移転し、分割は行いません。Bがこの取引を受け取ると、資産が支払い条件を満たしているかどうか、余分な出力が発生していないかを確認する必要があります。

確認が必要な条件には以下が含まれますが、これに限定されません：

* Bが作成した資産ツリーに、支払い条件を満たす新しいUTxOが含まれていますか？
* 入力UTxOは、すでに更新されたAの資産ツリーから削除されていますか？
* 取引に他の出力がある場合、それらは別の資産ツリーを含んでいますか？

これらの情報は、MS-SMTのメンバー/非メンバー証明やTproot出力の前像および証明によって検証できます。資産の統合や分割については、詳細は省略しますが、それらのプロセスは資産移転のプロセスに類似しており、出力のUTxO*には分割証明や統合証明が含まれています。

Taro Universe

Universeは、資産の保有者に資産情報や証明を提供するサービス[\^6]であり、その役割はビットコインブロックエクスプローラー[\^13]に似ていますが、Taro資産クライアントと共にオフチェーンに保存されたTaproot資産の取引データを表示します。Universeは資産の発行者自身が運営することも、発行者が特定のオペレーターを任命することもできます。コミュニティが運営するUniverseが資産保有者から提出された情報を集約することも想像できます。

五、結論

前回はここまでで、Taro資産の実現に基づく技術とその実現原理について簡単に紹介しました。次回は、3P LabsがOrdinalsおよびTaro資産の発展状況について紹介します。

資料引用
[\^1]: [Ordinal Theory Handbook]
[\^2]:[What Is Taro in Bitcoin?]
[\^3]:[Taproot Assets]
[\^4]:[A BRIEF INTRODUCTION TO RGB PROTOCOLS]
[\^5]:[Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning]
[\^6]:[Taproot Assets Protocol]
[\^7]:[Merklized Abstract Syntax Tree]
[\^8]:[Merklized Abstract Syntax Tree]
[\^9]:[What is a Bitcoin Merklized Abstract Syntax Tree (MAST)?]
[\^10]:[Understanding Taproot Assets Protocol]
[\^11]:[bip-tap-ms-smt]
[\^12]:[Fixing The Privacy Gap In Proof Of Liability Protocols]

[\^13]:[Blockstream Explorer]
[\^14]:[A Dive into Lightning Network (Part One)]([A Dive into Lightning Network (Part One)]
[\^15]:[Lightning network in depth, part 2: HTLC and payment routing]