RGB:ビットコイン上に構築された、スケーラブルで機密性の高いスマートコントラクトプロトコルの簡潔な分析
背景
ビットコインのパフォーマンスは、2009年に暗号通貨が立ち上げられて以来、注目を集めています。1秒間にわずか7件のトランザクションしか処理できないため、このネットワークではスケーラブルなスマートコントラクトが実現できません。SegWitアップグレードによりビットコインのブロックサイズ制限は4MBに引き上げられましたが(トランザクションデータ用に1MB、ウィットネスデータ用に3MB)、制限は依然として存在します。一方で、ビットコインの影響力が増大するにつれ、スケーラビリティの課題はより深刻になっています。スケーラビリティはビットコインエコシステムが直面する根本的な課題であり続けています。現在、実務者たちはさまざまなアプローチで解決策を探っており、主に以下のようなものがあります:
- Liquid、Stacks、Rootstockなどのサイドチェーン
- ライトニングネットワークのような、特定の高頻度トランザクションをオフチェーンで処理するステートチャネル
- RGBやビットコインスクリプトのような、ビットコインのコードを変更しないアップグレード不要のスケーリングソリューション
- Drivechain(BIP300/301)のような、強力なマイナーサポートを必要とし、ハードフォークを通じてスケーラビリティを実現するアップグレードベースのスケーリングソリューション
これらのさまざまなアプローチの中で、一部の初期のスケーリングソリューションが再び注目を集めています。特に、2022年後半に話題となったプロトコルであるNostrは、ライトニングネットワークの広範な採用に貢献しました。同時に、Ordinalsは2023年初頭にブームを迎えました。ビットコインとライトニングネットワークに基づき、チューリング完全性、スケーラビリティ、強力なプライバシー保護を提供するスマートコントラクトソリューションであるRGBは、今年4月に新バージョン(v0.10)をリリースしました。
RGBの進化
RGBの起源は2016年にさかのぼります。その年、Peter Toddがシングルユースシールとクライアントサイドバリデーションの概念を導入しました。これらの重要な概念に基づいて、2018年にRGBが提案されました。
2019年、RGBのコア開発者であるOrlovskyがRGBの開発を主導し、最終的にRGBプロトコルを構成する多くのコンポーネントを作成しました。さらに、スイスでLNP/BP協会が設立され、関連する標準の提供に貢献しました。
広範な開発努力の末、RGBは2023年4月にv0.10をリリースしました。
RGBの設計について
RGBがスケーラビリティと機密性を実現する方法は以下の通りです:
クライアントサイド検証
既存のほとんどのパブリックブロックチェーンは、グローバルコンセンサスモデルで動作しています。このモデルでは、すべてのノードがすべてのトランザクションを検証し、トランザクション情報を相互に共有し、統一されたグローバル状態を維持します。
しかし、このモデルはいくつかの課題をもたらします:
- すべてのコントラクトの相互作用を検証するのが高コストになるスケーラビリティの制限
- 高コストによるノード運用の中央集権化
- トランザクション情報が公開されることによるプライバシーの欠如
クライアントサイド検証(CSV)は、代替アプローチを提案します:コンセンサス層に要求されるのは、台帳イベントに関連する暗号学的コミットメントを満たすことだけで、実際のイベント情報(台帳)はブロックチェーン外に保存します。Peter Toddの研究に由来するこのアプローチは、「クライアントサイド検証」と呼ばれています。CSVはトランザクションデータをオフチェーンに移動し、詳細な情報はオフチェーンで保存・検証され、最小限の情報のみがブロックチェーン上に提出されます。さらに、トランザクションデータは送信者と受信者の間でのみオフチェーンで転送されます。例えば、実世界のトランザクションでは、ウォレットと関係者がコントラクトデータへのアクセスを要求した場合にのみ検証が必要となります。
CSVの主な特徴:
- 詳細なトランザクション情報はオフチェーンで保存され、クライアント上でのみ検証される
- トランザクションデータへのコミットメントのみがチェーン上に保存される
- 検証は、ユーザーが認識する必要があるトランザクションにのみ適用される
RGBでは、資産転送の検証メカニズムはビットコインとは大きく異なります。ビットコインネットワークでは、ノードは常にブロックとメモリプールのトランザクションをダウンロードし検証しており、これによりUTXOセットの最新の状態を把握できます。新しいトランザクションに遭遇すると、ビットコインのバリデーターは、すべての入力が最新のUTXOセットに存在するかどうかを確認することで、その履歴の有効性をチェックします。
一方、RGBはすべてのトランザクションのグローバルネットワークブロードキャストに依存せずに、ビットコインのUTXOセットに相当するものを作成します。これは、入金を受け取る際、RGBクライアントは最後の状態遷移が有効であることを確認するだけでなく、発行契約のジェネシス状態までのすべての以前の状態遷移に対しても同じ検証を行う必要があることを意味します。RGBにおけるこのボトムアップのトランザクション履歴の検証は、二重支払い攻撃からも保護します。
RGBは関連するトランザクションのみを検証することで、スケーラビリティを向上させます。しかし、このアプローチは、支払い検証を最適化するためにデータ共有が必要となる可能性のある、データの可用性の低さに関連する問題を引き起こす可能性があります。
ビットコインベースのシングルユースシール
物理的なシングルユースシールは、保管や輸送中の改ざんを検出するために一般的に使用される、固有の番号が付いたプラスチック製の結束バンドです。例えば、輸送中に輸送コンテナのドアが開けられたかどうかを知ることができます。デジタルシングルユースシールは、メッセージに対してデジタルシールを一度だけ使用できるように閉じることで、売り手が同じ財産を二度売ることを不可能にします。
デジタルシールの開閉を認証する信頼できる主体を使用する代わりに、ビットコインの未使用トランザクションアウトプット(UTXO)をシールとして使用することが可能です。UTXOは、作成されたときに閉じられ、使用されたときに開かれるシールとみなすことができます。ビットコインのコンセンサスルールに照らし合わせると、アウトプットは一度しか使用できません。したがって、シールは一度しか開けることができません。このように、シングルユースシールは、ビットコインのUTXOをオフチェーンの契約状態と関連付けるために使用され、オフチェーンのRGBトランザクション(シールを閉じる)を通じて次の状態遷移の実行を可能にします。輸送コンテナを保護するために使用される物理的なシングルユースシールと同様に、デジタルシングルユースシールは、二重支払いを防ぐために情報を正確にシールするユニークなオブジェクトです。
簡単な類推を挙げてみましょう:UTXOは、それぞれ異なる金額が記載された一連の小切手のようなものだと考えることができます。支払いをする際、本質的には未換金の小切手で誰かに支払っているのです。さらに、小切手の残高は新しい小切手の形であなたに戻ってきます。このシナリオでは、シングルユースシールは小切手の追加情報欄に特定の転送記録を追加します。小切手は一度しか換金できないため、この方法によってダブルスペンディングが防止されます。
アリス、ボブ、デイブの間でこのプロセスがどのように機能するか見てみましょう:
- まず、アリスが総供給量1億のRGBアセット(例:USDT Tetherまたは USDT)を発行し、有効な小切手(小切手A)の追加情報欄にコミットメント情報を追加します。小切手の発行者はこの追加情報を考慮する必要はなく、小切手Aはアリスの所有物で未換金である限り、額面金額はいくらでも構いません。
- アリスがボブに1000万USDTを送金したい場合、小切手Aを換金し、追加情報欄に1000万USDTがボブの所有する新しい小切手(小切手B)に移動し、残りの9000万USDTがアリスの所有する別の新しい小切手(小切手C)に移動することを記載する必要があります。
- ボブがデイブに1000万USDTを送金したい場合、小切手Bを換金し、追加情報欄に1000万USDTがデイブの所有する新しい小切手(小切手D)に移動することを記載する必要があります。
- その後の各送金でも同じプロセスが繰り返されます。具体的には、前の所有者が新しい受取人に金額の一部を裏書きし、受取人はアセットの転送履歴全体を検証します。流通する小切手と同様に、各送金で新しい小切手が作成され、各小切手は一度しか換金できません(UTXO)。同時に、古い小切手(UTXO)は無効となり、状態が前進のみ可能で後退できないようにし、ダブルスペンディングも防止します。このようにして、オンチェーンの記録は暗号資産の状態変化を確実に反映します。
RGBはビットコインベースの単一使用シールモデルを使用しています。これは、RGBトランザクションが発生すると、送信者が転送される権利を定義する契約の状態遷移を作成することを意味します。トークンの場合を例に取りましょう。まず、契約の発行者が初期状態を設定します。これには、資産名、総供給量、供給量を移動する権利を持つUTXOなどの契約詳細が定義されます。その後、資産が最初に転送される際、最初のUTXOの所有者は、新しいUTXOがどの資産を所有するかを定義する状態遷移を作成できます。RGBは、UTXOが一度しか使用できないというメカニズムを活用して状態遷移を実現し、これによって暗号資産の転送と所有権の変更を確実に定義し追跡することができます。
RGBはすべてのトランザクション情報をビットコインネットワークから切り離し、送信者と受信者の間でのみ転送します。一方、コミットメントデータはビットコインのUTXOにアンカリングされます。UTXOが使用されると、同じ方法で再度使用することはできず、これは契約の変更を意味します。
RGBはビットコインブロックチェーンを利用して二重支払いから保護し、これは移動される権利を所有するUTXOを使用するビットコイントランザクション内に各RGB状態遷移をコミットすることで実現されます。複数の状態遷移を単一のビットコイントランザクションに含めることができますが、各状態遷移は一度しか提出できません(そうでなければ二重支払いが可能になってしまいます)。1つのコミットメントに複数の状態遷移を含めるために、状態遷移は複数回集約され、その後TaprootまたはOP_RETURNを通じてビットコイントランザクションに提出されます。ビットコイントランザクションに複数のコミットメントが存在する場合、RGBの検証ルールにとって関連性があるのは最初のものだけで、他のものは無視されるため、二重支払いの試みは無意味になります。RGBの主要な特徴
スケーラビリティ
- ロジックをすべてチェーン上に保持する代替プロトコルと比較して、CSVはデータをオフチェーンに保持し、コストと計算負荷を軽減します。
- RGBは、コードの変更や複雑なオンチェーントランザクションを必要とせず、ビットコイン上ですぐに利用可能です。
- RGBはライトニングネットワークをサポートしています。
プライバシー
- 第三者はRGBトランザクションやそのシングルユースシールを観察できません。
- RGBはブラインドUTXOを特徴としています。ブラインドUTXOは、UTXOとランダムなブラインディングシークレットの連結のハッシュで構成されます。これにより、送信者は資産の行き先を知らず、新しい受信者は資産を使用する際にのみブラインドUTXOを検証できます。
- RGBはまた、ブレットプルーフと呼ばれるゼロ知識メカニズムを使用します。このメカニズムの下では、資産所有者は以前に資産を所有していたすべてのUTXOを見ることができますが、各状態遷移で転送された資産の量を見ることはできません。
RGBの多様な機能とユースケース
スキーマ
発行者は、特定のユースケースを対象とするために使用できる契約のテンプレートとして機能するRGBスキーマを使用できます。
以下はいくつかの例です:
- RGB20 代替可能資産の発行
- RGB21 非代替資産の発行
- RGB22 分散型デジタルアイデンティティ
- RGB23 監査可能なデータの検証可能な一意の履歴ログ
- RGB24 分散型グローバルドメインネームシステム
- RGB25 収集可能資産の発行
誰でもRGB開発者に許可を求めることなく、異なるアプリケーション用に独自のスキーマを開発する自由があります。ただし、ほとんどのユースケースは少数の主要なスキーマでカバーできると予想されています。
AluVM
RGBは、特別に設計されたレジスタベースのRISC仮想マシンであるAluVMを採用しています。AluVMはチューリング完全であり、既存のブロックチェーンベースのシステムと同じ可用性保証でグローバル状態を操作できます。EVMと同様に、AluVMはライトニングネットワークの上にRGBノードを入れ子にする構造を持ち、RGBノード上にRGBクライアントを配置しています。
ライトニングネットワークと完全に互換
特定のトークンの支払いチャネルをライトニングネットワークにリンクすることで、RGB資産は通常のライトニングネットワーク支払いと同じユーザー体験とセキュリティ前提を提供できます。これにより、低コスト、高速、安定した支払いが保証され、ユーザー、開発者、ライトニングノード運営者を含む全エコシステムに利益をもたらす可能性があります。
他のソリューションとの比較
RGB対TARO
TARO(現在はTaproot Assets)は、Taprootに支えられたTaroプロトコルで、Lightning Labsが7000万ドルのシリーズB資金調達後の2022年4月に導入しました。
RGBとTAROはどちらもCSVに基づいています。両者は類似した設計を共有しているため、TAROがRGBからインスピレーションを得たという意見もあります。しかし、現在では異なる側面に焦点を当てているようです:TAROはトークンに集中し、RGBはスマートコントラクト機能の実装を目指しています。
他のビットコインソリューションとの比較
BIP300とBIP301に基づきハードフォークを必要とするDrivechainとは異なり、RGBは既存のビットコイン技術および将来の潜在的なソフトフォークと互換性があり、ビットコインの基本層での修正を必要としません。
Ordinalsはすべてのデータをブロックチェーンにコミットしますが、RGBはデータのコミットメントのみをチェーン上に保持します。UTXOが提供するセキュリティを考慮すると、RGBはオンチェーンスペースを最小限に抑え、ライトニングネットワークとのシームレスな統合を可能にします。
RGB対ロールアップ
ロールアップは、イーサリアムのスケーリングソリューションで、ユーザーがイーサリアムのスマートコントラクトに資金を預け、同じロールアップ内の他のユーザーと取引することを可能にします。これらの取引は定期的に集約され、ブロックチェーンに提出されます。
- さらに、RGBは独立したブロックチェーンではありません。課題としては、RGBエコシステムがまだ初期段階にあることが挙げられます。インフラストラクチャーは既に整っていますが、エコシステムには基本的なアプリケーションがほんの一握りしかなく、RGBが開発者ツールとユーザーベースを拡大するにはしばらく時間がかかる可能性があります。
- RGBクライアントは大量のデータを保存し、検証用のオフチェーンデータが失われると支出が不可能になります。そのため、鍵だけでなく、データも保存する必要があります。さらに、ビットコインやその他のグローバルコンセンサスシステムとは異なり、RGBクライアントはグローバルにすべてのトランザクションを見たり検証したりする必要はありません。代わりに、自分のウォレットに関連するトランザクションのみを検証すればよいのです。これにより、各クライアントが検証しなければならないデータ量が大幅に削減され、システム全体がより拡張性の高いものになります。支払いを受け取る際に大量のデータを検証することは、検証が遅いと取引が遅くなるため問題に思えるかもしれませんが、これはトランザクション履歴が長い場合にのみ問題になります。そのような場合には、新しいデータ可用性レイヤーが必要になり、クライアントが特定の契約の状態遷移データを自発的に共有できるようになります。これにより、将来の受信者はトランザクション履歴の一部を事前に検証し始めることができます。
- 人気のあるCSVトークンについては、広範な採用により検証コストが上昇する可能性があります。
- RGBはコミュニティ主導の開発であり、チームの綿密な研究に依存しているため、進展が遅く、市場プロモーションが限られています。
開発者の学習曲線:ビットコインの知識に加えて、開発者はRGBの状態遷移と契約についても常に情報を得ておく必要があります。
エコシステムプロジェクト
DIBA
ウェブサイト: https://diba.io/
DIBAは、RGBスマートコントラクトプロトコルを使用したビットコインNFTマーケットプレイスです。
Cosminmart
ウェブサイト: https://www.cosminmart.com/
Cosminmartは、RGBプロトコルに基づくエコシステムで、ウォレット、マーケット、ローンチパッド、ブラウザなどの機能を提供しています。
Mycitadel
ウェブサイト: https://mycitadel.io/
Mycitadelは、マルチシグネチャ、時間制限付き支出条件、Taprootなど、幅広い機能を特徴としています。
Bitmask
ウェブサイト: https://bitmask.app/
Bitmaskはウォレット拡張機能です。
会社概要
2017年に設立された CoinEx は、暗号通貨取引をより簡単にすることに取り組むグローバルな暗号通貨取引所です。このプラットフォームは、200以上の国と地域にわたる500万人以上のユーザーに、スポット取引、マージン取引、先物、スワップ、マーケットメイクアカウント(AMM)、金融管理サービスなど、幅広いサービスを提供しています。平等で尊重される暗号通貨環境を創造するという当初の意図で設立されたCoinExは、使いやすい製品とサービスを提供することで、誰もが暗号通貨取引にアクセスできるよう、従来の金融の障壁を取り除くことに専念しています。
参考文献
https://hackernoon.com/top-4-directions-of-bitcoin-ecosystem-scalability
https://docs.rgb.info/
https://github.com/RGB-WG/blackpaper/blob/master/README.md
https://docs.lightning.engineering/the-lightning-network/taproot-assets
https://docsend.com/view/he8x9erkjmphphvn