Blockchain GIG#3 怖くない！エンタープライズブロックチェーン

2019/7/4 Blockchain GIG#3でしゃべった内容
エンタープライズ領域でのブロックチェーン利用に入門するエンジニアの多くが抱えている不安とその実態を紹介

Transcript

1. ‸ Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Blockchain GIG #3 怖くない！エンタープライズブロックチェーン 日本オラクル株式会社 中村 岳 2019年7月4日
2. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation. 2
3. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 自己紹介 •中村 岳 @gakumura • はてなブログ書いてます：空谷に吠える 主にHyperledger Fabric関連 • 現職：ソリューションエンジニア@日本オラクル • 前職：金融決済系SIer • 好きなOS：AIX • 好きなスタンド：クレイジー・D 3
4. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 恒例会場アンケート：ブロックチェーンやってますか？ •ブロックチェーンやってるよ／やったことあるよ –パブリック –プライベート／コンソーシアム •Hyperledger Fabric •Enterprise Ethereum •Corda •その他 4
5. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | エンタープライズ領域でのブロックチェーン案件の最近の状況 • 的を大きく外したユースケース検討は少なくなっている –先行事例を参照しながら冷静な検討 –どのあたりで使えそうかの共通認識（「常識」）が醸成されつつある？ • 比較的小規模な範囲で早期にスモールスタート –現実的な範囲で迅速に始め、将来でのコンソーシアム拡大を目標 –実績やノウハウを積み上げて他のユースケースに応用 • 技術指向（新奇性・PR）⇒実用指向（着実・地道）に 5
6. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | エンタープライズ領域でのブロックチェーン活用の有力分野 6 • 安全性・トレーサビリティ・アカウンタビリティ向上、規制への対応 • 流通路全体の見える化、最適化 モノ・情報のサプライチェーン • 証券などデジタルアセットを台帳上で価値移転 • 土地など現実のモノ（の所有権）もトークン化して管理 価値移転、アセットのトークン化 • 契約締結・履行、アセット由来の収益の分配など • B2C2C取引市場の実現、シェアリングエコノミー 取引・決済の効率化、自動化
7. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | でも難しいんでしょ。。。？ • ①ブロックチェーン基盤の選定はどうやって考えればいいの…？ • ②基盤の構築、ブロックチェーンネットワーク構築が大変らしい。。。 • ③スマートコントラクトって難しいんでしょ？ • ④パフォーマンスがぜんぜん出ないって聞いた！ 7 「エンタープライズ領域でのブロックチェーン利用」でイメージされている課題、困難
8. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 不安①：適切なブロックチェーン基盤の選定 • まずパーミッションレスorパーミッションド のどちらにするかを考える –パーミッションレス（パブリックブロックチェーン）とパーミッションド（プライベート ／コンソーシアムブロックチェーン）では特長、課題、向いている適用領域が かなり異なる –両者の区別と特性を把握し、ユースケースにマッチしているのはどちらかを検討 • エンタープライズ領域では主にパーミッションドが利用される傾向 • 自分のものと似たユースケースにどちらを利用しているものが多いか 8 パーミッションレスorパーミッションドの選択
9. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 2種類のブロックチェーン：Permission-less v.s. Permissioned 9 • 誰でもネットワークに参加しノードを保持できる • 現実世界の個人/法人のIDとの紐付が不要（匿名性） • 参加者の経済的インセンティブに基礎を置いたコンセンサス ⇒PoWなどを用い比較的低速なトランザクション処理 パーミッションレス a.k.a. パブリック • 招待されたメンバーのみが参加しノードを保持（許可制） • メンバーの現実世界でのIDの確認は必須 • コンセンサスはメンバーが明らかなことに依存可能 ⇒多数決などの比較的高速なトランザクション処理 パーミッションド a.k.a. プライベート
10. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | エンタープライズ領域でブロックチェーン基盤に求められるもの 10 • 「誰でも参照可能」はNGとなるケースが多い • コンソーシアム内で更に共有範囲を分割したいというニーズも データの公開範囲を限定できる • エンタープライズ利用に相応の耐障害性・可用性、 運用・保守性、セキュリティ、スケーラビリティ 非機能要件 • ある程度の実績はやはり重要 • 本番利用が始まってから基盤を切り替えることは容易ではない 基盤技術としての成熟度・信頼性、将来性
11. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 不安①：適切なブロックチェーン基盤の選定 • まずパーミッションレスorパーミッションド のどちらにするかを考える –パーミッションレス（パブリックブロックチェーン）とパーミッションド（プライベート ／コンソーシアムブロックチェーン）では特長、課題、向いている適用領域が かなり異なる –両者の区別と特性を把握し、ユースケースにマッチしているのはどちらかを検討 • エンタープライズ領域では主にパーミッションドが利用される傾向 • 自分のものと似たユースケースにどちらを利用しているものが多いか 11 パーミッションレスorパーミッションドの選択
12. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 不安①：適切なブロックチェーン基盤の選定 • パーミッションレス orパーミッションドのカテゴリの中で 自分のユースケースにマッチしたものがどれかを調査する • 機能面だけを見るのではなく、総合的な判断が必要 –ブロックチェーン基盤の開発体制、サポートはどうなっているか –公開情報は十分か、現時点での信頼性、将来性はあるか –似たユースケースでの実績は参考になる • 利用にあたって必要となる技術要素に対応できるか –開発要員の目処は立つか 12 カテゴリ内のブロックチェーン基盤の比較選定
13. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 代表的なブロックチェーン/DLT基盤 Bitcoin Ethereum Corda Enterprise Ethereum Hyperledger Fabric 用途 送金 汎用 金融機関間取引 汎用 汎用 主要ガバナンス 開発者コミュニティ 開発者コミュニティ R3社 EEA Linux財団 参加形態 Permission-less Permission-less Permissioned Permissioned Permissioned NW内情報共有範囲 公開 公開 限定 限定可能 限定可能 コンセンサス PoW PoW 当事者間 方式選択可能 方式選択可能 ベース暗号通貨 BTC ETH なし なし なし スマートコントラクト なし Solidity、 Vyper Kotlin、Java Solidity、 Vyper GO、Node.js、 Java（&EVM） 備考 ― PoSへの移行予定 金融以外の分野 での活用も進む 実装はQuorumな ど複数あり 安定LTS版1.4系、 最新機能の2.0系を 両輪でサポート 13
14. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 不安①：適切なブロックチェーン基盤の選定 • パーミッションレス orパーミッションドのカテゴリの中で 自分のユースケースにマッチしたものがどれかを調査する • 機能面だけを見るのではなく、総合的な判断が必要 –ブロックチェーン基盤の開発体制、サポートはどうなっているか –公開情報は十分か、現時点での信頼性、将来性はあるか –似たユースケースでの実績は参考になる • 利用にあたって必要となる技術要素に対応できるか –開発要員の目処は立つか 14 カテゴリ内のブロックチェーン基盤の比較選定
15. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 不安②：インフラ関連の設計、構築 • 試しに環境構築、だけでn週間かかっていたのは過去の話…… 公式ドキュメントの充実や書籍、各種ブログなどの情報が増え、 一時期に比べればかなり容易になっている • 日本語の情報もそろそろ充実…Qiitaでの検索結果： –“Hyperledger Fabric”: 229件 –“Quorum”: 169件 –“Corda”: 38件 –参考：”Kafka”:502件、”Hadoop”:1401件、”Kubernetes”:3211件 15 Getting Startedのハードルはいまやそれほど高くない
16. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | BaaS利用のすゝめ • とは言え、インフラ自前構築で本格利用にもっていくには 依然として覚えるべき技術要素、ハマりポイントは結構多い –OS、ネットワーク、VM、Docker、暗号鍵／署名、SDK、周辺ツール、etc… • BaaS（Blockchain as a Service）等のクラウドサービスが 充実してきており、これらの利用を第一に考えたほうがよい –テンプレート化され構築が容易にできるもの –マネージド・サービスとしてまるっと提供されているもの • インフラ構築が自前でできるということだけで価値になる状況では そろそろなくなってきている印象 16
17. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 独占管理方式 共同管理方式 課題②：インフラ関連の設計、構築 • コンソーシアム内でノードをどのように保持、管理するのか 17 ブロックチェーンネットワークのノード、アプリケーションのあり方の設計は独特の課題 個別管理方式 分散 集中
18. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 共通API方式 専用アプリ方式 個別アプリ方式 共通API コンソーシアムで利用するアプリケーションのあり方 18 ノード スマートコントラクト Ledger 個別アプリ SDK／ライブラリ ノード スマートコントラクト Ledger SDK／ライブラリ API利用アプリ 専用アプリ ノード スマートコントラクト Ledger SDK／ライブラリ ↑ コンソーシアムで 合意／共有 ↓ ↑ 参加者が 個々に開発
19. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 不安③：スマートコントラクトの開発 • （基本的に）外部参照しない決定論的なロジックという制限などか ら、それほど複雑にならない（コード量は限定的） • 専用言語があったり専用APIの習得も必要となるが、 既存サンプルを見ながら学習してキャッチアップすることは十分に可能 • そもそもスマートコントラクトはブロックチェーンを利用する システム全体からすればごく一部分 • スマートコントラクトの開発容易性のみに過度に注目して ブロックチェーン基盤を選定するべきではない 19 そんなに難しくない／難しくするべきではない
20. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 「スマートコントラクト」 20 ノード スマート コントラクト Ledger アプリ 既存 システム ノード 他参加者 アプリ ノード 他参加者 アプリ
21. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 「ブロックチェーンを利用するシステム全体」 21 ノード スマート コントラクト Ledger アプリ 既存 システム ノード 他参加者 アプリ ノード 他参加者 アプリ
22. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ネットワーク 「アプリケーション」 22 なんらかのフレームワーク なんらかのミドルウェア アプリケーションロジックとか UIとか なんらかのインフラ なんらかの データストア SDK／ライブラリ ノード スマート コントラクト Ledger
23. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | けっこうつらいのが分散トランザクション設計 • ブロックチェーン内だけを見れば更新トランザクションは整合性が保護されている • しかし、複数データストアを扱う場合、整合性保護を作りこむ必要あり – メンバーが個別に持つデータストアと台帳を同時に更新する場合 – 複数チャネル、コントラクトをまたいで台帳をアトミックに更新したい場合 23 Transaction Scope Transaction Scope
24. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 分散トランザクション設計における独特の難しさ • 基本的には分散システムでのトランザクション設計一般に準じる – 最も難しいのはタイムアウト障害のハンドリング：複数データストアで共通に持つKeyを用意 して冪等＆リトライ可能になるように設計しておくとベター • ブロックチェーンならではの注意すべきところは他参加者がいるところ – 他参加者が台帳の更新を受けて直ちにアクションを取っても問題ないようにする必要 – 他参加者も同時にトランザクションを仕掛けていても整合性が崩れないようにしておく 24
25. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 不安④：パフォーマンス • よく聞く懸念①： 「秒間数件しか処理できないんでしょ？」 「ブロックの確定に10分くらいかかるんでしょ？」 –いずれもパーミッションレスの話 –パーミッションドは段違いに速く、トランザクションの確定も数秒程度 –パーミッションレスでも高速なコンセンサスを採用したブロックチェーン基盤の 登場や、Lightning Network、Plasmaなどセカンドレイヤーと呼ばれる層での 改善が進んでいる 25
26. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 不安④：パフォーマンス • よく聞く懸念②： 『性能面については課題があり今後の改善が期待される』 –パーミッションドを使っていても数年前の実証実験などでは「性能面については 今後の改善が期待される」という報告が多かった –数年前の「今後」→現在。すでにかなり改善されてきている。 –パーミッションドブロックチェーン基盤では、限定的な条件下ではあるが、 n千TPS出たという報告はふつうになっている –RDBやNoSQL、HadoopやSparkと比べても意味はない。 自分のユースケースが実現できるかで考える。 –B2B分野だとほとんどのユースケースが二桁TPSくらいまでで収まるのでは？ 26
27. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | パフォーマンス関連の留意点 • とは言え設計、実装時に注意が必要な点はある –データのサイズが大きすぎる、ネットワークレイテンシが大きいなどは パフォーマンスにテキメンに影響する –先人が苦労した情報もぼちぼち出てきているので同じ失敗を繰り返さないよう にチェックしておく –早い段階でパフォーマンステストを行う、ネットワークが拡大しても 必要なパフォーマンスを維持するための仕組みの検討を行う • 自分が選定するブロックチェーン基盤以外の情報もウォッチすると吉 –基盤技術自体のパフォーマンス改善の方法が利用システム（ブロックチェーン ＋アプリケーション）設計のヒントになることがある 27
28. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | まとめ：Enterprise Blockchain is Ready !! • パーミッションレス／パーミッションドのカテゴリおよび ブロックチェーン基盤はそれぞれの特性を把握したうえで選ぶ • BaaSなどを活用し、迅速に取り組みを開始する • スマートコントラクトだけではなく、システム全体を視野に入れた上で 開発、インテグレーションのイメージを固めておく • パフォーマンスへの過度な不安は無用になりつつある、 ともあれまずはユースケースでのパフォーマンス要件の確認から 28
29. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Oracle Blockchain Platform Cloud Service • 数ステップで構築完了、GUIコンソールで管理・運用も容易 • Oracle以外のHyperledger Fabricともオープンに連携 • State DBとしてBerkeley DBを利用 –パフォーマンス向上 –Phantom Read問題の回避 • 多機能なREST API：Cheincode呼び出しや各種設定・管理 • 台帳を外部のRDBにレプリケーション：大量照会、分析用途 29 Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとして提供
30. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 参考資料 • OCHaCafe#4の資料…Hyperledger Fabricの基本的な情報やTips、利用するシ ステムを開発する上で考えなければいけないことなどのまとめ（長編） https://speakerdeck.com/gakumura/ochacafe-number-4-hyperledger- fabric • Blockchain GIG#2の資料…パフォーマンス関連の設計注意事項など https://oracle-code-tokyo-dev.connpass.com/event/122653/presentation/ • Oracle Blockchain Platformご紹介資料 https://www.slideshare.net/oracle4engineer/oracle-blockchain-platform- cloud-service20190619 30
31. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 31