「デジタル・分散型金融のあり方等に関する研究会」の第3回会合で申し上げた内容

以下、金融庁「デジタル・分散型金融のあり方等に関する研究会」の第3回会合で申し上げた内容です。議事全体は、こちらをご覧ください。

--
事務局の皆様、横関先生、御説明ありがとうございます。それで、まず論点シートに従って順に述べたいと思うんですけれども、まず全体の論点の１の分散型の整理についてですけれども、まず前から申し上げているシングルポイントフェーリアをなくすこと、また、分散型Ｐ２Ｐのアーキテクチャーが本当に大事だと認識させられることが昨日実は２つ重なって、１つはフェイスブックが、ＢＧＰとＤＮＳという、本来彼らが無意識に肩の上に乗っているインターネットに関係する基本的な部分の問題で長時間サービスが止まって、スマートデバイスを含めて大きな問題を引き起しました。もう一つはモバイルＳｕｉｃａのサービスが止まって、大事な時期なんですけれども、定期券の購入が止まったりとかチャージできない人がたくさん出ました。

前回、Ｍ２Ｍの話もちょっと差し上げたんですけれども、Ｍ２Ｍとかサイバーフィジカルのような既存のサービスとＡＰＩのような仕組みだけでは到底さばき切れないユースケースの対応が急務であって、こういうユースケースでの支払いと決済インフラの構築に失敗したら、日本として劣後することが分かっている。つまり、単にイノベーションとくくるわけではなくて、もうつくらないといけないものがはっきりしている中で、こういうシングルポイントフェーリアをなくすこと、Ｐ２Ｐとか分散型の金融サービスを信頼ある形で構成することの必要性とか、あるいはこの会議自体の大事さを改めて認識していました。

その上で、１についてまずレイヤー分けとかトラストとかガバナンスの定義というのは、今この領域の話をクリアに分析できる人というのは多分地球上に１人もいないというふうに個人的には思っていて、ＩＳＯ／ＴＣ３０７でブロックチェーンの標準化していますが、この委員会もかなりいろいろな難しい場面に遭遇しています。実際参加しています。それが１つの例だと思います。

例えばトラストについては、私が参加しているＴｒｕｓｔｅｄ Ｗｅｂ推進協議会の定義を事務局資料で引いていただいておりますが、これは我々が２０１６年に日経で連載した話とそれを書籍にまとめた『ブロックチェーン技術の未解決問題』という本があるんですけれども、そこの定義を採用していただいているのですが、これが実際にユースケース上どう取り扱われるかというのは、Ｔｒｕｓｔｅｄ Ｗｅｂ推進協議会そのもので鋭意研究中なんです。ということを考えると、事務局はすごい大変苦労されて整理を試みられたということだと思いますし、そのことにはまず心から感謝申し上げたいと思うとともに、一方でこれを時間をかけて磨いていくことがとても重要であって、だからこそこの研究会が、研究する必要がある研究会があるのだと思いますので、ぜひ一緒に協力させていただいて磨いていければなと思っています。

その上で、セキュリティ、トラスト、ガバナンスというのは、どうしてもレイヤーを分けて、分けた上でほかのレイヤーにお任せということにはならなくて、どうしてもレイヤーをまたがって一緒に検討しなければいけないというものなので、レイヤーを分けて検討するのではなくて、何に対するトラストなのか、何に対するガバナンスなのかという対象もはっきりさせて、要求事項を出していくことが先だと思います。

そして、台帳の部分を巻き戻ししなくても、台帳の意味を解釈するアプリケーションで巻き戻し相当の処理をするということすら可能なわけで、あるいはそのほうが課題解決に対するトレースが残ることになるということもあるので、いろいろなことを考えながら、事務局が書かれた今の資料でいうところの複数のレイヤーで問題を解決するということは可能なわけです。その方法を改めてじっくり考えられればなと思います。その意味で、（２）では、そのように考えて、複数のエンティティーで責任を分担するという可能性は、前回私がプレゼンしたように当然存在する形態かなと思います。

