アメリカのマイアミにてBitcoin 2022というカンファレンスが現在開催されています。その中で、LNDを開発するLightning Labs社のroasbeef氏がTARO (Taproot Asset Representation Overlay)というプロトコルと、それに関連するBIPsを発表しました。

ちょうど２週間前に解説したOmniBOLTのように、ビットコイン上で通貨・トークンを発行し、それをライトニングネットワークで送ることができる、という内容を強調した発表だったので、今日はTAROが既存のプロトコルとどう違うのか、実際に利用される見込みはあるのかについて調べました。

細かい仕組みがけっこう難解なので、現時点では理解しきれていない部分もあります。したがって今日解説する内容はある程度抽象化したものです。
もし大きく間違っていたら訂正記事を出します。

これまでのビットコイン上でのアセット発行

最近も本稿で触れたことのあるCounterpartyやOmniなど、ビットコイン上でアセットを発行するプロトコルは色々と存在しました。その共通点として

・オンチェーンにOP_RETURNでデータを記載することで発行・送金等を行う
・そのデータを該当するレイヤー２で解釈して検証する

という仕組みでした。また、これらは自分でノードを動かすこともでき、自分でブロックチェーンにトランザクションを発行できるパーミッションレスな形のものでした。

ビットコイン上でアルトコインを発行する需要はスケーラビリティ上の問題からアルトコインへと移っていきました。操作のたびにOP_RETURNを含んだビットコイントランザクションを発行しないといけないからです。

Taroはその点、スケーラビリティに優れているということですが、どういう仕組みになっているのでしょうか。

TAROの仕組み

まず確実に把握する必要があることは、TaroとCounterparty、Omniは全く異なる構造になっているということです。例えばTaroでは原則としてユーザーのトランザクションの実行にアセットの発行者の協力が必要な形を取るでしょう。

ユーザーは発行者に依頼して自分の残高を操作してもらい、その操作の結果は発行者がブロックチェーンにコミットします。発行者が残高一覧の更新をコミットする間隔は特に規定されていないので、多数のトランザクションをまとめることも、１トランザクションごとにコミットすることも可能です。

あるいはasset splitといって、ユーザーが自分の残高を減らし、その事実にコミットして減らした残高と等しい新しいアセットをオンチェーントランザクションを使って発行することもできます。(預り証みたいなものですね) これを使って発行者の立場で送金をすることもできますが、預り証ネットワークのユーザーの検証の手間は増えますし、動作し続ける必要のあるカウンターパーティの数も増えていきます。預り証の関係がネストされていくのは実際のところ好ましくないでしょう。

預り証と表現していますが、これは発行者が協力してくれなくなった場合にGOXすると思われるからであり、発行者による盗難リスクがあるのか(盗難を防止できるのは親となるアセットの発行者だけだと思われますが、それが期待できるか)は認識できていません。不正なトランザクションは没収されるとの記述を見ましたがそれを保証する仕組みはわかりませんでした。

ユーザーはブロックチェーンにコミットされているツリーや発行者に問い合わせたツリー、発行者が発行してくれるトランザクション受付の証明書などを通して自分の残高や総発行量が正しいことを検証できますが、根本的に動作のためには発行者に依存する仕組みです。

～～～

さて、Taroでは書き込みに際してOP_RETURNではなくTaprootを活用して、ブロックチェーンにアセットの発行や残高一覧を記録していきます。
80バイトという制限があり、トランザクションサイズに影響するOP_RETURNとは異なり、Taprootにおいてスクリプトを格納する木には大量のデータへのコミットメントを含めることができることを利用します。(ただしデータ自体はオフチェーンで保持しないといけません。)

Taprootを利用するUTXO (P2TR)では、スクリプトには木構造でコミットし、また１つの条件は公開鍵(keySpend)として表現することができます。この際、生成した秘密鍵を、スクリプトが含まれる木構造の内容を用いて改変することでkeySpendに対応する秘密鍵を作っています。(この改変をTaptweakといいます)

また、木構造にも色々ありますが、TaroではMS-SMTという独自のものを使用しています。Sparse Merkle Tree (SMT)というのは葉の位置自体がその葉のデータを表現するマークル木で、例えば2^256種類のデータを表現するのに深さ256の二分木を用い、どのデータをどの葉に格納するかはデータ自体の内容に従って決めるものです。(2^2種類の例として、2進数で"10"というデータは最初の分岐で左、次の分岐で右に行ったところ、というふうに)
マークル木はデータの存在証明に用いることが容易ですが、SMTはデータの内容によって位置が決まっているため、その位置のデータが存在しないことを証明することでデータの不存在証明ができます。

