RGBプロトコルのググりかた

RGBプロトコルのググりかた LNP/BP の今を眺める 邑中雅樹 a.k.a. もなか mailto: monaka[.at.]monami-ya.com https://www.monami-ya.com/

• https://www.monami-ya.com/

自己紹介

もなか (monaka) / monamour555 皆さん、私自身には、さしたる興味もないはずですので … 過去のインタビュー記事: https://xtech.nikkei.com/atcl/nxt/column/18/00240/100900018/ https://xtech.nikkei.com/atcl/nxt/column/18/00240/101000019/ https://journal.peakers.jp/0308021592/

• https://xtech.nikkei.com/atcl/nxt/column/18/00240/100900018/
• https://xtech.nikkei.com/atcl/nxt/column/18/00240/101000019/
• https://journal.peakers.jp/0308021592/

所属会社のプレスリリース

RGBについてググってみよう！

「英語わからんので、安土神に相談だ。」

[OLD!] ? archive? …嫌な予感が…

archived !? プロジェクト終わっちゃったの?

調査終了 _(:3」∠)_

な、わけなくて

移転先 https://github.com/lnp-bp

LNP/BP という、ムーブメント 【 現状分析 】 ● ● 現代のネットを支えているのは、階層構造。(例: IP → TCP → HTTP) ブロックチェーンの進化方向も (少なくともビットコインは)、階層構造。 【 整理解釈 】 ● ● BP (Bitcoin Protocol) の上に LNP (Lightning Network Protocol) があり、 その上に、アプリケーション層が実現される。

LNP/BP Association の Working Group ● ● ● ● ● ● ● RGB-WG: scalable & confidential smart contracts for Bitcoin & LN with client-side-validation 今回は、これ。 BP-WG: bitcoin protocol-related developments LNP-WG: lightning network protocol evolution Storm-WG: protocol for trustless decentralized & incentivized data storage network on top of Lightning network with bitcoin native payments Prometheus-WG: protocol for trustless decentralized & incentivized computing network on top of Lightning network with bitcoin native payments AluVM: AluVM virtual machine - functional RISC registry-based VM for ubiquitous deterministic computing Strict Encoding: encoding standard and schema language for deterministic binary data serialization in client-side-validation applications

• https://github.com/RGB-WG
• https://github.com/BP-WG
• https://github.com/LNP-WG
• https://github.com/Storm-WG
• https://github.com/Prometheus-WG
• https://github.com/AluVM
• https://github.com/strict-encoding

主要サードパーティ https://github.com/RGB-Tools https://github.com/diamondhands-dev 成果物 開発中 ● rgb-lib ○ ○ ● ● LNP/BP Association の成果物を束ね、RGB 対応ウォレットの開発を補助。 FFI バインディングで Rust 以外の言語もサ ポート Iris wallet (testnet) ○ Android 対応。Store でインストール可能 Shiro-wallet ○ UmbrelOS で使える RGB 対応ウォレット

• https://github.com/RGB-Tools/rgb-lib
• https://github.com/diamondhands-dev

その他、情報源 ● RGB-FAQ https://www.rgbfaq.com/ ○ ○ ● 親切とは云い難いが、なにもないよりはかなりマシ。 開発中枢の人たちが保守しているようなので、情報源としては押さえたほうが良さそう。 RGB Protocolとは何か https://atl.recruit.co.jp/blog/5241/ ○ ○ かなりよく纏まっている これを読めば、私がここに登壇する価値はほぼ無い。

• https://www.rgbfaq.com/
• https://atl.recruit.co.jp/blog/5241/

RGB プロトコルの特徴 高いプライバシー保護と耐検閲性 ● Client Side Validation ○ ○ ● Ethereum 系のような Global State は存在しない。 (プライバシー保護 ) ちなみに Counterparty や Omni は、Client Side Validation の先例。 Single Use Seals ○ ○ Counterparty や Omni とは異なり、オンチェーンにメッセージを含めない。 ≒ マイナーはトランザクションの選り分けが困難。 (耐検閲性)

Single Use Seal https://www.slideshare.net/Codemotion/single-use-seals-building-consensusapplications-on-bitcoin-peter-todd-blockchain-conf より引用。

