ブロックチェーンの可能性と課題 - SIerとしての視点から

© 2017 NTT DATA Corporation
ブロックチェーンの可能性と課題
- SIerとしての視点から -
2017年3月16日
株式会社NTTデータ
稲葉高洋、山下真一

2© 2017 NTT DATA Corporation
アジェンダ
1. ブロックチェーンシステム開発の10の論点
2. ブロックチェーンシステム運用の勘所

© 2017 NTT DATA Corporation 3
1. ブロックチェーンシステム開発の10の論点

1. ブロックチェーン製品の選定
2. クラウドかオンプレミスか
3. コストは安くなるか
4. 誰がノードを所有するのか
5. 環境の構築
6. 設計をいかに進めるか
7. データをどのように持つか
8. 製造・試験
9. セキュリティ
10.ネットワークの遅延
ブロックチェーンシステム開発の10の論点

• ブロックチェーン基盤はビジネスモデルに大きな影響を与えるので、ビ
ジネス要件に適切なものを選定する必要がある。
• 製品そのものではなく、開発コミュニティあるいは開発企業の規模、運
営方法、活動の活発さ、ライセンス形態、業界での認知度なども考慮す
る。
• 製品が有する機能はAP開発コストに影響する。
• 大まかな技術的観点と該当する製品には以下のようなものがある。
1. ブロックチェーン製品の選定
ビジネス要件対応する製品
パブリックネットワーク
/ 自律分散型
Bitcoin Core, Ethereum,
Sawtooth Lake
コンソーシアム指向
/ パーミッション型
Fabric, Enterprise
Ethereum?
BtoC Iroha
相対取引指向
/ 公証 (notary) 型
Corda

1. ブロックチェーン製品の機能
PoW
PoW
Contract
言語：Solidity、他
chaincode
言語：Go、Java
PBFT / SBFT
PoS
Membership
services
Bitcoin Ethereum Hyperledger Fabric
パブリック型コンソーシアム型
コンセンサスアルゴリズム
偽造防止・暗号化
スマートコントラクト
P2Pネットワーク
メンバー管理
拡張機能
メンバー管理・認証
周辺機能運用監視
・・・・
安全対策
Public-key crypto
Crypto Hash
Public-key crypto
Crypto Hash
Public-key crypto
Crypto Hash
Discovery
Management
Message Format
Discovery
Management
Message Format
Discovery
Management
gRPC, Protocol Buffers
・・・・
補完していく領域
ブロックチェーン特
有

1. ブロックチェーン製品の機能
パブリックコンソーシアムプライベート
ノード型制限なし制限可能制限可能
ブロックチェーン
閲覧
制限なし制限可能制限可能
ブロック生成時の高
難易度な仕組み
必須任意任意
マイニング報酬必要任意任意
ビットコインは
パブリック型
エンタープライズ利用は
コンソーシアム型が有力視

• 「ブロックチェーンはクラウドでないとダメなのか」ということはない。
• 一般的なシステムと同様、要件に合わせて選定する。
• 価格、納期
• インフラに要求される柔軟性の程度
• 他のシステムとの連携や組織でのインフラストラクチャポリシー
• セキュリティ
• データセンタの場所など
• ブロックチェーンならではがあるとすると、複数の主体による分散配置
した構成要素が強調動作するための広域ネットワークへの影響がある。
(後述)
• 素のサーバに1からブロックチェーン基盤を構築するか、ある程度構築さ
れたBaaS的なサービスを利用するか検討する。
• 今後はSaaS的なサービスが増えていくと思われる。その場合、あまりブ
ロックチェーンを意識しなくなるだろう。
2. クラウドかオンプレミスか

• 「ブロックチェーンを使えばコストが安くなるんでしょ」
• コストの観点でブロックチェーンが直接影響するのはシステムの一部に
過ぎないので、全体としてみればブロックチェーンによる影響は大きく
ないこともある。
• JPXのワーキングペーパー*1によると、ハードウェア、ソフトウェア (パッ
ケージ)、保守はコスト削減の可能性があるとしているが、アプリケーショ
ンについては差異なしと結論付けている。
• ガートナーの記事*2ではブロックチェーンにかかわる部分はシステム開発全
体の5%未満といわれている。
• ブロックチェーンあるいは分散台帳技術はまだまだ発展途上の技術なの
で、POCや各種コンソーシアム活動など成熟した技術と比べると、逆に
コストがかかる可能性がある。技術の進歩に追従するためのマイグレー
ションにも注意を払う必要がある。
• コスト以外の分散台帳のメリットに注目してプロジェクトを進めるべき
である。対改竄性や一貫した台帳情報の共有など。
3. コストは安くなるか
*1 JPXワーキング・ペーパー「金融市場インフラに対する分散型台帳技術の適用可能性について」
http://www.jpx.co.jp/corporate/research-study/working-paper/tvdivq0000008q5y-att/JPX_working_paper_No15.pdf
*2 Top 10 Mistakes in Enterprise Blockchain Projects
http://www.gartner.com/smarterwithgartner/top-10-mistakes-in-enterprise-blockchain-projects/

