ブロックチェーン導入における課題とその対応について

2016年8月23日
株式会社NTTデータ 赤羽喜治

Copyright © 2016 NTT DATA Corporation

Agenda１．直近のブロックチェーン界隈のトピック
・Ethereumハードフォーク問題
・ビットコイン半減期問題
・Vault OSローンチ

２．当社の取組と実装事例
・貿易金融
・分散板寄せ３．導入にあたって考慮すべき安全面の課題
・ブロックチェーンを構成する技術
・各レイヤーごとの課題

４．実システムへの導入に向けて

Copyright © 2016 NTT DATA Corporation2

１．直近のブロックチェーン界隈のトピック

Copyright © 2016 NTT DATA Corporation3

1.１ Ethereumハードフォーク問題
2016年6月

The DAO Attack問題発生（DAO・・・decentralized autonomous organization）

スマートコントラクトを使って作られた、資金集めプログラムの脆弱性をついて不正送金が繰り返され、約50億円もの詐取が行われかけた事件◆攻撃時動作◆正常時動作DAODAO（0x1234567…）（0x1234567…）

③引出依頼

③引出依頼

①Split要求②DAO生成④送金①Split要求②DAO生成④送金（総額約52億円）

子DAO

子DAO

（0x987654…）（0x987654…）

ユーザ（自分の出資分を引き揚げて、別の資金集めをしたい）

2016年7月③と④のループ

攻撃者

不正コード埋め込み

Ethereumコミュニティがどのような対応を取るか注目されていたが、結局ハードフォーク（ブロックチェーンを不正の行われる以前に巻戻し）となった。反対運動も発生。

Mt Gox事件と同じく、Ethereumという基盤ではなく、DAOというプログラムの脆弱性が原因。とはいえ・・・
本件で垣間見えたように、何らかの原因で正しくない情報がブロックチェーンに書き込まれてしまった場合の運用対処方法は重要な観点となる
Copyright © 2016 NTT DATA Corporation4

1.２ ビットコイン半減期問題
・2016年7月、ブロック生成の報酬が半額に(25BTC→12.5BTC)

マイナー業界への影響はBTC相場の高騰で限定的(※)
BTC対ドルレート

マイナー業者の収入※取引所「Bitfinex」へのハッキング・盗難事件により急落
Copyright © 2016 NTT DATA Corporation5

1.3 Vault OSローンチ
銀行基幹システムをブロックチェーンで置き換えることを目指すVault OS発表

Googleをスピンアウトした技術者により設立されたThoughtMachine社が開発。
LINUXベース、クラウド（AWS）上で提供（BaaS）。
ブロックチェーンを謳う傍らで「中央集権型・パーミッション型」とも言っていて詳細は不明。

Copyright © 2016 NTT DATA Corporation

6

２．当社の取組と実装事例

Copyright © 2016 NTT DATA Corporation

7

貿易金融分野へのブロックチェーン技術の利用
Ethereum※を用いて、貿易金融のＬ／Ｃ発行に係る業務の一部をプロトタイプ実装し検証いたしました。
本PoCでの検証対象となる機能は、以下の通りです。
①信用状発行依頼②信用状発行（開設依頼の受付）③信用状確認（開設取引の照会）
従来型システムの処理の流れ

海外

Ethereumのブロックチェーン技術を活用した処理の流れ

国内

海外(3) 与信枠確認(5) 確認オリックス銀行様
海外コルレス銀行(海外コルレス銀行)

静岡銀行様（信用状発行銀行）(4) L/C発行 ※(4) L/C発行

通知銀行
買取銀行

※ SWIFT/郵送

税関

船会社

通知銀行
買取銀行

(3) 与信枠確認③③(5) L/C確認(5) L/C確認

静岡銀行様（信用状発行銀行）(4) L/C発行

ブロックチェーン
でL/Cを共有②

税関(2) L/C発行依頼 ※(2) L/C発行依頼(6) L/C発行
到着通知

