BLOCKCHAIN EXE#3

1. 2017年7月
KDDI総合研究所
清本 晋作
ブロックチェーンの研究動向
－セキュリティとプライバシー

2. ブロックチェーン＝非中央集権型のタイムスタンププロトコル
ブロックチェーンとは？
1© KDDI R&D Laboratories Inc,
CONFIDENTIAL PROPRIETARY
2017/8/1
デジタル情報が一旦ブ
ロックチェーンに組み込ま
れると後で順番を入れ替
えたり、内容を変更するこ
とが困難
ある時刻にあるデジタル情報が存在したこと
を第３者に保証することが可能
“2) Fe.h+R” “kO4-?S1*”
ブロックチェーン処理の不
正を防止するため一定間
隔でハッシュ値を公開し、
共有する ハッシュ値を
公開
非中央集権型＝第三者機関が不要。集団
的相互監視により安全性を確保
プロトコル参加のインセンティブを与える

3. 取引履歴のブロックチェーンへの組み込み
2© KDDI Research Inc,
2017/8/1
取引履歴をブロックチェーンの中に組み込むことにより、ビットコ
インによる取引が成立。
 新たなトランザクション（取引）が発生する毎に最後のブロックにトランザク
ションを追加する。
 電子署名の付与によりブロックの改竄を防止
直前の
ハッシュ値
Nonce
ルート
ハッシュ値
Tx0 Tx1 Txi・・・ ・・・
ブロックヘッダ
直前の
ハッシュ値
Nonce
ルート
ハッシュ値
ブロックヘッダ
直前の
ハッシュ値
Nonce
ルート
ハッシュ値
ブロックヘッダ
Txn Txn+1
取引履歴（台帳） 新規取引
ブロックチェーンへの
組み込み
2
電子
署名
電子
署名
電子
署名

4. ルートハッシュの処理
3© KDDI Research Inc,
2017/8/1
ルートハッシュは、効率的な計算が可能な二分木のハッシュツ
リー（Markle Hash Tree)を採用
直前のハッシュ値 Nonce
ルートハッシュ値
ブロックヘッダ
Tx0 Tx1 Tx2 Tx3
Hash0 Hash1 Hash2 Hash3
Hash01 Hash23
Tx0 Tx1 Tx2 Tx3
Hash0 Hash1 Hash2 Hash3
Hash01 Hash23
Tx4
Hash4
Hash44
Hash4444Hash1234
直前のハッシュ値 Nonce
ルートハッシュ値
ブロックヘッダ
取引Tx4の追加
3

5. ハッシュ関数を使ったマイニング
4© KDDI Research Inc,
2017/8/1
x=“直前のハッシュ値,
ルートハッシュ値,
Nonce”
“0000014a8bd…”
一方向性ハッシュ関数
H(x)
• Bitcoinでは、ある条件のハッシュ値を満足するブロックヘッダの
Nonceを求める「Proof-of-Work」と呼ばれる問題を使う
• ハッシュ値の先頭に０が指定された数続くような、元の値“ｘ”を求めるクイ
ズ
• ハッシュ関数は逆関数を求めることが困難であり、トライアンドエラーでxを
求める必要がある。
• 直前のハッシュ値とルートハッシュ値は既知であるので実際はNonceの値を
求める問題
“00000ad3b2f…” Nonce
ルートハッシュ値
ブロックヘッダ
Nonce
ルートハッシュ値
ブロックヘッダ
“0000014a8bd…”

6. マイニングが偽造防止となる仕組み
5© KDDI Research Inc,
2017/8/1
 P2P環境において、正規の参加者が、攻撃者及びその結託者よりも十分多
数であるという（現実的な）想定の上では、計算能力の差から、偽造され
たブロックチェーンは存続させることができない
マイニング マイニング マイニング マイニング
マイニング マイニング
マイニング
マイニング
偽造されたブロックチェーン
正規のブロックチェーン
【ブロックチェーンの正当性判定ルール】
ブロックチェーンが枝分かれする場合には、最長のブロック数を有するチェーンが正しいと
解釈する。
5
多くの参加者がい
るためチェーンの
伸びが早い
不正者は少数であ
るため計算に時間
がかかる

