分散型台帳技術にかかる基礎実験

第3回FinTechフォーラム『金融分野における分散型台帳技術の活用に向けて』
日本銀行決済機構局河田雄次
2017年2月28日

本日のテーマ

１．中央銀行とDLT

２．DLTにかかる基礎実験

３．金融゗ンフラ分野における許可型DLTの活用可能性（注）本資料は、作成者の個人的見解を取りまとめたものであり、日本銀行の公式見解を表すものではありません。

1１．中央銀行とDLT
 各国中銀にて研究活動が活発化。活用を巡る議論には「中央銀行デジタル通貨」に加え、「中央銀行当座預金（金融゗ンフラ分野）のDLT化」も含まれる。

中銀マネー：マネタリーベース

中銀当座預金銀行券

貨幣

中銀デジタル通貨？

DLT・ブロックチェーン？
2

（参考）主要中央銀行における取組み
DLTの活用可能性
中銀デジタル通貨
ECB：証券ポストトレードへの活用可能性に関する調査論文を公表（2016.4）

ユーロ圏

ECB：日本銀行との共同研究を公表（2016.12）
ド゗ツ連銀：ド゗ツ証券取引所と共同での実証実験を公表（2016.11）

英 国

゗ングランド銀行：民間と共同で、DLTを使った仮想の金融資産の管理・移転計画を公表（2016.6）

米 国

FRB：NY連銀、シカゴ連銀と共同で、決済システムへの活用可能性に関する調査論文を公表（2016.12）

カナダ

カナダ中銀：民間と連携し、DLT上で中銀債務を発行・流通・決済する実証実験を開始（2016.6）

ロシゕ

ロシゕ中銀：DLTを用いた市場参加者間の情報伝達ツールの試作品を開発（2016.10）

ロンドン大学：中銀発行デジタル通貨(RSCoin)の論文を公表（2016.2）

中 国

中国人民銀行：中長期的にデジタル通貨を発行する構想を発表（2016.1）

ｽｳｪｰﾃﾞﾝ

リクスバンク：e-kronaの補完的な発行を検討するプロジェクト立ち上げを発表（2016.11）3

２－１．DLTにかかる基礎実験 － 概要
 目的：技術の理解深耕 「銀行間資金決済システムの擬似環境」を用いて有効性や課題を評価。

 評価項目：
評価項目

実験内容① スマートコントラクト• 複雑な業務処理の実装可能性• 非確定的な処理の影響② 処理性能• 検証ノード数やリクエスト数の影響• 日銀ネットの業務処理量における処理性能③ 可用性• 障害時および障害復旧後の業務継続性

 DLT基盤：Hyperledger Fabric v0.6.1-preview版
 実験環境：スタンドゕロン端末（注）基礎実験を進めるにあたっては、日本IBM、NTTデータ、日立製作所のスタッフの方々から、多くの有益かつ貴重なコメントを頂いた。 4

２－２．スマートコントラクトに関する暫定結果
 日銀ネット同時決済口における流動性節約機能の一部を再現。
 時刻起動等の非決定的な処理や非停止性の処理などの実装には留意の必要。
本実験で確認した範囲＜二者間同時決済の例＞
30 の支払A行
残高 10B行
同時決済

Yes

支払指図
二者間決済

残高 0（即時決済を含む）

20 の支払条件付起動

No＜多者間同時決済の例＞

待ち行列

A行
20 の支払残高 1030 の支払

No

同時決済

C行

B行

残高 0残高 020 の支払

決済

キュー管理

特定の時間に起動
Yes

多者間決済

5

２－３．処理性能の「傾向」に関する暫定結果
 処理性能と可用性はトレードオフの関係にある。可用性向上には、ノード数を増やし、かつ地理的・ハードウェゕ的にも分散させることが望ましいが、これは処理性能の悪化をもたらす。
 検証ノード数の増加に伴いレ゗テンシが拡大。この傾向は処理負荷が高まるほど顕著。

7台の検証ノードの下で、1,000件/秒の振替依頼を処理するのに平均18.3秒かかることを示している。

処理性能

可用性
6

（参考）処理性能の「傾向」にかかる暫定結果
 検証ノード数が増えるほど、処理負荷増加による遅延度合いが拡大。
 CPUがボトルネックとなり、正確な評価に至っていない可能性に留意の必要。

 認証局は（取引認証書を発行するため）処理性能面ではボトルネックになり得るが、これまでのところその影響は概ね限定的。

