Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Blockchain GIG#11 開発 Hyperledger FabricアプリとChaincode / developing-hyperledger-fabric-application-and-chaincode

4b09160b087e45103b210ef95079cee4?s=47 gakumura
December 08, 2021

Blockchain GIG#11 開発 Hyperledger FabricアプリとChaincode / developing-hyperledger-fabric-application-and-chaincode

2021/12/8 Blockchain GIG#11でしゃべった内容
Hyperledger Fabricのクライアントアプリケーション、Chaincodeを開発する際に知っておきたいこと

4b09160b087e45103b210ef95079cee4?s=128

gakumura

December 08, 2021
Tweet

More Decks by gakumura

Other Decks in Technology

Transcript

  1. Blockchain GIG #11 開発! Hyperledger FabricアプリとChaincode!! 中村 岳 日本オラクル株式会社 2021/12/8

  2. 中村 岳 Twitter @gakumura はてなブログ @gakumura …主にHyperledger Fabric関連 • 現職:ソリューションエンジニア@日本オラクル

    • 担当:Oracle Blockchain Platform、Blockchain Table • 前職:金融決済系SIerでパッケージ開発 • 最近はウマ娘を… Copyright © 2021 Oracle and/or its affiliates 2
  3. Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとオンプレミスで提供 • GUI • • • Oracle • State

    DB Berkeley DB Hyperledger Fabric Phantom Read • REST API • RDB Oracle Blockchain Platform Copyright © 2021 Oracle and/or its affiliates DC 3
  4. • Hyperledger Fabric v2.2系ベースのインスタンスが作成可能に • 以下を含むv2.x系での改善を利用可能 • 新しいChaincodeライフサイクル • Chaincodeのパッケージと定義の分離による、より柔軟なデプロイプロセス

    • より柔軟な秘匿と共有パターンを可能にするPrivate Data Collectionの機能強化 • インスタンス作成時にv1.4系ベースとv2.2系ベースから選択 • 新規ユーザーはv2.2系ベースのインスタンスの作成を推奨 • 既存OBPユーザーは継続してv1.4系ベースのインスタンスも作成可 • v2.2系とv1.4系は同一ネットワークに混在不可 Oracle Blockchain Platformアップデート: Hyperledger Fabric v2.x系に対応 Copyright © 2021 Oracle and/or its affiliates 4
  5. • 今度こそわかる!Hyperledger Fabric(再)入門 • Hyperledger Fabricを構成する基本的な要素 • トランザクションフロー • ChannelとPrivate

    Data • 使いこなす!実践Hyperledger Fabric • 設計の前提を整理する • Hyperledger Fabricのネットワーク構成を設計する • 開発!Hyperledger FabricアプリとChaincode!!←この資料 • Chaincodeの開発 • クライアントアプリケーションの開発 Blockchain GIG; Hyperledger Fabricを学ぼうシリーズ Copyright © 2021 Oracle and/or its affiliates 5
  6. • はじめに:基本の復習 • Chaincodeの開発 • クライアントアプリケーションの開発 • アプリケーションが考慮すべき複数データストア間 の整合性 ※なお、文中のHLF=HyperLedger

    Fabric 資料の内容 Copyright © 2021 Oracle and/or its affiliates 6
  7. Copyright © 2021 Oracle and/or its affiliates はじめに:基本の復習 7

  8. Orderer Hyperledger Fabricネットワークの概観図 8 Peer Client App CA Chain Code

    Ledger Orderer A社 Orderer Peer CA Chain Code Ledger Orderer Orderer Orderer Peer Chain Code Ledger CA Orderer CA Orderer Peer Chain Code Ledger B社 D社 C社 Client App Client App Client App Copyright © 2021 Oracle and/or its affiliates
  9. 独特な点:ブロック生成専用のノードの分離と階層型アイデンティティの採用 Organization • ネットワークに参加するメンバーの 「組織」を表す抽象的な単位 • コンポーネントやユーザーが所属 Peerノード • 台帳(World

    StateとBlockchain)を保持 • Chaincodeをリクエストに応じて実行する Ordererノード • ひとつ~複数のOrdererノードでOrdering Serviceを構成 • トランザクションの順序を確定し、ブロック を生成しPeerノードに配布 Chaincode(スマートコントラクト) • 台帳の更新、照会のビジネスロジック クライアントアプリケーション • Hyperledger Fabricを利用するアプリ CA(Certificate Authority) • 各コンポーネントやユーザーのアイデンティ ティ(証明書)を発行するPKIの認証局 • 通常、Fabric CAを利用するが他の実装も利用 可能 登場する要素、コンポーネント 9 Copyright © 2021 Oracle and/or its affiliates
  10. ChannelはHLFの基礎の一部、Private Dataはオプショナル Channel ネットワークをサブネットワークに分割し、 トランザクションそのものの(すなわち、そこで 扱われるデータの)共有範囲を限定 Private Data Channel内で共有されるトランザクションのう ち、一部のデータ項目を更に範囲を限定して共有

    できる ChannelとPrivate Data L1 L2 L3 【お客様情報レコード】 “ID : 1234567890” “生年月日 : 1987年1月1日” “性別 : 男性” “名前 : 鈴木太郎” “住所 : 東京都千代田区X-X-X” “電話番号 : 080XXXXXXXX” “契約コース : 従量制A” “契約日時 : 2019/1/21” Channel内の 一部のメンバーのみ データを共有 (他のメンバーには 秘匿) Copyright © 2021 Oracle and/or its affiliates 10
  11. 流れと各フェーズの目的を理解しておく Endorsement:トランザクションの内容について合意する • クライアントアプリケーションからPeerにChaincode実行依頼(Transaction Proposal)を送付 • PeerノードがChaincodeを実行(※)し署名を付けて結果(Endorsement)を返却 • クライアントはEndorsement Policyで定められた必要な分のEndorsementを収集する

    (※)この時点では台帳に反映しないため「シミュレーション実行」と言われることもある Ordering:トランザクションの順序を確定しブロックを生成・配布する • Endorsementを集め終えたクライアントアプリケーションがTransactionを送付 • 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布 Validation:トランザクションの有効性を検証したうえで反映する • Peerがブロック内のTransactionを検証し台帳に反映(コミット) Endorsement・Ordering・Validationから成るトランザクションフロー Copyright © 2021 Oracle and/or its affiliates 11
  12. トランザクションフローの図 Copyright © 2021 Oracle and/or its affiliates 12 Peer

    Chain Code Ledger Client App Orderer Orderer Orderer Client App Client App Peer Chain Code Ledger Peer Chain Code Ledger 1 1.5 1.5 1 2 2 3 3.5 4 4 4 5 5 5 1)Transaction Proposal 送付 1.5)Chaincode 実行 2) Endorsement 返却 3)Transaction 送付 3.5)Block生成 4)Block配布 5)Validation →Commit 2.5) Endorsement 収集 2.5
  13. 13 From: https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html ①Transaction Proposal送付 (1.5)Chaincode実行 (2.5) Endorsement収集 ③Transaction送信 ④Block配布

    (5)Validation →Commit (※)Tx Event通知 ②Endorsement 返却 (3.5)Block生成 Copyright © 2021 Oracle and/or its affiliates
  14. Copyright © 2021 Oracle and/or its affiliates Chaincodeの開発 14

  15. • 所謂「スマートコントラクト」をHLFではChaincodeと呼んでいる • 別にコントラクト=契約を表現していなくてもよい(契約を表現していてもよい) • 単に「台帳の読み書きのロジック」と考えるとわかりやすい • 「RDBにおけるストアドプロシージャのようなもの」という説明もある • 台帳(のデータ)の更新の唯一の手段である

    • Chaincodeの関数がトランザクションの実行単位である • Chaincodeを経由せずに台帳を更新する(適切な)手段はない • 台帳の参照についてはいくつかバイパス手段がある • ブロックを直接見る、State DBを直接見る、外部DBに複製したデータを見る • ユーザーが開発する通常のChaincode(→User Chaincode)の他に、Chaincodeライフ サイクルやChannel設定などに関連したロジックを担うプリセットのSystem Chaincodeが存在する • System Chaincodeについては通常特に意識しないでOKなので本資料では触れず、 以降ではUser Chaincodeのみの話をします Chaincodeとは何か? Copyright © 2021 Oracle and/or its affiliates 15 Client App Fabric SDK Peerノード Ledger Chaincode
  16. • エンタープライズブロックチェーンでは、台帳のデータを通じて/データに基づいて複数組織がコ ミュニケーションする(組織間ワークフローを実行する) • Chaincodeはそのメッセージングインターフェースであり、同時に台帳のデータ構造定義とデータに 対してのロジックを担う • データ構造は概ね、組織/人を中心として所有するモノなどの属性の更新を表現していくアカウント 型のモデルと、モノを中心として状態の推移を表現していくアセット型のモデル、そして両者の組み 合わせいずれかになる

    • アカウント型の例:ある口座にいくら入っているか • アセット型の例:あるモノを今誰が持っているか • データ構造が決まった後に必要となるロジックを設計していく • データのライフサイクルを表現するためのCRUD操作 • 実装上および運用上のシステム的な都合で必要なロジック • Chaincode開発の前提としてHLFの構造、要素(アイデンティティ、Channel、Private Dataなど) とトランザクションフローのしっかりとした理解は必要 Chaincodeの役割と設計の流れ Copyright © 2021 Oracle and/or its affiliates 16
  17. • 各々が自身のPeerにInstallした後に、Channelで有効化することで実行可能に • 有効化の手続きはv1.x系とv2.x系で異なる(v2.x系ではオペレーションが一層分権化) • バージョンアップ可能:Chaincodeはバージョンアップできるため、稼働後も修正や改善が可能 • 新バージョンで旧バージョンのChaincodeが書いたレコードにもアクセスできる Chaincodeのライフサイクル Copyright

    © 2021 Oracle and/or its affiliates 17 Install 有効化 Upgrade 新バージョン のInstall 各Orgで行う ローカルな オペレーション ネットワークの オペレーション 新バージョン 稼働
  18. 運用上重要なものを含むが、Chaincodeの開発自体にはあまり関係ないかも 項目 内容 有効化とアップグレード の分権化 v1.4系ではChaincodeの有効化およびアップグレードを単一のOrgのオペレーションで行っていた。その ため、Chaincodeのパラメータ(Endorsement PolicyやPrivate Data Collection、Init関数の引数など)

    に他のOrgが関われなかった。 v2.x系の新ライフサイクルでは、パラメータ内容を含む有効化&アップグレードオペレーションについ て、予め複数のOrgからの承認が必要になった。 パラメータ設定更新方法 の改善 Chaincodeをインストールし直さなくてもEndorsement PolicyとPrivate Data Collectionのを更新するこ とが可能になった。 パッケージ概念の追加 v1.x系でのChaincode IDとバージョンの概念に加え、インストールモジュールの実体を指すパッケージ 概念が追加された(パッケージを単位としてインストールするようになった)。 また、インストールされた同一のパッケージを元に複数のChaincodeインスタンスを別のChaincode ID /バージョンを付与し、別のパラメータで同一Channelで稼働させることが可能になった。 ローカルカスタマイズが 可能に v2.x系では、各OrgでインストールするChaincodeのロジック内容(→パッケージの内容)が必ずしも一 致していなくてもよくなった。これにより、自Orgのみが使う参照用の関数の追加など、ローカルなカ スタマイズを行うことができるようになった。 Chaincode稼働環境の 柔軟化 v1.x系ではChaincodeインスタンスはPeerごと×Chaincode(&バージョン)ごとに作成されるDockerコ ンテナ上で稼働していた。v2.x系ではDockerコンテナ以外の稼働環境も選ぶことができるようになり、 また、必ずしもPeerごとの単位ではなく、外部サービスのかたちで稼働させて複数Peerから共用するこ とができるようになった。 参考:v2.x系でのChaincode関連の主要な変更 Copyright © 2021 Oracle and/or its affiliates 18
  19. • Chaincode開発言語の選択肢:Node.js、Go、Java • これらの言語で用意されたFabric Chaincode SDKを利用してChaincodeを 実装する • できることは基本的には変わらないので、お好みで選択 •

    いずれかのAPIを選択して実装する • fabric-contract-api(後から追加された高レベルAPI、現在の推奨) • fabric-shim(初期から存在する低レベルAPI) • 多くの場合、Chaincodeはそれほど複雑にも大規模にもならない • Ethereumにおけるスマコン(ERC、Open Zeppelin、etc.の学習が必須& データの持ち方と扱い方のお作法がだいぶ特殊)とは事情はかなり異なる ので、イメージに引きずられない • まずはHLFのGitHubのサンプルコーナー (https://github.com/hyperledger/fabric-samples)にあるChaincodeをいろ いろ眺めてみることを推奨 Chaincodeの実装 Copyright © 2021 Oracle and/or its affiliates 19 Peerノード Ledger Chaincode fabric-contract-api Client App Fabric SDK
  20. • Chaincode内に実処理を記述した関数を複数実装し、クライアントがトランザクションでどの関数を 利用するかを指定して呼び出すことになる • 関数の分岐はどちらのAPIを利用しているかによって書き方が異なる • fabric-shimを利用している場合、invoke()関数が単一のエントリーポイントになっており、invoke の処理の中で実処理を担う関数の呼び出しに分岐させる invoke(実処理関数名, [引数の配列])

    { if (実処理関数名 == hoge) {hoge([引数の配列])} if (実処理関数名 == fuga) {fuga([引数の配列])} ... } • fabric-contact-apiを利用している場合invoke()関数は不要で、実処理を担う関数の呼び出し分岐ま でAPI側でやってくれる • init()という名前で初期化関数を実装しておく必要がある • Chaincodeの有効化とアップグレードのトランザクションの中で呼び出される • init()内ではChannelの台帳のセットアップ的なことをやってもよいし、何もやらなくてもよい Chaincodeの実装お作法 Copyright © 2021 Oracle and/or its affiliates 20
  21. Peer Peerノードが保持する分散台帳の1コピー 復習:Hyperledger Fabricにおける「台帳」 21 • 台帳は以下ふたつの要素から構成される + Blockchain:履歴 •

    トランザクションの履歴が格納される ハッシュチェーンで連結されたブロックのファイル • 追記オンリーで蓄積していく World State:状態 • 各Keyに対する現在(最新)バージョンの値を保持 • レコードは更新、削除が可能 (履歴はBlockchainに残っている) • State DBと呼ばれるDBに格納される Ledger Peer Ledger Peer Ledger Peer Ledger Copyright © 2021 Oracle and/or its affiliates
  22. 台帳に保存される「現在の値(ステート)」とそれを保持するデータベース World StateはKey-Valueストアで、Valueには任意の文字列やバイナリを格納可能 • ChaincodeはWorld StateからKeyのValueを読み出し、書き込むことで 台帳上のデータに対してのビジネスロジックを表現する • State DBと呼ばれるデータベースに保持される

    通常のHLFではState DBにはLevelDBかCouchDBを選択可能 • LevelDB:シンプルなデータ構造を扱う場合向き(例:口座番号がKey/残高がValue) • Keyを指定するステート検索しかできない(単一指定or範囲指定) • CouchDB:複数の属性を持つValueを扱いやすい • JSON形式でValueを格納すると、Attributeを条件に指定して検索できる(リッチクエリ) • LevelDBに比べると低速な点、Phantom Read問題に係る制約には留意 復習:World StateとState DB 22 Copyright © 2021 Oracle and/or its affiliates
  23. ある程度柔軟なデータ構造を扱え、State DBによる検索の表現能力もそこそこ 復習:World Stateで扱うデータ構造の例 Copyright © 2021 Oracle and/or its

    affiliates 23 Key:口座番号 Value:残高 1020345 10,000,000 1020346 56,400 Key:アセット種別とID Value:アセット情報 car^aaa111 {“color”:”red”, “price”:10000, “owner”:”Bob”, “drive”:”front”} car^bbb222 {“color”:”blue”, “price”:30000, owner”:”Alice”, “drive”:”AWD’} bike^xyz345 {“color”:”green”, “price”:30000, owner”:”Alice”, “CC”:”1800’} シンプルなKey-Value構造:口座 複合キーとJSONを用いたKey-Value構造:アセット台帳 Keyの値を指定してValueを読み取る/書き込む 複合キーの利用や Key値の範囲指定のクエリも可 State DBにCouchDBを使いValueをJSONにしておくと リッチクエリが使える (例:ownerがAliceのアセットを全件取得)
  24. • Chaincodeを実装する際に利用する主な機能はSDKのChaincodeStubクラスにまとまっている • このクラスの内容(関数)を抑えておけば基礎の学習はだいたいOK • Go/Java/Node.jsのSDKで細かい関数の有無、関数名に差異(ここではNode.js基準で記載)があるが、実質 的にできることは同等。Node.jsのドキュメントは説明が多くてわかりやすい。 • 以下によく使う主要なものを抜粋して記載 Chaincode

    SDKの主要な機能① Copyright © 2021 Oracle and/or its affiliates 24 カテゴリ 関数 説明 引数 getArgs クライアントから渡された引数を取得する getTransient TransientMap(Transactionに載らない=Blockchain上に値が記録されない 特殊な引数)として渡された引数を取得する トランザクション 情報 getTxTimeStamp クライアントから渡されたTransactionのタイムスタンプを取得する getTxID クライアントから渡されたTransactionのID(ランダムなGUID)を取得する getMspId トランザクション発行者(クライアント)の所属Organizationを取得する getCreator トランザクション発行者のアイデンティティを取得する
  25. • 台帳操作系の機能のうち主要なものは以下(World Stateへの操作についてはPrivate Data用に同等の機能が存在す るが、ここでは一律割愛) • いずれも特に難しいところはないが、参照系はRead-Set Validationとの絡みで更新トランザクション内での利用に 制約がつくもの、注意が必要なものがある点は留意(後述) Chaincode

    SDKの主要な機能② Copyright © 2021 Oracle and/or its affiliates 25 カテゴリ 関数 説明 World Stateの 更新 putState 指定したKey、ValueのレコードをWorld Stateに書き込む(Keyが既にあればValueを上 書きする) deleteState 指定したKeyのレコードをWorld Stateから削除する 台帳の参照 getState 指定したKeyのValueをWorld Stateから取得する getStateByRange StartKey~EndKeyで指定した範囲のKeyのレコードをWorld Stateから検索し取得する getStateByPartial CompositeKey 複合Keyを持たせたレコードについて、複合Keyの前部分を指定し、前方一致でWorld Stateから検索し取得する getQueryResult State DBのデータベース実装が対応している構文でクエリを渡し、World Stateの検索 結果のレコードを取得する(例:CouchDBを利用→JSONリッチクエリ) getHistoryForKey 指定したKeyについての履歴(過去から現在のバージョンのValue、TxIDと TimeStamp)をBlockchainから取得する
  26. • ChaincodeはEndorsement Phaseの中で呼び出されてPeer ノードにより実行される • クライアントアプリケーションからPeerにChaincode実 行依頼(Transaction Proposal)を送付 • Chaincode関数の引数はここで渡す

    • PeerノードがChaincodeを実行し署名を付けて結果 (Endorsement)を返却 • 関数のレスポンスとRWSetが含まれる • クライアントはEndorsement Policyで定められた必要な分の Endorsementを収集する →Chaincodeは通常、複数のOrganizationの複数のPeerで冗長 に実行される • Peerの処理リソースはネットワークの共有資産 • Chaincodeの処理コストには敏感になったほうが良い 復習:トランザクションの中でのChaincodeの使われ方 Copyright © 2021 Oracle and/or its affiliates 26
  27. • 台帳上のデータを参照したいが台帳を更新する意図がない場合、クライアントアプリはEndorsement (に含まれるレスポンス)だけ受け取れば良いのでEndorsement Phaseまででトランザクションを終 わらせる(OrdererにTransactionメッセージを送信しない) • Fabric SDKにクエリ用APIとして用意されている • この場合冗長に実行させる必要はなく、ひとつのPeerにTransaction

    Proposalを送れば良い • v2.x系で可能になったローカルカスタマイズと組み合わせるといろいろ便利なこともできる • なお、参照した事実だけ記録するためにそのままOrdering Phaseまで進めることもできる • 参照はした(→Read-Setアリ)が更新しなかった(→Write-Setナシ)トランザクションとして Blockchainに残る • 参照の記録はクライアントアプリ次第なので、 強制できない点には留意 Tips: Chaincodeで台帳の参照だけを行う(更新を行わない) Copyright © 2021 Oracle and/or its affiliates 27
  28. 指針として、Chaincodeに何もかもやらせようとせず、できるだけシンプルなものに留めておいたほうがよい →Chaincodeに必須でないもの、向いていないものはクライアントアプリケーションロジックや、台帳データ複製先の データベースで引き取る やるべき • Chaincodeに必須なのはWorld StateとPrivate Dataの更新に関連する機能 • 更新の中で必要な参照機能(条件評価など)を含む

    • 基本的な(それほど複雑でない、規模の大きくない)クエリの機能もあって良い やらないべき • Chaincodeは複雑でコストの重い処理、広い範囲のデータを一括で読み書きする処理にはあまり向いていない • Endorsementでは複数Peerでロジックが冗長に実行される • State DBはRDBと同じようには使えない…大規模集計、分析は得意ではない • トランザクションフローの仕組み上、1トランザクションに大量のRWSetが含まれると他のトランザクション と衝突しやすく、結果的に処理性能に問題が発生しやすい • 必要な場合はバッチとして切り出し時間を区切るなどして他のトランザクションに影響を与えないように工夫する 何をChaincodeのロジックとして持っておくべきか? Copyright © 2021 Oracle and/or its affiliates 28
  29. • 前述の「複雑でコストの重い処理、広い範囲のデータを一括で読み書きする処理」以外にも Chaincodeロジックの設計あるいは実装にあたって注意が必要な以下の点を説明していく Chaincodeロジックの注意点 Copyright © 2021 Oracle and/or its

    affiliates 29 項目 要点 非-決定性ロジック 実行したPeer間で結果がバラバラになり得るロジックは作り込んではいけない 外部情報の参照(オラクル) Chaincodeから台帳の外部にある情報を見に行くのは難しい Read My Writes 今書いたValueはまだコミットされてないので読めない 更新トランザクション内での 一部クエリ機能の利用制約 一部のクエリ(World State、Private Data、Blockchainの検索)機能は Validationで検出されない不整合を起こし得るので更新トランザクションの中で の利用には注意が必要 Chaincode内Chaincode呼び出し Chaincode内から別のChaincodeを呼び出せるが、同一Channelでない場合は安 全でない、呼び出し先のChannelの更新もできない 同一レコードについての 更新スループット追及上の限界 トランザクションフローにおけるRead-Set Validationの関係で、同一のレコー ドを高密度で更新するユースケースが苦手
  30. ステートマシン • 現在の状態(State)と入力条件によって次の状態に遷移 • 入力条件とはたとえば処理内容(e.g. 起動する、停止する、値を増やす/減らす)や、処理内容に対 して外部から与えられる引数(e.g. いくつ値を増減する) 非-決定性 Staten

    Staten+1 入力(処理)X Copyright © 2021 Oracle and/or its affiliates 30
  31. 分散台帳とステートマシン • ノードそれぞれが持つ台帳は独立したステート • それぞれのノード上でトランザクションを処理してステートが遷移 • 分散/独立しているが一致したステートを実現するのが分散台帳 非-決定性 Staten Staten+1

    Tx ノード Staten Staten+1 Tx ノード Staten Staten+1 Tx ノード Staten Staten+1 Tx ノード Copyright © 2021 Oracle and/or its affiliates 31
  32. スマートコントラクトとステートの一致 分散/独立したステートを一致させるにはどうすればよいか? 前提として、ステートを更新する方法、条件を予め合意し共有しておく • 予め合意していることをもってシステム化された「契約」とみなせるため スマートコントラクトと呼ばれる • ステートは契約の履行の結果を記した台帳ということになる そのうえで、全ノードで一致したステートを保持する方法はふたつ •

    全てのノードがそれぞれスマートコントラクトを実行してステートを遷移させる • 一部(単一または複数)のノードでスマートコントラクトをシミュレーション実行し、 事後状態となるステートを伝播する • Hyperledger Fabricのコンセンサスモデルはこちら 非-決定性 Copyright © 2021 Oracle and/or its affiliates 32
  33. Chaincode(シミュレーション)実行のBefore/Afterの状態セット RWSet(Read-Write-Set)と呼ばれるトランザクションの仕組み上必要なデータと、 クライアントアプリケーションへの返り値がChaincode実行結果には含まれている RWSet:Chaincodeを実行するなかでの、 • World Stateから読み取った値があればそのKeyとバージョンのセット(Read-Set) • World Stateに書き込む(予定の)値があればそのKeyとValueのセット(Write-Set)

    HLFのトランザクションフロー上、以下のような意味を持っている • Read-Set:そのトランザクションが前提とした台帳の状態 • Write-Set:そのトランザクションが有効となった場合に書き込む値 復習:「Chaincode実行結果」とRWSet Copyright © 2021 Oracle and/or its affiliates 33
  34. あるTransactionがWorld Stateから読んだレコード、書き込む(予定の)値 <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> 復習:RWSetの例 ※バージョンの形式は単純化しており正確なものではない Copyright © 2021 Oracle and/or its affiliates 34 • K1とK2のレコードを読んでいる • それぞれバージョンは”1” • K1に”V1”という値を、K3に”V2”という値を それぞれ書き込もうとしている • K4のレコードを削除しようとしている
  35. Chaincodeの決定性がなぜ必要か • Chaincodeにはそのインプットとして常に台帳の現在ステートとクライアントからの入力値(引数) が存在する • 複数ノードでそれぞれChaincodeが実行された結果に含まれる事後ステート=Write-Setが同一になっ ていないとならない • 異なるWrite-Setを集めてきてもEndorsement Policyを満たさない

    • すなわち、同一インプットからは同一の事後ステートが導かれるようにしておく必要がある • この条件を満たすChaincodeをdeterministic(決定性の、決定的な)であると呼び、 そうでないものをindeterministic(非-決定性の、非-決定的な)と呼ぶ • Chaincode内に非-決定性のロジックを作り込んではならない 非-決定性 Copyright © 2021 Oracle and/or its affiliates 35
  36. 非-決定性ロジックの例:ランダムな値の生成 • Chaincodeの中でGUIDの生成などのためにランダムな値を生成する処理(UUID ver4など)を 使いたくなるが、当然複数ノード間で一致しなくなるのでNG • 代替としてステート内にシードを用意しておき、そこから決定的に生成する処理を利用する(UUID ver3など)、あるいはクライアント側で生成してから渡す 非-決定性 P

    L CC P L CC ≠ Copyright © 2021 Oracle and/or its affiliates 36
  37. 非-決定性ロジックの例:ノードのローカル日時の利用 • Chaincode内でノードのローカル日時を取得して利用するのは、 他のノードと必ずしも一致しなくなるのでNG • 時刻同期が不完全なことによるズレ • Chaincodeの実行タイミングのズレ • 「現在」の日時はクライアント側で決定してから渡すしかない

    • ⇨クライアント側で任意の値を渡すことができる(不正の余地がある) • これはつまり、特別な手段を講じない限り「現在」日時はコンセンサスの外部ということ 非-決定性 P L CC P L CC ≠ 12:00:00 12:01:23 Copyright © 2021 Oracle and/or its affiliates 37
  38. 日時に関する補足 非-決定性 Copyright © 2021 Oracle and/or its affiliates •

    ブロック内のトランザクションデータ(ト ランザクション履歴)として保存されてい るタイムスタンプもクライアントアプリ ケーションで決定しているもの • 必ずしもクライアントが正しいタイムスタ ンプを渡すとも限らない • トランザクション履歴を利用する際には、 順序付けなどにこのタイムスタンプを使用 してはならない 38
  39. 非-決定性ロジックの例:オンチェーンデータの外部に存在する情報の利用 • Chaincodeから(クライアントから渡されるもの以外の)オンチェーンデータ外部の情報を取得しよ うとすると、各ノードで個別に取得した結果が一致することを保証するのは困難 • Chaincodeの実行タイミングによって違う値が返ってくる、あるいは取得できない可能性 • 外部ハッキングあるいはノード所有者によって不正な値を取得させられてしまう可能性 • なお、ノードのローカル時刻も「台帳の外部に存在する情報」の一種

    非-決定性 P L CC P L CC ≠ 天気予報 60 % 40 % 明日の降水確率 Copyright © 2021 Oracle and/or its affiliates 39
  40. • 例えばスポーツ賭博や予測市場などのサービスをブロックチェーン/分散台帳で実現しようとしたと きに、現実世界の情報(試合結果や値動き)が必要 • クライアントアプリケーションから渡すことにすると、都合良く偽れてしまう • 不正があったことを後から追求可能ではあるので、それで問題ないユースケースならそれでよい • スマートコントラクトからネットワーク外部の情報にアクセスしてコンセンサス内で取得してこない とならない

    • 何も考えないで実装すると、外部サービスへのアクセスにインタラプトするMockを建ててそこか ら都合の良い情報を返す、などわりとかんたんに不正ができる • このような要求に対して、中立かつ信頼できるかたちでネットワーク外部の情報を提供するサービス をオラクル(Oracle、託宣)と呼ぶ • オラクルが情報を自身の署名付きで提供することで、偽装や改ざんが不能でコンセンサスに取り入れ られる外部情報が利用できる • しかし署名の検証をどう行うかまで考慮が必要となるなど、オラクル利用はけっこう難しい 安全な外部情報の利用(オラクル) Copyright © 2021 Oracle and/or its affiliates 40
  41. • Chaincodeの中でWorld StateまたはPrivate Data Collectionにデータを書き込み(PutState/ PutPrivateData)したあとに、同一Tx内で先程書き込んだデータを読み出そう(GetState/ GetPrivateData、あるいは各種クエリ)としても読み出せない(反映されていない) • 例:{Key, Value}=K1,

    V1のレコードにK1, V2を上書き(PutState)してからすぐGetStateすると取 得したデータはK1, V1のまま • 理由:台帳とPrivate Dataに更新が反映されるのはValidation/Commitフェーズなので • それまでは更新が反映されないので、さっき書いたものが読めない…”Can’t Read My Writes” • 対処法は一時格納用の変数を用意するだけなので簡単だが、知らないとたまにハマるので注意 Read My Writes Copyright © 2021 Oracle and/or its affiliates 41
  42. • HLFではValidationフェーズでのRead-Set ValidationによりMVCC(MultiVersion Concurrency Control)でのデー タ整合性、一貫性保護を行っている • また、一部のレンジクエリ機能はValidation時にChaincode実行時と同じ検索条件で再実行され、結果セット(の サマリ値)が変わっていないことを確認している→Phantom Readが検知される

    • 対象:getState(PrivateData)ByRange,getState(PrivateData)ByPartialCompositekey • Chaincode内で使えるクエリ機能のうち以下はValidationの検知スコープ外の挙動が発生する可能性があるため、 更新トランザクション内での利用には注意が必要(基本的には使用するべきではない) 更新トランザクション内での一部クエリ機能の利用制約 Copyright © 2021 Oracle and/or its affiliates 42 クエリ機能 問題点の説明 getHistoryForKey 履歴は読んでもRead-Setに載らないので、Validationフェーズま でにそのKeyに更新があっても検知できない ※ただしgetStateと併用していれば問題ないので回避は容易 getStateByRangeWithPagenation, getStateByPartialCompositeKeyWithPagenation, getQueryResult, getPrivateDataByRangeWithPagenation, getPrivateDataByPartialCompositeKeyWithPagenation, getPrivateDataQueryResult これらのレンジクエリ(検索結果としてゼロ~複数の結果セット を返すクエリ)は共通してValidationフェーズに再実行されない ため、Phantom Readの発生を検知できない →Phantom Read問題
  43. Tx2 • Read-Setに含まれるKeyのバージョンが自身の現在のWorld Stateのそれと一致しているか • 言い換えると、Chaincode実行時点(Endorsementフェーズ) で読み取ったレコードのValueが、Validation時点までに更新 されていないことをチェックしている Read-Set Validationの必要性:

    • HLFはあるトランザクションでStateをReadする時点とWrite/ Commitする時点が離れており、その間のロックもしていない • Read時点からWrite時点までにトランザクションの前提とした Stateの状態が変わってしまうケースがある • i.e. 他のトランザクションによって更新 • 前提が変わっている場合には検出してトランザクションを無効 にする必要がある 復習:Read-Set Validation Copyright © 2021 Oracle and/or its affiliates 43 World State <read key=“A", version=“3"> <write key=“A", value=“800”> Key Value Version A 0 4 不一致
  44. CouchDBでのリッチクエリでの例 リッチクエリとは • HLFではState DBとして利用しているデータベース側の機能を利用し、そのデータベースネイティブのクエリ文に よりWorld StateおよびPrivate Dataの検索を行うリッチクエリを利用することができる • getQueryResult、getPrivateDataQueryResultでクエリ文を渡す

    • KeyではなくValueの内容を検索条件に使えるのが非常に強力な点…ビジネスロジックの表現力の大幅な拡張 • どのようなリッチクエリを使えるかはState DBとして利用するデータベースに依存する • State DBにCouchDBを利用している場合、ValueをJSONにして格納しておくと、JSONの属性とその値を条件に指 定したクエリ(⇨JSONリッチクエリ)が利用可能 • 例:{“owner” : “Bob”, “color” : “Red”, “size” : “100” }というような項目を持ったmarbleアイテムに対して、 ownerがBobである、colorがRedでない、sizeが50より大きいといった条件で検索 Phantom Read問題にかかる制約 • リッチクエリを含む一部のレンジクエリはValidation時に再実行されない • 本来結果セットのレンジに入るべきレコードがEndorsement~Validationフェーズの間で追加、更新により増 えていても検知できない(Phantom Readの発生を検知できない) • ロジックの意図とデータの更新結果の不整合を起こす可能性があるため、(運用上の特別な考慮をしてPhantom Readの発生可能性を排除できない限り)更新トランザクションで使用してはならない Phantom Read問題 Copyright © 2021 Oracle and/or its affiliates 44
  45. 物の所有権をHLFの台帳上で管理しており、初期状態は以下とする CouchDBのPhantom Read問題:事象の例① Key: Item ID Value: JSON形式 Item1 {“owner”

    : “Alice”, “color” : “Blue”, “size” : “50” } Item2 {“owner” : “Bob”, “color” : “Red”, “size” : “100” } Item3 {“owner” : “Carol”, “color” : “Yellow”, “size” : “80” } • この状態からふたつの更新トランザクションを間を置かずに発行する – Tx1 :Carolの持ち物をすべてAliceに譲渡する…ownerがCarolのものをAliceに更新する – Tx2 :Aliceの持ち物をすべてBobに譲渡する…ownerがAliceのものをBobに更新する • State DBとしてCouchDBを使用しており、Owner値による更新すべきレコードの抽出にはリッチクエリ を使用する前提とする Copyright © 2021 Oracle and/or its affiliates 45
  46. まずCarolの持ち物をすべてAliceに譲渡したのちにAliceの持ち物をすべてBobに譲渡したいので、Tx1 と Tx2 の実行後の期待される結果は以下 CouchDBのPhantom Read問題:事象の例② しかしCouchDBではPhantom Read問題により以下の結果になる場合がある Item ID

    Owner初期状態 中間状態(Tx1後) 結果(Tx2後) Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Bob Item ID Owner初期状態 中間状態(Tx1後) 結果 Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Alice 取りこぼし Copyright © 2021 Oracle and/or its affiliates 46
  47. トランザクションが以下の時系列で処理されると意図しない結果が発生する • Tx1 のEndorsementをE1 、ValidationをV1、 Tx2 も同様にE2 とV2 とし、OrderingをOと表記 CouchDBのPhantom

    Read問題:事象の例③ E1 E2 O V2 V1 Item ID 初期状態~V1前まで V1後 V2後 Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Alice Copyright © 2021 Oracle and/or its affiliates 47
  48. • V2 でAliceの持ち物であるにもかかわらず、Item3の取りこぼしが生じている • Tx2 でのリッチクエリ結果にはItem3が含まれておらず、したがってRead-Set ValidationにItem3は含ま れず取りこぼしは検知できない • このようなパターンの不整合を検知するにはValidationフェーズでのレンジクエリの再実行が必要

    CouchDBのPhantom Read問題:事象の例③ E1 E2 O V2 V1 Item ID 初期状態~V1前まで V1後 V2後 Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Alice Copyright © 2021 Oracle and/or its affiliates 48 V2 Validation
  49. State DB Berkeley DB パフォーマンス&ロジック表現力を強化 • Oracle Blockchain PlatformではState DBとして独自に

    Berkeley DBを採用 • JSONをValueとして格納しておくと、ふたつの形式のリッチ クエリを利用可能 • CouchDB互換のJSONリッチクエリ • SQLリッチクエリ…集計関数も使える • Validation時にリッチクエリが再実行される • 再実行時に抽出したレコードセットとEndorsement時に抽 出したレコードセットが異なる場合にはトランザクション はinvalidと判定され、コミットは中止される • 「取りこぼし」は検知可能なため、更新トランザクション でもリッチクエリ使用可 【PR】Oracle Blockchain Platformのリッチクエリ改善点 Copyright © 2021 Oracle and/or its affiliates State DB World State Hyperledger Fabric Ledger ※通常のHyperledger Fabricでは、 State DBはLevelDBかCouchDB 49
  50. 単一ChannelでのChaincode呼び出し • 単一Channel上で複数Chaincodeを稼働させることが(ふつうに)可能 • ただし、あるChaincodeが台帳/Private Data Collectionに書き込んだレコードは、そのChaincodeからしか直接ア クセスできない • Chaincode

    A on Channel Xが書き込んだレコードは、Chaincode B on Channel Xからは直接にはアクセスでき ない • World State/Private Dataだけでなく、Blockchainから取得できるキー履歴、トランザクション履歴の参照に もこの制約がある • Chaincodeから同一Channel内で稼働する別のChaincodeを呼び出すことが可能 • Chaincode A on Channel X⇒Chaincode B on Channel Xは可能 • Chaincode A on Channel XがChaincode B on Channel Xが書き込んだレコードを参照/更新したいときは、 Chaincode Bを経由すれば参照/更新できる • ただし、実行するPeerには呼び出し元と呼び出し先両方のChaincodeがInstallされていることが必要 • 管理が煩雑になるので再利用性の理由のみなどでのChaincode分割は推奨しない • 単一Channel上であれば複数のChaincodeが絡んでも単一トランザクションとなり、RWSetも共有している Chaincode内Chaincode呼び出し Copyright © 2021 Oracle and/or its affiliates 50
  51. 別ChannelのChaincode呼び出しに関わる制約 • ChaincodeはChannelごとにインスタンス化(Instantiate)され稼働しており、呼び出し(Invoke)する際も Channelを指定して呼び出し実行させる • あるChannelでInvokeされたChaincodeから他のChannel上のChaincodeを呼び出し、台帳(およびPrivate Data) を参照することは可能だが、呼び出し先のChannelの台帳の更新を実行することはできない • Chaincode

    A on Channel XからChaincode B on Channel Yを呼び出してChannel Yの台帳をクエリした結果を Chaincode Aから利用することは可能だが、Channel Yの更新は不可ということ • Channelごとに台帳が存在する、つまりChannelが異なれば別の台帳であり、ステートおよびトランザクションは 共有していないということに留意が必要 • 整合性、一貫性を担保する仕組みはChannelごとにしか用意されていない/機能しない • Chaincodeから他のChannelのChaincodeを呼び出してクエリした際にタイミングマターが生じ、複数Peer間で のクエリ結果が異なる可能性がある Chaincode内Chaincode呼び出し Copyright © 2021 Oracle and/or its affiliates 51
  52. • トランザクションフローにおけるRead-Set Validationの関係で、同一の(Keyの)レコードを複数トランザクショ ンが一定以上の高頻度で更新することができないという制約がある • あるレコードを複数のトランザクションが高頻度に更新しようとする場合、Endorsement~Validationのターン アラウンドタイムより間隔が短いと無効になるトランザクションが出てくる • この制約が弱みになる苦手パターンがあることは覚えておいたほうがよい •

    典型的には「単一口座から高頻度で送金」のユースケース(支払いでマイナスにならないか現残高のチェック が必要)だとこれがネックになりやすい • なお、「単一口座に高頻度で入金」なら回避できる(現残高チェックはいらないので入金額を別のレコードで 記録しておき折を見て集計すればよい)ことにも留意 • 同一のレコードを更新するトランザクションの密度が濃いと、Invalid(Read Conflictエラー)になるトランザク ションの割合が増えて結果的にスループットが悪化する • 時々Invalidになること自体はクライアントがProposalから再トライすれば良いだけで問題ない • 密度が濃くInvalidが多発する場合、再トライも増えてますます密度が濃くなる悪循環に陥る 同一レコードについての更新スループット追及上の限界 Copyright © 2021 Oracle and/or its affiliates 52
  53. 同一レコードに対して頻繁に読み書きするとタイミング次第でしばしば発生する Read-Set Validationで無効になるパターンのシーケンス Copyright © 2021 Oracle and/or its affiliates

    53 レコード x Tx1 Tx2 Read(x) Read(x) RS-V (x) Write(x) RS-V(x) version=n version=n? OK version=n version=n? NG Endorsement Ordering Validation Endorsement Ordering Validation version=n+1
  54. スループット向上のための独自のトランザクション最適化 • Oracle Blockchain Platform付属の開発ツールBlockchain App Builder(後述)は Fungible Token(お金やポイントなどの数量で表されるアセット)のChaincode開発に も対応

    • 口座と残高からなるAccount/Balanceモデルで表現 • 生成、送付、分割、保留、破棄などの振る舞いをサポート • Hyperledger Fabricでトークンを扱う際に制約となる、トランザクションのMVCCに係る Read Conflictエラー多発問題を独自の改善で解消 • Blockchain App Builderで生成したトークンChaincode専用のオプションを有効化す るとMVCCを最適化し、スループットを改善 • 「Fungible Tokenの残高」に関しては通常のRead-Set Validationはバイパスし、特別な Validationを行う • オリジナルHyperledger Fabricでは苦手だった、同一口座の高頻度の入出金を含む ユースケースを扱うことが可能に 【PR】Oracle Blockchain PlatformのFungible Tokenの改善点 Copyright © 2021 Oracle and/or its affiliates 54 詳細は以下のブログを参照: https://blogs.oracle.com/blockchain/post/obptokenoptimization 54
  55. Chaincodeの開発、テスト、デプロイを容易にする開発補助ツール • Visual Studio Codeの拡張機能、およびCI/CD用のCLIツールとして提供 • Chaincodeの一連のライフサイクル(開発、パッケージング、デプロイ、アップデート)をサポート • ローカルなHyperledger Fabricネットワークを自動構成してデプロイ、テスト

    • Chaincodeのステップ実行によるデバッグが可能 • リモートのOracle Blockchain Platformにデプロイ、テストも可 • アセット仕様からChaincodeを自動生成 • 宣言的に記述アセットの属性とメソッドの仕様をもとに Chaincodeのコード、プロジェクトを自動生成 【PR】Blockchain App Builder Copyright © 2021 Oracle and/or its affiliates 詳細は以下のドキュメントを参照: https://docs.oracle.com/en/cloud/paas/blockchain-cloud/usingoci/using-chaincode-development-tools.html 55 55
  56. Chaincodeのオンチェーンアクセス権限制御ライブラリを提供 • ACLを台帳上に記載したうえで(On-chain ACL)、 ACLを参照してChaincodeロジックのアクセス制御する • Chaincode自体のアップデートをすることなく、 動的にACLを更新できるメリット 以下の要素で権限を制御 •

    リソース:アクセスを制御する対象 • アイデンティティ:アクセスする企業やユーザー • グループ:アイデンティティのグループ • アクセス制御リスト: • どのアイデンティティ/グループに • どのリソースに対し • どのような操作(CREATE、READ、UPDATE、DELETE、etc.)を • 許可する/しない 【PR】Fine Grained On-Chain Access Control Copyright © 2021 Oracle and/or its affiliates 詳細は以下のドキュメントを参照: https://docs.oracle.com/en/cloud/paas/blockchain-cloud/usingoci/using-fine-grained-access-control-library.html 56 56
  57. Fine-Grained Access Controlライブラリの利用イメージ Copyright © 2021 Oracle and/or its affiliates

    Ledger Chaincode Identity: O=OrgA, CN=UserA1 業務関数 ACL チェック FGAC ラ イ ブ ラ リ ACL管理 関数 業務データ ACL関連データ リソース グループ ACL Identity: O=OrgB, CN=UserB1 アクセス権限制御のため のデータを台帳上で管理 Chaincode関数内で 権限チェックを実施 Chaincode呼び出しの Identity(証明書)を組 織レベルやユーザーレベ ルでグループ化して制御 ACLの管理に関わる機能も関数として実装し、 ACL管理関数の権限もACLで管理 57
  58. • Chaincodeは台帳(のデータ)の更新の唯一の手段である • Chaincodeは台帳のデータを通じた複数組織間のコミュニケーションのメッセージン グインターフェースであり、同時に台帳のデータ構造定義とデータに対してのロジッ クを担う • Chaincode SDKを通じて実装する •

    開発言語はNode.js、Go、Javaが選べる • ChaincodeのSDKはそれほど難しくない • 多くの場合、Chaincodeはそれほど複雑にも大規模にもならない • 向いていない、できない、知らないとハマるなど、Chaincodeロジックの設計あるい は実装にあたって注意が必要な点は抑えておく Chaincodeまとめ Copyright © 2021 Oracle and/or its affiliates 58 Client App Fabric SDK Peerノード Ledger Chaincode
  59. Copyright © 2021 Oracle and/or its affiliates クライアントアプリケーションの開発 59

  60. • HLFの種々の機能を利用するアプリケーションのこと…… だが、主にはHLFのトランザクションを使うアプリケーションをクライアン トアプリケーションと呼んでいる(→トランザクションの主体である) • トランザクションにおいて以下の役割を担う • Peerノードに対してChaincode実行を依頼する • Peerノードから返ってきたEndorsementを集める

    • Ordering ServiceにTransaction(メッセージ)を送付する • クライアントアプリケーションは一般にHLFとのインタラクション以外にも 色々と役割を持たされるが、そのあたりは一般のアプリケーション開発の範 疇なのでここではあまり触れない クライアントアプリケーションとは? Copyright © 2021 Oracle and/or its affiliates 60 Client App Fabric SDK Peerノード Ledger Chaincode 証明書
  61. • クライアントアプリケーションは通常、Fabric SDKを用いて実装する • Fabric SDKはNode.js版とJava版が正式リリース • Node.js版:fabric-network パッケージを用いる…高レベルなAPI、現在の推奨 •

    低レベルなAPIはfabric-common パッケージ • Java版:Hyperledger Fabric Gateway SDK for Javaを用いる…高レベルなAPI、現在の推奨 • 低レベルなAPIはHyperledger Fabric SDK for Java • Node.js版とJava版のSDKでは細かい機能の有無や粒度、実装お作法などはだいぶ異なっているが、実 質的にできることはおおよそ同じ(※のはず…) • アプリケーション設計、実装にあたっての抽象的な概念(設計要素)は共通しているので、ここでは その要素の話をしていく クライアントアプリケーションの実装 Copyright © 2021 Oracle and/or its affiliates 61
  62. • クライアントアプリケーションは自身のOrganizationに所属するものだけではなく、他 Organizationに所属するPeerやOrdererともメッセージをやり取りする • 大前提としてネットワーク的にアクセス可能であること(疎通)が必要 • 認証のためにお互いにHLFのネットワーク上のアイデンティティが必要 • ネットワークコンポーネントの存在、所在の認識が必要 クライアントアプリケーションとHLFネットワークコンポーネントの関わり

    Copyright © 2021 Oracle and/or its affiliates 62
  63. 復習:メッセージのデジタル署名とその検証 Copyright © 2021 Oracle and/or its affiliates 63 Client

    App Orderer Orderer Client App Peer Peer MSP MSP MSP MSP • HLFの各種モジュール間でやり取りされるメッセー ジにはデジタル署名が付与されている • これにより、不正な送信者の介入や、メッセー ジ内容の中途での改ざんを防いでいる • 署名の検証は各コンポーネントの持つMSP (Membership Service Provider)というモジュー ルが担う
  64. Fabric SDKの主要要素:Wallet Copyright © 2021 Oracle and/or its affiliates 64

    from: https://hyperledger-fabric.readthedocs.io/ja/latest/developapps/wallet.html • クライアントアプリケーションが用いるHLFネットワーク上のユーザーアイデンティティの(抽象的な)ストア • 秘密鍵/証明書ペアにIDラベルを付けてWalletに追加し、以降そのIDラベルによってWalletからアイデンティティ を用いる • ファイルシステムWallet、インメモリWallet、CouchDB Walletの形態から選べる • 秘密鍵をHSMに格納することも可 • 秘密鍵/証明書ペアの作成/発行は Fabric CA Clientなどで予めやっておく (Walletのスコープ外)
  65. • クライアントからHLFのネットワークコンポーネント(Peer、Ordererなど)に対してメッセージを送る際に、 「どこにいるどのコンポーネントにメッセージを送信するか」を抽象化して管理してくれる要素 • あるChannelのあるChaincodeのトランザクションを実行したい場合、Channel参加有無、Chaincodeインス トール有無やEndorsement PolicyなどによってTransaction Proposal送信先のPeerの使い分けが必要で、 Gatewayがそのあたりをやってくれる •

    ネットワークコンポーネントからクライアントアプリケーションへのメッセージ受け取り(Eventなど)も管 理してくれる • Connection Profileの設定(YAMLまたはJSONで記述)に基づいて動作する • 動的なConnection Profile:最小限の設定を記述しておき、PeerのService Discovery機能により動的にネット ワーク構成情報(トポロジーやノードの死活、Channel参加有無、Endorsement Policy、Private Data Collection参加有無など)を取得する • 静的なConnection Profile:上記の全てのネットワーク構成情報を予め記載しておく • クライアントアプリケーションはTransaction Proposal(Chaincode実行依頼)送信先をGatewayの動的な制御 に任せることもでき、ネットワークの構成情報を取得したうえで自身で細かく指定することもできる • 現状ではトランザクションの中で触るPrivate Data CollectionやCollection-Level/State-Levelの細かい Endorsement Policyまでは動的には考慮してくれない模様なので、そのあたりを使う場合自身で指定してやる 必要アリ Fabric SDKの主要要素: Gateway Copyright © 2021 Oracle and/or its affiliates 65
  66. • トランザクションの一連のプロセスを抽象化し実行してくれる • EndorsementフェーズでのPeerへのTransaction Proposalメッセージの送信~Endorsementの収集 • OrderingフェーズでのOrdering ServiceへのTransactionメッセージの送信 • Validationフェーズでのトランザクション結果のEventメッセージ受け取り

    • 前提としてWallet(および用いるユーザーアイデンティティ)、Gatewayの構成をしたうえでContractを用いてト ランザクションを実行する • 台帳の更新を行うトランザクション用の関数と、クエリ用の関数が用意されている • 【Node.js】submitTransaction/【Java】createTransaction …台帳の更新とValidation結果の取得まで行う • 【共通】evaluateTransaction …Chaincodeの実行結果レスポンスの取得まで(台帳は更新されない) Fabric SDKの主要要素: Contract Copyright © 2021 Oracle and/or its affiliates 66
  67. public static void main(String[] args) throws IOException { // Load

    an existing wallet holding identities used to access the network. Path walletDirectory = Paths.get("wallet"); Wallet wallet = Wallets.newFileSystemWallet(walletDirectory); // Path to a common connection profile describing the network. Path networkConfigFile = Paths.get("connection.json"); // Configure the gateway connection used to access the network. Gateway.Builder builder = Gateway.createBuilder() .identity(wallet, "user1") .networkConfig(networkConfigFile); // Create a gateway connection try (Gateway gateway = builder.connect()) { // Obtain a smart contract deployed on the network. Network network = gateway.getNetwork("mychannel"); Contract contract = network.getContract("fabcar"); // Submit transactions that store state to the ledger. byte[] createCarResult = contract.createTransaction("createCar") .submit("CAR10", "VW", "Polo", "Grey", "Mary"); System.out.println(new String(createCarResult, StandardCharsets.UTF_8)); // Evaluate transactions that query state from the ledger. byte[] queryAllCarsResult = contract.evaluateTransaction("queryAllCars"); System.out.println(new String(queryAllCarsResult, StandardCharsets.UTF_8)); } catch (ContractException | TimeoutException | InterruptedException e) { e.printStackTrace(); } } Java Gateway SDKを用いた実装サンプル: Copyright © 2021 Oracle and/or its affiliates 67 from: https://hyperledger.github.io/fabric-gateway-java/release-2.2/
  68. // Connect to a gateway peer const connectionProfileJson = (await

    fs.promises.readFile(connectionProfileFileName)).toString(); const connectionProfile = JSON.parse(connectionProfileJson); const wallet = await Wallets.newFileSystemWallet(walletDirectoryPath); const gatewayOptions: GatewayOptions = { identity: 'user@example.org', // Previously imported identity wallet, }; const gateway = new Gateway(); await gateway.connect(connectionProfile, gatewayOptions); try { // Obtain the smart contract with which our application wants to interact const network = await gateway.getNetwork(channelName); const contract = network.getContract(chaincodeId); // Submit transactions for the smart contract const args = [arg1, arg2]; const submitResult = await contract.submitTransaction('transactionName', ...args); // Evaluate queries for the smart contract const evalResult = await contract.evaluateTransaction('transactionName', ...args); // Create and submit transactions for the smart contract with transient data const transientResult = await contract.createTransaction(transactionName) .setTransient(privateData) .submit(arg1, arg2); } finally { // Disconnect from the gateway peer when all work for this client identity is complete gateway.disconnect(); } Node.js fabric-network-apiを用いた実装サンプル: Copyright © 2021 Oracle and/or its affiliates 68 from: https://hyperledger.github.io/fabric-sdk-node/release-2.2/module-fabric-network.html
  69. • クライアントアプリケーションは通常、Fabric SDKを用いて実装する • Fabric SDKはNode.js版とJava版が正式リリース • 凝ったことをやろうとしなければSDKがよしなにやってくれる部分が多く、HLFでのトランザクショ ン実行部分の実装はさほど難しくない •

    Connection Profile設定の用意、ユーザーアイデンティティ(CAを利用した秘密鍵/証明書の作 成)の用意は必要 • 前提としてHLFの構造、要素(アイデンティティ、Channel、Private Dataなど)とトランザクショ ンフローのしっかりとした理解は必要 クライアントアプリケーションのFabric SDKを利用した実装まとめ Copyright © 2021 Oracle and/or its affiliates 69
  70. ノード ノード エンタープライズ領域でのユースケースの クライアントアプリケーションのイメージ Copyright © 2021 Oracle and/or its

    affiliates 台帳 Chaincode アプリ ケーション データベース 既存 データベース API ユーザー アプリ連携 データ統合 データ複製 集計・分析 ERP、SCM等 基幹システム ERP、SCM等 基幹システム ERP、SCM等 基幹システム 既存 データベース 既存 データベース HLF トランザクション 70
  71. • クライアントアプリケーション自体のビジネスロジック、UIなどの実装がもちろん必要 • 多くの場合、自身のローカルなデータストアを持つことになる • アプリケーションユーザーの認証…HLFのネットワークアイデンティティとは別の層(HLFでは一般的にエン ドユーザーごとにネットワークアイデンティティを割り当てることはしない) • 必要に応じて台帳からデータベースへのデータの複製を行う •

    集計、分析をデータベース上で行えるようになり、データの活用可能性が向上 • データ統合も容易になる • 別アプリケーション/システムとの連携 • エンタープライズのユースケースでは多くの場合、ERPやSCM、基幹システムとの連携が必要 • APIやインテグレーションツールを通じたアプリケーション連携 • 既存データとのデータ統合 • 関係先が増えると、HLF上のデータ(トランザクション)との整合性の考慮も必要に… • ChaincodeロジックおよびHLFトランザクション部分よりも、それ以外の側面のほうが開発ボリュームの割合は恐 らくだいぶ大きくなる • ので、一般的な(エンタープライズ領域の)アプリケーション/システム開発のスキルも重要 クライアントアプリケーションのHLFトランザクション以外の役割 Copyright © 2021 Oracle and/or its affiliates 71
  72. REST APIでのブロックチェーン利用でアプリケーション開発が容易に REST REST API Fabric SDK 【PR】Oracle Blockchain PlatformのRESTプロキシー

    Copyright © 2021 Oracle and/or its affiliates Oracle Blockchain Platform Fabric Peer Fabric SDK Fabric Peer REST Fabric SDK gRPC REST API Fabric SDK ⇨ Fabric REST API ⇨Web OK 72
  73. Oracleデータベースにブロックチェーンのデータを複製 • 台帳のデータをブロックチェーン外部のリレーショナルデータベースに複製 • ブロックチェーンが苦手とする複雑な参照処理(集計、分析)を、 データベース側で実装可能に • 多くの開発者が慣れ親しんでいるOracleデータベースでの開発 • Oracle

    Analytics Cloudをはじめとした多種多様なBIツールの利用 • 他システムとのデータ統合も一般的なツールとノウハウで容易に実現可能 • ERP、SCMなどの基幹システムとブロックチェーンのデータを 統合することで、データの価値を最大限に活用 【PR】 Oracle Blockchain Platformのリッチヒストリーデータベース機能 Copyright © 2021 Oracle and/or its affiliates State DB World State 台帳(Ledger) 73
  74. Copyright © 2021 Oracle and/or its affiliates アプリケーションが考慮すべき 複数データストア間の整合性 74

  75. アプリ自身のデータベース、社内の別システム、複数のChannelなどなど…… アプリケーションはしばしば複数のデータストアを扱う Copyright © 2021 Oracle and/or its affiliates 75

    アプリ RDB 社内の 別システム Peer 他参加者 アプリ Peer 他参加者 アプリ Peer Channel X Channel Y Channel Z
  76. • 単独Channelでの更新トランザクションはHLFの機能で整合性を保護できる • しかし、アプリケーションから見て以下のようなケースで複数データストアを扱っている場合、それ らの間の整合性保護はHLFでは担保できないので、アプリケーション側で作りこむ必要がある • アプリケーションが個別に持つデータストアと台帳を同時に更新したい場合 • 複数Channelの台帳を同時に更新したい場合 HLFのトランザクションと複数データストアの整合性保護

    Transaction Scope Transaction Scope Copyright © 2021 Oracle and/or its affiliates 76
  77. • 基本的には分散システムでのデータストア間の整合性を保護する方法に準じる • 2PC/3PCは使えないのでSagaパターン、補償トランザクションなどで対応 • 最も難しいのはタイムアウト障害のハンドリング:複数データストアで共通に持つKeyを用意して 冪等&リトライ可能になるように設計しておくとベター • ブロックチェーンならではの注意すべきところは他参加者がいるところ •

    他参加者が台帳の更新を受けて直ちにアクションを取っても問題ないようにする必要 • 他参加者も同時にトランザクションを仕掛けていても整合性が崩れないようにしておく 複数データストア利用時の整合性保護の方式 Copyright © 2021 Oracle and/or its affiliates 77
  78. • 基本的には個別データストア→台帳の順序がおすすめ • オフチェーンの個別データストアは取り消しなどの手当がしやすく、他参加者にも伝わらない • 個別データストアでの更新が成功してから(成功する確証が取れてから)台帳の更新トランザク ションを発行する • 個別データストア側の更新をロールバックできるならベター •

    先にRDB側でトランザクション発行しホールド • HLFのトランザクションが確定(valid/committed)したらコミット • Proposalでエラーになるか、Validationフェーズでinvalidになったらロールバック • ロック長時間化による性能劣化の可能性には留意 ケース①:台帳&個別データストアを同時に更新したい Transaction Scope Copyright © 2021 Oracle and/or its affiliates 78
  79. 正常系 Copyright © 2021 Oracle and/or its affiliates 79

  80. 異常系①:Proposalでエラー Copyright © 2021 Oracle and/or its affiliates 80

  81. 異常系②:Validationでエラー Copyright © 2021 Oracle and/or its affiliates 81

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

    its affiliates 82
  83. • 複数Channelに同時にトランザクションを発行すると結果が出る順序がまちまちになったりしてハン ドリングが難しくなるため、基本的に直列に順次発行する • Ch1にTx発行⇒Ch1成功⇒Ch2にTx発行⇒… • 参加者の間でChannelの更新順序を合意しておくことがベター(場合によってはデッドロック状態回 避のために必須) • 更新順序は規約、マナー、慣行ではなくシステム的に作り込めると安全

    • Ch1で削除したときに生成されるIDをCh2に登録時に入力する、など ケース②:複数Channelを同時に更新したい Transaction Scope moveOut(Item1) outKey moveIn(Item1,outKey) Copyright © 2021 Oracle and/or its affiliates 83
  84. 複数Channelで順次Txを行った場合にも… • 後に回したほうのChannelで更新が行えなかった場合の手当ては検討しておく必要がある • Ch1からCh2にアセットを移動しようとしたが、Ch2に追加できなかったためCh1に復活、など • いわゆる補償トランザクション • Ch2に追加できなかった原因次第で対応を分ける、とすると他参加者に混乱が生じる可能性があるた め、常にいったんは一定の対応をとることにしたほうがシンプル

    • 最低限、中途半端な状況になっていることを発見できるようにしておく ケース②:複数Channelを同時に更新したい Transaction Scope moveOut(Item1) outKey moveIn(Item1,outKey) undo(moveOut,Item1,outKey) Copyright © 2021 Oracle and/or its affiliates 84
  85. Copyright © 2021 Oracle and/or its affiliates Appendix. Oracle Blockchain

    Platformのご紹介 85
  86. Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとオンプレミスで提供 • 数ステップで構築完了、GUIコンソールで管理・運用も容易 • エンタープライズグレードの耐障害制、堅牢性 • マルチクラウド、ハイブリッドクラウド、 オープンなネットワーク構成が可能 •

    Oracle独自の付加価値: • State DBとしてBerkeley DBを利用:パフォーマンスとクエリ利便性向上、 Hyperledger FabricのPhantom Read問題に係る制約も解消 • 多機能なREST API:スマートコントラクトの利用を容易に • 台帳のデータをRDBに複製:大量照会、分析、データ統合 Oracle Blockchain Platform Copyright © 2021 Oracle and/or its affiliates DC 86
  87. 5つの特長によりエンタープライズでのブロックチェーン活用を加速 Oracle Blockchain Platform Copyright © 2021 Oracle and/or its

    affiliates Pre-Assembled: 簡単、高速に高機能なインフラを構築 Easy to Use: 運用、管理の手間を削減 Open: マルチクラウド、ハイブリッドクラウド、 オープンで柔軟なネットワーク構成が可能 Enterprise Grade: エンタープライズ要件を満たすために 独自に強化された基盤 Quick Integration: 他システム連携、アプリ開発を容易にする 独自の機能とサポートツール Oracle Blockchain Platformの特長 提供する価値 ✓ 独自機能によりエンタープライズ用途に最適 化された基盤をすぐに利用可能 ✓ 環境構築やアプリ開発、運用管理の工数を 削減し、業務検討に注力可能 ✓ 迅速な立ち上げとスケールを実現、 エコシステムの拡大を促進 87
  88. • 数ステップ、数分で構築完了 • 必要なブロックチェーンネットワーク構成要素は自動でセットアップ • 構築後すぐにコンソール画面の利用やスマートコントラクトのデプロイが可能 Pre-Assembled:簡単、高速に高機能なインフラを構築 Copyright © 2021

    Oracle and/or its affiliates 88
  89. • 基盤の運用 • 使いやすいコンソールと多機能なサービスAPI • 動的なスケールアウトとスケールアップ • セキュリティ管理 • クラウドID管理と統合された認証・認可

    • 送受信データ、保存データの自動暗号化 • 可用性とメンテナンス • ビルトインされたHA構成 • ゼロダウンタイムでのパッチ自動適用、アップグレード Easy to Use:運用、管理の手間を削減 Copyright © 2021 Oracle and/or its affiliates 89
  90. 使いやすいコンソール画面と多機能なサービスAPIで運用、管理をサポート • 運用、監視、管理のための使いやすいコンソール画面および多機能なサービスAPIを提供 • 必要となる運用、管理タスクをコンソール画面とAPI両方でカバー: …Hyperledger Fabricの難解な設定ファイル、コマンド、手順は習得不要 • ノードの起動/停止 •

    設定の変更 • ブロックチェーンネットワークのメンバー追加 • 監視とトラブルシューティングも: • ネットワークの視覚化 • リソース使用状況やノード死活情報 • トランザクション処理状況 Easy to Use:運用、管理の手間を削減 Copyright © 2021 Oracle and/or its affiliates 90
  91. • Oracle Blockchain Platformだけでなく、 他のHyperledger Fabricとのオープンなネットワーク構成が可能 • オンプレミスバージョンの提供: Oracle Blockchain

    Platform Enterprise Edition(OBPEE) • 自社データセンターやOracle以外のクラウド(IaaS)上にOBPを構築 • ブロックチェーン環境に必要な機能を事前定義、数クリックで環境構築 • サポートするVM基盤:Oracle VirtualBoxとVMware vSphere • Oracle Blockchain Platform Cloud Service (OBPCS) と同等の機能を提供 • APIは共通、アプリケーション移植性あり • アップデートもOBPCSと足並みを揃えて提供 Open:オープンで柔軟なネットワーク Copyright © 2021 Oracle and/or its affiliates 91
  92. オンプレミス、マルチクラウド、ハイブリッドクラウドでの構成が可能 Open:オープンで柔軟なネットワーク Copyright © 2021 Oracle and/or its affiliates オンプレミスベースの

    ブロックチェーンネットワーク 3rd Party Cloud 3rd Party Cloud 3rd Party Cloud マルチクラウドの ブロックチェーンネットワーク ハイブリッドクラウドの ブロックチェーンネットワーク Oracle Blockchain Platform Cloud Service (クラウドサービス) Oracle Blockchain Platform EE (オンプレミス) オープンソースのHyperledger Fabric (手組ベース) 92
  93. Enterprise Grade:エンタープライズ要件を満たす Copyright © 2021 Oracle and/or its affiliates 運用/保守性

    • 使いやすいコンソール画面と 多機能なサービスAPI • モニタリングダッシュボードを通じ システムの状態を把握 • OracleマネージドPaaS セキュリティ/機密性 • ID管理サービスとの統合 • より細やかな権限分割が可能 • 送受信/保存データ暗号化 処理性能/スケーラビリティ • 並行処理/高速なコンセンサス • 動的なスケールアップ/アウト • 低遅延のネットワーク 耐障害性/可用性 • HA構成のVMを標準で提供 • 自動再起動 • 台帳、設定の常時バックアップ 93
  94. State DB Berkeley DB パフォーマンス&ロジック表現力を強化 ・パフォーマンスの向上 • スマートコントラクトの同時実行性の強化 ・SQLリッチクエリのサポート •

    JSONの属性を指定してのSQL-Likeクエリが可能 • CouchDB形式のJSONクエリへの互換性も保持 ・CouchDB適用時の技術的な問題の解決/回避 • リッチクエリ使用時のPhantom Read問題を解消 • 大量レコード取得時のPagination指定が不要に Enterprise Grade:エンタープライズ要件を満たす Copyright © 2021 Oracle and/or its affiliates + ブロックチェーン: トランザクションと 値の履歴を格納 State DB (World State): 現在の値を格納する データベース Hyperledger Fabricにおける 台帳(Ledger)構成 ※通常のHyperledger Fabricでは、 State DBはLevelDBかCouchDB 94
  95. エンタープライズ活用で重要なシステム間の連携をサポートする機能を提供 Quick Integration:他システムとの連携を迅速に実現 Copyright © 2021 Oracle and/or its affiliates

    • REST APIでブロックチェーンが利用可能。 アプリケーション開発および既存システムとの連携 が容易に • Oracle Integration Cloudの事前定義済アダプ ターを用いることで、ERPなどの基幹システムや各種 SaaSとの連携を更に迅速に実現 アプリケーション連携 • ブロックチェーン上のデータをデータベースに複製す る機能が付属。複雑な集計、分析なども高速かつ 容易に開発可能 • ブロックチェーンのデータと他システムのデータをデータ ベース上で統合することで、 より高度なデータ活用も可能に Blockchain Integration Database データ連携 他システム BIツール等 95
  96. REST APIでのブロックチェーン利用でアプリケーション開発が容易に Quick Integration:他システムとの連携を迅速に実現 Copyright © 2021 Oracle and/or its

    affiliates Oracle Blockchain Platform Fabric Peerノード 台帳 スマートコントラクト アプリケーション Fabric SDK Fabric Peerノード 台帳 スマートコントラクト RESTプロキシー Fabric SDK アプリケーション gRPC REST API 96 Fabricの証明書 Fabricの証明書 gRPC Oracle CloudのID管理 サービスを利用して認証 • Fabric SDKの 組み込みが必須 • アプリで管理する秘密 鍵&証明書で認証 ⇨アプリケーション開発者 はFabricアプリ開発の習 熟が必須 通常のFabric利用アプリ開発 Oracle Blockchain Platform利用アプリ開発 • アプリはREST APIで ブロックチェーンを容易 に利用可能 • クラウドのIDを用いて容 易&セキュアに認証・認 可 ⇨Webアプリ開発の一般 的なスキルがあればOK
  97. Oracle Integration Cloud ERP SCM SaaS Quick Integration:他システムとの連携を迅速に実現 Copyright ©

    2021 Oracle and/or its affiliates ブロックチェーンネットワーク A社 B社 C社 D社 既存 システム システム 連携層 Oracleはもちろん、他社のクラウド/オン プレミスのソフトウェアとの豊富なアダプター を利用 例:SAP、Salesforce、 NetSuite Oracle SCM Cloud、 申請→承認などのワークフローの作りこみ や、 API管理も可能 Integration 97
  98. リッチヒストリーデータベース:Oracleデータベースにブロックチェーンのデータを複製 • 台帳のデータをブロックチェーン外部のリレーショナルデータベースに複製 • ブロックチェーンが苦手とする複雑な参照処理(集計、分析)を、 データベース側で実装可能に • 多くの開発者が慣れ親しんでいるOracleデータベースでの開発 • Oracle

    Analytics Cloudをはじめとした多種多様なBIツールの利用 • 他システムとのデータ統合も一般的なツールとノウハウで容易に実現可能 • ERP、SCMなどの基幹システムとブロックチェーンのデータを 統合することで、データの価値を最大限に活用 Quick Integration:他システムとの連携を迅速に実現 Copyright © 2021 Oracle and/or its affiliates ブロックチェーン: トランザクション と値の履歴を格納 State DB (World State): 現在の値を格納 台帳(Ledger) 98
  99. 現在および過去のデータを複製することで、様々な用途と角度で利用可能 リッチヒストリーデータベースによるブロックチェーン上のデータの複製 Copyright © 2021 Oracle and/or its affiliates ブロックチェーン

    台帳 • State Key-Value ※ World State/State DB • History Private Data • Transaction Details Last alpha History alpha State beta State beta History alpha beta 複 製 beta Transaction Details alpha Transaction Details 詳細は以下のドキュメントを参照: https://docs.oracle.com/en/cloud/paas/blockchain-cloud/usingoci/create-rich-history-database.html
  100. 複製先テーブルとしてBlockchain Tableに対応 • 格納先としてBlockchain Tableを選択可能に • 複製データにも更新や削除をできない耐改ざん性、更 新や削除されていないデータとしての証跡性を付与 • 複製データもブロックチェーン台帳上のデータと同

    様、信頼に足る情報、証跡として扱うことが可能に • 対象は履歴を追記で蓄積していくHistoryおよび Transaction Details • チャネルごとに複製先に別々のデータベースを設定可能に • 分析用データベース、監査証跡蓄積用データベースな ど、 チャネルのデータのタイプごとに用途別データベース を指定可 • Private Data Collectionのデータを複製可能に • 特に秘匿性の高い重要な情報を扱うPrivate Data Collectionの内容もデータベース上に複製可能にな り、 データ統合や分析の利便性がさらに向上 リッチヒストリーデータベースの機能拡張 Copyright © 2021 Oracle and/or its affiliates ブロックチェーン 台帳 alpha beta Database A Database B History on Blockchain Table State State History on Blockchain Table Transaction Details on Blockchain Table Transaction Details on Blockchain Table 複 製 複 製 100
  101. 台帳上のレコード(Key-Valueセット)の現在の値を格納 リッチヒストリーデータベースのテーブル:State カラム データ種別 説明 chaincodeId VARCHAR2(256) レコードを書き込んだChaincodeのID key VARCHAR2(1024)

    レコードのKey value VARCHAR2(4000) レコードのValue(JSON型でない場合にこちらのカラムに格納) valueJson CLOB レコードのValue(JSON型の場合にこちらのカラムに格納) blockNo NUMBER 更新トランザクションが何番目のブロックに格納されたか txnNo NUMBER 更新トランザクションがブロック内の何番目の位置に格納されたか Copyright © 2021 Oracle and/or its affiliates 101 Copyright © 2021 Oracle and/or its affiliates
  102. 台帳上のレコードの値の履歴(過去バージョン~現在バージョン)を格納 リッチヒストリーデータベースのテーブル:History カラム データ種別 説明 chaincodeId VARCHAR2(256) レコードを書き込んだChaincodeのID key VARCHAR2(1024)

    レコードのKey txnIsValid NUMBER(1) 更新トランザクションが有効だったか value VARCHAR2(4000) レコードのValue(JSON型でない場合にこちらのカラムに格納) valueJson CLOB レコードのValue(JSON型の場合にこちらのカラムに格納) blockNo NUMBER 更新トランザクションが何番目のブロックに格納されたか txnNo NUMBER 更新トランザクションがブロック内の何番目の位置に格納されたか (⇒blockNo+txnNoでバージョン情報として機能) txnId VARCHAR2(128) 更新トランザクションのトランザクションID txnTimestamp TIMESTAMP 更新トランザクションのタイムスタンプ txnIsDelete NUMBER(1) レコードを消去するトランザクションかどうか Copyright © 2021 Oracle and/or its affiliates 102 Copyright © 2021 Oracle and/or its affiliates
  103. 台帳上のトランザクションの履歴を格納 リッチヒストリーデータベースのテーブル:Transaction Details① カラム データ種別 説明 CHAINCODEID VARCHAR2(256) トランザクションのChaincodeのID BLOCKNO

    NUMBER トランザクションが何番目のブロックに格納されたか TXNNO NUMBER トランザクションがブロック内の何番目の位置に格納されたか TXNID VARCHAR2(128) トランザクションID TXNTIMESTAMP TIMESTAMP トランザクションのタイムスタンプ SUBMITTERCN, SUBMITTERORG, SUBMITTEROU VARCHAR2(512), VARCHAR2(512), VARCHAR2(512) トランザクション送信者の識別情報 CHAINCODETYPE VARCHAR2(32) Chaincodeの記述言語(Go、Java、JavaScript) VALIDATIONCOD ENAME VARCHAR2(32) トランザクションのValidation結果のコード(VALID or INVALID+理由コード) ENDORSEMENTS CLOB トランザクションにEndorseしたPeerノードの識別情報 INPUTS CLOB Chaincodeに引き渡された入力パラメーター EVENTS CLOB Chaincodeから発出したカスタムイベント名 Copyright © 2021 Oracle and/or its affiliates 103 Copyright © 2021 Oracle and/or its affiliates
  104. 台帳上のトランザクションの履歴を格納 リッチヒストリーデータベースのテーブル:Transaction Details② カラム データ種別 説明 RESPONSESTATUS NUMBER(0) Chaincodeが返却したレスポンスのステータス RESPONSEPAYLOAD

    VARCHAR2(1024 ) Chaincodeが返却したレスポンスのペイロード RWSET CLOB トランザクションのRWSet(Read-Write Set…読み書きした台帳上のレコードのKeyとバー ジョンやValueの値) BLOCKCREATORCN, BLOCKCREATORORG, BLOCKCREATOROU VARCHAR2(512), VARCHAR2(512), VARCHAR2(512) ブロックを生成したOrdererノードの識別情報 CONFIGBLOCKNUMBER NUMBER(0) トランザクション時点で有効となっていたConfig Blockのブロックナンバー CONFIGBLOCKCREATO RCN, CONFIGBLOCKCREATO RORG, CONFIGBLOCKCREATO ROU VARCHAR2(512), VARCHAR2(512), VARCHAR2(512) トランザクション時点で有効となっていたConfig Blockを生成したOrdererノードの識別情報 Copyright © 2021 Oracle and/or its affiliates 104 Copyright © 2021 Oracle and/or its affiliates
  105. Chaincode内・オンチェーンでのアクセス制御を容易に実装するためのライブラリを提供 • ブロックチェーン台帳上のデータへのアクセス権限を ブロックチェーン台帳上に記述して管理 • Hyperledger Fabricの標準機能よりも細かく、かつ、 扱いやすいアクセス権限制御を容易に実現 以下の要素で権限を制御 •

    リソース:アクセスを制御する対象 • アイデンティティ:アクセスする企業やユーザー • グループ:アイデンティティのグループ • アクセス制御リスト: • どのアイデンティティ/グループに • どのリソースに対し • どのような操作(CREATE、READ、UPDATE、DELETE、etc.)を • 許可する/しない Fine Grained Access Controlライブラリ Copyright © 2021 Oracle and/or its affiliates 105 詳細は以下のドキュメントを参照: https://docs.oracle.com/en/cloud/paas/blockchain-cloud/usingoci/using-fine-grained-access-control-library.html
  106. Fine-Grained Access Controlライブラリの利用イメージ Copyright © 2021 Oracle and/or its affiliates

    Ledger Chaincode Identity: O=OrgA, CN=UserA1 業務関数 ACL チェック FGAC ラ イ ブ ラ リ ACL管理 関数 業務データ ACL関連データ リソース グループ ACL Identity: O=OrgB, CN=UserB1 アクセス権限制御のため のデータを台帳上で管理 Chaincode関数内で 権限チェックを実施 Chaincode呼び出しの Identity(証明書)を組 織レベルやユーザーレベ ルでグループ化して制御 ACLの管理に関わる機能も関数として実装し、 ACL管理関数の権限もACLで管理
  107. Chaincodeの開発、テスト、デプロイを容易にする開発補助ツール • Visual Studio Codeの拡張機能、およびCI/CD用のCLIツールとして提供 • Chaincodeの一連のライフサイクル(開発、パッケージング、デプロイ、アップデート)をサポート • ローカルなHyperledger Fabricネットワークを自動構成してデプロイ、テスト

    • Chaincodeのステップ実行によるデバッグが可能 • リモートのOracle Blockchain Platformにデプロイ、テストも可 • アセット仕様からChaincodeを自動生成 • 宣言的に記述アセットの属性とメソッドの仕様をもとに Chaincodeのコード、プロジェクトを自動生成 Blockchain App Builder Copyright © 2021 Oracle and/or its affiliates 詳細は以下のドキュメントを参照: https://docs.oracle.com/en/cloud/paas/blockchain-cloud/usingoci/using-chaincode-development-tools.html 107
  108. トークンを扱うChaincodeを素早く開発するだけでなく、トランザクションにかかる独自の改 善を搭載 • Blockchain App BuilderはFungible Token(お金やポイントなどの数量で表されるア セット)のChaincode開発にも対応 • 口座と残高からなるAccount/Balanceモデルで表現

    • 生成、送付、分割、保留、破棄などの振る舞いをサポート • Hyperledger Fabricでトークンを扱う際に制約となる、トランザクションのMVCCに係る Read Conflictエラー多発問題を独自の改善で解消 • Blockchain App Builderで生成したトークンChaincode専用のオプションを有効化す るとMVCCを最適化 • オリジナルHyperledger Fabricでは苦手だった、同一口座の高頻度の入出金を含む ユースケースを扱うことが可能に Blockchain App Builderによる(Fungible)Token開発 Copyright © 2021 Oracle and/or its affiliates 108
  109. • Hyperledger Fabric v2.2系ベースのインスタンスが作成可能に • 以下を含むv2.x系での改善を利用可能 • 新しいChaincodeライフサイクル • Chaincodeのパッケージと定義の分離による、より柔軟なデプロイプロセス

    • より柔軟な秘匿と共有パターンを可能にするPrivate Data Collectionの機能強化 • インスタンス作成時にv1.4系ベースとv2.2系ベースから選択 • 新規ユーザーはv2.2系ベースのインスタンスの作成を推奨 • 既存OBPユーザーは継続してv1.4系ベースのインスタンスも作成可 • v2.2系とv1.4系は同一ネットワークに混在不可 Hyperledger Fabric v2.x系に対応 Copyright © 2021 Oracle and/or its affiliates
  110. 利用料金の構成は、選択したインスタンスタイプにより ① or(②+③)のどちらかになります: • 2つのインスタンス・タイプ(CPU数×使用時間) • ①Standard:2 OCPUで固定、ストレージは50GB付属で追加不可、非HA構成 • ②Enterprise:OCPU拡張可能(最小4

    OCPU)、ストレージは150GB付属で追加可能、HA構成可能 • ③追加ストレージ(TB/月)…Enterpriseのみ追加可能(オプショナル) インスタンス停止中のOCPU分の料金は25%に低減されます • 例:インスタンスを月20日×8時間稼働(残りは停止)させた場合の月額: • Standardの場合…2×(25.8×8×20+25.8×0.25×(16×20+24×11))= 15789.6 (円) • Enterprise最小構成の場合…4×(51.612×8×20+51.612×0.25×(16×20+24×11))= 63173.088(円) Oracle Blockchain Platform Cloud Service の価格体系 Copyright © 2021 Oracle and/or its affiliates サービス名 単価 メトリック 最小構成 参考月額費用(※) ①Oracle Cloud Infrastructure – Oracle Blockchain Platform Cloud Service –Standard ¥25.8 OCPU/Hour 2 OCPU(固定) ¥38,390 ②Oracle Cloud Infrastructure – Oracle Blockchain Platform Cloud Service –Enterprise ¥51.612 OCPU/Hour 4 OCPU(拡張可能) ¥153,597 ③Oracle Cloud Infrastructure – Oracle Blockchain Platform Cloud Service -Storage ¥8,448 TB/Month 1 TB単位で追加可能 ¥8,448 ※最小構成の24時間×31日 稼働で計算 110
  111. Oracle Blockchain Platform ノード ノード ブロックチェーン ノード Oracle Blockchain Platformを利用したシステムのイメージ

    Copyright © 2021 Oracle and/or its affiliates 台帳 Chaincode (スマート コントラクト) REST Proxy アプリ ケーション Oracle データベース 既存 データベース API ユーザー アプリ連携 データ統合 データ複製 BIツール ERP、SCM等 基幹システム ERP、SCM等 基幹システム ERP、SCM等 基幹システム 既存 データベース 既存 データベース 呼び出し
  112. Oracle Integration Autonomous DB Oracle Blockchain Platform ノード ノード ブロックチェーン

    ノード Oracle Cloudのサービスを利用して簡易に実現する例 Copyright © 2021 Oracle and/or its affiliates 台帳 Chaincode (スマート コントラクト) REST Proxy APEXアプリ データベース 既存 データベース API ユーザー アプリ連携 データ統合 データ複製 Oracle Analytics ERP、SCM等 基幹システム ERP、SCM等 基幹システム ERP、SCM等 基幹システム 既存 データベース 既存 データベース Oracle REST Data Service (ORDS) 呼び出し
  113. Oracle Blockchain & PoC 1/2 Copyright © 2021 Oracle and/or

    its affiliates 113
  114. Oracle Blockchain & PoC 2/2 Copyright © 2021 Oracle and/or

    its affiliates 114
  115. オラクルのブロックチェーンへの取り組み、ブロックチェーン概要ご紹介 動画でご紹介 ブロックチェーンと Oracle Blockchain Platform Cloud Serviceのご紹介 https://youtu.be/efUTDWxEMkU Oracleのブロックチェーンへの取り組み

    https://youtu.be/HZ0Si8Xcz_8 Copyright © 2021 Oracle and/or its affiliates 115 Copyright © 2021 Oracle and/or its affiliates 115
  116. Oracle Blockchain Platform Cloud Serviceの概要、実際の利用方法について動画でご紹介 動画でご紹介 Oracle Blockchain Platform Cloud

    Service の概要紹介(日本語字幕) https://youtu.be/wDrYM9ecYz4 Oracle Blockchain Platform Cloud Service 活用デモ(SupplyChain、英語) https://youtu.be/iSpg4KgHoA0 Oracle Blockchain Platform Cloud Service の一連のデモ、実際の利用方法(日本語) https://youtu.be/IuUrqBQ2bXY Copyright © 2021 Oracle and/or its affiliates 116 Copyright © 2021 Oracle and/or its affiliates 116
  117. Oracle Blockchain Platform Cloud Service サイト、ドキュメント、事例 • https://www.oracle.com/jp/application-development/cloud-services/blockchain-platform/ Oracle Blockchain

    Platform Enterprise Edition サイト、ドキュメント • https://www.oracle.com/database/technologies/blockchain-platform-enterprise-edition.html ブロックチェーン活用の構想から構築まで、ぜひお気軽にご相談ください また、パートナーの皆様、スタートアップの皆様も、ぜひお声がけください Oracle Blockchain Platform 関連情報 Copyright © 2021 Oracle and/or its affiliates 117 Copyright © 2021 Oracle and/or its affiliates 117
  118. Thank you Copyright © 2021 Oracle and/or its affiliates 118

  119. None