MS-SMTというのはこのSMTのすべての葉に数値(残高)が格納されており、各ノードで数値が加算されていく性質を追加したものです。これによって、例えば2^256あるアドレスの間で残高を移動する処理を行う際に、アセットが不正に新規発行されていないことをユーザーが検証できます。

TaroではこのMS-SMTの根をTaprootの木構造に含めることでそのアセットに関する残高一覧にコミットします。アセットの発行者は任意のタイミングで古いP2TR UTXOから新しいものへと送金し、新しい残高一覧にコミットします。

最終的なユーザーはというと、オフチェーンで発行者とやり取りして残高を更新してもらうことになり、オンチェーンでMS-SMTの根にコミットされる内容と照らし合わせることができます。発行者とのやり取りの具体的な方法は定義されていないのですが、仕組み的に対検閲性を持たせられるかはわかりません。

構造が違う：TAROはRGBにちょっと似ている

さて、TaroをCounterpartyやOmniと比較して一番異なる点はTaprootの活用ではなく、発行者の協力が必要な構造だと上で述べました。本稿でもこれと似たものを紹介したことがあります：RGBです。

RGBも難解なので今日は触れません。

TaroやRGBは各アセットごとに発行者のオレオレチェーンのような使われ方が主になると予想されるので、ビットコインなどとは異なり、どちらかというと証券トークンのように発行体に対するトラストが既に存在し、協力的な状態で存続することが見込まれる場合に向いているのではないかと考えられます。現時点でその需要がどれくらいあるのかは未知数です。

皮肉な視点を持っている人は多くのアルトコインもこう見えているかもしれませんが、一度発行したコインが永遠に勝手に取引可能な場合と異なり、トランザクションを集約＆コミットするサーバーの運営を放棄するとホルダーがGOXする仕組みは他人に責任を丸投げしたいアルトコイン発行者の99％にとっては重たすぎる仕組みだと思います。

ライトニングで送れる？

Taroの残高にもそれぞれBitcoin Scriptで定義したスクリプトを持たせることができるようです。実際にはアセットの発行者がトランザクションを実行する際にスクリプトを検証することになるので、このスクリプトに関してはProof of authority (=発行者をトラスト)なんじゃないかと思います。

一方で、上述した「預り証」メソッドで自分用のTaro UTXOを用意してビットコイントランザクションに含めることでTaroの残高の操作をビットコイントランザクションを結びつける方法を取ると、ビットコイン自体のスクリプトでHTLCを作ることができ、それでライトニングネットワークで送金することができます。相手のノードが自分の預り証を認めてくれていればBTCと預り証両方が１つのチャネルで利用できますし、中継ノードが対応していれば、中継時はBTCに交換して中継するといったこともできます。roasbeefは中継ノードすべてがそのアセットを保有する必要がないことを大きなメリットとして強調しています。

しかしながら、交換が発生する以上、中継ノードは決済までのタイミングの価格変動リスクを一方的に負うことになります。送金のフリをして、交換レートが特になった場合のみ決済させるというフリーオプション問題を解決する仕組みはまだないので、中継ノードは対応したくない、もしくは高い手数料を課すしかないのが本音でしょう。(もちろん、ピア間でこの問題について同意が取れていれば問題はありませんが。)

ライトニングで送れるというのは間違いではありませんが、中継ノードが交換レートのリスクを負ってしまう点は解決がかなり難しい問題だと思います。

まとめ

つい一昨日発表されたTaroについて、あくまで自分の現時点での理解に基づく解説なので細かいところが間違っていたり、指摘に対する反論が存在するかもしれませんが、大まかには正しく把握できていると思います。

まとめると、Taroで発行するトークンの仕組みは：
・RGBのように発行者が存在し、ユーザーの残高一覧をP2TRのTaptreeにコミットし、オフチェーンでトランザクションを処理している
・発行者は任意のタイミングで前のP2TR UTXOをSpendして新たなP2TR UTXOにコミットする (ある程度間隔をあけて、多数の取引を集約する場合がほとんどと思われる)
・ユーザーが持つTaroアセットについて、自身のUTXOに引き出したり、発行者の管理下に戻すことができる。(asset split/merge) このUTXO内に残高を持つ他のユーザーが出てくれば、このUTXOを持つユーザーにもトランザクションの実行に関して依存するという意味では「預り証」である。
・保有するTaro UTXOを含めたファンディングTX及びコミットメントTX(すなわちライトニングチャネル)を作ることができ、１つのチャネルでBTCや任意の数のTaroアセットに対応できる
・中継ノードがTaroアセットを持たなくていいのはまた別の話。中継ノードが交換に応じてくれるという前提がある。(極端な話、普通のLNでも中継ノードがBTCを持つ必要すらない)