OCHaCafe #4 Hyperledger Fabric

‸ 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.

| 自己紹介 •中村岳 @gakumura • 現職：ソリューションエンジニア@日本オラクル • 前職：金融決済系SIer • 好きなOS：AIX • 好きなスタンド：クレイジー・D

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

| 「Hyperledger Fabricのアプリケーション設計」 •なんだかむずかしい・・・ •なにがむずかしいのかもよくわからない・・・ •Fabric覚えること多すぎ・・・ •情報がない・・・ 5

| ネットワーク一般的な「アプリケーション設計」で考える必要のある範囲 6 なんらかのフレームワークなんらかのミドルウェアアプリケーションロジックとか UIとかなんらかのインフラなんらかのデータストア

| 「Hyperledger Fabricのアプリケーション設計」で考える必要のある範囲 7 Peer Chaincode Ledger アプリデータストア既存システム Peer 他参加者アプリ Peer 他参加者アプリ

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

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

| Hyperledger Fabricについて抑えておくべき基本 10

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

| 代表的なブロックチェーン/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

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

| • 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のお勉強要素赤字：理解が必須の基礎知識青字：知ってると便利、応用編それ以外：必要に応じて学ぶ

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

| 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

| 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を共有する範囲

| 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がある通常、企業などのコンソーシアムに参加する組織と対応する

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

| 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” }

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

| 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のみ

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

| 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

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

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

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

| トランザクションフロー：図 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 – 台帳に書き込み

| 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

| 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

| 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

| 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後）

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

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

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

| ネットワークとアプリケーションのあり方 36

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

| 独占管理方式共同管理方式ノードの持ち方モデル 38 個別管理方式分散集中

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

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

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

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

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

| 共通API方式専用アプリ方式個別アプリ方式共通API 利用するアプリケーションのあり方 44 Peer Chaincode Ledger 個別アプリ Fabric SDK Peer Chaincode Ledger Fabric SDK API利用アプリ専用アプリ Peer Chaincode Ledger Fabric SDK 分散集中 ↑ コンソーシアムで合意／共有 ↓ ↑ 参加者が個々に開発

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

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

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

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

| アプリケーション設計上のポイント 49

| 設計上のポイント：以下についてHyperledger Fabricならではのポイントを紹介 • データ設計 • ロジック設計 • トランザクション設計 • Endorsement Policy設計 • スケーラビリティとパフォーマンス 50

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

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

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

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

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

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

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

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

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

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

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

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

| 正常系 63

| 異常系① Proposalでエラー 64

| 異常系②： Validationでエラー 65

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

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

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

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

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

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

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

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

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

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

| スケーラビリティとパフォーマンス：スループット • 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

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

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

| まとめ＆Oracle Blockchain Platformのご紹介 79

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

| 本日みなさんが考えられるようになった（はずの）「Hyperledger Fabricのアプリケーション設計」 81 Peer Chaincode Ledger アプリデータストア既存システム Peer 他参加者アプリ Peer 他参加者アプリ

| Oracle Blockchain Platform Cloud Service • 数ステップで構築完了、GUIコンソールで管理・運用も容易 • Oracle以外のHyperledger Fabricともオープンに連携 • State DBとしてBerkeley DBを利用 –パフォーマンス向上 –Phantom Read問題の回避 • 多機能なREST API：Cheincode呼び出しや各種設定・管理 • 台帳を外部のRDBにレプリケーション：大量照会、分析用途 82 Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとして提供

| 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） … 以下ふたつから構成

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

| 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

| 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

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

| Confidential – Oracle Internal/Restricted/Highly Restricted 88 Oracle Code Tokyo 2019 Sheraton Miyako Hotel Tokyo 2019/5/17 10:00 – 18:00

| Appendix 1. Hyperledger Fabricのトランザクション詳細 89

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

| 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を集める

| 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

| 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

| 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

| 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 // クライアントの署名 }

| 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に対しての署名 } }

| RWSetの例 97 <TxReadWriteSet> <NsReadWriteSet name="chaincode1"> <read-set> <read key="K1", version="1"> <read key="K2", version="1"> </read-set> <write-set> <write key="K1", value="V1”> <write key="K3", value="V2”> <write key="K4", isDelete="true" > </write-set> </NsReadWriteSet> <TxReadWriteSet>

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

| Transactionメッセージの構造 99 Transaction { Payload Payload { ChannelHeader ChannelHeader {略} SignatureHeader SignatureHeader {略} TransactionAction TransactionAction { Args [][]byte // Chaincodeに与えた引数 ProposalResponsePayload ProposalResponsePayload {略} Endorsements []Endorsement {略} // 集めたEndorsementの配列 } } Signature []byte }

| 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が有効か検証し、更新内容を台帳にコミットする

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

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

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

| 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

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

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

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

| 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値による更新すべきレコードの抽出にはリッチクエリを使用する前提とする

| 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 取りこぼし

| 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

| 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

| 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

| 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

| Appendix 2. Chaincode Taboos & Tips 114 Confidential – Oracle Internal

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

| 分散台帳とステートマシン • ノードそれぞれが持つ台帳は独立したステート • それぞれのノード上でトランザクションを処理してステートが遷移 • 分散／独立しているが一致したステートを実現するのが分散台帳 116 Staten Staten+1 Tx ノード Staten Staten+1 Tx ノード Staten Staten+1 Tx ノード Staten Staten+1 Tx ノード

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

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

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

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

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

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

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

| 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の相互呼び出し

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

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

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

| 128

OCHaCafe #4 Hyperledger Fabric

OCHaCafe #4 Hyperledger Fabric

More Decks by gakumura

Other Decks in Technology

Featured

Transcript