オリックス銀行様
海外コルレス銀行(海外コルレス銀行)

国内

船会社

ブロックチェーン
ネットワークL/C（Ethereum） contract※ 外為ネットバンキング

税関

税関(2) L/C発行依頼

オリックス
輸出者
銀行様（Shipper）
(7)確認
(7)
確認
(輸出者)

(1) 売買契約

オリックス様輸入者（Buyer）(輸入者)

オリックス輸出者
銀行様（Shipper）
(輸出者)

輸入者
オリックス様（Buyer）(輸入者)(1) 売買契約③①(5) L/C確認(5) L/C確認③※ 分散型アプリケーションの構築プラットフォーム
ブロックチェーンの支払いの仕組み以外に、独自の振る舞いを持つコントラクトをプログラマブルに定義可能となっており、様々な拡張が容易であることが特徴
Copyright © 2016 NTT DATA Corporation8検証内容・検証範囲・アプリケーション概要(2) 与信
枠確認

ｵﾘｯｸｽ銀行様（海外コルレス銀行）
通知銀行
買取銀行

(4) L／C確認

船会社
税関

ブロックチェーン
でL／Cの情報を共有(4) L／C確認(3) L／C発行

ブロックチェーンネットワーク（Ethereum）[凡例] ：

Copyright © 2016 NTT DATA Corporation(1) L／C発行依頼(4) L／C確認【システム構成】②User

Webブラウザ③Flow

IE
JavaScript
データ取得(JSON-RPC接続)

各種関係者

処理

(4) L／C確認【Contract構成】①ControllerContract
全てのContract処理の起点(呼び出しの窓口)②UserContract
ユーザ毎の権限設定を管理③FlowContract
全てのL／Cのアドレスを保有④MasterContract
画面に共通的に表示するコードや値を保持⑤DataContract(L／C)
L／Cの内容を保持

Contract

税関

各種
contract

ｵﾘｯｸｽ銀行様
（輸出者）

静岡銀行様
（信用状発行銀行）①
Controller

Ethereum node④
Master⑤Data(L／C)

ｵﾘｯｸｽ様（輸入者）

ブロックチェーンの各ブロックへ個別に格納された各種コントラクト（アプリケーションプログラム）が連携し、L／Cを生成し、フロー制御でステータスを更新する。
更新結果はブロックチェーンに格納、保持される。

9分散証券取引プラットフォーム検証範囲• 証券取引全体にブロックチェーン技術を適用
トレード

株式
発
行注
文

注文
受付

ポストトレード

価格の決定（約定）

権利移転ク
リアリング決済

今まで検証された範囲
今回検証した範囲
Copyright © 2016 NTT DATA Corporation10

分散証券取引におけるスマートコントラクト構成
注文コントラクト

銘柄コントラクト<変数>・銘柄名
・銘柄コード・所有者リスト・発行済株数・現在価格 など
<メソッド>
・投資家追加・権利移転
・保有株情報取得
・銘柄情報取得
・所有者リスト取得
・増資
・減資<メソッド>
・注文受付
・注文内容取得
・注文内容更新
・注文削除

投資家B

投資家A

投資家A

ブロックチェーン
ネットワーク銘柄Ａ

取引コントラクト

投資家C

投資家B

投資家C

<メソッド>
・価格決定（板寄せ）

注文

運営会社コントラクト
銘柄Ｂ

投資家コントラクト
投資家E

<変数>
・氏名
・住所
・残高
・買付余力
・所有銘柄リスト<メソッド>
・買い注文
・売り注文
・注文履歴取得・取引履歴取得
・所有銘柄情報取得
Copyright © 2016 NTT DATA Corporation

銘柄Ｃ

取引

運営会社X

投資家E
投資家D

投資家D

[凡例]

運営会社

：Ethereum node

<変数>・管理銘柄一覧
・残高<メソッド>
・板寄せ実行・クリアリング実行
・決済

