中央銀行デジタル通貨のデザイン（２）CBDCとはなにか？
この連載では、中央銀行デジタル通貨のデザインについて説明しています。
第１回：イントロダクション
CBDCの定義と特徴
これだけ中央銀行デジタル通貨（CBDC）の議論が盛り上がっているにもかかわらず、「CBCDとは何か」について、金融当局者の間にも一致した意見があるわけではありません。
たとえば市場インフラ委員会（CPMI）の市場委員会が2018年に公表した「Central Bank Digital Currency」では、「既存の支払単位建ての中央銀行の負債であって、交換媒体と価値保蔵手段の双方の機能を持つもの」という定義を用いています。
ここでは、米国セントルイス連銀のCharles Kahn氏とカナダ中央銀行のFrancisco Rivadeneyra氏の論文「Should the central bank issue e-money?」で提案されている「中央銀行に対する電子債務であって、トークンとして又はアカウント内に保持されるもの」という定義を用いることとしたいと思います。
この定義によるところのCBDCが何を意味しているか、分かりやすく言えば何をCBDCではないと言いたいのかを理解してもらうために、「おカネ」の特性を以下の４つに分けてみたいと思います。
(1) 発行者は誰か？ － (a)中央銀行か、(b)それ以外か
(2) 媒体は何か？ － (a)電子か、(b)それ以外か
(3) 誰が持てるか？ － (a)誰でも持てるか、(b)限定的か
(4) 移転方法は？ － (a)中央集権型か、(b)分散型（P2P）か
この４つの特徴は、国際決済銀行（BIS）が2017年に公表した報告書「Central bank cryptocurrencies」に書いてあるものです。
この記事で採用しようとしている上記のCBDCの定義は、(1)と(2)については(a)だけれども、(3)と(4)については両方ありうる、ということを言っていることになります。
そしてもう一つ、この記事のCBDCの定義は、その実装方法について「トークンとして」又は「アカウント内に」保持されるということを言っています。
ちなみにこのBISの論文は、CBDC界隈では有名な「Money Flower」を考案したとてもよく知られたものです。Money flowerとは、上記の4つの楕円を重ねて花のようにしたもので、そのうちのどれがCBDCなのかということを視覚的に訴える資料です。
アカウント型とトークン型の違い
上記のCBDCの定義では、CBDCにはアカウント型とトークン型があるということを主張しています。アカウント型とトークン型というのは、多分にブロックチェーンを意識しての区別でありますが、両者の相違は、中央銀行に対する債務の検証方法の違いということができます。
すなわち、アカウント型のCBDCというのは、支払に際し、支払者がそのアカウントの保有者であるということを確認することで、決済が行われるという種類のものです。「アカウントの保有者である」ということの意味は、本当は、そのアカウントへの事実上のアクセス権がある（authentication：認証）ということと、実際にアカウントにアクセスした人が本人である（verification：身元確認）ということの２つに分かれているわけですが、ここでは前者について言っています。預金通貨による支払いをする際には、口座番号と共にIDやパスワードを銀行に聞かれて、銀行がこれを確認して初めて支払いができることになりますから、これはアカウント型ということになります。
これに対して、トークン型のCBDCというのは、支払いに際し、支払者が誰かということではなく、そのトークンが本物なのかということ（authenticity）を確認することで、決済が行われるという種類のものをいいます。紙幣や貨幣は、支払っている相手方が誰かではなく、それが本物かどうかということによって、決済が有効に行われるかどうかが決まりますので、これはトークン型ということになります。
アカウント型では、支払者による支払い行為をきっかけに、アカウント管理者が、支払い行為をしようとしている者が、アカウントにアクセスして残高を変更する権限がある者であるかどうかを検証しなければ、決済は完了しません。検証に誤りがあった場合の責任はアカウント管理者が負うということになります。
これに対してトークン型において問題となるのは、受け取ろうとしているトークンが真正のものであるかどうかということのみです。支払者が誰なのかという確認も必須ではないですし、口座管理者のような第三者を開催させなくても決済が可能です（P2P型）。そして、もしそのトークンが偽物であった場合のリスクは、原則としてそれを受け取った者が負担することになります。
移転方法の中央集権性と非中央集権性について
CBDCの特徴をつかむうえで、もう一つ理解しておきたいのは、中央集権と非中央集権（分散）が何について言われているかということを正しく理解しておく必要があるということです。
データベースをいじる人には当然のことでありますが、帳簿記録に対する権限というのは大きく2つあります。すなわち、帳簿を閲覧する（アクセスする）権限と、帳簿を書き換える（アップデートする）権限の２つです。日本では銀行APIの議論をきっかけに、「参照系」と「更新系」という言葉が広く知られるようになってきましたが、まさにその２つです。
中央集権性（centralized）と非中央集権性（decentralized）の相違は、帳簿の参照と更新のそれぞれについて、これらを誰が許可するのかということに関連します。つまり、中央集権型と分散型というのは、参照と更新のそれぞれについて別に検討することができるということです。具体例を図示してみると以下のとおりです。
記録管理システムのトリレンマ
記録管理システムにはトリレンマがあるということが知られています。すなわち、アクセス性、セキュリティ、プライバシーの３つを完全に満たすシステムはないというものです。どのような記録管理システムも、この３つについて、どこかで妥協をしながらバランスを取らなければならないということを含意するものです。
アカウント型のCBDCとトークン型のCBDCも、記録管理システムのもとにありますから、それぞれこのトリレンマが当てはまります。そして、CBDCの特性も、このトリレンマのもとで各プレイヤーのモチベーションがどのようになるかということによって影響を受けることになります。
たとえばアクセス性とセキュリティの間のトレードオフについてみてみましょう。
アカウント型のCBDCは、これが機能するためには必ず口座管理者が必要ですので、これは必然的に中央集権的になります。そして、先ほど見たように、アカウント型のCBDCについて、不正取引については基本的に口座管理者にそのリスク負担が寄せられます。そうすると、アカウント型のCBDCは、アクセス性を制限してセキュリティを重視する方向に振れることになります。
トークン型のCBDCは、トークンの真正性を確認できれば決済ができるのですから、アカウント型のCBDCとは異なり、不正取引のリスクは支払いの受領者が負担することになります。不正取引は、二重払いによるものと偽造トークンによるものがありえますが、受領者はこれを確認しなければならないことになります。もし、トークン型のCBDCについて、アクセス性を広くすると、こうした二重払いや偽造が起きないための仕組みを整えなければなりません。
デジタルトークンのうち、アクセス性を大きく高めて対応しようという発想で作られたのものの典型が、ビットコインをはじめとする分散型の移転方式を採用した暗号資産です。その結果、これらの暗号資産は、二重払いや偽造が起こらない正しい帳簿の更新を実現するために、マイナーに大きな報酬を支払うことを余儀なくされています。CBDCをトークン型で構成することを考えたときには、アクセス性の広さを確保するためにどの程度のコストをかけることが必要かということを考える必要があることになります。
アクセス性とプライバシーの間のトレードオフについても、こうしたことと似たような分析を行うことができます。すなわち、CBDCをアカウント型で実装するにしてもトークン型で実装するにしても、トリレンマから逃れることはできない以上は、アクセス性、プライバシー、セキュリティについて、システム面においてバランスを取りながら実現しつつ、必要な部分を法律・規制などを用いて補強・補完していかなければならないということがわかります。
かんたんなまとめ
以上、CBDCといっても、①アカウント型による実装とトークン型による実装があること、②トークン型の実装の場合には参照と更新の双方について権限を集中させるのか分散させるのかの選択がありうること、また③記録管理システムのトリレンマに基づき、アクセス性、プライバシー、セキュリティのどの部分をどの程度重視するかによるデザインのバリエーションがあること、をご理解いただけたかと思います。
上記が技術的なデザインのバリエーションだとすると、これに法律によるデザイン、すなわち規律によるデザインを追加して施し、場合によってそのデザイン性につき技術による担保を施すという形で、CBDCはデザインされます。そして、そのデザイン次第でCBDCは様々な特徴を持ちうるということになります。
それぞれの特徴が、CBDCの正確にどのように影響を与え、またその特徴にもかかわらず変わらないポイントが何かということを頭に入れながら、次回の「なぜCBDCは必要なのか」を皆さんと一緒に考えていきたいと思います。
なお、以上ではまだ、「(3) 誰がCBDCを持つか」についてご説明していません。これはCBDCのアカウント構成の問題として、CBDCの実装にとって本質的な問題になりますので、この点については次々回に説明することにします。
この記事が気に入ったらサポートをしてみませんか？