• https://www.slideshare.net/Codemotion/single-use-seals-building-consensus-applications-on-bitcoin-peter-todd-blockchain-conf

Single Use Seal Peter Todd 氏が発案。 数式抜きで解説されたブログがある。(ありがたい) → https://petertodd.org/2016/commitments-and-single-use-seals ただしハッシュだらけで読みづらいので、補足記事あり。(日本語) → https://gist.github.com/monaka/dc46d97edbacb5bab1966c8f5197f90a

• https://petertodd.org/2016/commitments-and-single-use-seals
• https://gist.github.com/monaka/dc46d97edbacb5bab1966c8f5197f90a

ざっくり説明 Single Use Seals (½) ゴール ● ● ● 時系列で変化する情報を 改ざんも検閲も避けて Bitcoin のチェーンに刻みたい。 前提: UTXO は… ● ● ● ブロックに取り込まれたら UTXO に 戻せない。(reorg は除く) BTC 送金以外のデータを含められ る。 マイナーから検閲されうる。

ざっくり説明 Single Use Seals (2/2) そこで…。 ● データは、次に示す 2 つの情報のハッシュを取った上で チェーン外に保存する。 ○ ○ ● ● ● 記録したい情報そのもののハッシュ。 次に紐づけたい UTXO の在処 (TxHash:番号)。 上記ハッシュを、UTXO に埋め込んでブロードキャストする。 UTXO はブロックに取り込まれる。 数ブロック待てば、 BTC 並みの改ざん耐性を得る。

RGB プロトコルのアセット移動 ● ● ● ブロックチェーン上では、アセットを 移動した事実が見えない。 移動履歴の全貌は、いくつかの条件 が整えば可能だが、割と困難。 Alice や Bob が保持すべきデータ ○ ○ 各自の stash 直接関わった state https://www.rgbfaq.com/community/presentation-slides/ にある How RGB works.pdf から引用。

• https://www.rgbfaq.com/community/presentation-slides/

RGB プロトコルのデータ構造全貌 ● ● アセット移動の states は、俯瞰する と DAG 構造となる。 UTXO の保持が、それに紐付けられ たアセットの所有権を示す。 ○ 所有権に関しては BTC も同じなので、 その点は判りやすい。 https://www.rgbfaq.com/community/presentation-slides/ にある How RGB works.pdf から引用。

• https://www.rgbfaq.com/community/presentation-slides/

Any questions?

RGB, now and in the future

Ethereum 的スマコンは、どうよ?

Ethereum 的スマコンは、どうよ? (½) AluVM ってのが開発中らしい。https://github.com/AluVM ● ● ● ● ● ● 割と素直な RISC。レジスタベース。 演算装置(ALU) はクリプト向け演算に全振り。 チューリング完全。実行ステップ数でのタイムアウトあり。 ハードウェア化も想定している様子。 ただし開発中。先日も、ビルドさえ通らない状態となっていたり。 「RGB にどう組み込むのかも、厳密には定まっていないのでは」説。

• https://github.com/AluVM

Ethereum 的スマコンは、どうよ? (2/2) 記述言語として Contractum ってのが開発中らしい。 https://github.com/RGB-WG/contractum-lang ● ● 処理系のコードが公開されていない。 言語の構文を定義する EBNF ファイルは、ある様子。

• https://github.com/RGB-WG/contractum-lang

LN 対応は、どうよ?

Lightning Network 対応は、どうよ? 公式声明を否定する気はないが… 私見では、道はかなり遠そう…。 ● ● LNP/BP assoc の開発者数に比べて風呂敷がでかすぎる。 BOLT を追加または改訂する必要があり、折衝コストがありそう。 (今回の「仮想通貨の冬」は、長びきそうなので…地味に整備していく…感じ?)

state ってどこに保存されるの?

state って、どこにどう保存されるの? 【理想】 ● Bifrost と呼ばれる、LN watch tower の拡張に保管され共有される。 【現実】 ● ネット上に proxy-server を建ててウォレット間で共有する。 https://github.com/grunch/rgb-proxy-server

• https://github.com/grunch/rgb-proxy-server

Any questions?

Thank you! 邑中雅樹 a.k.a. もなか mailto: monaka[.at.]monami-ya.com https://www.monami-ya.com/

• https://www.monami-ya.com/