これらのコントラクトが互いに連携し、自律的に価格を決定し、その結果より所有権の移転・決済を実行する。
11詳しくは日経FinTech5月号をご参照ください

Copyright © 2016 NTT DATA Corporation

12

３．導入にあたって考慮すべき安全面・運用面の課題

Copyright © 2016 NTT DATA Corporation13主要なブロックチェーンプラットフォーム実装
名称

開発元

Bitcoin Core

Bitcoin Core

Ethereum

Ethereum Foundation

スマートコントラクトを使用してコインの移転以外にも広く使える

Hyperledger
FabricHyperledger Project

PoWではなくBFTを使うのでブロックの生成が速い。認証の仕組みを標準で持つ

Corda

R3

参加者間ですべてのデータが共有されるわけではない

Chain OS 1

Chainmijin

テックビューロ

OrbOrb

ブロックチェーンのフォークによるトランザクションの手戻りリスクの低減

Eris

Eris Industries

Ethereumから派生し、許可型ネットワーク向けに改造したもの

Copyright © 2016 NTT DATA Corporation

特徴
オリジナルのビットコインクライアントの後継一貫性の維持にSimplified BFTを使う
Proof of Stakeを使用するが、高速な処理を指向

14

各ブロックチェーン実装の構成比較と課題
ブロックチェーンを構成する各技術のレイヤごとに技術の深堀と検証が必要
メンバーシップ管理など、従来システムと同様の安全対策が求められるレイヤーとブロックチェーンならではの観点が求められるレイヤーとがあり、特に後者についての蓄積が求められている。
拡張機能
メンバー管理・・・・

安全対策

スマートコントラクト
コンセンサスアルゴリズム

PoW

メンバー管理・認証

Membershipservices

Contract

chaincode

言語：Solidity、他

言語：Go、Java

PoS

Sieve
PBFT

PoW

PoW,Paxos,RAFT・・・

偽造防止・暗号化

Public-key crypto
Crypto Hash

Public-key crypto
Crypto Hash

Public-key crypto
Crypto Hash

P2Pネットワーク

Discovery
Management
Message FormatDiscovery
Management
Message Format

Discovery
Management
gRPC, Protocol Buffers

運用

監視

周辺機能
bitcoin
パブリック型
Copyright © 2016 NTT DATA Corporation

ethereum・・・・

補完していく領域

ブロックチェーン
特有

Hyperledger Fabric
コンソーシアム型
15

P2Pネットワーク

Copyright © 2016 NTT DATA Corporation

16

P2Pネットワークの分類と特徴（１）
主なP2Pネットワークの形態

ハイブリッドP2P・探索用のインデックス・サーバを持つ。

ピュアP2P・全ノードが同じ役割

スーパーノード型
・メンバシップ管理など特定のノードが管理機能を持つ○シンプルでシステムを管理しやすい×システムに中心を持つため、スケーラビリティや耐障害性が十分に発揮されにくい○スケーラビリティや耐障害性が高い
×実装が複雑、ノード数が増えた場合に、マシンリソース消費拡大の懸念○ハイブリッドP2PとピュアP2Pの長所を併せ持つ。
×スーパーノードがSPOFになりやすいため対策が必要

Copyright © 2016 NTT DATA Corporation

17安全面・運用面で考慮すべきこと
パフォーマンス・転送回数やネットワーク遅延等－ P2Pネットワーク上で動作するブロックチェーンは、クライアント・サーバ型のシステムと比較して遅延が懸念されるため、リアルタイム性を求められる領域での適用が難しいとされている
確実性・ブロードキャスト－ブロックチェーンネットワーク全体で同期が可能か－到達保証（受信確認）はどうするか・ノードやネットワークの信頼性－ブロックチェーンが有効に動作するために最低限必要なノード数や、これを下回った際の運用ルールの策定が必要－ノード障害を考慮したネットワーク設計

Copyright © 2016 NTT DATA Corporation18

偽造防止・暗号化

