CBDCの落とし穴~ロイター記事より~(後半)
今回の記事は、「SBI R3 Japan」が公開しているMediumから転載したものです。
より様々な内容の記事に興味のある方は、是非こちらにも訪れてみてください。
ロイターの記事(Swedish bankers face identity crisis over digital currency plans)をベースに、CBDCにまつわる課題を論じた前半。
後半では、
6. 課題解決に向けて
についてお話ししようと思います。
6. 課題解決に向けて
CBDCの課題は3つありました。
2. CBDCがもたらす課題①調達の不安定化(ロイター記事の問題意識)
3. CBDCがもたらす課題②マイクロマネジメント
4. CBDCがもたらす課題③プライバシー
こうした課題に対する答えを探してみようと思います。
①調達の不安定化と②マイクロマネジメントの課題は、いずれも「非金融機関の持つ預金の急激な移動」にあります。そして、③プライバシーの課題は、「非金融機関のプライバシー」に属する問題です。
(金融機関の行動は、結果レベルとはいえ中央銀行が全て知っているべき事象です。)
つまり、ここで出てきた懸念のほとんどは
非金融機関が中央銀行のシステムに直接アクセスできること
が真の課題であると理解できます。しかし、CBDC技術の背後にあるのは「ブロックチェーン/分散型台帳」という技術です。きちんとアーキテクチャを用意すれば、
ネットワークは中央銀行が管理しているが、個別システムは中央銀行のシステムではない
という状況を構築しえます。大事なことは、技術的な実現可能性と、ビジネス目線での導入意義の確立です。
例えば・・・
下図のような枠組みが考えられます。一般的には2層構造のCBDCモデルと言われるものです。
CBDCのトークン自体は銀行免許を持つ企業(要は銀行)だけがアクセスできる形にします。
この場合、
CBDCの目的は純粋に銀行間決済の事務コスト削減とします。
金融調整という観点から、CBDCのスコープに国債とのDvP決済実現(による事務コストと決済リスクの削減)があってもよいかもしれません。いずれにせよ個人や一般法人が入らない事を仮定することで、要件は軽くなります。
なまじ、CBDCにできそうなこと(例えばスマホでアクセスできる口座である・・)をすべて盛り込む事は、実現可能性という意味でも、本稿の前半で述べたようなリスクを回避するという観点からも避けるべきです。
そして、その際にCBDCの技術要件の一部として、
「CBDCと同様の技術(ブロックチェーン/分散台帳型であること)を用いたトークン」との交換仕様を提示
します。もちろん、通常の決済仕様を定めたISO20022等とも透過的な仕様とするべきです。
もちろんこの交換仕様にCBDCは準拠する形で実装します。
この交換に関する仕様も含めて、CBDCは、その技術仕様をセキュリティの観点で避けるべき部分を除いて公開します。そうすることで、例えば、国債DvP実現に向けた実装であれば、その仕様を利用することで社債のDvPが実現できるかもしれません。
(民間への展開を前提とするのであれば、「契約当事者のみ情報を保持する」、「個人情報の削除にネイティブで対応できる」という要件を満たす唯一の基盤であるCordaの使用を是非ご検討いただければと思います)
いずれにせよ重要なのは、民間のビジネスへ中央銀行が出て行かない事。それから、市中の情報を中央銀行が管理しない事だと考えます。
その代わり、CBDCと交換可能なトークン側の仕様をより「分散的」なものにする(例えばトークン交換には資本関係のない複数の銀行の承認が必要である)事も検討できます。こうする事で分散化によって得られる、中長期的な社会コストの低減という目標にも資することができるかもしれません。
そうすることで、例えばDvP化したSTOプラットフォーム、SCMと連動するトランザクションレンディングといった様々なユースケースがCBDCを起点に生まれてくると考えます。下図のようなイメージです。
7. 先進事例、そしてR3の取り組み
CBDCを検討するにあたっては、他にも多くの課題があります。例えば、先進的な取り組みで知られるタイ中銀は、その最新のレポートとそのサマリーにおいて、Hyperledger Besuを用いたホールセールCDBCの実験結果を公表しています。
(上に示した概念も、タイ中銀が昔から公開していたアイディアを少し形を変えてみたものになります)
タイではCordaを用いた世界最大規模のソリューション(B2Pプロジェクト)が大規模に商用化されています。その為、ホールセールCBDCのレイヤーの実装に(B2Pプロジェクトは異なる)Besuを用いた場合、何が課題となるのかを今回検討したのではないかと推測しています。
そのレポートでは、彼らの用いた技術は、プライバシーとパフォーマンス(TPS)に関して課題があることを明言しています。
※1 プライバシーについてはゼロ知識証明を使う場合とBesuのプライバシーグループを比較してより高度で柔軟性を持つゼロ知識証明を選択したが、それでも望むような結果は得られなかったようです。
※2 パフォーマンス(TPS)についてはRollupの活用を試したが、トランザクションを思うように詰め込めなかったようです。
CDBCに関しては、他にも非常に多くの話題、課題があります。例えば
✓今回取り上げたような金融安定とバランスシートコントロールに関する課題
✓倒産隔離や(Direct型のCDBCなら)相続などの法的枠組みへの対応
✓ネッティング実装や流動性供給などアプリデザインの課題
✓インフラ課題(特にプライベート型ブロックチェーンであれば、PKI基盤の管理)
✓(ダイレクトリテールCDBCの目的である)金融包摂を先進国が目指す意味、価値がどこにあるのか?という課題
等々・・・こうした数多くの論点に対し、R3では世界中の中銀やBISといった組織の方々と一緒に、CBDCワーキンググループというものを構築しています。そこではより精緻で真剣な議論が重ねられています。
例えばこちらのビデオをご覧ください。もしご興味があれば、コメントや弊社HPを通じて是非ご一報いただければと思います。ご対応させていただきます。
又、R3では、CBDCのサンプル実装としてBank in a Boxというサンプルアプリケーションも用意しています。試してみるという観点では、利息支払いなど、非常に面白いユースケースを実装しています。
当然コードも公開されているので、議論のたたき台としてとても分かりやすいものなのではないかと思います。こちらの使い方については弊社の担当者がご説明可能です。ご興味があればお声がけください。
https://github.com/corda/bank-in-a-box最後までお読み頂き誠にありがとうございます。記事へのご質問やブロックチェーンに関してお困りごとがございましたらお気軽にご連絡下さい。
ブレインストーミングやアイデアソンも大歓迎です。
Facebook: https://www.facebook.com/R3DLTJapan
Twitter: https://twitter.com/R3Sbi
HP: https://sbir3japan.co.jp/product.html
お問い合わせ:info-srj@sbir3japan.co.jp
おすすめ記事
記事一覧はこちら
(記事作成:SBI R3 Japan/YuIku)