RGB プロトコルにおける "schema"

RGB プロトコルは、アセットの状態(state)遷移(transition)をクライアントサイドで検証(validate)します。

本稿では、どのように検証を行っているのか、という内部の解説を試みます。

他プラットフォームでの仕組み

本論に入る前に、先行する他のアセット発行流通プラットフォームについて、仕組みをおさらいしてみます。

Ethereum

RGB と同様にアセットを発行・移転ができるプラットフォームとしては、Ethereum がよく知られています。

Ethererum は EVM という仮想マシンを土台としたプラットフォームであり、ERC20 ERC721 といったトークンは、EVM を利用したプログラム…スマートコントラクト…として定義されます。

Counterparty

Ethereum と同様に、アセットの発行・移転ができるプラットフォームとして、Counterparty もよく知られているかもしれません。

Counterparty は、スマートコントラクトに相当する処理は、事前にハードコードされています。少なくとも現時点では、コア開発者以外での拡張はできません。過去に EVM を搭載する計画がありましたが、頓挫しています。

Omni

概ね Counterparty と同じ仕組みです。

RGB での仕組み

RGB は Ethereum とも Counterparty とも違う方針を採っています。

まず、 RGB では、EVM のような自由度の高い仮想マシンはオプションです。無くても動きます。RGB と同じく LNP/BP association の下で開発が行われている AluVM は、採用有力ながらも、本稿執筆時点ではオプションであり必須ではありません。

しかし、Counterparty や Omni のように決め打ちでもありません。

RGB アセットの挙動を決める根幹技術が、 schema です。

schema には、下記のような情報を記述できます。

• アセットに持たせたい属性
• 誰にどの属性を操作可能とするか
• 状態遷移の種類と許可条件

アセットの生成者(issuer) は、アセットに任意の schema を設定できます。

その後、RGB アセットが状態変化(典型的には送信)を起こそうとする都度 schema が参照され、状態変化を認めるか否かが各ノード(クライアント)により判断されます。

Ethereum での ERC721 に相当する、RGB21 アセットの schema では、状態遷移の許可条件として、各ノードに埋め込みの条件を使うよう記述されています。

今後は、許可条件として、AluVM で記述されたコントラクトを使えるようになるはずです。

まとめ

本稿では、RGB プロトコルでのアセットを定義する "schema" を紹介しました。挙動ではなく制約条件を宣言的に記述することで、EVM のような仮想マシンを導入せず、かつ Counteparty より自由度の高いアセット設計が可能となっています。今後、AluVM 等の仮想マシンを導入可能とする余地が残されていることで、AMM や DAO のような、複雑なシステムに向けたプラットフォームとなる可能性も秘めています。

schema の具体例は、たとえば RGB-21 が参考になります。