Copyright © 2016 NTT DATA Corporation19

ブロックチェーンにおける電子署名の利用
ブロックチェーンにおける偽造・改ざん防止は、既知の暗号化技術である電子署名とハッシュを組み合わせることで実現している。

電子署名による本人性保証

トランザクションにおける電子署名の利用
トランザクション

トランザクション

トランザクション

花子さんの公開
鍵次郎さんの公開
鍵三郎さんの公開
鍵

ハッシュ

ハッシュ

ハッシュ

検証

太郎さんの署名

花子さんの秘密鍵

検証

花子さんの署名

署名次郎さんの秘密
鍵次郎さんの署名

署名

三郎さんの秘密鍵

ブロックチェーンでは各トランザクションに1つずつ電子署名が付与される。
また、電子署名を検証するための公開鍵もセットで付与される。
ビットコインを例にとると、電子署名と公開鍵がセットで付与されることで、過去ビットコイン上で行われた全ての取引を順次検証することができる。
ビットコインの電子署名を検証することで、以下を確認することができる。
・第三者が取引内容を偽造・改ざんしていないこと
・第三者がなりすましを行って取引を行っていないこと
・コインの正しい所有者が確かに取引を行ったこと（そんな取引はしていないと否認することを防止）
Copyright © 2016 NTT DATA Corporation20

ブロックチェーンにおけるハッシュの利用
ブロックチェーンにおける偽造・改ざん防止は、既知の暗号化技術である電子署名とハッシュを組み合わせることで実現している。

ハッシュによる改竄防止

ブロック生成時におけるハッシュの利用
ブロックヘッダ１
前ブロックヘッダのハッシュ値

ブロックヘッダ２

ハッシュ前ブロックヘッダのハッシュ値

ナンス

ナンス

ハッシュ木のルート

ハッシュ木のルート

ハッシュ

前ブロックヘッダのハッシュ値

トランザクション１

トランザクション２

トランザクション２

トランザクション３

トランザクション３

：

：

小

ハッシュ

大

ハッシュ木のルート

ブロックヘッダ３
前ブロックヘッダのハッシュ値

ブロック生成ナンス
成功！
ハッシュ木のルート

ナンス
トランザクション１

難易度に指定された
閾値と比較

ナンスを変更トランザクション１
トランザクション２

トランザクション１

トランザクション３

照合

トランザクション２

ハッシュハッシュ木のルート：

トランザクション３

ブロックチェーンでは複数のトランザクションをまとめたブロックを作り、ブロックには前のブロックのハッシュを付与する。
また、ハッシュの計算に使用するナンスと呼ばれる値もセットで付与される。
ブロックに付与されるハッシュは、1つ前のブロックをハッシュ関数に入力することで生成される。
そのため、あるブロックの内容を偽造・改ざんすると、ハッシュ関数の特性により、その次のブロックに付与するハッシュが変わり、同様に、以降全てのブロックに付与するハッシュが変わる。
偽造・改ざんを成功させるためには、これら全てのハッシュを再計算しなければならず、偽造・改ざんを困難にする。

Copyright © 2016 NTT DATA Corporation21安全面・運用面で考慮すべきこと
秘匿情報をどのように扱うか・ブロックチェーンにおける暗号化技術の利用は、偽造・改ざんを防止するためのものであり、取り扱うデータそのものは暗号化されていない。
そのため、ブロックチェーンで機密情報や個人情報等を扱いたい場合に、どのように情報を秘匿化するか検討する必要がある。
暗号技術を利用したシステムにおける運用課題
・鍵管理－鍵ペアの有効期間の管理、新しい鍵への置き換え等
・暗号技術の危殆化－ハッシュ関数や電子署名は、時間の経過と共にその強度が弱くなる運命－量子コンピュータが登場すると電子署名の有効性が失われる（ブロックチェーンは長期的に運用される前提にも関わらず検討がされていない。
セキュリティ界隈では取り組みは始まっている（英Post Quantum等））
実装面での脆弱性
・“トランザクション展性“のような実装面で脆弱性が入り込んでいないかの検証※ビットコインで問題となった、トランザクションの一部が署名対象となっていなかったことに起因する脆弱性。デジタル署名が検証可能のままで取引データが改ざん可能だった。
MtGOX事件などでも取り上げられた。

