データベース屋がHyperledger Fabricを検証してみた

データベース屋が
Hyperledger Fabricを検証してみた
Hyperledger Meetup
NECクラウドプラットフォーム事業部並木悠太
2017年3月16日

目次
今日の発表の目的
データベースの視点から見るブロックチェーン
ブロックチェーンに対する学術的な取り組み
まとめ

4 © NEC Corporation 2017
自己紹介
▌並木悠太
y-namiki@ak.jp.nec.com
▌NECクラウドプラットフォーム事業部
▌入社以来、データベース関連製品の設計開発に従事
インメモリ列指向データベースの開発
スケーラブルなSQLデータベースの開発
• SQLパーサー、プランナー、エグゼキュータ、...
ブロックチェーンに関する技術支援

今日の発表の目的
▌データベースを見る視点からHyperledger Fabricを紹介し、（主にデー
タベースの経験のある方の）理解の一助になること
▌ブロックチェーンに対する研究を紹介し、ブロックチェーンの課題の一例
とその解決への方向性を知っていただくこと
▌おことわり
ブロックチェーンにはデータベース以外の側面もあり、本稿はブロックチェーンを無理に
データベースと解釈して理解することをお勧めするものではありません
本稿では「ブロックチェーン」として特に記載がない限りHyperledger Fabric v0.6を代
表例としています
本稿では「データベース」として問合せ言語としてSQLを持つリレーショナルな分散デー
タベースを指します

データベースの視点から見るブロックチェーン

（先に）まとめ
▌ブロックチェーンの設計思想（データベースとの差異）
中央集権的な役割の排除
悪意ある参加者の存在（ビザンチン障害）を考慮
• データベースでは応答を停止するような障害（クラッシュ障害）の考慮に留まる
▌ブロックチェーンはデータベースを置き換えるものではなく、信頼を前提
せず分散システムを運用するための基盤

システム構成
▌やや強引だがブロックチェーンとデータベースの共通要素をまとめてみる
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
インタフェース
（アプリケーション）
復旧

システム構成の説明
▌（図の下側から）
▌ネットワーク
 システムを構成するノードでメッセージのやり取りをする
▌データ構造
 データを特定の形式で保存する
▌同時実行制御
 複数の処理を「正しく」並列して実行する
▌合意形成
 システムとして単一の見解を導出する
▌復旧
 システムに障害が発生したときに正常な状態に復旧する
▌セキュリティ
 不正な使用からの保護
 プライバシーの保護
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
復旧

システム構成の比較
▌各構成要素の実現技術（いずれも代表例）
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
復旧
ブロックチェーンデータベース
（ストアドプロシージャ）
SQL
2PC、Paxos、Raft
2PL、MVCC
リレーショナルモデル
クライアントサーバ
暗号化
（スマートコントラクト）
REST
PBFT
...?
ブロックチェーン
P2P
電子署名

ネットワーク
▌データベース：クライアントサーバ
▌ブロックチェーン：P2P
▌ブロックチェーンでは権限の集中してしまうサーバを
排除するためにP2Pを構成する
▌分散データベースが処理、データをシステム中のノードに分散させて処理
するのに対し、ブロックチェーンは基本的に分散させないため（レプリカ
）、各ノードがシステム全体分のリソースを持つ必要がある
▌構成の柔軟性（ノードの追加などの可否）は合意形成アルゴリズムの選択
にも依存する
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
復旧

データ構造
▌データベース：リレーショナル
▌ブロックチェーン：ブロックチェーン
▌改竄を困難にするため、「ブロック」と呼ばれる単位
でハッシュ値を計算し、それを次のブロックに保存する
（ハッシュ値でリンクされたブロックのリストを構成）
▌汎用ブロックチェーンではアプリ開発者の視点からのデータの保存先はブロ
ックチェーンそのものではなく、ワールドステート（Fabric用語）
 ワールドステートはキー・バリュー・ストア（表形式に見せるラッパーもあり）
 Fabricはワールドステートのハッシュ値をブロックチェーンに書き込む
▌ブロックチェーンは「履歴」の管理に適したデータ構造で、データベースの
ように複雑なモデルの大容量のデータの投入には不適
 複雑で大きなデータそのものは外部に置き、そのデータの権利の移転情報などブロックチェーン
