‸ Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイド 日本オラクル株式会社 中村 岳 2019年3月28日 

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. 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 自己紹介 •中村 岳 @gakumura • 現職：ソリューションエンジニア@日本オラクル • 前職：金融決済系SIer • 好きなOS：AIX • 好きなスタンド：クレイジー・D 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 本日のテーマ： Hyperledger Fabricアプリケーション設計入門ガイド • パーミッションドブロックチェーン基盤としてエンタープライズ領域で既に多くの実績 があり、おそらく最も注目を集めているHyperledger Fabricを扱います • 一方でHyperledger Fabricは非常に多くの機能を備えており、また、アプリケー ション開発とコンソーシアムネットワークをどのように構成すればよいのかについてあ まり共有されているノウハウもない状態で、「とっつきづらい」「どこから取り組んだ らいいのかわからない」という方が多いと思います • ということで、Hyperledger Fabricを用いてアプリケーションを開発し、コンソーシア ムネットワークを構成する際に必ず重要となる基本的な機能と、アプリケーション ／コンソーシアムの設計の際の検討すべき点、考え方などを解説します 4 Connpassの紹介文から抜粋 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 「Hyperledger Fabricのアプリケーション設計」 •なんだかむずかしい・・・ •なにがむずかしいのかもよくわからない・・・ •Fabric覚えること多すぎ・・・ •情報がない・・・ 5 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ネットワーク 一般的な「アプリケーション設計」で考える必要のある範囲 6 なんらかのフレームワーク なんらかのミドルウェア アプリケーションロジックとか UIとか なんらかのインフラ なんらかの データストア 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 「Hyperledger Fabricのアプリケーション設計」で 考える必要のある範囲 7 Peer Chaincode Ledger アプリ データ ストア 既存 システム Peer 他参加者 アプリ Peer 他参加者 アプリ 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | おしながき 本日喋る内容 • Introduction ←今ここ • Hyperledger Fabricについて抑えておくべき基本 • ネットワークとアプリケーションのあり方 • アプリケーション設計のポイント 資料だけ公開 • Hyperledger Fabricのトランザクション詳細 • Chaincode Taboos & Tips • Etc. 8 設計にあたって ・必須の前提知識は何か ・何を考えなければならないか ・つまずきやすいポイント 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | OCHaCafe 9 ・オープン・スタンダードなテクノロジーを テーマに取り上げ、 短時間でガッツリ 学んでお持ち帰りいただく ・お仕事帰りにCafeでくつろぎながら、 テーマ毎のテクノロジーを習得する ・入門ではなく開発者向けに一歩踏 み込んだDeepな内容を扱う 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Hyperledger Fabricについて抑えておくべき基本 10 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 2種類のブロックチェーン：Permission-less v.s. Permissioned 11 • 誰でもネットワークに参加しノードを保持できる • 現実世界の個人/法人のIDとの紐付が不要（匿名性） • 参加者の経済的インセンティブに基礎を置いたコンセンサス ⇒PoWなどを用い比較的低速なトランザクション処理 パーミッションレス a.k.a. パブリック • 招待されたメンバーのみが参加しノードを保持（許可制） • メンバーの現実世界でのIDの確認は必須 • コンセンサスはメンバーが明らかなことに依存可能 ⇒多数決などの比較的高速なトランザクション処理 パーミッションド a.k.a. プライベート 

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 プライバシー 公開 公開 限定 限定可能 限定可能 コンセンサス PoW PoW 当事者間 方式選択可能 方式選択可能 暗号通貨 BTC ETH なし なし なし スマートコントラクト なし Solidity、 Vyper Kotlin、Java Solidity、 Vyper GO、Node.js、 Java（&EVM） 備考 ― PoSへの移行予定 金融以外の分野 での活用も Ethereumの Permissioned版 フォーク 12 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Hyperledger Fabric • Hyperledger : Linux財団がホストするオープンなコミュニティ – 世界で最も成功したOSS=Linuxでの成功実績に基づいた運営 – さまざまな業種の企業およびIT企業、研究機関が240以上参加 – Fabricをはじめ、複数ブロックチェーン/DLT基盤およびツール等をOSSとして開発 • Fabric : 汎用ビジネス利用のためのブロックチェーン基盤 – メンバー管理サービスを備えたパーミッションドブロックチェーンを実装 – セキュリティ、機密性/プライバシーを強化するための多様な機能 – スマートコントラクトによって業務を自動化 – 大量処理をサポートするためのスケーラブル、プラガブルな設計 – マイニングなどの大規模コンピューターパワー投入は不要＆ファイナリティ有 13 エンタープライズ用途を目的として開発されたブロックチェーン 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | • Organization • Peer – Endorser / Committer – Gossip • Anchor / Leader • Intra Org / Inter Org • Ordering Service – Type: Solo / Kafka – Block Generation Settings • MSP • Ledger – State DB / Blockchain • Endorsement Policy – Chaincode Level / Key Level • Transaction Flow • Channel – Capability Requirements • Private Data – Auto Purge / Delete • Identity Mixer • Peer Event Service – Transaction/Network/ Channel /Custom • Service Discovery 14 • Chaincode Lifecycle • Chaincode Techniques – Get State / Put State – Ranged Query / Rich Query – Transient Map – Custom Event – Attribute-based AC – Key History / Transaction History – Inner CC Invocation • Intra / Inter Channel – Ethereum VM (Burrow) • Fabric SDK Hyperledger Fabricのお勉強要素 赤字：理解が必須の基礎知識 青字：知ってると便利、応用編 それ以外：必要に応じて学ぶ 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | • Peerノード – 台帳（State DBとブロック）を保持 – 依頼されたChaincodeを実行 – トランザクションを検証して台帳に反映 • Ordering Service – ひとつ～複数のOrdererノードで構成 – 受け取ったトランザクションの 順序を確定してブロックを生成 （決定論-性の順序付け） – 生成したブロックをPeerノードに配布 • Chaincode(スマートコントラクト) – 台帳の更新、照会のビジネスロジック • MSP(Membership Service Provider) – 証明書を管理する – 署名を検証する • クライアントアプリケーション – PeerノードにChaincode実行を依頼 – Ordering Serviceにトランザクション受付を 依頼 – Fabric SDKを用いて実装 15 ネットワークの構成要素 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Peer 16 Hyperledger Fabricネットワーク Peer Ledger Chain code App MSP Peer Peer Ledger Chain code App MSP Peer Peer Ledger Chain code App MSP O O O O Ordering 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Peer 17 Hyperledger Fabricネットワーク Peer Ledger Chain code App MSP Peer Peer Ledger Chain code App MSP Peer Peer Ledger Chain code App MSP O O O O f Ordering Fabricで言う「ネットワーク」は ひとつのOrdering Serviceを 共有する範囲 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Peer 18 Hyperledger Fabricネットワーク Peer Ledger Chain code App MSP Peer Peer Ledger Chain code App MSP Peer Peer Ledger Chain code App MSP O O O O Ordering ノードやMSP、クライアントアプリケーション のネットワーク構成要素を管理する （責任を持つ）単位として Organizationがある 通常、企業などのコンソーシアムに 参加する組織と対応する 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Peer 台帳（分散台帳の1コピー） 19 Peerノードはそれぞれ台帳を保持している 追記型かつバージョン管理されたKey-Valueストア になっており、以下ふたつの要素から構成される ＋ ブロックチェーン： 最新／過去のバージョンの値を格納 ＆トランザクションの履歴を格納 State DB（World State）： 最新バージョンの値を格納するデータベース Peer Peer Peer 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | State DB • StateDBはKey-Valueストアで、Valueには任意のバイナ リを格納可能 • State DBにはLevelDBかCouchDBを選択可能 • LevelDB：シンプルなValueを扱う場合向け • CouchDB：複数の属性を持つValueを扱いやすい – JSON形式でValueを格納すると、Attributeを条件に指定して クエリできる（リッチクエリ） – LevelDBに比べてかなり低速 – Phantom Read問題に注意が必要 • 台帳に更新をかけるトランザクションでリッチクエリを使うな、の制約あり 20 Key: marble1234567 Value： { “color”:”red”, “size”:12, “price”:200, “owner”:”Bob” } 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | チャネル • ブロックチェーンネットワークを さらにサブネットワークに分割し、 データ（台帳）の共有範囲を限定 プライベートデータ • チャネル内で共有されるデータのうち、 さらに項目を限定して共有できる 21 Hyperledger Fabricのデータ共有範囲制御 L1 L2 L3 【お客様情報レコード】 “ID : 1234567890” “生年月日 : 1987年1月1日” “性別 : 男性” “名前 : 鈴木太郎” “住所 : 東京都千代田区X-X-X” “電話番号 : 080XXXXXXXX” “契約コース : 従量制A” “契約日時 : 2019/1/21” 一部参加者のみで 共有し、 他参加者には秘匿 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 22 情報共有範囲制御①：チャネル • チャネルはサブネットワークの分割単位であり、データ共有範囲である • チャネルごとに台帳が存在し、そのチャネルに参加するPeerノード間で共有される • あるPeerノードはひとつ～複数のチャネルに参加できる – 即ち、あるPeerノードは参加しているチャネルの数だけ台帳を保持することになる ノードA ノードB ノードC チャネル1 L1 L2 L1 L1 L2 L3 L3 チャネル2 チャネル3 • ノードAはチャネル1と2に参加しており、 台帳(Ledger)1と2を保持する • ノードBはチャネル1,2,3の全てに参加しており、 台帳1,2,3を保持する • ノードCはチャネル1,3に参加しており、 台帳1と3を保持する • 台帳1のデータはノードA,B,C全てに共有される が、台帳2はAとB、台帳3はBとCのみ 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 23 チャネルの活用例 • たとえば原料生産⇒製造⇒小売までの製品トレーサビリティを実現するための コンソーシアムを考えたときに、以下のような要件が考えられる： – メーカーはコンソーシアムを通じてすべての情報を把握したい – 複数小売業者が参画しており、小売業者相互には仕入数などの情報を明かしたくない – 原料から製造までの情報は原料サプライヤーとメーカーだけが共有できればよい • チャネルによりこうした要件を満たした情報共有が実現できる L1 L1 L2 L3 L2 L3 原料サプライヤーと メーカーが参加するチャネル メーカーと小売業者Aが 参加するチャネル メーカーと小売業者Bが 参加するチャネル 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 24 情報共有範囲制御②：プライベートデータ • 共有されるデータの内容のうち、一部の項目のみについて共有するノードを限定 することができる • プライベートデータ（PD）は台帳の外（Side DB）に保持される – 手動削除可能な他、予め決めた期間後に自動削除（パージ）することができる ノードA ノードB ノードC チャネル1 L1 PD1 L1 L1 PD1 PD2 PD2 PD1の 共有範囲 PD2の 共有範囲 【お客様情報レコード】 “ID : 1234567890” “生年月日 : 1987年1月1日” “性別 : 男性” “名前 : 鈴木太郎” “住所 : 東京都千代田区X-X-X” “電話番号 : 080XXXXXXXX” “年収 : XXX万円” “勤務先 : XX株式会社” PD1 PD2 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | プライベートデータの活用例 • たとえばメーカー⇒卸売⇒小売での在庫情報共有および契約効率化のための コンソーシアムを考えたときに、以下のような要件が考えられる： – ある商品の在庫数は全体で共有し、追加発注もスマートコントラクトにより自動化したい – メーカーから卸売業者への販売価格は小売業者に知られたくない、 また、卸売業者から小売業者への販売価格はメーカーに知られたくない • プライベートデータによりこうした要件を満たした情報共有が実現できる 個々の製品についてのレコードを共有 ・ID ・所在情報 ・製造年月日 ・etc. 二社間での売買価格は PDとして限定共有 二社間での売買価格は PDとして限定共有 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Chaincodeのライフサイクル • PeerにInstall⇒チャネルでInstantiate（インスタンス化）することで実行可能に – InstallはPeerスコープ：各Orgが各Peerにinstallする必要がある – Instantiateはチャネルスコープ：この際にEndorsement Policyを指定 • バージョンアップ可能：新しいバージョンをInstall、Upgradeを行うことで新バー ジョンがInstantiateされて有効になる – 新バージョンで旧バージョンのChaincodeが書いたレコードにもアクセスできる 26 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | トランザクションフロー • Endorsement： – クライアントアプリケーションからPeerにTransaction Proposalを送付 – PeerノードがChaincodeを実行し署名を付けて結果（Endorsement）を返却 • Ordering： – Endorsementを集め終えたクライアントアプリケーションがトランザクションを送付 – 受け取ったOrdering Serviceがブロックを生成、Peerノードに配布 • Validation： – Peerがブロック内のトランザクションを検証し台帳に反映（コミット） 27 Endorsement・Ordering・Validationの3フェーズ 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | トランザクションフロー：図 28 クライアントアプリ Fabric SDK Keys MSP Peerノード（複数） Endorser StateDB Committer Ordering Service Certificate Authority 2.1 –ブロックの配布 署名の検証、認証 トランザクションの 順序を確定し バッチ（ブロック） を生成 2.0 – Transactionの送付 （Endorsementを含む） ブロック チェーン 3.0 – Validation 4.0 – 結果通知（Event） Chaincode 1.1 – Chaincodeの実行 3.1 – 台帳に書き込み 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Endorsement Policy • Endorsement：Chaincode実行結果にPeerが署名したもの • Endorsement Policy：あるChaincodeのトランザクションを台帳に反映するため に、どのようなEndorsementを集めてこなければならないかを定める条件 （どうしたらコンセンサスが取れたことになるか） – Chaincode×チャネル単位で設定可能（Chaincode Instantiate/Update時に設定） – 単純なEndorsementの数による条件から重みづけまで、柔軟な設定が可能 – EndorsementはPeer単位ではなく、Organization単位でカウントされる – 例：Org A,B,Cで構成されるネットワークの場合に、「3つのOrgのうち、任意の2つのOrg配 下の任意のPeerからEndorsmentの取得」といったような条件 29 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Endorsement Policyの例 AND、OR、OutOfの組合せで定義 • AND(‘Org1.member’, ‘Org2.member’, ‘Org3.member’) 全Org必須 • OR(‘Org1.member’, ‘Org2.member’) どっちかのOrgでOK • OutOf(2, ‘Org1.member’, ‘Org2.member’, ‘Org3.member’) いずれか2つOrg • AND(OR(‘Org1.member’, ‘Org2.member’), ‘Org3.member’) Org1かOrg2のどっちか + Org3必須 ※memberとadminはPeerのRole（Peerノード構築時に定義） 30 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Peerのふたつの役割：Endorser / Committer • あるトランザクションに関してChaincodeを実行する、つまりEndorsementを行う PeerをEndorser（Endorsing Peer）と呼ぶ • Validation/Commitを行うPeerをCommitter（Committing Peer）と呼ぶ • Endorsementを行うPeerはValidation/Commitも行うが、 Validation/Commitだけを行うPeerも存在できる • EndorsementをしないPeerにはそのChaincodeをインストールしなくてよい • EndorsementとValidation/Commitの負荷分散のための仕組み 31 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 32 From: https://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html Peerへの Transaction Proposal送付 Chaincode実行 Endorsement返却 Endorsement収集 Transaction送信 ブロック生成 →配布 Validation →Commit Tx Event通知 （Validation後） 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Event Service • PeerはEvent Serviceを持っており、クライアントが登録しておくとイベントを通知し てくれる – Transaction/Channel/Network/Customという単位で指定できる • Transaction Event ：Transaction ID指定で登録しておくと、そのPeerでの当該 トランザクションのValidation/Commit結果を通知してくれる（Valid/Invalid） • なんらかの理由でクライアントが通知を受け取れなかった場合にも、再通知はし てくれないことに注意 – さっきのトランザクションの結果どうなったんだっけ…？問題 33 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 台帳への書き込みの有無 • Fabric SDKにはQueryといったような名がついたChaincode呼び出し機能があり、 これを使うとEndorsementフェーズまででトランザクションを打ち切る – Peerからの応答メッセージにはChaincodeの返り値が含まれているため、台帳の読み取り （クエリ）に利用することができる – Ordering ServiceにTransactionを送付しないので台帳への書き込みは行われない • ステートに更新を行わない場合でも、Ordering Serviceにトランザクションを送付 し、トランザクションを行ったこと自体を台帳に記録することは可能 • クライアントアプリケーションに任されているため、「読み取りだけでも（ステートの 更新がなくても）必ずトランザクションを台帳に記録する」運用は強制できない 34 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Orderingサービス補足 • 複数チャネルで並行実行可能（Pub-Sub Messaging） • 決定論的な順序化を行う • 一貫性の保証： 全Peerは同一の順序でメッセージを受 け取る • HLFv1.4現在、選べる構成は以下： –Solo：単一Orderer、主に開発用想定 –Kafka：Kafka+ZooKeeperで1~nノードのクラスター • バッチタイムアウト時間（1つ目のトランザクションを受け 取ってからブロック生成を待機する時間）、含められる最 大トランザクション数は設定可能 35 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ネットワークとアプリケーションのあり方 36 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | どのようにネットワークを構成するか • ブロックチェーンをベースとするシステムを利用するにあたり、 必ずしも利用者全員がノードを持つ＝ブロックチェーンネットワークの構成員とな る必要はない • 利用方法は以下のパターンが考えられる – 自身でノードを持ち、自らブロックチェーンネットワークの構成員となる – コンソーシアムの運営には関わるが、自身でノードは持たず コンソーシアム共同管理のノードを利用する – サービスだけ利用する 37 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 独占管理方式 共同管理方式 ノードの持ち方モデル 38 個別管理方式 分散 集中 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ノードの持ち方：個別管理方式 • ブロックチェーン台帳を利用する参加者がそれぞれノード を管理する方式 • 分散、水平 – 互いに利害関係の対立がある企業も参加しやすい • 自由度が大きいのでシステム、規約の作り込みが重要 – システムの運用を適正に行えるか • 参加者の増大につれノードが増えていく • 一部のノードを共同管理にする方式もあり得る – 大企業やコンソーシアムの存続にステークの大きな企業は個別 にノードを持ち、そうでない企業は利用だけする 39 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ノードの持ち方：共同管理方式 • コンソーシアムが運営する共同組合がノードを管理する方式 • ガバナンス、バランス – 組合への信頼がそのままネットワークへの信頼 – 組合の適切な運営が重要 – ネットワーク、ノードの構成を最適化しやすい – システムの運用にガバナンスが効く • 組合は中間団体なのでその運営コストは必要 • 既存の業界団体がリードするコンソーシアムの場合にフィットする可能性が高い • 金融など規制が厳しい業種でのユースケースにも適合しやすい 40 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ノードの持ち方：独占管理方式 • ある組織が独占的にノードを管理する方式 • 独占、ヒエラルキー、信用 – 独占する組織にデータを集中させ、それを利用させてもらうというモデルになる • 利用者側にとっては基盤がブロックチェーンかどうかはあまり意識されないかも 41 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | • メリット – ネットワーク運営に影響力を保持 – 台帳データを自身で保持できる • ある日ネットワーク運営が止まってもそこまでの データを確保 • ブロックチェーン外に台帳を作らなくてよい – 台帳データの利用方法が柔軟 • デメリット – ノード構築、運用コストがかかる • 自前サーバ運用 or クラウド利用料 • メリット – ノード構築、運用コストがかからない • デメリット – ネットワーク運営への発言権が弱い – 台帳アクセスに主体性がもてない • 可用性、パフォーマンスをコントロールしづらい • 他の組織の意向で制限される可能性がある • 結局ブロックチェーン外に自前台帳を作りこむ必 要性が生じる場合が多いと思われる – ノード利用料を徴収される場合がある 42 ノードを自身で管理することのメリットとデメリット ノードを持つ ノードを持たない 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ブロックチェーン台帳を利用するアプリケーションのあり方 • Chaincodeの内容が公正であると確認できても、 他者が提供しているアプリケーションでしかChaincodeを呼び出せないとしたら？ – 台帳がどうなっているかはそのアプリケーション経由でしか知ることができない – アプリケーションが不正な挙動（提供元にとっては都合がよい挙動）をするかもしれない – アプリケーションのコードを公開してレビューする？ – 公開されているコード通りのアプリケーションが提供されている保証は？ • Hyperledger Fabricがシステムとして信頼を提供できる台帳／Chaincodeとは 別のトラストレイヤーになるため、クライアントアプリケーションのあり方も重要 43 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 共通API方式 専用アプリ方式 個別アプリ方式 共通API 利用するアプリケーションのあり方 44 Peer Chaincode Ledger 個別アプリ Fabric SDK Peer Chaincode Ledger Fabric SDK API利用アプリ 専用アプリ Peer Chaincode Ledger Fabric SDK 分散 集中 ↑ コンソーシアムで 合意／共有 ↓ ↑ 参加者が 個々に開発 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 利用するアプリケーションのあり方：個別アプリ方式 • Peer/Chaincodeへのインターフェースを参加者に開放し、 個々に開発したアプリケーションを通じてブロックチェーン台 帳の利用を行う方式 – ノード個別管理方式の場合、インターフェースを（技術的には） 限定しようがないため個別アプリ利用可になる • 個々に開発するコストを省いて参加できるよう、共同で開 発した標準アプリケーションを提供することもあり得る – 個別アプリの開発・利用を選択してもよいということがポイント • 自由度が高いため、Chaincodeの内容やEndorsement Policyの設計、およびクエリ／Endorsement依頼先の Peerに関する規約が重要になる 45 Peer Chaincode Ledger 個別 アプリ Fabric SDK 標準 アプリ Fabric SDK 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 利用するアプリケーションのあり方：共通API方式 • Peer/Chaincodeへのインターフェースは参加者には直接 開放せず、共通APIを通じてブロックチェーン台帳の利用 を行う方式 • API層を通じてノードの存在を隠ぺいできるため、API利用 アプリの開発にあたってはEndorsement先やクエリ先を意 識する必要がない • API層で利用者ごとの権限制御を作り込めるため、ガバナ ンスの実現が比較的容易になる • APIの開発元、運用者に対しての信用が必要になる 46 共通API Peer Chaincode Ledger Fabric SDK API利用アプリ 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 利用するアプリケーションのあり方：専用アプリ方式 • Peer/Chaincodeへのインターフェースは参加者には直接 開放せず、共同で開発したアプリケーションを通じてのみブ ロックチェーン台帳の利用を行う方式 • 専用アプリの提供者に対しての信用が必要になる • 利用者側にとってはアプリケーションの裏側にブロックチェー ンがあるかどうかはあまり関係ない 47 専用アプリ Peer Chaincode Ledger Fabric SDK 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ネットワークとアプリケーションのあり方まとめ • どのようなあり方のネットワークなのか？ • どのようなアプリケーションが利用できるのか？ • 自分が開発しようとしている「アプリケーション」はどの部分にあたるのか？ • 設計時に考慮すべきこと、あるべき仕様が変わるのでまずこれらを確認する 48 ？？？ Fabric SDK 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | アプリケーション設計上のポイント 49 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 設計上のポイント： 以下についてHyperledger Fabricならではのポイントを紹介 • データ設計 • ロジック設計 • トランザクション設計 • Endorsement Policy設計 • スケーラビリティとパフォーマンス 50 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | データ設計：台帳と個別データストア • 共有する台帳だけではデータストアとして一般に不十分で、各参加者／アプリ ケーション個別にもつオフチェーンのデータストア（個別データストア）も必要 • システム全体としてどのようなデータを扱い、それらを台帳と個別データストアのど ちらに配置するのかを検討 51 ネットワークで共有する台帳のデータと参加者個別にもつデータの検討が必要 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | • 他組織と共有したいデータ – アセットの基本情報（ID、カテゴリ等） – アセットのステート（所有者、現在位置、 数量、残高など） – ステート変更の条件評価に必要な情報 • 証跡として残したいデータ • 共有不可／不要だが、台帳と組み 合わせて使うデータ – アセットの詳細情報、集計情報 • 整理、分析などのための台帳のデータ のコピー、一時キャッシュ、アーカイブ • 個別アプリケーションのデータ（認証 情報など） 52 データ設計：台帳と個別データストアの棲み分け 台帳 個別データストア 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | データ設計：台帳に載せるデータ検討上の注意点 • 個人情報は書き込まない – 個人情報保護法、GDPRなどの法規制 – 「削除して」と言われても台帳に書いてあると消せない（State DBからは削除できてもブロッ クチェーン上にWrite-Setが履歴として残ってしまう） – 個別データストア、あるいはPrivate Dataを活用 • サイズに注意 – 画像イメージや文書ファイルなど、サイズの大きいデータの保管には向かない • ×：ファイルそのものを保存 ○：ファイル内容のハッシュ値を保存 – 台帳への書き込み内容はネットワークを伝播するため、パフォーマンスへの影響が大きい • 特にトランザクションボリュームが多い場合は注意 • 略語を使用してチャネル名や変数名を縮めるなどの細かい努力（Name⇒Nm、Number⇒Numなど） 53 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | データ設計：チャネルでの台帳共有範囲分割の検討 • 単一のHLFトランザクションで複数台帳をアトミックに更新することはできない – 複数台帳を横断しての検索も不便、Read-Consistency確保も困難 • チャネルをまたいでのトランザクションはクライアントアプリケーション側で整合性保 護を作り込む必要がある – ブロックチェーンのトランザクションはロールバックできず、2フェーズ/3フェーズコミットなどのス キームが利用できないためわりと難しい • 複数の台帳のデータをクライアントアプリケーション側で統合する必要 • チャネルを分けなくて済むなら分けないほうがいい – 本当に共有できないのか？Private Dataで解決できないか？ 54 データを共有できないならばチャネルを分けるが、分割のデメリットに留意 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | データ設計：Private Dataの利用の検討 • ステートを共有したい、トランザクションを分けたくないが、一部のデータ項目だけ 秘匿したい場合に有用 • Auto Purge（nブロック後に自動削除）の利用の検討 – nブロック以内に個別データストアに退避する？ – nブロックは十分な猶予時間か？ • DeletePrivateDataで手動削除することができる – 他参加者に手動削除されても問題ないか？⇒消される前に退避？ • Chaincodeが複雑になりがちなのが難点 – Endorsement Policy、クエリ先のPeerなども複雑化 55 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | データ設計：データ保持方法まとめ 共有範囲 削除可否 特性 台帳（State DB ＋ブロック） チャネル内 不可（ブロック に残る） 耐改ざん性があり削除できないため証跡として機能する チャネルごとに台帳が分かれる ⇒トランザクションは分断される サイズが大きいレコードを扱うと性能が出ない 構造化や大規模検索、分析などのバッチ処理は苦手 Private Data （Side DB） チャネル内 の限定さ れたPeer 可（Auto Purge か手動Delete） チャネル内でデータ項目を限定して一部参加者から秘匿で きる 自動あるいは手動で削除できる KeyとValueのハッシュは台帳に載るため検証が可能 サイズが大きいレコードを扱うと性能が出ない 構造化や大規模検索、分析などのバッチ処理は苦手 個別データストア 共有なし 可 データベース、ストレージなど任意のデータストアを利用 56 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | データ設計Tips：履歴もステートにすべき？ • 「どのようにステートを更新したか」はトランザクション履歴としてブロックチェーン内 に残っている – チャネル名、Chaincode名、実行ユーザー、Function名、引数、Write-Set – 例：口座ごとの残高をステートとしたとき、口座間の送金履歴はトランザクション履歴に記 録されている • しかしこのトランザクション履歴は、Chaincode内ではKey History⇒Transaction Detail とたどらなければならず検索性は低い • トランザクション履歴をあえて冗長にステートとしても残すこともあり得る – レコード量増加とのトレードオフ Confidential – Oracle Internal/Restricted/Highly Restricted 57 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ロジック設計：ロジックの配置 • Chaincodeとクライアントアプリケーションでロジックの分担を検討 • Chaincodeにあまり複雑なことをやらせるべきではない – Endorsementで処理が冗長に実行される、State DBはRDBと同じようには使えない – 修正、改善にいちいち合意、Install&Instantiateしなければならず反映が手間 • 「Chaincodeにないと困る」機能以外はクライアントアプリケーション側に配置する – Chaincodeに必須なのは台帳の更新処理＋基本的なクエリ処理 – 更新条件の確認に必要なステートの現在状態確認も独立したクエリ機能として実装 – 大規模集計、分析などの複雑なクエリはChaincodeに作り込まないほうがよい ⇒個別データストアに台帳のデータをキャッシュ／複製し、そちらで行う 58 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ロジック設計：Chaincode設計の注意事項 • Chaincodeの処理内容はdeterministic（決定論－的）にする必要がある – クライアントから渡される値と台帳にある現在ステートを入力として、出力であるクライアント への返り値と更新後ステートが一定に定まらなければならない – Chaincode処理がdeterministicでないと、Endorsement Policyを満たせずトランザクション が有効にならない • 典型的にはPeer内部時刻の利用、乱数の生成など • 台帳以外の外部データストア、外部サービスからの情報の利用も決定論－的 であることを保証できない（また、不正のリスクがある）ので基本的には不可と 考えておく 59 非決定論-的な挙動の回避 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | トランザクション設計：整合性保護について • 単独チャネルでの更新トランザクションはHLFの機能で台帳のインスタンス間での 整合性が保護されている • しかし、複数データストアを扱う場合、整合性保護を作りこむ必要あり – 個別データストアと台帳を同時に更新する場合 – 複数チャネルをまたいで台帳を同時に更新する場合 60 Transaction Scope Transaction Scope 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | トランザクション設計：分散トランザクション設計 • 基本的には分散システムでのトランザクション設計一般に準じる – 最も難しいのはタイムアウト障害のハンドリング：複数データストアで共通に持つKeyを用意 して冪等＆リトライ可能になるように設計しておくとベター • ブロックチェーンならではの注意すべきところは他参加者がいるところ – 他参加者が台帳の更新を受けて直ちにアクションを取っても問題ないようにする必要 – 他参加者も同時にトランザクションを仕掛けていても整合性が崩れないようにしておく 61 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 分散トランザクション 台帳＆個別データストア • 基本的には個別データストア→台帳の順序がおすすめ – オフチェーンの個別データストアは取り消しなどの手当がしやすく、他参加者にも伝わらない – 個別データストアでの更新が成功してから（成功する確証が取れてから）台帳の更新ト ランザクションを発行する • 個別データストア側の更新をロールバックできるならベター – 先にRDB側でトランザクション発行しホールド – HLFのトランザクションが確定（valid/committed）したらコミット – Proposalでエラーになるか、Validationフェーズでinvalidになったらロールバック – ロック長時間化による性能劣化の可能性には留意 62 Transaction Scope 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 正常系 63 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 異常系① Proposalでエラー 64 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 異常系②： Validationでエラー 65 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 異常系③： Validation結果不明 ・なんらかの理由によりValidation結果の Peer Eventが取れなかったパターン ・場合によってはRDBでロールバックせず にコミットしちゃうのもありかも 66 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 分散トランザクション：複数チャネル • 複数チャネルに同時にトランザクションを発行すると結果が出る順序がまちまちに なったりしてハンドリングが難しくなるため、基本的に順次発行する – Ch1にTx発行⇒Ch1成功⇒Ch2にTx発行⇒… • 参加者の間でチャネルの更新順序を合意しておく • 更新順序は規約、マナー、慣行ではなくシステム的に作り込めると安全 – Ch1で削除したときに生成されるIDをCh2に登録時に入力する、など 67 Transaction Scope moveOut(Item1) outKey moveIn(Item1,outKey) 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 分散トランザクション：複数チャネル • 後に回したほうのチャネルで更新が行えなかった場合の手当ての検討 – Ch1からCh2にアセットを移動しようとしたが、Ch2に追加できなかったためCh1に復活、など – Ch2に追加できなかった原因次第で対応を分ける、とすると他参加者に混乱が生じる可能 性があるため、常にいったんは一定の対応をとることにしたほうがシンプル – 最低限、中途半端な状況になっていることを発見できるようにしておく 68 Transaction Scope moveOut(Item1) outKey moveIn(Item1,outKey) undo(moveOut,Item1,outKey) 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Endorsement Policy設計 • 耐障害性、セキュリティ、パフォーマンス（スケーラビリティ）のバランス • 基本的にはm out of n（n個のOrgのうちm個）のモデルで考えていく m > n – （同時に 不正／外部攻撃／故障 を起こすかも…なOrgの数） • BFTのm > 2n/3モデルも参考になるがMUSTではない • 必須のOrgを作る場合、当該OrgのEndorsing Peerの可用性、 処理性能がネットワーク全体にとってクリティカルな問題になる 69 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スケーラビリティとパフォーマンス：ターンアラウンドタイム • クライアントから見たときの ターンアラウンドタイムとは： Transaction Proposalを送信～ Peerでのvalid/committedイベン ト通知が届くまで 70 トランザクションのターンアラウンドタイム 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スケーラビリティとパフォーマンス：ターンアラウンドタイム • 内訳としては２段階： – Transaction Proposalを送信してか ら必要なEndorsementが集まるまで – Transactionを送信してからPeerで のvalid/committedイベント通知が 届くまで 71 ターンアラウンドタイムの内訳 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スケーラビリティとパフォーマンス：ターンアラウンドタイム • 要素：各Endorsing Peerでの – メッセージ往復時間 – Chaincode実行時間 • 最も遅い応答に依存 • 改善要素： – PeerのEndorsement負荷分散 – ネットワーク距離 – Peerの処理性能（CPU／メモリ／IO） – Chaincodeの内容 72 前半部分：トランザクションのEndorsementフェーズ 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スケーラビリティとパフォーマンス：ターンアラウンドタイム • 要素 – メッセージ、ブロック、イベント伝送時間 – Ordering Serviceでのブロック生成時間 – Committing PeerでのValidation/Commit時間 • 改善要素： – Ordering Serviceのブロック生成設定 • バッチタイムアウト時間を減らす – ネットワーク距離 – Orderer、Peerの処理性能（CPU／メモリ／IO） 73 後半部分：トランザクションのOrdering＋Validation/Commitフェーズ 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スケーラビリティとパフォーマンス：スループット • スループットの改善要素 – PeerのChaincode実行（待ち）時間を減らす • Chaincodeのロジックを改善 • Chaincode実行（Endorsement）の負荷を分散する – Ordering Serviceの最適化：バッチタイムアウト時間と最大Tx量を増やす – Validation/Commitの負荷を分散する – ネットワーク伝送時間を減らす • ネットワーク距離、帯域（パケット詰まりの解消）、メッセージのサイズ – Peer、Ordererの処理性能（CPU／メモリ／IO） 74 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スケーラビリティとパフォーマンス：スループット • Validation/Commitの処理量はチャネルでのトランザクション数に依存 • Peerごとに所属するチャネルを分け、トランザクション数を平準化させる 75 Validation/Commitの負荷分散 Peer CH1 CH2 CH3 Block Peer CH1 Block Peer CH2 Peer CH3 Block Block 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スケーラビリティとパフォーマンス：スループット • Chaincodeでの役割分担：PeerごとにインストールするChaincodeを分けておく • チャネルでの役割分担：Peerごとに所属するチャネルを分けておく 76 Endorsement負荷分散：Peer側の役割分担 Peer CH1 CC1 CC2 CH2 Proposal Peer CH1 CC1 Peer CH2 CC1 Peer CH1 CC2 Peer CH2 CC2 Prop osal Prop osal Prop osal Prop osal 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スケーラビリティとパフォーマンス：スループット • クライアント側のTransaction Proposalの分散 • 候補のOrg、Peerから単純にラウンドロビンやランダムでリクエスト先を選ぶ • Chaincode／チャネルでの役割分担を依頼側で行うことも可能 • 他参加者も同様のリクエスト戦略で行わないと平準化できない 77 Endorsement負荷分散：クライアント側のリクエスト戦略 Peer Peer Peer Peer Peer Peer Peer Peer 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スケーラビリティとパフォーマンス：スループット • 単一のステート（単一のKeyに対するValue）を更新するトランザクションの間 隔はEndorsement～Commitまでの間隔以下には短くならない – ValidationでステートがChaincode実行時から更新されていないかの確認が行われ、更新 されていた場合Invalidになるため • 同一のステートを更新するトランザクションの密度が濃いと、Invalidになるトラン ザクションが増えて結果的にスループットが悪化する • 台帳内の整合性を確保できる範囲でステートを分割できないか検討 78 単一ステートに対するトランザクションのスループット追及上の限界 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | まとめ＆Oracle Blockchain Platformのご紹介 79 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 本日のテーマ： Hyperledger Fabricのアプリケーション設計入門 本日喋った内容 • Introduction • Hyperledger Fabricについて抑えておくべき基本 • ネットワークとアプリケーションのあり方 • アプリケーション設計のポイント 資料だけ公開 • Hyperledger Fabricのトランザクション詳細 • Chaincode Taboos & Tips • Etc. 80 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 本日みなさんが考えられるようになった（はずの） 「Hyperledger Fabricのアプリケーション設計」 81 Peer Chaincode Ledger アプリ データ ストア 既存 システム Peer 他参加者 アプリ Peer 他参加者 アプリ 

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にレプリケーション：大量照会、分析用途 82 Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとして提供 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Berkeley DB（BDB）の採用でパフォーマンス＆クエリを強化 Oracle Blockchain Cloud ServiceはState DBとして Berkeley DBを採用 ※標準のHLFではLevelDB or CouchDB • パフォーマンスの向上 – スマートコントラクトの同時実行性の強化 • SQLリッチクエリのサポート – JSONの属性を指定してのSQL-Likeクエリが可能 – CouchDB形式のJSONクエリへの互換性も保持 • CouchDB適用時の技術的な問題の解決／回避 – リッチクエリ使用時のPhantom Read問題を解消 – 大量レコード取得時のPagination指定が不要に 83 ＋ ブロックチェーン： トランザクションと 値の履歴を格納 State DB （World State）： 現在の値を格納する データベース Hyperledger Fabricにおける 台帳（Ledger） … 以下ふたつから構成 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | リッチヒストリーデータベース • 台帳のデータをブロックチェーン外部のリレーショナルデータベースに複製 • 参照用途の他、ブロックチェーンが苦手とする大規模検索処理（集計、分析）を データベース側で実行可能 – 開発者が慣れ親しんだ、リレーショナルデータベースでの開発は容易 – Oracle Analytics Cloudをはじめとした多様なBIツールの利用 • 他システムとのデータ統合も容易に 84 Oracleデータベースにブロックチェーンのデータを複製 ＋ ブロックチェーン： トランザクションと 値の履歴を格納 State DB （World State）： 現在の値を格納 台帳（Ledger） 複製 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 85 豊富なREST API Framework – Transactions/Queries/Events Transactions and Queries Events • Get version (of REST proxy) • Query chaincode function • Get transaction ID • Invoke transaction synchronously • Invoke transaction asynchronously • Subscribe to event, event type: “transaction”: concerned with events on a particular transaction ID “txOnChannel”: returns a transaction object for every new transaction on a particular channel “txOnNetwork”: returns a transaction object for every new transaction in the entire network “blockOnChannel”: returns a block header for every new block on a particular channel “blockOnNetwork”: returns a block header on creation of a new block in the entire network “chaincodeEvent”: returns custom events emitted from chaincode • Unsubscribe event 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 86 豊富なREST API Framework – Admin/DevOps Channels Statistics Chaincodes Nodes Organizations • Create channel • Get channel list • Get channel list for chaincode • Get channel list for a peer • Update channel configuration • Get channel info • Get ledger block by block ID • Get blocks by ID range • Get blocks by time range • nodeResUsage (CPU, Mem, Disk) • nodeHealth • channelInfo • channelsJoined • chaincodeInstalled • chaincodeInstantiated • userTrans • billableTrans • Endorsements • Commits • Blocks • proxySyncInvocation • proxyAsyncInvocation • proxyConfiguredCC • Get list of installed cc’s • Get a list of chaincodes on a specific peer • Get list of chaincodes on a channel • Install chaincode • Instantiate chaincode • Get chaincode info • Get node list • Get a list of peers on a channel • Get a list of peers for a specific chaincode • Add a peer node • Start/Stop a peer node • Remove a peer node • Get/Set a peer node’s attributes • Join a peer to a channel • Export/Import peers • Start/Stop an orderer • Get/Set an orderer’s attributes • Start/Stop a CA node • Get/Set a CA’s attributes • Start/Stop REST proxy • Get/Set REST proxy’s configuration • Get org certificates • Get org admin credentials • Get ordering service setting in a founder org • Join a new org to a founder org • Set ordering service to a participant org 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 最新のデータベース、コンピュート、コンテナ、IoT、ビッグ・データ、API管理、 統合、チャットボット、その他の各種クラウド・サービスを、無料で体験して みませんか？ 無料トライアルのお申込方法の詳細は、QRコード、またはURLに アクセスしてください。 Oracle Cloud 最大 3,500 時間の 無料トライアル oracle.co.jp/tryit_dev 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 88 Oracle Code Tokyo 2019 Sheraton Miyako Hotel Tokyo 2019/5/17 10:00 – 18:00 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Appendix 1. Hyperledger Fabricのトランザクション詳細 89 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | • Endorsement： PeerがChaincodeを実行し、クライアントがEndorsementを集める • Ordering： ある期間内のTransactionの順序を確定し、ブロックを生成、配布する • Validation： PeerがTransactionが有効か検証し、更新内容を台帳にコミットする 90 トランザクションの3フェーズ：Endorsement、Ordering、Validation 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Endorsementフェーズ • クライアントアプリケーションがTransaction Proposalを1～nのPeerノード （Endorser）に送信する • Peerノードが指定されたChaincodeを実行 – 実行結果をここでは台帳にコミットしないため、仮実行、Simulationとも呼ばれる • PeerノードはProposal Response（RWセットとEndorsement）返却 • クライアントアプリケーションはRWセットを（他Peerのものと）比較 • Endorsement Policyを満たすだけのEndorsementが集まれば、（全Peerからの 応答を待たずとも）クライアントはOrderingフェーズに進むことができる 91 PeerがChaincodeを実行し、クライアントがEndorsementを集める 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Endorsement、Endorsement Policy、Endorser • Endorsement：EndorseしたPeerのID、署名（over RWSet） • Endorsement Policy：あるChaincodeのトランザクションを台帳に反映するため に、どのようなEndorsementを集めてこなければならないかを定める条件 （どうしたらコンセンサスが取れたことになるか） – Chaincode×チャネル単位で設定可能（Chaincode Instantiate/Update時に設定） – 単純なEndorsementの数による条件から重みづけまで、柔軟な設定が可能 – EndorsementはPeer単位ではなく、Org単位でカウントされる – 例：Org A,B,Cで構成されるネットワークの場合に、「3つのOrgのうち、任意の2つのOrg配 下の任意のPeerからEndorsmentの取得」といったような条件 • Endorser：Chaincodeを実行し、Endorseを行うPeer（コミットも行う） ⇔Chaincodeを実行せずコミットだけ行うPeer：Committer 92 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Endorsement Policyの例 AND、OR、OutOfの組合せで定義 • AND(‘Org1.member’, ‘Org2.member’, ‘Org3.member’) 全Org必須 • OR(‘Org1.member’, ‘Org2.member’) どっちかのOrgでOK • OutOf(2, ‘Org1.member’, ‘Org2.member’, ‘Org3.member’) いずれか2つOrg • AND(OR(‘Org1.member’, ‘Org2.member’), ‘Org3.member’) Org1かOrg2のどっちか + Org3必須 ※memberとadminはPeerのRole（Peerノード構築時に定義） 93 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | RWSet（Read-Write-Set） • かんたんに言うとChaincode実行のBefore/Afterの状態セット • EndorserがChaincodeを（仮）実行するなかで： – State DBから読み取った値があればそのKeyとバージョンのセット（Read-Set） – 台帳に書き込む（予定の）値があればそのKeyとValueのセット（Write-Set） • Read-Setはない場合がある（新規Keyインサートのトランザクション、Keyの現在 Valueを無視して更新を行うトランザクションなど） • Write-Setもない場合がある（参照トランザクション） 94 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Transaction Proposalメッセージの構造 95 SignedProposal { Proposal Proposal { ChannelHeader ChannelHeader { ChannelId string // 指定するチャネル ChaincodeName string // 指定するChaincode ChaincodeVersion string // Chaincodeのバージョン TxId string // トランザクションID（App側で生成 } SignatureHeader SignatureHeader {略} Args [][]byte // Chaincodeに与える引数 } Signature []byte // クライアントの署名 } 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Proposal Responseメッセージの構造 96 ProposalResponse { ProposalResponsePayload ProposalResponsePayload{ ProposalHash []byte // ProposalのHash値 ChaincodeName string ChaincodeVersion string RWSet []byte RV []byte // Chaincodeで明示的に指定した戻り値 } Endorsement Endorsement{ Endorser []byte // EndorseしたPeerのID Signature []byte // Payload＋Endorserに対しての署名 } } 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | RWSetの例 97 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Orderingフェーズ • クライアントがTransactionをOrdering Serviceに送信 • Ordering Serviceが、その前後で受け取った当該チャネルでのTransaction（あ れば）とともに1～nのTransactionを固めてブロックを生成 – このブロック生成時点でTransactionの順序が確定 • 生成したブロックを当該チャネルのすべてのPeerに配布 98 ある期間内のTransactionの順序を確定し、ブロックを生成、配布する 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Transactionメッセージの構造 99 Transaction { Payload Payload { ChannelHeader ChannelHeader {略} SignatureHeader SignatureHeader {略} TransactionAction TransactionAction { Args [][]byte // Chaincodeに与えた引数 ProposalResponsePayload ProposalResponsePayload {略} Endorsements []Endorsement {略} // 集めたEndorsementの配列 } } Signature []byte } 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Validationフェーズ • ブロックを受け取った各Peerは、含まれるTransactionそれぞれを検証する – Endorsement Policyを満たしているか（含：各Endorserの戻したRWSetの比較） – 各署名（クライアント、Endorser、Orderer）の検証 – Read-Setに含まれるKeyのバージョンが自身のState DBのそれと一致しているか …Chaincode実行時点で読み取られたKeyが、ここまでに更新されていないことをチェック • すべてのTxの検証後、ブロックを保存 – Valid/Invalidの判定結果はブロックのメタデータ部にも保存 • 合わせて、ValidのTxのみをState DBに反映（コミット） – ここで反映される値はWrite-Setに含まれるValueそのもの – Chaincodeを再実行して書き込んでいるわけではない 100 PeerがTransactionが有効か検証し、更新内容を台帳にコミットする 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | • Endorsement： PeerがChaincodeを実行し、クライアントがEndorsementを集める • Ordering： ある期間内のTransactionの順序を確定し、ブロックを生成、配布する • Validation： PeerがTransactionが有効か検証し、更新内容を台帳にコミットする 101 まとめ トランザクションの3フェーズ：Endorsement、Ordering、Validation 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Validation補足：Read-SetのValidation • Read-Setに含まれるKeyのバージョンが自身のState DBのそれと一致しているか …Chaincode実行時点で読み取られたKeyが、ここまでに更新されていないこ とをチェック • これは一種のトランザクション保護 • 残高の二重使用といったケースを防ぐことができる 102 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Read-Set Validationで防げる残高の二重使用の例① • 物の所有権をHLFの台帳上で管理しており、初期状態は以下とする 103 Item ID (Key) Owner (Valueの一部) Item1 Alice Item2 Bob Item3 Carol • この状態からふたつの更新トランザクションを間を置かずに発行する –Tx1 :Aliceがitem1をBobに譲渡する –Tx2 :Aliceがitem1をCarolに譲渡する 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Read-Set Validationで防げる残高の二重使用の例② • トランザクションが以下の時系列で処理されると、 E2 の段階では二重使用が発 生するが、 V2 でのRead-Set ValidationによってTx2 がInvalidと判定される – Tx1 のEndorsementをE1 、ValidationをV1、 Tx2 も同様にE2 とV2 とし、OrderingをOと表記 104 E1 E2 O V2 V1 Item ID 初期状態～V1前まで V1後 V2後 Item1 Alice Bob Bob 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | CouchDBのPhantom Read問題：説明① • Read-Set Validationでチェックしているのは、台帳の中のクエリ条件に当ては まったレコードが、EndorsementフェーズからValidationフェーズまでで更新されて いないこと • Q.クエリ条件に当てはまらなかったレコードはチェックしなくてもよいのか？ • A.よくない。チェックするべきである。 – Endorsementフェーズで（Chaincodeの中で）実行されたクエリを、Validationフェーズで再 実行し、クエリ結果が変わっていないことを確認するべき 105 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | CouchDBのPhantom Read問題：説明① • HLFではEndorsement・Ordering・Validationコンセンサスモデルをとっており、更 新トランザクションの場合、基本的な流れは以下となる – Endorsement：Chaincodeを実行し、更新するレコードを抽出したうえで、そのRead/Write の値セット（更新前後の値）を採取 ※ここではコミットしない – Ordering：トランザクションの順序を決定 – Validation：Read値がEndorsement時から変更されていないか検証したうえで、Write値 を台帳にコミット • 「どのレコードを更新すべきか」の決定がEndorsement時に行われるが、 EndorsementとValidationの間に他のトランザクションによるコミットが入る場合が あるため、Validationでは更新すべきレコードセットを確認するためにクエリを再実 行するべきである 106 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | CouchDBのPhantom Read問題：説明② • State DBがLevelDBの場合、Validation時にクエリが再実行される – 再実行時に抽出したレコードセットとEndorsement時に抽出したレコードセットが異なる場 合にはトランザクションはinvalidと判定され、コミットは中止される • State DBがCouchDBであり、かつ、更新すべきレコードセットの抽出にリッチクエリ を使用している場合、Validation時にリッチクエリは再実行されない – これにより後述の例で説明するような「取りこぼし」が生じる可能性がある – 現状HLFではこのCouchDBのPhantom Read問題は解決が困難であるとして、更新を伴う トランザクションでのリッチクエリ使用上の制約として扱われている 107 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | CouchDBのPhantom Read問題：事象の例① • 物の所有権をHLFの台帳上で管理しており、初期状態は以下とする 108 Item ID (Key) Owner (Valueの一部) Item1 Alice Item2 Bob Item3 Carol • この状態からふたつの更新トランザクションを間を置かずに発行する –Tx1 :Carolの持ち物をすべてAliceに譲渡する –Tx2 :Aliceの持ち物をすべてBobに譲渡する • State DBとしてCouchDBを使用しており、Owner値による更新すべきレコードの 抽出にはリッチクエリを使用する前提とする 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | CouchDBのPhantom Read問題：事象の例② • まずCarolの持ち物をすべてAliceに譲渡したのちにAliceの持ち物をすべてBobに 譲渡したいので、Tx1 とTx2 の実行後の期待される結果は以下 109 • しかしCouchDBではPhantom Read問題により以下の結果になる場合がある Item ID 初期状態 中間状態（Tx1後） 結果（Tx2後） Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Bob Item ID 初期状態 中間状態（Tx1後） 意図しない結果 Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Alice 取りこぼし 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | CouchDBのPhantom Read問題：事象の例③ • トランザクションが以下の時系列で処理されると意図しない結果が発生する – Tx1 のEndorsementをE1 、ValidationをV1、 Tx2 も同様にE2 とV2 とし、OrderingをOと表記 110 E1 E2 O V2 V1 Item ID 初期状態～V1前まで V1後 V2後 Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Alice 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | CouchDBのPhantom Read問題：事象の例④ • V2 でAliceの持ち物であるにもかかわらず、Item3の取りこぼしが生じている • 更新レコードを決定するE2 時点でAliceの持ち物ではなかったため 111 E1 E2 O V2 V1 Item ID 初期状態～V1前まで V1後 V2後 Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Alice 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | CouchDBのPhantom Read問題：事象の例⑤ • Tx2 での更新対象はItem1のみであり、Item3はTx2 の更新対象ではないため、 V2 でのRWセットの検証にはItem3は含まれず「取りこぼし」は検知できない 112 E1 E2 O V2 V1 Item ID 初期状態～V1前まで V1後 V2後 Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Alice V2 Validation 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | CouchDBのPhantom Read問題：説明② • State DBがLevelDBの場合、Validation時にクエリが再実行される – 再実行時に抽出したレコードセットとEndorsement時に抽出したレコードセットが異なる場 合にはトランザクションはinvalidと判定され、コミットは中止される • State DBがCouchDBであり、かつ、更新すべきレコードセットの抽出にリッチクエリ を使用している場合、Validation時にリッチクエリは再実行されない – これにより後述の例で説明するような「取りこぼし」が生じる可能性がある – 現状HLFではこのCouchDBのPhantom Read問題は解決が困難であるとして、更新を伴う トランザクションでのリッチクエリ使用上の制約として扱われている • Oracle Blockchain PlatformではState DBとしてBerkeley DBを採用しており、リッ チクエリを使用する場合もValidation時にクエリが再実行される – 「取りこぼし」は検知可能なため、更新トランザクションでもリッチクエリ使用可 113 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Appendix 2. Chaincode Taboos & Tips 114 Confidential – Oracle Internal 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ステートマシン • 現在の状態（State）と入力条件によって次の状態に遷移 • 入力条件とはたとえば処理内容（e.g. 起動する、停止する、値を増やす／減 らす）や、処理内容に対して外部から与えられる引数（e.g. いくつ値を増減す る） 115 State n State n+1 入力（処理）X 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 分散台帳とステートマシン • ノードそれぞれが持つ台帳は独立したステート • それぞれのノード上でトランザクションを処理してステートが遷移 • 分散／独立しているが一致したステートを実現するのが分散台帳 116 Staten Staten+1 Tx ノード Staten Staten+1 Tx ノード Staten Staten+1 Tx ノード Staten Staten+1 Tx ノード 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | スマートコントラクトとステートの一致 • 分散／独立したステートを一致させるにはどうすればよいか？ • 前提として、ステートを更新する方法、条件を予め合意し共有しておく – 予め合意していることをもってシステム化された「契約」とみなせるため スマートコントラクトと呼ばれる – ステートは契約の履行の結果を記した台帳ということになる • そのうえで、全ノードで一致したステートを保持する方法はふたつ – 全てのノードがそれぞれスマートコントラクトを実行してステートを遷移させる – 一部（単一または複数）のノードでスマートコントラクトをシミュレーション実行し、 事後状態となるステートを伝播する • Hyperledger Fabricのコンセンサスモデルはこちら（EndorsementでSC実行 ⇒ Orderingでブロック配布 ⇒Validationでコミット） 117 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Chaincodeの決定論－性 • Chaincodeにはそのインプットとして常に台帳の現在ステートとクライアントからの 入力値（引数）が存在する • 複数ノードでそれぞれChaincodeが実行された結果に含まれる事後ステート＝ Write-Setが同一になっていないとならない – 異なるWrite-Setを集めてきてもEndorsement Policyを満たさない • すなわち、同一インプットからは同一の事後ステートが導かれるようにしておく 必要がある • この条件を満たすChaincodeをdeterministic（決定論的）であると呼び、 そうでないものをindeterministic（非-決定論的）と呼ぶ • Chaincode内に非－決定論的なロジックを作り込んではならない 118 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 非－決定論的なロジックの例 • GUIDの生成などのためにランダムな値を生成する処理（UUID ver4など）を 使いたくなるが、当然複数ノード間で一致しなくなるのでNG • 代替としてステート内にシードを用意しておき、そこから決定論的に生成する処 理を利用する（UUID ver3など）、あるいはクライアント側で生成してから渡す 119 ランダムな値の生成 P L CC P L CC ≠ 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 非－決定論的なロジックの例 • Chaincode内でノードのローカル日時を取得して利用するのは、 他のノードと必ずしも一致しなくなるのでNG – 時刻同期が不完全なことによるズレ – Chaincodeの実行タイミングのズレ • 「現在」の日時はクライアント側で決定してから渡すしかない • これはつまり、特別な手段を講じない限り「現在」日時はコンセンサスの外部とい うこと 120 ノードのローカル日時の利用 P L CC P L CC ≠ 12:00:00 12:01:23 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal 日時に関する補足 121 • ブロック内のトランザクションデータ（トランザクション履歴）として保存されている タイムスタンプもクライアントアプリケーションで決定しているもの • 必ずしもクライアントが正しいタイムスタンプを渡すとも限らない • トランザクション履歴を利用する際には、順序付けなどにこのタイムスタンプを使 用してはならない 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 非－決定論的なロジックの例 • Chaincodeから台帳の外部にある情報を取得しようとすると、各ノードで個別に 取得した結果が一致することを保証するのは困難 – Chaincodeの実行タイミングによって違う値が返ってくる、あるいは取得できない可能性 – 外部ハッキングあるいはノード所有者によって不正な値を取得させられてしまう可能性 • なお、ノードのローカル時刻も「台帳の外部に存在する情報」の一種 122 （クライアントから渡される値以外の）台帳の外部に存在する情報の利用 P L CC P L CC ≠ 天気予報 60% 40% 明日の降水確率 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 外部情報の利用に関する補足 • 例えばスポーツ賭博や予測市場などのサービスをブロックチェーン／分散台帳で 実現しようとしたときに、現実世界の情報（試合結果や値動き）が必要 • クライアントアプリケーションから渡すことにすると、都合良く偽れてしまう • スマートコントラクトからネットワーク外部の情報にアクセスしてコンセンサス内で 取得してこないとならない • このような要求に対して、中立かつ信頼できるかたちでネットワーク外部の情 報を提供するサービスをオラクル（Oracle、託宣）と呼ぶ • オラクルが確定した（不変の）情報を自身の署名付きで提供することで、偽 装や改ざんが不能でコンセンサスに取り入れられる外部情報が利用できる – しかし署名の検証をどう行うかまで考慮が必要となるなど、オラクル利用はすごく難しい 123 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Chaincode Tips • 単一チャネル上で複数Chaincodeを稼働させることが可能 • あるChaincodeが台帳に書き込んだレコードは、そのChaincodeからしかアク セスできない – Chaincode A on Channel Xが書き込んだレコードは、Chaincode B on Channel Xからは アクセスできない – State DB上の現在ステートおよびブロックチェーン上のキー履歴、トランザクション履歴のいず れにもこの制約がある • Chaincodeから同一チャネル内の別のChaincodeを呼び出すことは可能 – Chaincode A on Channel X⇒Chaincode B on Channel Xは可能 • 単一トランザクションとなり、ステート、RWSetも共有している 124 単一チャネル上での複数Chaincodeの相互呼び出し 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Chaincode Tips • Chaincodeはチャネルごとにインスタンス化（Instantiate）され稼働しており、 呼び出し（Invoke）する際もチャネルを指定して呼び出し実行させる • あるチャネルでInvokeされたChaincodeから他のチャネルの更新トランザクショ ンを実行することはできない – Chaincode A on Channel XからChaincode B on Channel Yを呼び出してChannel Yの台帳 をクエリすることは可能だが、更新は不可 • チャネルごとに台帳が存在する、つまりチャネルが異なれば別の台帳であり、 ステートおよびトランザクションは共有していないということに留意が必要 – Chaincodeから他のチャネルのChaincodeを呼び出してクエリした際にタイミングマターが生じ、 複数Peer間でのクエリ結果が異なる可能性 125 クロスチャネルのChaincode呼び出しに関わる制約 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Chaincode Tips • クライアント側で複数チャネルのChaincodeを並列にInvokeすることは可能 • ただし複数チャネルをまたぐアトミックトランザクションは実現できない – そもそもHLF内のトランザクションはロールバックできず、したがって2フェーズ／3フェーズコミッ トなどの分散トランザクション制御の仕組みも適用できない • トランザクション順序はチャネルごとにしか保証されない点には留意 – 複数チャネルのChaincodeを並列にInvokeした場合、それぞれのチャネルでステートに反映 される順序は保証されないということ • あるチャネルのトランザクション事前＆事後ステートに依存して別のチャネルでの トランザクションを並列実行すると、同時に他のクライアントが逆の依存関係で 並列実行していた場合にハマるパターンがある 126 複数チャネルでのトランザクション並行起動時の注意 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Chaincode Tips • Chaincodeから台帳のブロックチェーン部分に記録されているキー履歴、トランザ クション履歴を利用することができる • が、これらの履歴はValidationでのトランザクション保護に含まれない – State DBにある現在ステートはEndorsementフェーズでのChaincode実行時点～ ValidationでのコミットまでにRead-Setのバージョンが更新されていないか、Phantom Readが 生じていないかをチェックされるが、履歴についてはチェックされない • クライアントアプリケーション側で安全を保証できない限りは、台帳を更新するト ランザクション内でのChaincodeで履歴を利用することは避ける 127 更新トランザクションでのキー履歴、トランザクション履歴の利用 

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 128 

129