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

もなか

2022-12-24T21:58:51Z

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 が参考になります。