の特性が生きる部分だけをブロックチェーンで管理するのがよさそう
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
復旧

同時実行制御
▌データベース：2PL、MVCCなど
▌ブロックチェーン：...?
▌いかに多数のトランザクションを並行して実行させて
システムのスループットを向上させるかについては
長い間研究が行われてきている
▌ブロックチェーンではまだこれから?
Fabricではトランザクションは順次実行
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
復旧

合意形成
▌分散システムにおいて複数のノード間であることに
ついて合意を形成すること
▌障害の分類
 クラッシュ障害
• 応答が停止するような障害（プロセス停止、電源断など）
 ビザンチン障害
• より一般に「正しくない」動作をするような障害（メモリビット化けによる誤動作、悪意ある不正なメッセー
ジなど）
▌データベースとブロックチェーンで前提とする障害が異なる
 データベース：クラッシュ障害
• 2相コミット、Paxos
 ブロックチェーン：ビザンチン障害への耐性が求められる
• 次ページ参照
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
復旧

ブロックチェーンで用いられる合意形成アルゴリズムの比較
▌PoW（Proof of Work）
 パブリック型（ビットコインなど）で用いられる
▌BFT（Byzantine Fault Tolerance）
 コンソーシアム型、プライベート型で用いられる
▌ビザンチン障害への耐性が要求されるため、データベースで用いられるもの
に比べ処理が重い傾向がある
Vukolić M. (2016) The Quest for Scalable Blockchain Fabric: Proof-of-Work vs. BFT Replication. In: Camenisch J., Kesdoğan D. (eds) Open Problems in Network Security.
iNetSec 2015. Lecture Notes in Computer Science, vol 9591. Springer, Cham
PoW BFT
ノードの構成ノードを把握
する必要なし
参加ノードを把
握する必要あり
合意のファイナリティなしあり
スケーラビリティよい限定的
スループット限定的よい
応答時間長い短い
電力消費非常に悪いよい
PBFTのメッセージの流れ
f台の故障への耐性のために (3f + 1) 台必要

▌データベース
SQL、ODBC、JDBCなど規格あり
豊富な機能：集計、ストアドプロシージャ
▌ブロックチェーン
標準化された問合せ言語はなし
スマートコントラクトの記述にはDSLあるいはGoなどの一般的な言語を利用
• 無限ループや不適切なリソースへのアクセスから守るため、実行にコード量に応じたコストの支払い
を求めたり、機能の制限されたDSLの利用、コンテナによる実行環境の隔離などの対策を行っている
▌ブロックチェーンは自体はそもそも複雑なデータを格納するものではない
ので、機能豊富な問合せ言語は不要であるかも
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
復旧

セキュリティ
▌データベース
方向性：正当な権限をもつものだけがデータにアクセスできる
（機密性）の確保
手段：データのアクセス権の管理、格納したデータの暗号化、
通信路の暗号化
▌ブロックチェーン
方向性：データの正当性の保証（完全性）（+ 機密性）
手段：電子署名によるメッセージの検証、ビザンチン障害に体制のある合意形成アルゴリ
ズム
▌一口にセキュリティと言っても目指すところに差がある
分散データベースではノードは互いに信頼をしている
ブロックチェーンでも機密性への対応が進められている
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
復旧

復旧
▌データベース：どんな瞬間にシステム全体あるいは
あるノードが停止しようとも一貫性のある状態に
復旧できることが期待される
▌ブロックチェーン：...?
▌ブロックチェーンでは十分な考慮がされていないという印象
今後に期待
ネットワーク
データ構造
セキュリティ
同時実行制御
合意形成
復旧

構成要素以外の観点から

性能
▌性能は測定方法により大きく変化するため、感覚的な表現で
スループット
応答時間
min
μs
ms
s
10 100 1000 (tps)
RDB
PFBT
PoW
ブロックチェーン
「高性能」

スケーラビリティ
▌データ量の観点で
データベース：シャーディングなどで対応
ブロックチェーン：なし（各ノードはすべて同じデータ（コピー）を持っている）
▌ノード数を増やしてもノードあたりのデータ量は減らない
ブロックチェーンデータベース
A-K
L-P Q-Z
A-Z
A-Z A-Z
3 2
1
1
2
3