7. スケーラビリティの確保
複数のサブグループに分け、それぞれがコンセンサスを実行し、
それを結合させることで並列化
ランダムサンプリングによる効率化
並列化・冗長化
木構造を使ったチェーンの構成
DAG(グラフ構造）を使ったチェーンの構成
効率化に向けた検討
6© KDDI Research Inc,
2017/8/1

8. ブロック追加には一定の手続き(コンセンサス）が必要
 Bitcoinでは、手続き（暗号問題の解読等）に成功したノードだけがブロック
追加を宣言し、報酬（コイン等）を得ることができる。
• コイン＝金を掘り当てることに例え、「マイニング（採掘）」と表現。
• マイニングには「膨大な計算機リソースが必要」「承認に時間がかかる」
等の欠点もあるため、様々な改良手法が検討されている。
• マイニングとして、他の演算（より有益な演算）を用いようとする研究も
多い。
 クローズ型ではPBFT等を用いる。
取引履歴の改ざん対策
7© KDDI Research Inc,
2017/8/1
公開
/非公開
合意形成の例 平均承認速度 ブロック承認者
ノードの
信頼性確保
具体例
オープン型
（Permissio
n-Less)
公開
(Public)
Proof of Work
Proof of Stake
遅い 誰でも参加可能 不要 Bitcoin
クローズ型
（Permissio
ned）
公開
(Public)
PBFT やや速い
信頼できる投票
者のみ
必要 Hyperledger
非公開
(Private)
PBFT 速い
信頼できる投票
者のみ
必要 独自システム
K Wust and A. Gervais “Do you need a Blockchain?”, IACR ePrint 2017/375.

9. ブロックチェーンが適するケース
複数のステークホルダーが存在し、相互にやり取りが
存在する
第三者に対しての証明が必要
イベントの時系列が重要な意味を持つ
ブロックチェーン選択のポイント
8© KDDI Research Inc,
2017/8/1

10. ブロックチェーンの構成について、以下の選択肢が存在
 パブリックか、プライベートか？
 Permissioned(特定のエンティティのみ） or Permission-less（不特定多数）
ブロックチェーンの選択
9© KDDI Research Inc,
2017/8/1
K Wust and A. Gervais “Do you need a Blockchain?”, IACR ePrint 2017/375.
yes
yes Public
Permissioned
Blockchain
Private
Permissioned
Blockchain
Permissionless
Blockchain
Don’t use
Blockchain
状態を保持す
る必要がある
か？
書き換えを行
う担当者は複
数か?
常にオンライ
ンのTTPをつ
かうことがで
きるか？
書き換えを行
う担当者が全
て決まってい
るか？
書き換えを行
う担当者が全
て信頼できる
か？
第三者が検証
することが必
要か？
yes yes no no
yesno no
no
yes no

11. 3つのトレンドがある
安全性評価・攻撃
コンセンサスアルゴリズムの改良（ブロック
チェーンの高速化および安全性証明）
プライバシ保護
ブロックチェーン研究のトレンド
10© KDDI Research Inc,
2017/8/1

12. 暗号プリミティブの安全性評価
 ハッシュ関数への攻撃（SHA-256など)
 署名アルゴリズムへの攻撃（secp256k1楕円曲線など）
暗号アルゴリズムの解析状況は、Watchしておく必要がある
マイニング/ブロックチェーンスキームの安全性評価
 Refund Attacks on Blockchain [McCorry et al. 2016]
 Eclipse Attack [Heilman et al. 2015]
 Stubborn Mining [Nayak et al. 2015]
 Double Spending Attack [Karame and Androulaki, 2012]
ブロックチェーンの安全性評価
11© KDDI Research Inc,
2017/8/1

13. オープン型ブロックチェーンにおいてコンセンサスが満たすべき
セキュリティ要件
コンセンサスのセキュリティ要件
12© KDDI Research Inc,
2017/8/1
不正者が意図的にブロックを追加できない
ブロックの署名者がランダムに（フェアに）選択される
かつ
第三者が署名者選択の過程を検証可能
上記を考慮して、マイニングよりも高速な手法を考案

14.  Prof. Micali（2012年のチューリング賞受賞者）他のMIT研究チームが考案1)
 40秒間に2M個のブロック処理が可能2)
 前のブロック（の要素）のハッシュ値から、次のブロックの署名者を決定
