oracle invent 2019/2 blockchain gig#1 sisco

1. パーミッション型ブロックチェーン
基盤の使い分け
Blockchain GIG#1

2. 自己紹介
金融系システム Sier 10数年
Fintch・ブロックチェーン技術のR&D専業
（株）セゾン情報システムズ
先端技術部 ブロックチェーンラボ(BCLab)
Fintech／ブロックチェーン
清水 健一

3. プロダクト紹介
BC宅配ボックス
配送に関わる荷物のトレーサビリティを実現
「本人のみ」確実な受け取りを可能とする

4. プロダクト紹介
コネクテットキー・プラットフォーム
IoTと組み合わせたデジタルキーの
所有者管理

5. プロダクト紹介
社内仮想通貨「SISCOIN」
bitcoin coreをベースとした、
独自のキャッシュレス決済基盤

6. プロダクト紹介
DataSpider for Blockchain
異なるBC基盤でシームレスな連携を可能と
するEAIツール。Ethereum、Bitcoin core、
fabric、Rippleに対応

7. プロダクト紹介
個人情報連携プラットフォーム（BCPDS）
パーソナルデータのポータビリティを実現
あらゆるデータに付加価値をもたらす。

8. AGENDA
本日のテーマ
検証シナリオ
比較検証結果
まとめ

9. AGENDA
本日のテーマ
検証シナリオ
比較検証結果
まとめ

10. 本日のテーマ
伝えたいこと
• BC基盤（技術）の特徴を整理し、エンタープライズ領域での”BC技術”の使い
どころを見極める（切欠になれば）
HLF/ETHで比較。基盤の選定理由
• “抽象的な”コントラクト（ビジネスロジック）が書ける。
• いろいろなクラウドでサービス化されている（もしくは予定）
• 我々も一番よく使う

11. 本日のテーマ
前提知識
• BC基盤で何らかしらプロダクト（サービス）を作ったことがある
※BC用語（特にfabric）がたくさん出てきます

12. AGENDA
本日のテーマ
検証シナリオ
比較検証結果
まとめ

13. 複数の企業間連携（製造メーカー、直販店、代理店）
製造メーカー
直営店
代理店A 代理店B

14. 複数の企業間連携（製造メーカー、直販店、代理店）
• 登場するのはメーカー、直販店、代理店A、B
• 商品販売における在庫管理。販売する際には必ずメーカーから取り寄せて販売。
• 全体で共有するのは、それぞれ商品ごとの在庫数、販売した顧客ID
（それぞれ販売店ごとに異なってもよい）
• 限定共有するのは顧客リスト

15. 実現したいこと
• 商品ごとの全体の在庫数を関係者全員で共有したい（顧客にも開示）
• 商品を販売した実績（いつ・誰が・何を・誰に・幾つ）を共有したい
（※顧客の匿名性は担保）
• 系列店では顧客リストを共有したい
• 共有台帳にアクセスするユーザごとにアクセス管理したい
• 過去にわたり、共有したログが参照できる

16. AGENDA
本日のテーマ
検証シナリオ
比較検証結果
まとめ

17. fabric/Ethereumの構成
fabric ethereum (parity)
※Groupの概念はコントラクトで実装

18. 機能比較
機能 fabric ethereum
台帳の更新
※ビジネスロジック
CC単位に決定（EP,RWsetと関連）
※CC設計時に考慮（EP）
コントラクトで決定
台帳の参照 EP？
整合性のチェックはない。
整合性のチェックはない。
（複数台帳の整合性は意識できない）
証明書・秘密鍵の管理 Orgs単位にCA（もしくは外側）で発行
※必ず必要
EOA（外側）
※必ずしも必要ではない
証明書確認 自動的に確認 コントラクトで実装
GAS(ETH)の保有
組織（概念） Orgs ない。コントラクトで実装
チャネル（概念） Channel ネットワークを別ける

19. 機能比較
機能 HLF ETH
コントラクト Go,js,java
パッケージ署名
solidity,serpent,LLL
コントラクトで実装
stateDB KVS,オブジェクトDB
※クラウドサービスによりカスタム
KVS(world state)
※実装により固定される
コンセンサス CCの設計（EP,RWset）とorderer
※特定の機能に依存
PoA,PoW
権限あるnode内でランダム（2~）
シングルトンマシン
検証エラーは個々で捨てられる
※基本的にnodeを意識しない
• PoAのアルゴリズムはAura(authority round)
• endorsement policyは、Proposalフォーマット、2重実行、クライアント実行権限のチェック、仮実行
• RWsetは全てのノード(EP)が同じ結果を出す決定的でなければならない。1つの失敗はすべて失敗する。

20. コントラクトで注意すべき点
• 永久ループ,バグなど
ETHはバージョン管理機構を実装する必要がある、またfieldコントラクトを別ける。
ループは、HLFはエンドースで失敗。ETHはGAS欠
• マルチチャネルのメッセージのやりとり（台帳分割）
クライアント側でどのチャネル、CCに対しアクセスするかコントロールする必要がある
• RWsetエラー。TRNコンフリクト、意図しない更新。
HLFは、pub/sub eventで受けれる。
ETHは、強制上書き（設計で作りを考慮。コントラクトでチェック）
• EPエラー。複数nodeで整合性が異なる。
HLFは、pub/sub eventで受けれる
ETHは実装不可（シングルトン・マシン）→ 少数は破棄されreorgされる。

21. AGENDA
本日のテーマ
検証シナリオ
比較検証結果
まとめ

22. 技術面で比較すると、いづれのBC基盤も実装は可能
それぞれ得意・不得意があり、やりたいこと・実現したいことにより、
選択し使い別けることが重要
単純なアセットの交換する仕組み（コインやポイント）ならば、特化型
BC基盤を使うという選択肢もある（サポートありのmultichainなど）

23. 業務システムはBC技術だけでは実装できない
エンタープライズ向けの業務システムとして考えた場合、実運用を鑑みる
とBC基盤（技術）だけでは不十分なことが多く、他の既存技術も組み
合わせて実装する必要がある。
BC基盤を選択する上で、HLFの方がいいのか？ETHの方がいいのか？
は、BC技術である必要があるのか？と同義
”BC技術”をうまく活用していくには、実現すべき機能軸（ストーリー単
位）でそれぞれ役割を整理し、検討する必要がある。

24. シナリオで実現したいこと （再掲）
• 利害の異なる参加者で情報を共有したい（共有）
• 取引の客観的な真正性を担保したい（事後否認、なりすまし）
• 過去に渡り改変不能なログを残したい（改ざんや不正の検知）
• 綿密なアクセス管理したい（予め決めた参加者、不特定の参加者）
色々なモノが繋がる世界を見据え、新たなサービスを実現するにあ
たり、技術的優位性がどこにあるか見極め実装する必要がある