Block Commit Latency (CA, BatchSize=500, Loop=5)
RPS10

RPS100Effect of CA (BatchSize=500, Loop=5)

RPS1000

RPS10

50x27.1

1.635

1.4Ratio (CA/NoCA)

Latency (seconds)

1.8

40x16.3

30252010

RPS1000

2.04515

RPS100x9.8

1.2

1.00.80.6
0.4

50.200.0
410# of Nodes

16410# of Nodes167

２－４．処理性能の「水準」に関する暫定結果
 2016年3月31日9:15～9:30までの日銀ネット同時決済口データを用いたところ、振替依頼の送信からブロック確定までに要した時間は平均約2秒。
 ただし、実験環境の制約から全体の取引処理に60分超を要したため、実験環境拡充後に再検証の必要。

（注）検証ノード7台・認証局1台で確認。 8

２－５．可用性に関する暫定結果
 検証ノード4台・認証局1台の下では、検証ノードの障害は1台まで許容され、台帳間で同期がとられる。
 検証ノード1台に障害が発生しても、残りの3台で処理を継続
 検証ノード2台以上に障害が発生した場合は、処理は中断。
 障害ノード2台のうち1台が復帰した場合は、障害中に処理されなかったトランザクションが処理され、併せて検証ノード間での台帳も同期。
検証ノードA

検証ノードB

検証ノードC

検証ノードD

1

1

1

1

正常実行

2222

正常実行

3

検証ノードC停止。
残りの3台で処理継続。

4

検証ノードC再起動。
台帳は自動的に同期。

34

3

4

4

（注）円柱内の数字はブロック高。 9（参考）可用性にかかる暫定結果（検証ノード4台、認証局1台）
 1ノードの障害（ハードウェゕ障害、ネットワーク障害、ビザンチン障害）
 残りのノードで処理は実行※ ただし、ネットワーク障害時は当該ノードには空のブロックが生成される

 2ノードの障害

乱数を含む処理の場合も同様

 処理は中断、ブロックも生成されない※ ただし、ビザンチン障害1台と他の障害1台の組合せでは、処理は継続するものの、一時的に台帳がずれる場合あり

 障害中の2ノードからの1ノードの復帰
 中断中のトランザクションが即座に処理される※ 同期は一定間隔毎に行われる。差分同期が難しい場合は台帳ごと差し替えられる

 認証局の障害（単一障害点における障害）
 新たなユーザでのログ゗ンは不可、取引証明書が無くなるとそれ以上のトランザクションの送信は不可
 設定フゔ゗ルを書き変えて再起動すれば、任意のユーザを追加可能

10

２－６．DLTにかかる基礎実験 － まとめ
暫定的な結果・ネッテゖングなどの複雑な業務処理をスマートコントラクトで実装可能。
・従来システムに比べ、「処理性能」の面では見劣りするものの、「可用性」の面でメリットをもたらし得る可能性（ただし、処理性能と可用性はトレードオフ）。

今後の取組み・評価基準の充実化：主に安全性に関わる面で、さらなる確認を要する点が多い。
・実験環境の向上：パフォーマンスを左右する要素の洗い出しには、実験環境によるボトルネックを極力排除することが望ましい。
・基盤技術革新への対応：例えば、Hyperledger Fabricにおける新しいコンセンサス
モデルやチェーン間連携など。など

11

３－１．金融インフラ分野における許可型DLTの活用可能性 － 仲介者の存在
 仲介者および単一障害点の存在 (注)ビットコ゗ン゗ーサリゕム

仲介者なし

ノード
(参加者)

ノード
(参加者)

Fabric v0.6

Fabric v1.0

Corda v0.5

認証局

認証局
Orderer

Notary Service、
Network-Map
Service

ノード
(参加者)

ノード
(参加者)

スーパーノード
ノード
(参加者)

ノード
(参加者)

ノード
(参加者)

ノード
(参加者)

（注） FabricおよびCordaでは、単一障害点解消のため、仲介者の分散化が検討されている(2017年1月時点)。12

３－２．ビザンチン障害耐性、改竄耐性
 コンセンサスゕルゴリズムとビザンチン障害に類する障害への耐性 (注)ビットコ゗ン ゗ーサリゕム