事例１）Algorand
13© KDDI Research Inc,
2017/8/1
1) https://arxiv.org/pdf/1607.01341.pdf
2) https://eprint.iacr.org/2017/454.pdf
B(t-1)
Q
Root
Hash
B(t-2)の
Hash
前のブロックの値をもとに
次のブロックB(t)の署名者
を選択する
ハッシュ
関数
出力されたハッシュ値と
条件が一致するエンティ
ティを署名者とする
前のブロックの
値は操作不可能
であるため、
ハッシュ関数の
出力は乱数と見
なせる
特定のエンティ
ティを意図的に
選ぶことはでき
ない

15.  エジンバラ大学、オーフス大学らのチームが考案
 公開されたランダムビーコンで署名者を決定
事例２）Ouroboros
14© KDDI Research Inc,
2017/8/1
署名者
A
署名者
B
署名者
C
署名者
D
署名者
E
署名者
B
署名者
A
署名者
D
署名者
F
時
間
の
流
れ
予め当時
間間隔で
署名者を
割り当て
ビーコンは
ランダムに
点滅
署名者
B
署名者
E
署名者
A
ビーコンのタイミングで該当する
署名者がブロック生成

16. コンセンサス構築には信頼できる機関のみが参加
Practical Byzantine Fault Tolelance（PBFT)
ネットワークを経由した分散型プロトコル
多数決によって信頼度を確保
処理効率（平均、ワーストケース）を改善したいくつかの改良
方式が存在
• Tendermint
• Stellar Consensus Protocol
• HoneyBadger-BFT
• Etc...
クローズ型のコンセンサス
15© KDDI Research Inc,
2017/8/1

17.  C. Cachin and M. Vukolic “Blockchain Consensus Protocols in the Wild”から抜粋
コンセンサスプロトコルの比較
16© KDDI Research Inc,
2017/8/1
方式 故障耐性 不正ノード耐性
Kafka (Hyperledger Fab.) n/2 -
PBFT
(Hyperledger Fab.)
n/3 n/3
Tendermint n/3 n/3
Symbiont-BFT-SMaRt n/3 n/3
R3 Corda - Raft n/2 -
R3 Corda – BFT-SMaRt n/3 n/3
Iroha -Sumeragi n/3 n/3
Chain – Federated Consensus n/3 n/3
Quorum – QuorumChain n/3 n/3
Quorum - Raft n/2 -

18. プライバシへの配慮
17© KDDI Research Inc,
2017/8/1
ブロックチェーンに閉じる台帳は
第三者が検証可能である
台帳に記載される情報は開示される（こと
がある）
プライバシ問題が顕在化

19. プライバシに配慮した設計のポイント
台帳に記載するデータは開示しても良いのか？
• 開示範囲の確認（リスク分析）
• ハッシュで置き換え可能か？
台帳情報が蓄積されることによりプライバシリスクが
上昇する懸念はないか？
• データの蓄積により個人が特定される可能性は？
データ所有者の同意は必要ないのか？
• そのデータは誰のものか？
各国法制度への対応
• GDPRとか
Privacy By Design on Blockchain
18© KDDI Research Inc,
2017/8/1

20. 階層化したハッシュ木による開示制御
プライバシ要件に合わせて木を適切に設計
いわゆる墨塗り問題
ノード分割による開示制御
台帳情報を安全に分散管理
• 暗号学的手法の活用（ORAM等）
階層化して台帳を管理。ハッシュ値だけを他のノードに送る
プライバシに配慮した設計例
19© KDDI Research Inc,
2017/8/1
Tx0 Tx1 Tx2 Tx3
Hash0 Hash1 Hash2 Hash3
Hash01 Hash23
Tx0を検証するのにTx1, Tx2, Tx3を開示する
必要はない（Hash1, Hash23で良い）
PPMという中間ノードを置いて台帳情報を管理

21. Coinswap
複数人でコインの入れ替え
（代理支払い）を行うことで、
トランザクションを匿名化
Coinjoin
複数のトランザクションをま
とめることで匿名化
Bitcoinトランザクションの匿名化
20© KDDI Research Inc,
2017/8/1