スケーラビリティ
▌ノード数の観点で
データベース
• RDB：数ノード
• いわゆるNoSQL：数百～数千ノード
ブロックチェーン
• 合意形成アルゴリズムに依存
• PBFT：数ノード
• PoW：数千ノード
1 10 100 1000
RDB
PFBT PoW
NoSQL
ノード数

運用
▌監視
▌バックアップ
ブロックチェーンでは今後に期待

ここまでのまとめ
▌ ブロックチェーンの設計方針（データベースとの差異）
 中央集権的な役割の排除
 悪意ある参加者の存在（ビザンチン障害）を考慮
• データベースでは応答を停止するような障害（クラッシュ障害）の考慮に留まる
▌ これらを実現するため、電子署名、ビザンチン障害に対応した合意形成などの技術を導入
▌ ブロックチェーンはデータベースを置き換えるものではなく、信頼を前提とせず分散システムを運用する
ための基盤
 データベースの方が特性上優位であること
• 大量あるいは複雑なモデルのデータの保存
• 多種多様な問合せのサポート
• 性能（ブロックチェーンの特性を無視して単に読み書きする点において）
• データ・処理を複数のノードで分割
▌ 適材適所で活用していくことが重要
▌ 発展途上
 次に学術の面から進化の取り組みを紹介

学術的な取り組み
▌データベース界よりもセキュリティ界での取り組みが盛ん
▌最近の学会での発表内容
攻撃手法の発見 [1]
Bitcoinにおけるトランザクションやブロックの伝搬を大きく遅延させる攻撃を提案し、二
重支払攻撃やDoS攻撃が可能になることを示した
安全性の評価手法の提案 [2]
Proof of Workベースのブロックチェーンについて、セキュリティとパフォーマンスを定
量評価可能なフレームワークを提案
活用方法の提案 [3]
ブロックチェーンを活用した乱数発生メカニズムにより、オンラインゲームで用いられて
いる乱数が公正に発生されたものであることをユーザーによって検証可能にした
[1] A. Gervais, H. Ritzdorf, G. Karame and S. Capkun, “Tampering with the Delivery of Blocks and Transactions in
Bitcoin,” in ACM CCS, 2015
[2] A. Gervais, G. Karame, K. Wust, V. Glykantzis, H. Ritzdorf and S. Capkun, “On the Security and Performance of
Proof of Work Blockchains,”, in ACM CCS, 2016
[3] 佐古和恵 and 井口圭一, “ブロックチェーンを用いたオンラインゲーム向け検証可能乱数発生,” in SCIS, 2017

研究の紹介（1）
▌Intel SGXを利用した合意形成の高速化
PBFT（Practical Byzantine Fault Tolerance）は3相から構成され、メッセージのマルチ
キャストが多用される
Intel Software Guard Extensions（SGX、第6世代Intel Coreプロセッサが提供する命令
セット）が提供する「安全な領域」を活用することで、(1) フェーズの削減、(2) 同じ台
数の障害に対応するための必要ノード数の削減が可能になる
PBFTのメッセージの流れ
f台の故障に対し (3f + 1) 台必要
提案手法のメッセージの流れ
Pre-Prepareフェーズを削減し、
また、必要な台数を (2f + 1) 台に削減

研究の紹介（2）
▌Intel SGXを利用した合意形成の高速化
メッセージの削減によりスループットが向上（オリジナルと比較して約3倍）
より多くの故障に対応しようとするとスループットは低下する
提案手法により、必要なスループットの範囲でより多くの障害に対応することができる
0
100
200
300
400
1 2 3
Throughput (tps)
Hyperledger Fabric Proposed
3x

まとめ
▌データベースを見る視点からブロックチェーンを紹介
設計思想に差
データベースを置き換えるものではない
適材適所で利用を検討する
実装はまだ発展途上の段階
▌ブロックチェーンの進化に向けた学術的な取り組みを紹介
▌ブロックチェーンの今後の発展に期待

データベース屋がHyperledger Fabricを検証してみた

データベース屋がHyperledger Fabricを検証してみた

More Related Content

What's hot

Viewers also liked

Similar to データベース屋がHyperledger Fabricを検証してみた

More from LFDT Tokyo Meetup

データベース屋がHyperledger Fabricを検証してみた