PoW

Fabric v0.6

Fabric v1.0

Corda v0.5

PBFT

重み付き多数決ないし条件式(Endorser間)

RAFT(Notary間)

ノード数の約1/3まで任意のノード数まで総ノード数（約1/3未満と解釈）

Ethashブロック生成難度の累積値が最も大きい帳簿が正CPU能力の50%までゼロ（注）コンセンサスゕルゴリズムが用いられる箇所において、どれだけの割合の障害まで耐えられるかを図示したもの。なお、FabricおよびCordaは代表的なコンセンサスゕルゴリズムを挙げている(2017年1月時点)。

 ブロック生成時間と改竄耐性
ビットコ゗ン ゗ーサリゕム
約10分約12秒（フォーク頻度の上昇等）

Fabric v0.6

Fabric v1.0

Corda v0.5

任意任意ブロックという形は採らない
13

３－３．共有範囲
 台帳およびスマートコントラクトの共有範囲 (注)ビットコ゗ン ゗ーサリゕム

Fabric v0.6

Fabric v1.0

参加者全員での共有（GlobalSharing/Global Execution）

台帳

Corda v0.5

関係者に限定した共有（Local Sharing/LocalExecution）

ノード
(参加者)

ノード
(参加者)

ノード
(参加者)

ノード
(参加者)

ｽﾏｰﾄ
ｺﾝﾄﾗｸﾄｽﾏｰﾄ
ｺﾝﾄﾗｸﾄｽﾏｰﾄ
ｺﾝﾄﾗｸﾄｽﾏｰﾄ
ｺﾝﾄﾗｸﾄ

台帳

台帳

台帳

スーパーノード

台帳ノード
(参加者)

ノード
(参加者)

ｽﾏｰﾄ
ｺﾝﾄﾗｸﾄｽﾏｰﾄ
ｺﾝﾄﾗｸﾄ
台帳
台帳

ノード
(参加者)

ノード
(参加者)

ｽﾏｰﾄ
ｺﾝﾄﾗｸﾄｽﾏｰﾄ
ｺﾝﾄﾗｸﾄ
台帳（注）Fabric v1.0とCorda v0.5の差異については、本資料では割愛している。 14

３－４．許可型DLTにおける最近の流れ
ﾋﾞｯﾄｺｲﾝを他分野へ適用する際の主な論点

許可型DLTにおける最近の流れ① ビザンチン障害の考慮

簡素化② 結果整合性の採用

強い一貫性③ ブロックサ゗ズ/生成時間の制約

制約の撤廃④ 送信順序と処理順序の相違

相違の発生抑制⑤ 機能拡充の制約

制約の撤廃⑥ ストック情報の未検証

ストック情報の検証追加⑦ プラ゗バシーの割り切り

Local Sharing（関係者に限定したデータ共有）

スマートコントラクト対応に伴う主な論点

許可型DLTにおける最近の流れ⑧ 非決定性・非停止性の処理の制限

当該処理の禁止（事前ないし事後の確認）⑨ 処理ノードの冗長性

Local Execution（関係者に限定したｽﾏｰﾄｺﾝﾄﾗｸﾄ実行）⑩ 直列処理の制約

ある程度の並列化⑪ ラ゗ブラリの未成熟

枯れた技術の採用

許可型ネットワークに伴う主な論点

許可型DLTにおける最近の流れ⑫ 単一障害点

ある程度の許容⑬ 改竄耐性の劣化

改竄の阻止から改竄の検知へ

Local Sharing/Local Executionに伴う主な論点

許可型DLTにおける最近の流れ⑭ 可用性担保の必要性

ある程度の許容⑮ ネッテゖング処理の制約

ある程度の許容（注） 効率性に関わる面を中心に、 ビットコ゗ン・゗ーサリゕム・Fabric・Cordaの状況から取り纏めたもの(2017年1月時点)。 15

３－５．許可型DLTの方向性 金融゗ンフラへの活用に向けて、許可型DLTは以下の方向で検討が進む模様。
ﾋﾞｯﾄｺｲﾝで挙げられる主な特徴

許可型DLTの方向性と新たな論点の例

仲介者の排除信頼できる仲介者の導入（単一障害点における可用性等担保の必要性）

不特定多数による協働、ビザンチン障害耐性

信頼できる参加者間での協働で対処（多重投票の発生を検知する仕組みの必要性）