Copyright © 2016 NTT DATA Corporation22

コンセンサスアルゴリズム

Copyright © 2016 NTT DATA Corporation23

コンセンサスアルゴリズムとは分散ネットワーク上で各ノードが合意形成をするためのアルゴリズム。
コンセンサスアルゴリズムの一つとしてPoWがある。
 PoW(Proof of Work)-Proof-of-Workアルゴリズムは、取引情報(Block)を時系列にチェインし、ひとつ前の取引情報のハッシュ値(タイムスタンプを含む)を元に、自取引のハッシュ値を生成/設定する仕組み。
-改ざん/複製する場合、一部だけの改ざんでは矛盾が発生する為、過去に遡ってハッシュ値を書き替える必要がある。
過去に遡ってハッシュ値を書き替える為には、膨大なコンピューターリソースが必要。
-BitcoinはコンセンサスアルゴリズムとしてPoWを用いている同時に作られたブロック

長い方を正当なブロックとする同時に作られたブロック

 PoS(Proof of Stake)、PoI（Proof of Importance)-Proof of Workへの代替案（マイニングによる消費電力がない等）-コインを持っている割合(Stake)や“重要性“でブロックの承認の割合を決める
Copyright © 2016 NTT DATA Corporation24

コンセンサスアルゴリズムとはBitcoinではPoWでコンセンサスを成立させていたが、ブロックチェーン的には他にも様々なコンセンサスアルゴリズムが提唱、実装されている。
-P2Pなアルゴリズムと異なり、Leaderが存在する-CandidateからLeaderを選び、 Leaderを中心にデータを送信しコミットしてから合意に達する

 Paxos-L. Lamportが提案-State MachineはProposers、Acceptors、Learnersのいづれかの役割を果たしコンセンサスの合意を目指す

 PBFT(Practical Byzantine Fault Tolerance)-M. Castro と B. Liskovが提案-Client、Validator、Execution、Agreementから構成

 Sieve-PBFTを拡張したアルゴリズム-Client、Validator、Replicaから構成

Copyright © 2016 NTT DATA Corporation

Hyperledger Fabricではこれらの実装が差し替え可能となることを目指す Raft25

アルゴリズムの例：PBFTの動作概要
1. クライアントが命令をすべてのサーバー（Replica ０～3）に送る。

“リーダー”による合意形成

2. primary は実行順序nをつけた上で命令を他のすべてのサーバーへ送付する。

3. 各サーバー は命令を受け取ったら、他のサーバー に受け取った合図を送る。
4. 各サーバーは 3 で他のサーバーが送付した PREPARE メッセージを受け取る。
ある一定数以上の他のサーバーからのPREPAREメッセージが集まったら、他のサーバーに受け取った合図を送付する。
5. 各サーバーは 4 で他のサーバーが送付したCOMMITメッセージを受け取る。
ある一定数以上の他のサーバーからの COMMIT メッセージが集まったら、そのサーバーのコミット命令として登録する。
実行順序n 未満のコミット命令がすべて実行されていれば、この n 番目の命令を実行する。
そうでなければ、n未満の数値の命令がコミットされるまで、この番号の命令に関しては実行を保留する。
実行結果をクライアントに送る（REPLYメッセージ）。
6. クライアントは各サーバーが送付したREPLYメッセージを受け取る。ある一定数以上のサーバーからのメッセージが集まったら、中身がすべて同じか確認する。同じ REPLYメッセージがある一定数以上あれば REPLY の値として これを実行結果とする①primary⑥②③④⑤=リーダー

Copyright © 2016 NTT DATA Corporation26

