2018 年 2 月 仮想通貨と分散型台帳技術 世界の中央銀行の動向 日本銀行仙台支店長 副島 豊 本資料の内容や見解は報告者個人に属します 詳細な一次情報は巻末の参考文献を参照ください
今日のお話 デジタルマネーって何? 仮想通貨の特徴 中央銀 の動向 1
そもそも お金って何? お札 ( 紙幣 本銀 券 ) コイン ( 貨幣 ) 預 もお では 融資産は? 現金 預金 払に使える? 現 決済 電 決済 すぐ使える? ( 流動性 ) Yes 価値は? 安定 定期預金 金融資産 実物資産 ( 不動産など ) No 変動 2
預金はすでにデジタルマネー デジタルマネー 実はもう使ってる じゃあ 何を騒いでいるの?? そもそもデジタルマネーの定義は? たとえば プリペイドカード クレジットカード スマホ決済 ビットコインを区別するものは何? 仮想通貨はどう位置づけられる? 3
様々なデジタルマネー 電 マネー ( 狭義 ) は前払い制でお を貯めておく電 決済 Suica や WAON のように物理的なカードもしくはスマホに 1 前払い資 の残 の電 情報 もしくは 2 残 を確認するための通信機能を持たせる 現 に戻すことはできない ( 少なくとも 本では ) お を預かったほうは少なくとも半額以上を供託せねばならない 要は テレカなどに始まり 途がより広くなってきたプリペイドマネー クレジットカードはいったん借 をして その後 預 で決済 デビッドカードはリアルタイムの預 決済 電 マネーのように前払いでお を貯めておく必要なし J-Debitは 今年からレジでのキャッシュアウトが可能に ( 預 から現 を引き出すという点でATMと同じ ) 4
仮想通貨は他と何が違う? 単位が円や海外通貨ではない 従って 現実の通貨との交換 率がある 電 マネー ( 狭義 ) は仮想通貨ではない cf. J コインと MUFG コイン 分散型台帳システム 特にブロックチェーンを使うものが多い 預 や国債 株式 投資信託など全ての 融資産は 中央集中管理 ( 保管振替機構 銀ネット 銀 勘定系システム ) 電 マネーも中央集中管理 現 は発 廃棄は集中管理 しかし使う際は完全匿名 暗号が必須 ゆえに暗号通貨とも ( 後述 ) 現 と違い法定通貨ではない ( 強制 がない 電 マネーも同じで受取 次第 ) その価値は法定通貨との交換 率で される Bitcoin が使える店でも 1Bitcoin の購買 は円換算しないとわかりにくい ( 海外旅 での買物体験と似ている ) 5
仮想通貨 Bitcoin のアプローチ 問題 誰がいくら持っているか 誰が誰にいくら払ったか ( その結果 残 が減ったこと ) をどうやって管理するか? 通信途中の改ざんや 重使 をどう防ぐか 法 ワレット ( 電 財布 ) にアドレス ( 所有者アカウント 座 ) をつくる 1つのワレットに複数アドレスあってもOK 仮想通貨を払う = アドレス A からアドレス B に付け替える その際に暗号技術を使う デジタル署名で 署名者が確かに払ったことを証明し いくら払ったかを他者に変更 改ざんされないようにし 払ったこと ( 残 がその分減ったこと ) を当事者が誤魔化せないようにする 重使 の防 6
さらなる問題 どうやってワレット残 や 払いの正しさを保ち続けるか? 誰が作業する? 法 分散型台帳技術 中央集中型では 中央機関が台帳を作って 集中的に管理する ( 銀 預 の数字をシステム上変更できるのはその銀 だけ ) 分散型台帳システムの初期型 ( ビットコイン型 バブリック ブロックチェーン ) では 多くの が台帳を持ち これらを同期することで解決 勝 に台帳を変更しようとすると莫 な計算時間とコストがかかる ( 事実上不可能な ) 仕組み 仮想通貨を使う は台帳を持たされて 同期させられる ( この負担をユーザーが負わないような設定も可能 cf. フルクライアント / 軽量クライアント / ウェブ クライアント 最初に台帳記 できた は報酬を仮想通貨で得る これがマイニング 最初に台帳記 するには計算コストがかかる 計算競争 7
台帳の作り方 : ブロックチェーン 取引を複数個まとめてブロックにして 前のブロックに繋げる 繋げるには新しいブロック内のハッシュ値が必要 これは 前のブロックに含まれる取引データ 前のブロックのハッシュ値 ナンス値を暗号変換したもの ハッシュ値としての適性条件を満たすようなナンス値を 既知の取引データとハッシュ値から計算する必要 ( ハッシュ値は後述 ) つまりマイニングとはナンス値の計算作業 この計算コストが きい ある取引を改ざんするためには 後ろを全部再計算する必要 ( それよりも早く後ろのブロックが計算競争で追加されていくので無理 ) 新ブロックの取引データセットは マイナーが 分のアドレスに送 する記録から始まる ( 無から新規に通貨が誕 ) ブロック ハッシュ値 ナンス値 複数の取引データ 新ブロック前のブロックに対するハッシュ値 複数の取引データ チェーンのように繋がり続ける = 台帳は きくなる 8
( 参考 ) 公開鍵 秘密鍵による暗号化 暗号を作るときと 復号して中 を るときに使う鍵が異なる A さん 公開鍵と秘密鍵を持っている 公開鍵 暗号化されたメッセージ 公開鍵 B さん メッセージ 暗号化されたメッセージ 秘密鍵元のメッセージ 公開鍵は秘密鍵から作成されるが 公開鍵から秘密鍵を逆算することはできない共通鍵 式 ( 例 :Excelのパスワード) は共通鍵の受け渡しの際に盗まれたら暗号化した内容が られてしまう また 相 ごとに鍵を変える必要あり 9
( 参考 ) 公開鍵 秘密鍵を使ったデジタル署名 Aさん送りたい内容 B さん ハッシュ関数 秘密鍵 ハッシュ値 暗号化されたハッシュ値 ( デジタル署名 ) ハッシュ関数とはデジタル情報を 較的短い数値に変換する技術 元の情報が僅かにでも異なれば全く違うハッシュ値になる ハッシュ値から元情報は逆算不能 元の内容にデジタル署名を付けて送る 公開鍵 暗号化されたハッシュ値 復号されたハッシュ値 元の内容 ハッシュ値 両者が同じなら このセットを送ってきた は紛れもない A さん デジタル署名の 的 :Aが送ってきたこと 元の内容が改ざんされていないこと の確認送信内容を られたくなければ Bが持つ別の暗号鍵 ( 図中はAの鍵 ) の公開鍵をA が使って内容とデジタル署名ごと暗号化し Bはこれを 分の秘密鍵で開ければよい 10
( 参考 ) ハッシュ関数とハッシュ値 ハッシュとはある い数値や 字列を短い数値 ( ハッシュ値 ) に変換する暗号技術 変換する関数がハッシュ関数 もとの情報はどれだけ くてもいい 変換されるハッシュ値はハッシュ関数によって さが決まっている 例 :SHA-256 なら 256 ビット (16 進数で 64 桁 ) 参考 :16 進数 1 桁 (0-f) は 進数で 4 桁 ハッシュ値から元の情報を復元することはできない 元の情報が僅かにでも異なれば 出てくるハッシュ値は全く異なる 異なる元の情報が同じハッシュ値を出す ( ハッシュ衝突が起こる ) 可能性は極めて低い 同じハッシュ値が出るように元の情報を作ることは途轍もなく困難 (= 暗号として強い ) Bitcoinのブロックチェーンのハッシュ値 (SHA-246 64 桁 ) の条件は 冒頭にゼロが多数ならぶような さい値であること マイナーの計算能 が上がれば ブロック追加間隔 ( 約 10 分 ) を維持するために計算負荷が上昇する Blockchain.infoで最新のブロック組成状況がみれる 11
( 参考 ) 秘密鍵の管理方法 1 ワレットを PC やスマホに持ち ワレットのアカウント ( 座 ) ごとの秘密鍵を PC やスマホ内で管理する 2 ワレットをネット上で管理してくれるサービスを利 する ( アカウントと秘密鍵の管理を委託する ) 委託された業者が秘密鍵を盗まれ 仮想通貨が流出する事件が発 3 秘密鍵を専 のハードウエア (USB 接続する 型のメモリー等 ) に保存し 使 するときのみネットに繋がった PC やスマホに秘密鍵を提供する 1 に べると使 の際だけネット機器に繋がるので 較的安全 4 デジタル機器を使わず紙に書いて保存し 使 する際に打ち込む もしくは 紙にすら書かずに脳内で保持する ただし 桁数が いので変換プログラムを使わないと難しそう 12
分散型台帳技術の応用可能性 要は 台帳を管理する新技術 預 や有価証券の台帳 ファンディング 商流管理 投票 決議 認証システム 個 売買 シェアエコノミー : スマートコントラクト技術 地や法 の登記 住 台帳など広範なデータベースに応 可能 ビジネス マーケティングツールのポテンシャルと情報管理 台帳管理に中央管理者が不要 ( メリット デメリットあり ) DLT:Distributed Ledger Technology 利 者の範囲 取引の承認 台帳への反映 法 ( 台帳管理者の制度設計 ) 合理性 :1 コスト安 ( 種の STP 例 : 有価証券取引の照合事務 ) 2 い障害耐性 3 外部性 ( データの活 他ビジネスへの連動拡張 ) 13
分散型台帳技術のバリエーション ポイントバリエーション 字は 融機関が 掛ける DLT の主流技術 参加者台帳合意形成 コンセンサスアルゴリズム ( 承認やブロック 成 ) 承認や記帳への報酬取引データの閲覧 オープン型 クローズド型 ( コンソーシアム型 プライベート型 < インハウス型 >) 分散型 複数のプライベート型 単 のプライベート型 ( 中央集中型 ) PoW( プルーフ オブ ワーク Bitcoin 型 ) PBFT( プラクティカル ビサンティン フォルト トレランス ) 取引当事者間承認 PoS ( プルーフ オブ ステーク ) PoI( プルーフ オブ インポータンス ) マイニングに対する報酬 報酬無し ( リアル通貨の場合は報酬原資の問題 ) 由 ( 取引者はアドレス匿名 ) 制限( 取引当事者のみ ぶら下がり参加者分は閲覧可 他に様々なバリエーション ) 論点 : 取引の安全性 取引決済速度 ファイナリティの確保 取引情報の保護 ( 公開 限定公開 ) トラブル時の対応 中央監督管理者の必要性 14
中央銀行デジタルマネー : 現金 中央銀 がリテール決済 の仮想通貨を出す? 制度設計上の論点 途上 すべての企業や個 が利 可能なシステムになろう 1 中央集中管理型か 2オープン型の分散型台帳システムか 1の場合 中銀が全ての企業や個 の 座を管理するか 融機関に管理を委託するか ハイブリッド型もありうる ( 中銀が 融機関に発 その 合いで 融機関が企業や個 に発 ) 融機関や 間企業に委託した場合 預 ( デビッドカード ) や電 マネー ( プリペイド型 ) と何が違うか 裏付け資産が違うだけでは 2 では 台帳管理をオープンにするか 部参加者に限定集中させるか ( 限定した場合 その担い は中銀か 融機関か ) 合理性の論点 : 推進中の中銀は極めて例外的 ( 後述 ) 既存の電 マネーや Bitcoin のような仮想通貨より何が優れているか? 間部 との役割分担は? 情報管理 プライバシー保護 サイバーセキュリティは? 15
中央銀行デジタルマネー : 預金ほか 中央銀 の当座預 や証券の保管振替は すでにデジタルマネー化 電 証券化済み 技術的論点 アカウントを銀 など 部の 融機関から個別企業や個 に拡 するか 仮想通貨の特徴である分散型台帳システムに当座預 や証券の保管振替システムを移 させるか その場合の分散型台帳システムの特徴は? 合理性の論点機能 ( 安全性 速度 情報保護 STP 化 省プロセス化 速化 ) コスト 外部経済性( 拡張性 データエコノミーへの対応 ) 16
世界の中央銀行の動向 スウェーデン : リクスバンクが e クローナを準備中 理由は 現 が機能しなくなってきたから ( デジタル化推進ではない ) 現在の検討案 :250 クローネ以下の少額決済は カードやスマホへの価値保存型 ( 電 マネーや仮想通貨 ) を想定 e クローナは電 マネー型に限定 シンガポール :MAS( シンガポール通貨庁 ) が 銀 間 取引に DLT を利 する案を検討 MAS が銀 預託資 を 合いに DLT 型システム上で中銀債務 ( 預 証書 ) を発 し 上記の資 決済に利 するもの DVP にも拡張できないか検討 本 ユーロ圏 : 銀と ECB が共同プロジェクトとして ハイブリット RTGS 資 決済を DLT で実現可能か実データを使って検証 (Hyperledger Fabric を使 ) 現 システムとほぼ同等のパフォーマンス DLTの特性があり ( 例 : 取引検証参加者の数や拠点間距離の増加で処理時間が増加する傾向 ) スマートコントラクトで流動性節約機能が実装可能 検証ノード数 ( 後述 ) に上限 DLTは技術が 分成熟しておらず 銀ネットのような 規模システムへの応 には適さない カナダ : カナダ中銀が上記シンガポールと類似の DLT を実験中 参加者は銀 で 途は銀 間決済に限定 イーサリウムのブロックチェーンを利 17
( 参考 ) 現金通貨の回転率 通貨流通残 / 名 GDP 出典 ) 林亜紀 ほか 本銀 決済機構局 2016 年 ( 巻末参照 ) 18
( 参考 ) Hyperledger Fabric (Linux) クローズド型 認証局があり 参加者の 元やアクセス権限を す電 証明書の発 取消を う ( 認証局は必須ではない ) 検証ノード ( 参加者 ) は取引の検証と台帳管理 他の検証ノードへのブロードキャストを う ( 次 を参照 ) ver0.6ではコンセンサスメカニズムにpbftを利 定数の検証ノードからコミットメントを受信すると 全検証ノードは取引処理を実 し ( ここにスマートコントラクトを実装可能 ) 分が持つ台帳のブロックを更新する 検証ノードでない参加者は クライアントアプリケーションから取引内容を検証ノードに送信 19
( 参考 ) Hyperledger Fabric の処理プロセス (1) クライアント X が の電 署名を付してトランザクションを検証ノード A へ送信する (2) 検証ノード A は受付通知をクライアント X へ送信する (3) 検証ノード A は 事前に定義したバッチサイズ以上のトランザクションの受領 もしくは 定時間経過後に その間に受領した 連のトランザクションに 通し番号等を付して 他の検証ノードにブロードキャストする ( 事前準備メッセージ ) (4) 他の検証ノードは電 署名や通し番号等の確認を ったうえで 回のブロードキャスト ( 準備メッセージ コミットメッセージ ) のやり取りを う (5) 各検証ノードは コンセンサスの形成に必要な数 ( 検証ノードが全体で 4 台の場合は を含む 3 台 ) の検証ノードからコミットメッセージを受信したことを確認したうえで スマートコントラクトにより 連のトランザクションにかかる処理を実 する (6) 各検証ノードは 実 結果に基づきステータス情報を更新するほか 新たなブロックを追加して 連のトランザクションにかかる情報 ( 取引の内容 タイムスタンプ等 ) を保存する 出典 ) 本銀 決済機構局 (2017 年 ) 巻末参考 献を参照 20
中央銀行の仮想通貨へのスタンス 欧 は批判的 中国は取引禁 規制必要との声も FRB 議 イエレン :Bitcoin は極めて投機的な資産 安定的な価値保蔵 段でない 仏ルメール経財相 :G20 で ビットコインについての議論を う発議をする ビットコインにはリスクがあり どのような規制が必要なのかを議論するべき ECB 副総裁コンスタンシオ : Bitcoin は通貨ではなく ( オランダで 17 世紀にバブルを引き起こした ) チューリップのようなもの BIS 総 配 カルステンス : バブルと投資詐欺と環境破壊の組み合わせ 払 段や価値の維持 価値の尺度というマネーの役割を満たすのに適さない ( 参考 ) スウェーデン中銀総裁イングベス : 現 がネットワーク効果 ( 利 者が多いほど効 も増える ) を失う段階にまで っている 本は中国の取引禁 以降にユーザーが急増 資 決済法で法的位置づけを明確化 ( 通貨というより決済 段としての特性に注 ) 交換業者は登録制により監督対象に 税務上の扱いも明確化 ( 雑所得として 20 万円以上は確定申告 分離課税でない ) 世界的には 本は仮想通貨サポーティブに外からは えている 誤解も多い 総裁 : 払 決済 段でなく 単なる 融的な投資や投機の対象になっている まとめると 仮想通貨には厳しいスタンス でDLTは評価 中銀も実証テスト ( 時代についていく必要性 + 潜在 を評価 ) 21
参考文献 アンドレアス M アントノプロス ビットコインとブロックチェーン : 暗号通貨を える技術 本語訳フリー版 ( 今井崇也 鳩 純 郎訳 ) 2016 年 https://bitcoinbook.info/translationsof-mastering-bitcoin/ 岩下直 中央銀 から たブロックチェーン技術の可能性とリスク IBM Blockchain Summit 2016 本銀 website 2016 年 11 16 沖野健 分散台帳技術のセキュリティ要件 : 銀 振替処理への適 融研究第 37 巻第 1 号 2018 年 1 pp.89-108 林亜紀 ほか 中央銀 発 デジタル通貨についてー海外における議論と実証実験ー 銀レビュー 2016-J-19 本銀 決済機構局 2016 年 11 早川周司 中央銀 によるデジタル通貨発 の取り組み 融財政事情 2017 年 12 11 号 pp.14-17 中島真志 アフタービットコイン 新潮社 2017 年 本銀 決済機構局 Project Stella: 本銀 欧州中央銀 による分散型台帳技術に関する共同調査報告書 2017 年 9 6 本取引所 藤敦史ほか 融市場インフラに対する分散型台帳技術の適 可能性について JPX ワーキングペーパー Vol.15 2016 年 8 本取引所 近藤真史ほか 融市場における分散型台帳技術の活 に係る検討の動向 JPX ワーキングペーパー Vol.20 2017 年 9 22