RGB protocol (以下、RGB) の概要は、上記リンク先をご参照ください。

RGB で発行されたトークン(アセット)が、どのように転送(transfer ≒ 送金・価値移転)されるのか。その手順を本記事では解説します。

技術的背景

まず、背景から。

本稿執筆時点での RGB は Bitcoin のオンチェーンを用いています。しかしながら、将来的には Lightning Network (以下、LN)を用いることも想定されています。LN での送金したことがある方ならご承知だと思いますが、最も基礎的な LN での送金処理起点は、 請求書(invoice)です。おそらく LN の影響を受けて、RGB の送信処理起点も請求書となっています。

将来的に LN 上で RGB のトークンが送金可能になるとしても、それは当面の話ではありません。本稿執筆時点では、Bitcoin のオンチェーンが使われます。

オンチェーン上の RGB プロトコルでは、支払者(payer)・受取者(peyee)との仲介を行う proxy-server が必要となります。proxy-server は送金の可用性と可否判断の面で、 trust point になります。しかしながら、proxy-server が転送中のアセットを強奪できないという点では、安全です。

送金手順

proxy-server には rgb-proxy-server という OSS 実装があり、GitHub で公開されています。

以下、リポジトリ内にある README を読めば解るのですが、母語が日本語の人(私も)が、英文を読むのは面倒でしょう。ここで和訳しながら解説していきます。

図は上記 README からの引用です。下記手順も README を参考にしていますが、原典では読みづらい部分を、若干噛み砕いています。

1. 転送のトランザクションは、受取人(payee)が発行する請求書(invoice) が起点になります。受取人は、今後のトランザクションの識別子として、blinded UTXO を発行し請求書に含めます。(blinded UTXO については後ほど解説)
2. 転送におけるトークンの支払人(payer)は、proxy-server に転送委託ファイル(consignment file)を投稿します。ファイルの識別子として、受取人が請求書で提供した blinded UTXOを使用します。
3. 受取人は、proxy-server に、請求書で以前に提供した blinded UTXOに関連する転送委託ファイルを求めます。
4. そのような blinded UTXO に関連するファイルがある場合、proxy-server はファイルを受取人に返します。
5. 受取人は、転送委託ファイルの内容を検証します。
6. 受取人は、提案された転送委託ファイルの内容に満足した場合、proxy-server に承認(ACK)メッセージを投稿します。それ以外の場合は、不承認(NACK)メッセージを投稿して、支払人にRGB転送が失敗とみなされることを伝えることができます。
7. 支払人は、以前に投稿した転送委託ファイルに関連する承認/非承認ステータスをproxy-server に尋ねます。転送委託ファイルが受取人によって承認されている場合、支払人は、RGB転送委任ファイルへのコミットメントを含むBitcoinトランザクションをブロードキャストします。

このように proxy-server を挟むことで、支払人・受取人ともに一時的に offline になりうる環境(典型的にはモバイル)でも RGB トークンの送受を行えます。

blinded UTXO

さて、先程は解説を保留した blinde UTXO について概説します。

支払人は、コミットメントを含むトランザクションを作成するために、受取人の UTXO を知る必要があるかもしれません。

しかしながら、proxy-server はどうでしょうか? UTXO を知られると、コミットメントの流れを proxy-server が知ることができます。UTXO から受取人のアドレスが明らかになりますから、proxy-server に悪意があれば検閲が可能となります。

ここで、blinded UTXO の登場です。

blinded UTXO は、下記のような計算で求められます。

blinded_utxo = hash(utxo + random)

blinded UTXO は、(すでに解説したとおり)受取人が発行し、請求書に含める形で支払人と共有されます。 以降、proxy-server を仲介したトランザクションでは blinded UTXO のみが識別子として用いられます。結果、 proxy-server は、どの UTXO に関するやり取りなのかを傍受できません。

blinded UTXO を識別子とすることで、秘匿性・耐検閲性が高まります。

仕様上の制約

転送では受取人が blinded UTXO を発行する必要があります。つまり受取人のアドレスには、UTXO が存在する必要があります。分かりやすく言い換えると、受取人のアドレスには、dust と同額でも構わないので、BTC が存在する必要があります。

これを欠点と見るかどうかは、判断の分かれるところかもしれません。Counterparty や Omni といった類似競合のプロトコルでは、この制約は存在しません。しかし、それら競合のプロトコルには RGB とは異なる種類の制約があります。

まとめ

RGB の基本機能であるトークンの「転送」の裏側で起こっていることについて概説しました。

RGB と同様に Bitcoin のオンチェーン上でトークン(アセット)を発行するプロトコルとして、Counterparty や Omni が先行して存在しています。これらの転送手順とと RGB との違いについても書きたいところですが、それは稿を改めて解説できればと思います。