あとは、前回時間がなくてあえて参考資料のほうに回しましたが、前回資料の私の資料の３６ページ、３７ページに今回の横関メンバーと同じようなことについて記載させていただいておりまして、まさに全く同じ考え方でございます。暗号とかその応用する世界においては、公開での第三者認証の組合せというのが、この２０年、２５年の世界中で努力して構築したトラスト、信頼の唯一のスタンダードであって、改めてＩＳＯなどで決められたＩＳＭＳであるＩＳＯ／ＩＥＣ２７０００シリーズ、コモンクライテリアと呼ばれるＩＳＯ／ＩＥＣ１５４０８、ＪＣＭＶＰなど、複数のレイヤーにまたがる仕組みなんですけれども、既に存在する公的認証と第三者認証の成功例に倣うということが重要かと思います。

そして、１について時間をかけてゆっくり検討するということを申し上げた一方でステーブルコインについては、事務局説明のとおり、裏づけ資産やＡＭＬ／ＫＹＣをはじめとして多くの問題が指摘されていて、米国でもたった今、現在、様々な議論が行われていますし、再来週、私がおりますワシントンＤＣでフィンテックウィークというイベントが行われますけれども、名立たる主要な規制当局者のトップクラスが最新の状況の議論をそこで行います。これらは、先ほど申し上げた分散型金融全体の論点とは独立に課題を指摘できると思いますし、既に論点２の（２）に挙げられているものは明白な論点かと思いますので、これを中心に次回などに集中的にステーブルコインの課題、現在においても規制目標から外れた点を明確にする必要があると思います。これはＰ２Ｐなど本当に大事にしなければいけない、最初に申し上げた点とは無関係に指摘できると思います。

あとは今回の２つのコインの分類に関していうと、リスクの分析を行った上で少し改良の余地があると思うので、できればバージョンアップに協力したいと思っています。

最後に、論点３、４については、各国のＣＢＤＣの状況を見てもそうですし、分離するのが当然考える対象であると。これは最初に申し上げた昨日のフェイスブックの件、Ｓｕｉｃａの件もそうですけれども、障害が起きる、あるいは運営会社が止まる、破綻するということを想定するとこのようになって当然で、２５年前の日銀ＮＴＴ電子現金でもう既に同じように考えています。つまりは、ＡＭＬ／ＫＹＣは除くものの、実はそのときに検討済みのところもあって、例えば日銀はあまたある銀行の中では一番破綻をしないという前提で、一方で市中銀行はそれより破綻する可能性があると。電子現金やＣＢＤＣは、自分が口座を持つ銀行が破綻しても有効でないといけないので、だとすると分離型になるというのは当然だと考えるのが普通のわけです。こういう感じで２５年前の実験からも学ぶ必要もあるでしょうし、幸い詳細を当時検討した生き残りがメンバーに２人いますので、そのこともこれでぜひ、将来のこの研究会の会でその辺の議論を協力させていただければいいかなと思っています。
--
追加の機会をいただいてありがとうございます。野田さん、佐古さん、栗田さんの今の話をちょっと補足したいと思います。結局のところは、いろいろな金融システムの考え方をプログラミングコードに落としたときに、それがまともなのかをどうチェックするのかという話になるわけですね。

まず、悪いほうのニュースを言うと、野田さんが最初に、オープンソースにすることでかなりそこはよくなるんじゃないかということだったんですけれども、私の経験からいうと、オープンソースだからといって、あるいは目が多いからといってセキュアになるということはかなり幻想であって、オープンソースのＬｉｎｕｘとかＵＮＩＸのシステムだって、２０年前に埋め込まれた脆弱性が今日発見みたいなニュースは結構日々目にするわけです。