改竄困難

改竄検知で代替（改竄を検知する仕組みの必要性）

実質ゼロダウンタ゗ム、参加者全員での台帳共有関係者に限定したデータ共有・スマートコントラクト
実行で代替（各ノードにおける可用性等担保の必要性）

 信頼のおける仲介者の下、相当程度信頼のおける参加者間での、資産や取引毎に関係者を限定したデータ共有・スマートコントラクト実行（Local Sharing／LocalExecution）
 今後の取組みでは、効率性・安全性含むトータルでの費用対効果の検証が進むのではないかと考えられる。
16

（参考）ビザンチン障害
 任意障害とも言われ、P2Pネットワーク上で発生し得るあらゆる障害を指す。
 ビザンチン障害耐性が重要とされるユースケースは、ビットコ゗ン以外では、金融以外のミッションクリテゖカルな分野（Honeywell SAFEbus、NASA Spider等）
が知られる。

ビザンチン障害
欠落障害

欠落障害以外の障害

クラッシュ障害
タ゗ミン
グ障害

応答障害

（注）Clement, A. et al. (2009) “UpRight Cluster Services”, Proceedings of the ACM SIGOPS 22nd
Symposium on Operating Systems Principlesより作成。 17

（参考）ビットコインとイーサリアムにおけるマイナーの分布＜ビットコ゗ン＞（注） ビットコ゗ンはblockchain.infoより転記。
゗ーサリゕムはetherchain.orgより転記。
（2017年2月21日時点）＜゗ーサリゕム＞

18

３－６．金融インフラ分野における許可型DLTの活用可能性 － まとめ• 実用化が見込まれる多くのユースケースでは、ビザンチン障害耐性の代わりに、（従来システムと同じく）参加者間の信頼で担保する方向と見られる。
• 一方で、その普及にあたっては、従来システムと比べて具体的で分かりやすいメリットを、ユースケースに結び付けていく必要があると考えられる。

金融インフラ分野における許可型DLTのメリットとは何か？

19

参考資料

20

基礎実験の環境
 実験基盤: スタンドゕロン端末上の仮想環境
 検証ノード数: 1（認証局）＋ 4～16（検証ノード）
 コンセンサスゕルゴリズム: PBFT (Practical Byzantine Fault Tolerance)

スタンドゕロン端末 (Windows, 64bit, メモリ8GB)
仮想環境（Linux, 64bit, メモリ5GB）
チェーンコードクラ゗ゕントREST API・コンセンサス・チェーンコード制御
・ブロックチェーン、KVSへの書き込み等

検証ノード(VP)
検証ノード(VP)
A
検証ノード(VP)
検証ノード(VP)
B
C

認証局（CA）

D

・参加者認証・トランザクション認証（電子署名付与）・トランザクション暗号化
等

21

Hyperledger Fabric v0.6.1 での処理の流れ
クラ゗ゕントX（振替依頼人）検証ノードA

検証ノードB

検証ノードC

検証ノードD①振替依頼に電子署名を付して送信振替依頼
送信振替依頼受付③振替依頼を他の検証ノードに一斉配信②受付済通知を送信
振替依頼
受付④リーダーノードを中心に、電子署名の正当性やトランザクションの通し番号等を確認し合う。
⑤約2/3からの確認が得られた後で、スマートコントラクト（振替処理）を実行する。
⑥各検証ノードは、KVSに振替実行後の残高を、新たなブロック に当該振替依頼やブロック生成時刻等を書き込む。

振替依頼
受付

振替依頼
受付

④ コンセンサス⑤ 振替実行KVS

ブロックチェーン

⑥

振替実行

KVS

ブロックチェーン

振替実行

KVS

ブロック
チェーン

振替実行

KVS

ブロックチェーン

22

処理内容の制限、処理ノードの冗長性、直列処理の制約 必ず同じ結果になることが保証されている処理を、全てのノードが、直列に処理する必要。

＜集中管理型システム＞

tx1

tx2

中央サーバ

tx3

＜゗ーサリゕムおよびFabric v0.6＞
tx3
tx2
tx1

ノード1

ノード2

ノード3

ノード4

23

中央銀行の役割「触媒」としての役割「運営者」としての役割「オーバーシーゕー」としての役割

決済システム・金融インフラ

安全性の確保・向上

効率性の向上24