• 「参加者全員がノードを持つ必要があるのか」というとそうとは限らな
い。
• ノードを持つことの利益、あるいは持たないことによる不利益を考慮す
る。
• 利益
• 他社に先んじて競争力のあるサービスを提供する
• システムの安定的な稼動に寄与する
• システムの運用のコストを分担しつつ、相応の影響力を保持する
• 自分の好きな場所にデータを置ける
• 不利益
• システム上でのサービス提供に影響があるかもしれない
• システムの運用がノードを持つ主体の動向に左右される
• データの置き場所をコントロールできない
• システムによるメリットが大きい主体がノードを持ち、そうでもない主
体は共同で所有する、あるいはサービスだけ利用するということもでき
る。

A B
C D
A B
C
D
均等に所有
E
F G
部分的な組合
A
BC D
1主体が所有
A
組合が所有
B
C
D E
F G

• Fabricは以前はVagrantを使って構築するようになっていたが、これは結
構ハードルが高かった。
• Vagrantに馴染んだ人、馴染める人は必ずしも多くない。これを理由とした
問い合わせが多かった。できたものの提供も容易ではなかった。
• プロキシ環境対応がドキュメントに少し書いてあるが、絶望的に動かなかっ
た。
• Dockerイメージによる配布により、構築が劇的に簡単になった。ただし、
少し凝ったことをするにはDockerの知識が必要になる。
• 将来的にはオフラインインストーラやパッケージ管理システムを通じた
配布も行われるだろう。
• 評価やPOCの実施に当たってはインフラチームの協力や関与を推奨した
い。まだまだ導入や環境構築には専門的な知識が必要となる。
• CelloはFabricの環境の運用に有用と考えている。
• Hyperledger Blockchain Explorerは便利だが、もっとよくなる。
EthereumのEthereum Network Stats*1 (eth-netstats)はよくできてい
ると思う。
5. 環境の構築
*1 Ethereum Network Stats
https://github.com/cubedro/eth-netstats

Ethereum Network Stats (eth-netstats)
*1 Ethereum Network Stats
https://github.com/cubedro/eth-netstats

• 企画については既存の技術とかなり大きく異なるが、設計についてはそ
れほど大きな違いはないとの認識。
• RDMBSとNoSQLはそれぞれ違った知見が必要になるが、既存の技術でもそ
の程度の違いは普通にある。
• 大枠では既存の開発標準やノウハウを流用可能。
• 未成熟で変化の激しい技術とどう付き合うかが重要になるので、長大な
ウォーターフォールプロセスはリスクが高い。
• ブロックチェーンだけでシステムが完結するわけではないので、既存の
技術とどう組み合わせて責務を分担するかが重要。
• ブロックチェーンは単なるデータベースではないが、ユーザインタラク
ションを担わせるのには向かないので、フロントエンドを担う構成要素
が必要となる。
• 巨大なチェーンコードを開発することはできるが、適切なサイズでの分
割を考慮する必要がある。
• 分散環境でプログラム (チェーンコード/スマートコントラクト) を実行
するので、非決定論的挙動を作りこまないようにするのが重要。Fabric
1.0で改善される (はず) だが、根本的には解決できない。
6. 設計をいかに進めるか

• ブロックチェーンは単なるデータベースではない。
• しかし、データベースとしての一面も持つ。
• ブロックチェーンはファイルサーバやオブジェクトストレージではない。
少なくとも現状は。
• 大量のデータを格納する必要がある場合は、リンクやハッシュをブロック
チェーンに格納するというのは現時点では無理がない。
• Fabricのワールドステートは非常に単純なKey-Valueストアなので、複雑
な検索には向かない。
• 自前でインデックスのようなものを作る。
• テーブルの機能を使うと多少やりやすい。
• 1.0の機能強化に期待。
• 最初は個別の取引データだけを扱うのがやりやすいかもしれない。
7. データをどのように持つか
取引データの集積
集約データの格納
(残高/口座など)
“スマートコントラクト”

• Fabricではチェーンコードの開発にJavaが導入されて圧倒的に扱いやす
くなった。
• Javaの経験者は非常に多い。
• Eclipseなどの歴史あるIDEとそのプラグインが使えるのはとても便利。
• テスティングフレームワークやモックフレームワークもそろっている。
• shimに関係する部分のテストツールがあると便利だろう。
• Fabric Composerは現場にすんなり導入できるだろうか。
• EthereumのSolidityは言語仕様に制限が多く、開発ツールも貧弱で開発
が非常に困難。 (SolidityそのものというかEVMに由来する)
8. 製造・試験