私が結構昔にやったのは、ＳＳＬ／ＴＬＳという我々がよく使っている認証や暗号化のプロトコルというのが、おおむね７、８年前から１０年前にＳＳＬの古いバージョンとＴＬＳの古いバージョンで相次いでプロトコル仕様で脆弱性が見つかったんですね。実装もそうだし、仕様でも見つかって、ＴＬＳ１.３という今の新しいバージョンをつくるとなったときに、先ほど栗田さんがおっしゃいましたけれども、私はプロトコルの形式検証をずっとやっていまして、暗号プロトコルの形式検証のためのＩＳＯの規格もエディターでつくったんですけれども、世界中の形式検証の専門家も含めて、あるいはＭｏｚｉｌｌａとかＩＥＴＦでＴＬＳをつくっている人たちが一生懸命形式検証も含めてやっとセキュアにしました。

それでもまた、標準が決まった後に脆弱性が出てくるんですけれども、やっぱり相当努力をしないといけないというのと、ＩＥＴＦのスタンダードですら後から実装も含めて脆弱性が出てくるというのは、レイヤー分けが実は危険だという話とつながるんですけれども、ドキュメントって全部、こうしてほしいというアサンプションは書いていないんです。前回の私のスライドで、こうなるはずというのをたくさん書いていましたけれども、ああいう「はず」というのが全部ドキュメント化されてないがゆえに、プロトコルをちゃんとセキュアにつくったとしても、実装の人がそれを勘違いして実装して脆弱性が起こるということがあるんです。そういうことでいうと、オープンソースだから安全というわけじゃなくて、過去のいろいろなＴＬＳをつくった経緯も含めて、もうちょっとその辺のつくるガバナンスみたいなところを考えなければいけないと。これはバッドニュースです。

いいニュースは、栗田さんがおおむね１５４０８とかＪＣＭＶＰみたいに関わるところの話をされたんですけれども、セキュリティターゲットをつくります、プロテクションプラン（注：正しくはプロテクションプロファイル）をつくりますというのを一方でちゃんとやらなければいけない。例えばプロテクションプロファイルの例として、ＩＰＡさんのページに行くとＩＣパスポートの例とか、コピー機の例とか、守るべき資産がこういうのがあるのでこういうふうに装置を作ってくださいというプロテクションプロファイルの例をダウンロードすることができますので、既存の認証の仕組みが何を要求しているのかということをそこで多分理解する必要があるんだと思います。

私とか岩下先生がやっているＣＧＴＦという、もともとコインチェック事件が起きた後につくったセキュリティ基準をつくりましょうといってドキュメントを作った組織があって、岩下先生も一緒にやっていただいていますけれども、そこでやったドキュメントとか、その後それを基に僕らがＩＳＯでドキュメント化した暗号資産のセキュリティのレポートとか、取引上のセキュリティのＩＳＯ文書とかつくったんです。そこのところでやっぱりこれはそのうちプロテクションプロファイルにしなければいけないんだとかいう話もしていまして、やっぱりそういうものをつくっていくということが、逆に言うと皆さんが安心するために必要だろうし、佐古さんがおっしゃったところのインセンティブの一部になるんだろうと思っています。そうすると、こう言うと怒られるのかもしれませんけれども、ＦＩＳＣが金融システムに対して果たしている役割というものが拡張される、あるいは類似のものをこういうところでつくっていくということになるのだと思います。

あと最後、やっぱりエンジニアと規制当局が概念とか言葉を合わせる必要があります。これ、こんな言葉当たり前じゃないかと言うかもしれないですけれども、多分ビットコインの数学は、決済は考えてなくて支払いしかしないんです。決済を取引所に任せているんです。Ｐ２Ｐでやる部分とか、トラステッドサードパーティーがない部分は支払いができなくて、決済は別のトラステッドパーティーに頼んでいるから全体が回っているんです。実際にコードに落とすと、多分ペイメントとセトルメント、支払いと決済は違うと思うんです。その辺を実は概念を経済学者だとか法律家とエンジニアが合わせる必要がある。

あるいは、フィアット通貨とか関係ないとかさらっと言いますけれども、価値とはどういうことなのかということ、あるいはそれがコードになるとどういうことなのかということを実は改めて考える必要があって、この辺のところを詰めていくことが、今言ったように、コードに落としたときにそれがまともなのかということを改めて議論する必要があると思うので、そういうことをやっていくべきかなと思っております。