ビットコインのレイヤー2でトークンを発行・移転できるRGBとクライアントサイドバリ デーション
現在、トークンの発行を行えるブロックチェーンとして圧倒的に使われているものはイーサリアムです。ビットコイン上でも、カウンターパーティートークンやOMNI USDTなどに使われるカラードコインという仕組みを使ってトークンを発行することはできますが、USDTも送金手数料の上昇により他のブロックチェーンに移動するなど、利用は縮小傾向です。
今日紹介するRGBは、ライトニングネットワークと互換性をもつ、カラードコインを発行し送金することができるようになるレイヤー2プロトコルです。6月末に大石さんも投稿されていたので、そちらもご覧ください。
とは言っても、まだ自分の理解も完璧には程遠いので、技術面も含めてとりあえずざっくりとした紹介に留めます。
カラードコインとRGB
RGBを理解するにはカラードコインをおさらいする必要があります。
カラードコインとは、ビットコインのブロックチェーン上で他のトークンを扱う方法の総称です。元々は特定のUTXOが別のトークンとして扱われたため、それらのコインに色がついた状態と捉えてカラードコインと呼ばれましたが、現在の利用量では任意のデータを記録できるOP_RETURNを使ってビットコインブロックチェーンに送金情報を書き込む形式のものが主流です。(OMNI USDTなど)
カラードコインはビットコインのブロックチェーンを使用するので、スケーラビリティとプライバシーの問題をはらんでいます。あまり取り上げられない印象がありますが、特にプライバシーに関してはトランザクションの母数が少ない上に判別しやすく、ミキシングなども利用できませんのでほぼ追跡可能です。
RGBのコンセプトは、カラードコインをオフチェーンでやり取りすることでスケーラビリティとプライバシーを向上する仕組みです。これを実現するために、クライアントサイドバリデーションという仕組みを使っています。
ここまでは概ね大石さんの投稿にも書かれていたような内容です。ここからはもう少し技術面に踏み込んでいきましょう。
ちなみにRGBは光の三原色を表しますが、これはカラードコイン(「色付きコイン」)という言葉からきています。オシャレなネーミングセンスですね。
クライアントサイドバリデーション
クライアントサイドバリデーションとは、トランザクションの検証に必要な情報をブロックチェーンに記載することなく各参加者が保持し、送金の際には当事者たちがP2Pで「署名されたトランザクションのチェーン」のようなものを作っていくイメージです。
ビットコインの仕組みと比較したほうがわかりやすいかもしれません。ビットコインブロックチェーンは、全てのノードが全てのトランザクションとブロックを常時検証(バリデーション)して、ネットワーク全体が常にコンセンサスを保つようになっています。
一方で、クライアントサイドバリデーションとは、当事者間でコンセンサスが確認できれば良いので、ビットコインで例えるとトランザクションやブロックの内容はとりあえず無条件で受け入れて、実際にそれを使うときにだけ当事者間で不正がないか検証と確認が行われる、というような仕組みです。
ビットコイン上では意味を持たないOP_RETURNデータを参加者のみが読み取って使用するカラードコインも、それ以外のビットコインに関するデータを検証する必要はない(カラードコイン毎のルールだけ確認する)のでクライアントサイドバリデーションを使用しているといえますね。
クライアントサイドバリデーションを採用するメリットは自分に関係のない内容について検証するコストがかからないことです。極端な話、自分の関わるトランザクションに使われるコインが本物であることが確認できれば、それ以外の情報は全くいらないのです。つまり、全員が共有する必要のない情報は当事者のみが持つ、これがスケーラビリティのメリットを生みます。
LNでも自身のノードを経由する取引のことしか知らないのと似ています。
RGBにおいては、トークンの発行時にブロックチェーンに1回だけ記録された後は、送金のたびにそれまでの送金の履歴を積み重ねたデータ(DAG)を参照するため、必要十分な情報を、必要な当事者たちだけが保管することになります。そしてその情報を各ユーザーが保管することも、第三者(トークンの発行者など)に委ねることもできます。
RGB豆知識
①トークンの発行はコントラクトと呼ばれるものを用いてオンチェーンで行われますが、この際誕生するオンチェーンのUTXOの所有者(コントラクトの所有者)が、その後にトークンの送金履歴を積み重ねたデータ(State)をまとめて(ハッシュして)ブロックチェーンに記帳することができます(Seal)。どれくらいの頻度でこれを行うかは特に定められていませんが、Stateの監査に利用できるという側面があるのではないでしょうか。
②RGBではそれぞれのトークンについて別々のコントラクトとState Historyが存在するので、異なるトークンの送金データは原則的にそれぞれの当事者間のみで保管・流通され、こちらもスケーラビリティ面でのメリットとなります。厳密には異なりますが、イーサリアムのシャーディングに近いイメージです。
③RGBのコントラクトがUTXOベースのため、ライトニングチャネル上でトークンのやり取りをすることができ、LNのネットワーク効果やインフラを活用できるほかに、DEXのようなものを実現できるとされています。
RGBまとめ
最初にコントラクトの所有者が、トークンの発行時にオンチェーンにトランザクションを発行して初期状態を記録します。それ以降の取引はオフチェーンで行われ、取引データ(Proof)は暗号学的に署名され参加者間でDAGとして保持されます。また、コントラクトの所有者は任意のタイミングでその時点までの取引の結果(State)をブロックチェーンに記帳することができます。
トラストレスながらほぼブロックチェーンを使わず、当事者のみがデータを保管する仕組みによって、プライバシー・スケーラビリティを向上したビットコイン上でのトークン発行が可能になります。
かなり柔軟な仕組みなのであらゆるトークンが発行できると思われます。
また、現時点ではトークン発行のほうが注目されていますが、複雑なスマートコントラクトなども実現できるようです。この場合も、スマートコントラクトの当事者のみが計算と検証を行うことで、ブロックチェーン上で扱うよりも恐らくスケーラビリティとプライバシーのメリットがあると考えられます。
ただし、RGBが比較的難解なことや、LN自体の未成熟さもあって、完成度が高まって普及が始まるまで数年はかかりそうだという印象を受けます。
Client-side ValidationやSingle-use SealsなどPeter Toddの提案してきた技術が多く使われているので、そのあたりを勉強する必要がありそうです。
次の記事
読者になる
一緒に新しい世界を探求していきましょう。
ディスカッション