• 「ブロックチェーンの何がセキュアなのか」
• 改竄耐性が特徴となる。暗号、ブロックチェーン/ハッシュチェーン、
P2Pネットワーク、コンセンサスアルゴリズムによって成立する。
• ブロックチェーンならばセキュリティの心配がないということはない。
一般的なセキュリティ対策は必要。
• EhtereumのThe DAO AttackやDoS攻撃など
9. セキュリティ
•アプリケーションレベルの認証
•アクセス制御 (Application ACLなど)
•コンテンツの秘匿化
•機能バグやセキュリティバグを作りこまない
アプリケーション
•信頼できる製品の採用
•パッチの適用
•適切な設定
•ユーザの棚卸し
•安全な暗号アルゴリズムやハードウェア機能の利用
ミドルウェア
•ホストセキュリティ
•ネットワークセキュリティ
•物理セキュリティ
インフラ

• 複数のpeerが複数回の通信を行って合意形成を行うので、ネットワーク
の遅延は性能に大きな影響を与える。
• 処理性能が重視される場合は、各peerをネットワーク的に近い場所に配
置する必要がある。
• ビジネス要件などによって遠隔地に分散配置する場合は、処理性能への
影響を評価する。
10. ネットワークの遅延
AWSリージョンレスポンスタイム (ms)
東京 28
シンガポール 174
カリフォルニア 240
オレゴン 291
シドニー 309
バージニア 370
アイルランド 573
サンパウロ 658
http://www.denet.ad.jp/technology/2014/01/vol9-aws.htmlから引用

10. ネットワークの遅延
delay proc time note
0 22 same machine
90 370 tokyo - singapore
120 496 tokyo - california
150 606 tokyo - oregon / sydney
175 716 tokyo - virginia
285 1,149 tokyo - ireland
300 1,227
330 1,332 tokyo - São Paulo
y = 3.9974x + 15.223
R² = 0.9998
0
500
1,000
1,500
0 50 100 150 200 250 300 350
proc time
• Hyperledger Fabric 0.6.1
• 4つのvalidating peerを1つのt2.mediumインスタンスに配置
• 空のJavaチェーンコード
• tcコマンドにより擬似的に遅延を発生
• sendBatchとexecDoneSyncの時間差を測定
• バッチサイズは1
• それぞれ1回のみ測定した

2. ブロックチェーンシステム運用の勘所

ブロックチェーンを利用していく上で
“良くあるこれまでの” システム基盤とは変わってくる
従来のシステムブロックチェーン
RDBMSや
ビッグデータ基盤
APサーバ XXサーバ
各種ソフトウェア
中央集権ではない
管理主体が1組織でなくても良い
一部を止めても大丈夫
中央集権・特定の組織で管理
(信頼性対策、HA、セキュリティ、監視など)
新たな
発想が必要

ブロックチェーンを利用していく上で
ブロックチェーンをどのように組み合わせるかも大切
サービス
チェーンB
チェーンA チェーンC
複数のブロックチェーンを
組み合わせたサービス
サービス
異なるブロックチェーン
技術を組み合わせた
サービス
技術A 技術B
サービス
ブロックチェーン技術と
外部システムとの連携

ブロックチェーンを利用していく上での課題
例えば、問題が発生した際の対応は…
RDBMSや
拠点
調査
XX組織管理下
調査
情報収集
対応が容易
従来のシステム
調査？
DD組織管理下CC組織管理下
AA組織管理下 BB組織管理下
調査
調査？
問題解決までの
対応が複雑？

ブロックチェーンを利用していく上での課題
例えば、メンテナンスで止める場合
DD組織管理下CC組織管理下
AA組織管理下 BB組織管理下
RDBMSや
XX組織管理下
従来のシステム
メンテナンス周知
メンテナンス
メンテナンスが事前に周知され
決められた時間で実施
メンテナンス
メンテナンスメンテナンス
処理できない…
サービスを止めないように
メンテナンス時間の調整が必要

ログフォーマットの統一化
メトリクスの統一化
様々なブロックチェーン技術を活用し続けるために
ブロックチェーン技術を活用していくために
運用監視環境の共通化や
導入ツール整備
10:00:02 node A1 start.
10:00:20 tx commit
10:10:50 node B1 stop.
14:20:30 node C1 start.
14:20:50 node D1 stop.
15:00:20 tx commit
20:30:40 tx commit
20:30:50 node E2 start.
21:30:20 tx comit
接続ノード数: 20
Tx数: 500
Tx数: 2000
Tx数: 10

ブロックチェーンの隣にいるシステムも重要となる
例えば、、、
大量データの
保存・処理
存在証明

利用シーンに応じたルールを決めて運用することが重要
・他者・他組織と利用状況を共有する
・問題があった際には、他者・他組織に速やかに連絡する
・利用するプロダクトのバグは放置せず、
バージョンアップやパッチ適用について、速やかに協議する
・ハードフォークが必要となる場合の合意形成と移行手順

ブロックチェーンの可能性と課題 - SIerとしての視点から

More Related Content

More from LFDT Tokyo Meetup

ブロックチェーンの可能性と課題 - SIerとしての視点から