安全面・運用面で考慮すべきこと
コンセンサスアルゴリズム毎の属性（耐障害性・対攻撃性）把握
・Primaryノード障害発生時のリーダー交替プロセスの振る舞いや各ノードの異常動作時（リーダー、リーダー以外）の振る舞いについての検証が必要。
ex. ノード障害により、リーダーが交替し続け、コンセンサス形成に非常に時間がかかる事象等
分断耐性－分断時に複数のブロックチェーンに分岐が発生し、分断解消時に上書き等の問題が発生する
耐攻撃性－クエリー内容の改ざんやエクリプス攻撃等への対応

eclipse攻撃のイメージ
Copyright © 2016 NTT DATA Corporation27

スマートコントラクト

Copyright © 2016 NTT DATA Corporation28

スマートコントラクトの分類
スマートコントラクトの実行環境は、実装によって様々な形態がある
例１）Ethereum：EVMという「仮想マシン」上でプログラムを実行するEthereum
例２）ノードの実際のOS環境上でネイティブなプログラムを実行するHyperledger Fabric⇒ある程度の制約のかかるEthereumと一般のプログラムと同じ自由度のあるHyperledger Fabricネイティブ型

仮想マシン型(Ethereum)

コントラクトX（HyperledgerFabric）

実OS環境
CC

※CC:チェーンコード
WS:ワールドステート

プロパティ

ステート：B

Node1
EVM

Peer1

処理ステート変更(＊⇒＊)

WS
実OS環境

Node2
EVM

Node4
EVM

CC

Peer4

Peer2

実OS環境

WS

WS

CC

Peer3

Node3
EVM

WS

WS：プロパティ
ステートB

CC
実OS環境

Copyright © 2016 NTT DATA Corporation29

安全面で考慮すべきこと
コントラクト自体の脆弱性
・コントラクトコードのバグ・脆弱性をついて、不正な処理を実行されることが考えられる。
例）The DAO Attack事件
ブロックチェーン自体の脆弱性ではなくとも、コントラクトの脆弱性により誤った記録がブロックチェーンに書き込まれるという事象。攻撃ではなくともコントラクト自体のバグにより、同様の問題が発生するリスクがある（従来のシステムと同様のリスクが存在）
スマートコントラクトの実行環境・配布方式
・自由度の高さと安全性は基本的に二律背反。プログラムの安全性がどのように担保されているのか、実装ごとに確認が必要
・仮想マシンで実行環境を分離したり、機能やリソースを制限したりすることにより不具合や悪意のあるコードへのある程度の問題の緩和はできるが、開発生産性や実行効率に影響がある。
スマートコントラクトプログラムを一般的なプログラミング言語で書き、コンピュータ上で直接動作させるのは効率は良いが、不具合や悪意のあるコードへの考慮がより重要になる。

Copyright © 2016 NTT DATA Corporation30

安全面・運用面の課題

まとめ

安全面の課題・ブロックチェーンに関する安全性の定義が定まっておらず、その結果十分な安全性の検証がなされているとは言いがたい。
・ブロックチェーン基盤だけでなく、その上で実行されるプログラムの安全性を担保する手段についても十分な検証が必要。
運用面の課題・ブロックチェーンに誤った情報が書き込まれた際の対応については検討と検証が必要
・P2Pネットワークに分断が発生した際に運行を続行するか停止するかといったルール作りも必要となる・コンソーシアム型、パブリック型といった切り口でも運用の考え方は大きく変わる“ブロックチェーンは安全面の課題がある危ない技術”というメッセージではない。
過去に出現した様々な新規技術と同様に検証すべき項目が数多く残されているということ。
“原理的に大丈夫”という言葉の及ぶ範囲、実装とのGAPをしっかりと意識する必要がある。
ブロックチェーンはパーツの一つでしかない。
Copyright © 2016 NTT DATA Corporation

31

Copyright © 2011 NTT DATA Corporation

Copyright © 2016 NTT DATA Corporation