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

Blockchain GIG#10 実践 Hyperledger Fabric

Blockchain GIG#10 実践 Hyperledger Fabric

2021/7/15 Blockchain GIG#10でしゃべった内容
Hyperledger Fabricのネットワークを設計していくにあたっての流れと考え方

4b09160b087e45103b210ef95079cee4?s=128

gakumura

July 19, 2021
Tweet

More Decks by gakumura

Other Decks in Technology

Transcript

  1. Blockchain GIG #10 使いこなす! 実践 Hyperledger Fabric 中村 岳 日本オラクル株式会社

    2021/7/15
  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 • 構造と機能が多く、柔軟で色々できるが故に設計で悩みがち • ここでは公式ドキュメントを読みこんでいっても理解や想像をしづらい点、特に Hyperledger Fabricのブロックチェーンネットワーク部分の設計を進めていく流れを重点

    的に解説 • 合わせて知らないで設計を進めるとハマってしまいがちな留意点を紹介 • 設計を進めていく道のりを把握して、Hyperledger Fabricをガンガン使いこなそう!!!! 本セッションのねらい Copyright © 2021 Oracle and/or its affiliates 4
  5. • はじめに;入門編の振り返り • 設計の前提を整理する • Hyperledger Fabricのネットワーク構成を設計する • パフォーマンスあれこれ ※なお、文中のHLF=HyperLedger

    Fabric 資料の内容 Copyright © 2021 Oracle and/or its affiliates 5
  6. • 今度こそわかる!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 6
  7. Copyright © 2021 Oracle and/or its affiliates はじめに:入門編の振り返り 7

  8. なぜ複雑なトランザクションやデータ構造などの仕組みが必要になるのか? • ブロックチェーン/DLTは一般に、 (単一の管理体ではなく)複数の個人や組織が分散して所有・管理 するノード間でのデータ複製を確実に行う という「お題」に取り組んでいる(と捉えられる) • 故障やミスだけでなく悪意にも備える必要がある • 他参加者のノードは不正に改造されたものかも

    • 他参加者がネットワークへの攻撃を試みるかも • 以下の要素の組み合わせで実現している(と整理できる) • データの耐改ざん性と検証可能性 (→データ構造としてのブロックチェーン) • 状態遷移ロジックの事前定義 (→スマートコントラクト) • トランザクション実行時合意 (→トランザクションとコンセンサスのメカニズム) ブロックチェーン一般が取り組む共通の「お題」 Copyright © 2021 Oracle and/or its affiliates Staten Staten+1 Tx ノード Staten Staten+1 Tx ノード State Machine Replication 8
  9. ブロックチェーン一般の前提に加え、HLFの設計思想を抑えておく HLFの多くの機能や独特の仕様には、以下のような目的、背景があると考えると理解しやすくなる • 複数の企業/組織から成るコンソーシアム型のユースケースに最適化する • ネットワークの中で更にデータ共有範囲を分割/制御する • 重大なオペレーションの安全かつ分権したガバナンスを実現する • 耐障害性と可用性をブロックチェーン基盤の機能として確保する

    • ネットワークメンバー数とトランザクション処理能力のスケーラビリティを確保する Hyperledger Fabricの特色 Copyright © 2021 Oracle and/or its affiliates 9
  10. Orderer Organization配下にPeer、Orderer、CAのコンポーネントとクライアントアプリケーション Hyperledger Fabricネットワークの概観図 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 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. 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 12
  13. Copyright © 2021 Oracle and/or its affiliates 設計の前提を整理する 13

  14. • はじめにブロックチェーンネットワークの構成を設計するにあたって必要な前提を整理しておく • この段階で必要なのは • ステークホルダーを特定する • ブロックチェーン上で扱う情報を大まかに整理する • 誰がブロックチェーンノードを所有するかを検討する

    • ここの流れにはFabric固有の要素は特になく、エンプラブロックチェーン一般で概ね共通と思われる 設計の前提を整理する Copyright © 2021 Oracle and/or its affiliates 14
  15. 凡例 D社 C社 B社 A社 ノード コンソーシアム型ブロックチェーンのシステム概観 Copyright © 2021

    Oracle and/or its affiliates SC L ノード SC L ノード SC L ノード SC L 個社 アプリ ブロックチェーン プラットフォーム 個社 アプリ 共有 アプリ オペレーター 他システム SC スマート コントラクト L 台帳 15
  16. ブロックチェーン プラットフォーム 凡例 D社 C社 B社 A社 ノード 1. システムのステークホルダーは誰なのか?

    Copyright © 2021 Oracle and/or its affiliates SC L ノード SC L ノード SC L ノード SC L 個社 アプリ 個社 アプリ 共有 アプリ オペレーター 他システム SC スマート コントラクト L 台帳 • 「誰に向けたシステムなのか」「誰が使うシステムなのか」 は最初に明確にしておく • 当たり前のように聞こえるが、コンソーシアム型では この点が案外難しい • 言い換えると: • 解こうとしている課題の持ち主の特定 • 生み出されるメリットを享受する者の特定 • 初期の利用者となる組織の特定 • 将来的な利用者となり得る組織、あるいは 業種(役割)の構想 16
  17. 凡例 D社 C社 B社 A社 ノード 2. ブロックチェーン上でどのような情報を扱うのか? Copyright ©

    2021 Oracle and/or its affiliates SC L ノード SC L ノード SC L ノード SC L 個社 アプリ ブロックチェーン プラットフォーム 個社 アプリ 共有 アプリ オペレーター 他システム SC スマート コントラクト L 台帳 17
  18. • ブロックチェーン台帳上(⇨ブロックチェーンプラットフォーム)で どのような種類の情報(データ)を扱うのかを洗い出しておく • この時点ではそれほど詳細になっていなくても良い • それらの情報について共有範囲と信頼のあり方を検討する • どの範囲で共有可能か(全体/一部/元の持ち主のみ) •

    秘匿の必要があるか • 誰に対して秘匿されるべきか • 共有を必要とするのは誰か • 誰が/誰に対して不正な情報を示す動機があるか • 不正を働かないことは信頼可能か(検証しなくてもよいか) • これらがノードを誰が持つべきかの検討のインプットになる 情報の種類の洗い出しと共有範囲、信頼の検討 Copyright © 2021 Oracle and/or its affiliates L 18
  19. 凡例 D社 C社 B社 A社 ノード 3. 誰がノードを持つのか? Copyright ©

    2021 Oracle and/or its affiliates SC L ノード SC L ノード SC L ノード SC L 個社 アプリ ブロックチェーン プラットフォーム 個社 アプリ 共有 アプリ オペレーター 他システム SC スマート コントラクト L 台帳 19
  20. ブロックチェーンノード所有/管理/運用のパターンはさまざま Copyright © 2021 Oracle and/or its affiliates 分散 集中

    個別所有 部分共有 共有 専有 Consortium Private 20
  21. 凡例 D社 C社 B社 A社 ノード アプリは? Copyright © 2021

    Oracle and/or its affiliates SC L ノード SC L ノード SC L ノード SC L 個社 アプリ ブロックチェーン プラットフォーム 個社 アプリ 共有 アプリ オペレーター 他システム SC スマート コントラクト L 台帳 21
  22. 自前ノードで参加 自身のノードによるネットワークに参加のみが利用の形態ではない 「ブロックチェーンのシステムを利用する」モデル Copyright © 2021 Oracle and/or its affiliates

    ノード SC L アプリ ノード SC L アプリ ノード SC L アプリ 他者ノードを通じて 利用 他者アプリを通じて 利用 22
  23. ノードを直接、自由に触れないことに伴う制約と利用先との信頼の問題 • 利用先のノード or/and アプリの許す/提供する限りにおいてブロック チェーンプラットフォームの機能を利用することになる • 台帳上のデータ、およびスマートコントラクトロジックの検証可能 性が限定される(あるいは全くない) •

    都合の悪い情報の書き込み/参照をフィルタリングされたり、虚偽 の情報を示されたりする可能性がある(…ゲートキーパー) • 利用先との関係の悪化や、利用先自身の都合により利用が停止さ れ、プラットフォームへのアクセスができなくなる可能性がある (…アクセシビリティ問題) • 使い勝手が利用先の提供サービスに左右される • 利用者がアクセスできる情報は基本的には利用先ノードの持ち主もアク セスできることになるため、秘匿性との折り合いが必要 • 暗号化などで対処することは可能 • SSoTとなるデータが自身の手元にない…法的な要件などとの適合性 他者のノード を通じて利用する方式の留意点 Copyright © 2021 Oracle and/or its affiliates ノード SC L アプリ 他者ノード/アプリを 通じて利用 アプリ 23
  24. ステークの大きさとのバランス、秘匿要件、信頼の問題を考慮 • 自前のノードを持って秘匿性、アクセシビリティ、検証可能性を自身の手の内に確保するのは、ブ ロックチェーンを利用するシステムにとって本質的に重要な要素 • システムの使い勝手の面でも自前ノードのほうが有利 • 一方で、自前のノードを所有するには一定のコスト負担が、そして構築/管理/運用するには一定の 能力が必要 •

    構築や運用はベンダーにアウトソースするのも選択肢となるが、結局運用コストはかかる • ステークが小さく、利用先との信頼の問題が折り合う場合は他者の/共有のノードを通じて利用 するのも現実的なやり方 • プラットフォームに対してのステークの大きさと負担が釣り合うように検討すべき • 最初から管理/運用の分散までを含めたフルスペックでスタートしなくてもよい • 後からより分散したかたちに移行していく(移行できる可能性を残す)アプローチも検討する • BaaS(Blockchain as a Service)を利用するなどしてノード所有/管理/運用に求められる能力の ハードルを下げるのは、ブロックチェーンを利用するプラットフォームを成立させ、将来的に拡大さ せ、価値を増していくにあたって非常に重要 ノードの所有、管理/運用は誰が担うべきなのか Copyright © 2021 Oracle and/or its affiliates 24
  25. Copyright © 2021 Oracle and/or its affiliates Hyperledger Fabricネットワーク構成を 設計する

    25
  26. Orderer Organization配下にPeer、Orderer、CAのコンポーネントとクライアントアプリケーション Hyperledger Fabricネットワークの概観図 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 この範囲についてどう設計を進めていくべきかの流れを説明 26
  27. 1. オンチェーンで扱うデータとビジネスロジックを整理する 2. オンチェーンデータの共有範囲を整理し、実装方法を検討する 3. Chaincodeを設計する 4. Endorsement Policyを設計する 5.

    Peerの冗長性を確保する 6. Ordering Serviceの構成を設計する • アプリケーションでやることについてはこの章では扱わない • あるサービスを利用するアプリケーションであり、そのサービス(のひとつ)がブロックチェー ン、と考えるとアプリケーションの設計にあたってそれほど特殊なところはない • パフォーマンスやデータの整合性に関連して特に留意すべき点については後の章で説明 流れ Copyright © 2021 Oracle and/or its affiliates 27
  28. • 改めてブロックチェーンプラットフォーム上で扱う情報を整理する • 共有するデータについては、項目まで具体的、詳細に特定する • オンチェーンでのデータ共有は台帳(World State+ Blockchain)とPrivate Dataいずれかで行うことになる •

    場合によりオフチェーン共有ストレージを使う必要も発生する (個人情報、サイズの大きなファイルなど) • アプリケーション側で個別に持つデータはスコープ外 (アプリケーション個別の検討が必要になるため後回し&個別 検討) • 加えて、オンチェーンのデータに対しての操作(ビジネスロジッ ク)を洗い出す • Chaincodeとして実装されるべきビジネスロジックはなにか? • アプリケーション個別のロジックとしてよいものを除いていく 1. オンチェーンで扱うデータとビジネスロジックを整理する Copyright © 2021 Oracle and/or its affiliates アプリケーション Peer Chaincode Ledger Private Data オフチェーン 共有 ストレージ アプリ個別の ロジック 個別 データ ストア 個別 共有 28
  29. 個人情報(PII)に注意 • 個人情報保護法、GDPRなどの法規制 • 「削除して」と言われても台帳に書いてあると消せない • Private Dataであれば削除(パージ)可能 • オフチェーン共有ストレージに書いて受け渡し、もよくあるやり方

    サイズに注意 • 画像イメージや文書ファイルなど、サイズの大きいデータの保管には向かない • ×:ファイルそのものを保存 • ◦:ファイルそのものはオフチェーン共有ストレージに配置し、 台帳にはそのファイルへの参照情報(ID&URLなど)と内容のハッシュ値を保存 • 台帳への書き込み内容はネットワークを伝播するため、パフォーマンスへの影響が大きい • 特にトランザクションボリュームが多い場合は注意 • 略語を使用してチャネル名や変数名を縮めるなどの細かい努力(Name⇒Nm、Number⇒Numなど) 台帳に載せるべきでないデータ、向かないデータの考慮 Copyright © 2021 Oracle and/or its affiliates 29
  30. Chaincodeとアプリケーションでロジックの分担を検討 • Chaincodeは複雑でコストの重い処理、広い範囲のデータを一括で読み書きする処理にはあまり向い ていない • Endorsementでは複数Peerでロジックが冗長に実行される • State DBはRDBと同じようには使えない…大規模集計、分析は得意ではない •

    トランザクションフローの仕組み上、1トランザクションに大量のRWSetが含まれると他のトラン ザクションと衝突しやすく、結果的に処理性能に問題が発生しやすい • 必要な場合はバッチとして切り出して他のトランザクションに影響を与えないように実行する • Chaincodeで実現できない/実現が困難な機能は検討に先立って把握しておく必要がある(後の章で 説明) • 「Chaincodeにないと困る」機能以外はクライアントアプリケーション側に配置する方向で検討 • Chaincodeに必須なのはWorld StateとPrivate Dataの更新機能 +更新の中で必要な参照機能(条件評価など) +基本的なクエリのための機能 オンチェーンのビジネスロジックの範囲 Copyright © 2021 Oracle and/or its affiliates 30
  31. RDBに複製することでデータ活用の幅、利便性を向上 • オンチェーンデータをRDBに複製するパターン/テクニックが多くの場合(ほぼ?)使われている • 複製したDB上のデータをアプリから参照する、高度な検索や大規模集計/分析をBIツールで行 う、他のデータとデータ統合するなど • HLFに限らず(また、エンプラBCに限らず)使われるパターン/テクニックでもある • ブロックチェーンユースケースの中心はデータなので、データの活用可能性、使い勝手は非常に重要

    • 方式としては①Event経由で受け取ったデータを蓄積する②Chaincodeでクエリして取得したデータを 蓄積する③BlockchainからTxを読んでいって逐次反映していく④State DBを直接読む あたり • オンチェーン⇔複製で齟齬が発生しないように(齟齬を修正できるように)実装する必要がある • 【PR】Oracle Blockchain PlatformにはオンチェーンデータをOracle Databaseに複製する機能あり Tips:オンチェーンデータのオフチェーンデータベースへの複製 Copyright © 2021 Oracle and/or its affiliates State DB World State 台帳(Ledger) 31
  32. • オンチェーンデータに対して、可視範囲と秘匿性要件を整理する • 「A社」や「B社」など具体的な参加者ごとに区切っていくパターンと、 「製造元」や「配送業者」、「納入先」のようにアセットから見ての役割で区切っていくパター ンがある • あるデータについて項目レベルで範囲が変わる場合はそれらも定義する • 適切な実装方法を検討する。選択肢は:

    • Channelを分割する • Private Dataを使う • 暗号化して受け渡しする 2. オンチェーンデータの共有範囲を整理し、実装方法を検討する Copyright © 2021 Oracle and/or its affiliates データ/項目 原料 製造 小売 最終製品 × ◦ ◦ /識別ID × ◦ ◦ / × ◦ ◦ 部品 ◦ ◦ ◦ /識別ID ◦ ◦ ◦ /品質スコア ◦ ◦ × 32
  33. • トランザクション(で扱うあるデータの単位)自体はChannel内のメンバー全体に共有するが、その 中のある項目を限られたn者間に秘匿したい、という用途に使える • トランザクション内容の秘匿性についてはPrivate Dataの利用を基本に検討する • Private Dataのハッシュ値がChannel内メンバーに共有されるため検証可能性が損なわれないこ と、同一Channel内であればPDCまたぎのトランザクションも実行可能なことなど、Channelを分

    割する場合に比べてデメリットが小さい • Purgeもできるのでリクエストに応じてオンデマンドデータの受け渡し(⇨HLFを単にメッセージング レイヤーとして使う)のような用途にも使いやすい Private Dataを使う Copyright © 2021 Oracle and/or its affiliates OrgA Peer OrgB Peer OrgC Peer Channel 1 L1 PD1 L1 L1 Private Data Collection 1 PD1 33
  34. • トランザクションの存在そのものを秘匿したいケースではChannel による分割が有効 • トランザクションの量、頻度から何らかの情報が推測されてし まうことを防ぐ • トランザクションの存在から取引関係など、n者間の関係性が他 の参加者にリークしてしまうことを防ぐ •

    必要なn者間Channelだけ用意する運用だと、Channelの存在自体が 関係性をリークしてしまう • 関係性を秘匿したい場合には使用しないn者間のChannelも用意 しておく必要性 • Channelまたぎのビジネストランザクションは普通にやると一貫 性、整合性を担保することが難しい、また、両方のChannelに参加 しているメンバー以外には検証可能性がないことは抑えた上で検討 • 秘匿性担保上、およびパフォーマンスチューニング余地拡張上の効 果が大きいが、コストも大きい選択肢 Channelを分割する Copyright © 2021 Oracle and/or its affiliates Org A Org B Org C 34
  35. • ブロックチェーン上に暗号化したデータを書き込み、意図した相手 (復号鍵の所有者)にのみ内容が見られるようにするアプローチ • 共有範囲ごとにChannelやPrivate Data Collectionを切らなくていいた めHLFの構成がシンプルになる • 復号鍵の漏洩リスクに注意:台帳上で既に共有されている既存データ

    は更新できないため、復号鍵が漏洩した場合には漏洩先にそれまでの データを全て復号されてしまう 暗号化して受け渡しする Copyright © 2021 Oracle and/or its affiliates Org A Org B From: A To: B Content: XXXXXX←暗号化 Org C 復号可能 復号不能 35
  36. • 「あるメンバーに読み取りはさせたいが更新はさせたくない」という要件が存在 する場合には、Chaincode内でアクセス制御ロジックを作り込むことで対応する • Chaincode内でトランザクション実行者のIdentityを取得できる(CID;Client Identityライブラリ)ので、そのIdentityのOrganization(MSP)によって制御 する • 関数単位で利用可否(⇨あるデータについてputState,putPrivateDataする関数 を使えるかどうか)を制御するのが基本

    • よくある疑問:Chaincode内のアクセス制御ロジックを使い「読み取りパーミッ ションを付与しない」ことで秘匿性を実現できるのでは??? ⇨ノードの持ち主はChaincode内部で読み取る以外の方法(Block内のTxを読む など)でバイパスできるので基本的には使えない • なお、Channel Policyで設定できるOrganizationのWriter権限は「World Stateや Private Dataを更新できるか」ではなく「ChaincodeをInvokeできるか」の権限 (Queryもできなくなる)なので名前に騙されないように… Tips:更新パーミッションの制御 Copyright © 2021 Oracle and/or its affiliates Org A Org B Chaincode 関数 アクセス制御 Ledger Private Data 36
  37. Chaincodeのオンチェーンアクセス権限制御ライブラリを提供 • ACLを台帳上に記載したうえで(On-chain ACL)、 ACLを参照してChaincodeロジックのアクセス制御する • Chaincode自体のアップデートをすることなく、 動的にACLを更新できるメリット 以下の要素で権限を制御 •

    リソース:アクセスを制御する対象 • アイデンティティ:アクセスする企業やユーザー • グループ:アイデンティティのグループ • アクセス制御リスト: • どのアイデンティティ/グループに • どのリソースに対し • どのような操作(CREATE、READ、UPDATE、DELETE、etc.)を • 許可する/しない 【参考】 更新パーミッション制御の例: Oracle Blockchain Platformの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 37 37
  38. Chaincodeのロジックの内容 • ここまでの検討で概ね決まっているはずなので、基本的には素直に設計していくだけ • 改めてChaincode独特の制約や留意点には引っかからないようにチェック(後の章で説明) • なんらかの問題により適切な実装が困難と考えられる場合には、アプリケーションロジック側に切り 出せないかを再検討する、ChannelやPrivate Dataの構造から再検討するなどして対処が必要 Chaincodeのモジュール分割の粒度

    • 複数の種類の業務を単一Channel内で扱う場合には、それぞれでChaincodeを分けておくことで Endorsement Policyの設計やChaincode Lifecycleが運用しやすくなる • あまり細かく分割しすぎると依存関係が複雑になり、Peerへの各Chaincodeインストール要否やPeer 冗長性の検討、各ChaincodeのEndorsement Policy間の整合性が複雑になるのでほどほどに… 3. Chaincodeを設計する Copyright © 2021 Oracle and/or its affiliates 38
  39. Chaincodeの開発、テスト、デプロイを容易にする開発補助ツール • Chaincodeロジックは台帳/Private Dataに対してのAPIであり、かつ、 データのモデリングそのものを行う • 概ね、組織/人を中心として所有するモノなどの属性の更新を表現し ていくアカウント型のモデルと、モノを中心として状態の推移を表現 していくアセット型のモデル、そして両者の組み合わせいずれか •

    アカウント型の例:ある口座にいくら入っているか • アセット型の例:あるモノを今誰が持っているか 【PR】Oracle Blockchain PlatformのBlockchain App Builder • Visual Studio Codeの拡張機能、およびCI/CD用のCLIツールとして提供 • 宣言的に記述したアセットの属性とメソッドの仕様をもとに Chaincodeのコード、プロジェクトを自動生成 • アセットのCRUD関数が自動生成されるイメージ • ファンジブルアセットについてはアカウント/残高もサポート 【参考】Chaincodeロジックの形態と Oracle Blockchain PlatformのBlockchain App Builderの紹介 Copyright © 2021 Oracle and/or its affiliates 39 39
  40. • Endorsement Policyを設定できるレベルは以下3つ(下位の定義がOverrideし、複数のCollection Level/State-basedポリシーが絡む場合は集積して評価される) • Chaincode Level:Chaincodeインスタンスごとに設定する(Instantiate時パラメータ/ Chaincode Specの中で指定) •

    Collection Level:Private Data Collectionごとに設定する(同上) • State-based:World State/Private Dataの特定のKeyを指定して設定する(World State/Private Dataと同様にトランザクションで更新できる) • あんまり凝ったことをやると必要なPeer冗長性の検討が難しくなるので必要な範囲で…… • 単一のPeerノード内の不正に改造されたロジックによる更新の受け入れを防ぐため、2者以上の Endorsementを要求することが望ましい • n>3以上のn OutOfが必要か、特定のOrgを指定する必要があるかは参加者間の信頼のあり方次第 • 多くの場合はそれほど多数のEndorsement要求は不要なのでは? • Endorsement要求数増は性能上はネガティブな要素 4. Endorsement Policyを設計する Copyright © 2021 Oracle and/or its affiliates 40
  41. 5. Peerの冗長性を確保する ノード、台帳の冗長性確保の必要性 • 「ブロックチェーンではノードが複数あるので冗長性が担保されてい て障害に強い! 互いがバックアップになり台帳のデータが失われる心配がない!」 • パーミッションレス/パブリック型のブロックチェーンの場合は この言及は概ね正しい

    • パーミッションド/コンソーシアム型では必ずしも当てはまらない • コンソーシアム型ネットワークの場合、しばしばあるノードは他 ノードと役割(権限、責任)が等価ではないので互いに代替にな らない • あるノードが持つ台帳のデータサブセット(Tx履歴とStateのサ ブセット)もしばしば他ノードとは異なるのでそのままではバッ クアップにならない Copyright © 2021 Oracle and/or its affiliates クライアント ノード B ノード A 他ノードで 代替可 台帳を Fetchして 復旧可 クライアント ノード B ノード A 他ノードで 代替不可 台帳を Fetchして 復旧不可 役割/台帳が同じ場合 役割/台帳が違う場合 41
  42. 5. Peerの冗長性を確保する Hyperledger Fabricでのアプローチ • 基盤機能として役割&所有データサブセットが等価のノードを複数構成しておくことができることが HLFの強み • 他のブロックチェーン/DLT基盤だと通常のインフラアプローチで個々のノード/バックエンド DBの可用性/耐障害性を確保しておく必要がある

    • HW障害等でPeerノードおよびState DBが消失しても、自Org所有、また、他Org所有のPeerノードか ら台帳およびPrivate Dataをfetchすることでリカバリ可能 • 既存のPeerをリカバリする方法、新規Peerを追加する方法どちらも取れる • ネットワーク全体のスコープで複数Peerノードが同一Channelに参加している&&同一Private Data Collectionを持つ&&同一の役割を持つように構成しておくことで冗長性を確保しておく Copyright © 2021 Oracle and/or its affiliates 42
  43. Organizationの役割を整理する 5. Peerの冗長性を確保する Copyright © 2021 Oracle and/or its affiliates

    Org Channel X Channel Y 参加 CC X 参加 CC Y1 CC Y2 Endorse PDC X1 PDC X2 Endorse Endorse Org A ◦ 必須 ◦ ◦ ◦ 2 OutOf OR(A,B) Org B ◦ 1 OutOf ◦ ◦ 2 OutOf OR(A,B) Org C ◦ 1 OutOf ◦ ◦ × × Org D × ◦ 2 OutOf 必須 ここまでで切り出されてきたデータサブセット、役割を整理した上で、Organizationを軸に付与状況を まとめる • どのデータサブセットを持っているか:Channelへの参加、PDCへの参加 • どのような役割を持っているか:Chaincode Level/Collection Level/State-basedのEndorsement、 (作成していれば)更新権限などのカスタムアクセス制御上の権限など 43
  44. 各OrgでPeerの役割を検討し、ネットワーク全体で整理する • 各Orgで用意するPeer数、PeerごとのChannelへの参加/不参加とChaincodeのInstall有無 (Endorsementに参加できるかどうか)を一旦検討し、それらをマージした上でネットワーク全体で Peerの冗長性が不足ないかをOrganization役割に照らしてチェックする • ある役割に対してOrg内でPeerが冗長になっていると運用面での考慮が楽になる • 冗長性が増す方向での追加、調整はあとから各Orgで個々に実施して良い •

    パフォーマンスの改善のためにPeerを追加してスケールアウトしたり役割を分散させたりする必 要が生じる場合がある • インフラの冗長性、地理分散などが必要な場合はここで各Peerの所在を加味して検討する 5. Peerの冗長性を確保する Copyright © 2021 Oracle and/or its affiliates Org Peer Channel X Channel Y 参加 CC X 参加 CC Y1 CC Y2 Install Install Install Org A A1 ◦ ◦ ◦ × ◦ A2 ◦ × ◦ ◦ × A3 ◦ ◦ × A4 × ◦ ◦ ◦ 44
  45. • ChannelごとにOrdering Serviceクラスタを構成する(ChannelごとにOrderingに参加するOrdererを 指定する) • OrdererにはそのChannelのTransactionが蓄積していく=Ordererの持ち主はそのChannelの台帳の内 容をほぼ把握できる(Private Data内容はOrdererに行かないので読めない) • 基本的にはそのChannelにPeerを参加させているOrgのOrdererでOrdering

    Serviceを組んでいく • コンソーシアムの成り立ちによってはOrderer専任Orgを設ける例も 耐障害性 • Orderingには半数以上(>n/2+1)のOrdererが正常に機能していることが必要 • Ordering Serviceのクラスタ構成変更にも同様の条件 • 半数のOrdererがロストして復旧不能になると当該Channel機能のリカバリが非常に困難になる 性能とのバランス • Ordererが増えるとコンセンサスオーバーヘッドが増え、Orderingの処理性能は低下する • 一定数以上増やすと耐障害性のメリット<性能上のデメリットになる • Orderer数は3、5、7台のどれかとする例が多い(偶数にすると1台無意味なので避ける) 6. Ordering Serviceの構成を設計する(Raft前提) Copyright © 2021 Oracle and/or its affiliates 45
  46. Orderer Organization配下にPeer、Orderer、CAのコンポーネントとクライアントアプリケーション Hyperledger Fabricネットワークの概観図 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 だいたい設計できそう!!! 46
  47. Copyright © 2021 Oracle and/or its affiliates パフォーマンスあれこれ 47

  48. • スループット、ターンアラウンドタイムについてそれぞれ実現可能な規模感を把握しておき、それに 照らして要求が厳しいと思われる場合には注意しておく • ターンアラウンドタイム:ここではクライアントアプリケーションがTransaction Proposalを送信し てからPeerでのvalid/committedイベント通知が届くまで • おおよそ0.x秒後半を見込んでおくとベター •

    ロジックの内容と環境条件によっては、また、スループットに最適化するともっと長くなる場合はある • スループット:ここではあるChannelで1秒間に有効なトランザクションを処理できる件数(TPS) • 複数のChannelから成るネットワーク全体でのスループットはあまり考える意味がない • トランザクションはChannelごとに別々なので、処理を分散できる • 台帳を更新しない(OrdererにTxを送信しない)Peerへのクエリ件数はカウント外 • クライアント⇔Peerのローカルな範囲の話 • トランザクションの内容によって大いに変わるので事前に見込みが立ちづらい • 数千TPS出たよというペーパーはいくつかあるが、あくまで限定的な条件下なので鵜呑みにしない • ~数十はまあリーズナブルかな、~数百で最初から性能要件について注意と努力が必要だな、 千~くらいで細心の注意と大きな努力が必要、くらいのイメージ(個人的な感想) パフォーマンスの目安と向上のための施策 Copyright © 2021 Oracle and/or its affiliates 48
  49. トランザクションのターンアラウンドタイム クライアントから見たときの ターンアラウンドタイムとは: Transaction Proposalを送信~Peerでの valid/committedイベント通知が届くまで ターンアラウンドタイム Copyright © 2021

    Oracle and/or its affiliates 49
  50. ターンアラウンドタイムの内訳 内訳としては2段階: • Transaction Proposalを送信してから必 要なEndorsementが集まるまで • Transactionを送信してからPeerでの valid/committedイベント通知が届くま で

    ターンアラウンドタイム Copyright © 2021 Oracle and/or its affiliates 50
  51. 前半部分:トランザクションのEndorsementフェーズ 要素:各Endorsing Peerの • クライアントとのメッセージ往復時間 • Chaincode実行時間 ☆最も遅い応答に依存 改善材料: •

    PeerのEndorsement負荷分散 • Endorsement要求数を減らす • ネットワーク遅延を減らす • Peerのリソース(CPU/メモリ/IO)を増やす • Chaincodeの内容を見直す ターンアラウンドタイム Copyright © 2021 Oracle and/or its affiliates 51
  52. 後半部分:トランザクションのOrdering+Validation/Commitフェーズ 要素: • メッセージ、ブロック、イベント伝送時間 • Ordering Serviceでのブロック生成時間 • Committing PeerでのValidation/Commit時間

    改善材料: • Ordering Serviceのブロック生成設定を見直す • バッチタイムアウト時間を減らす (デフォルト2秒になってるので…) • Ordering Serviceの構成Ordererを見直す • Ordererを減らす • Ordererの負荷分散 • ネットワーク遅延を減らす • Ordererのリソース(CPU/メモリ/IO)を増やす • Peerのリソース(CPU/メモリ/IO)を増やす ターンアラウンドタイム Copyright © 2021 Oracle and/or its affiliates 52
  53. 必要な性能要件とボトルネックを見極めた上で手当てしていく ボトルネック箇所の特定: • Chaincodeの実行(Endorsement) • Ordering • Validation/Commit ベンチマークツール: •

    Hyperledger Caliperが代表的なツール • 他にPTE(Performance Traffice Engine)、 BlockBenchなど 主なスループットの改善要素: • PeerのChaincode実行時間を減らす • Chaincodeのロジックを改善 • Peerのリソース(CPU/メモリ/IO)を増やす • PeerのChaincode実行(Endorsement)の負 荷を分散する • Ordering Serviceの見直し • バッチタイムアウト時間と最大Tx量を増やす… ターンアラウンドタイムとトレードオフ • Ordererを減らす • Ordererの負荷分散 • Ordererのリソース(CPU/メモリ/IO)を増やす • PeerのValidation/Commitの負荷を分散する • ネットワーク遅延を減らす スループット Copyright © 2021 Oracle and/or its affiliates 53
  54. 同一Keyについての更新スループット追及上の限界 • トランザクションフローにおけるRead-Set Validationの関係で、Endorsement→Validationの間に同 一のKeyを複数回更新することができないという制約がある • この制約が弱みになる苦手パターンがあることは覚えておいたほうがよい • 典型的には「単一口座から高頻度で送金」のユースケース(支払いでマイナスにならないか現残 高のチェックが必要)だとこれがネックになりやすい

    • なお、「単一口座に高頻度で入金」なら回避できる(現残高チェックはいらないので入金額を別 のKeyで記録しておき折を見て集計すればよい)ことにも留意 • 同一のKeyを更新するトランザクションの密度が濃いと、Invalidになるトランザクションの割合が増 えて結果的にスループットが悪化する • 時々Invalidになること自体はクライアントがProposalから再トライすれば良いだけで問題ない • このパターンにハマりそうな場合はデータ構造とChaincodeロジックを見直すことで回避することが できないか検討する スループット Copyright © 2021 Oracle and/or its affiliates 54
  55. 同一レコードに対して頻繁に読み書きするとタイミング次第でしばしば発生する Read-Set Validationで無効になるパターンのシーケンス Copyright © 2021 Oracle and/or its affiliates

    レコード 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 55
  56. Validation/Commitの負荷分散 • Validation/Commitの処理量はPeerの参加するChannelでのトランザクション数に依存 • Peerごとに参加するチャネルを分け、トランザクション数を平準化させる スループット Peer CH1 CH2 CH3

    Block Peer CH1 Block Peer CH2 Peer CH3 Block Block Copyright © 2021 Oracle and/or its affiliates 56
  57. Endorsement負荷分散:Peer側の役割分担 • Chaincodeでの役割分担:PeerごとにインストールするChaincodeを分けておく • チャネルでの役割分担: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 © 2021 Oracle and/or its affiliates 57
  58. Endorsement負荷分散:クライアント側のリクエスト戦略 クライアント側のTransaction Proposalをの分散 候補のOrg、Peerから単純にラウンドロビンやランダムでリクエスト先を選ぶ Chaincode/チャネルでの役割分担を依頼側で行うことも可能 他参加者も同様のリクエスト戦略で行わないと平準化できない スループット Peer Peer Peer

    Peer Peer Peer Peer Peer Copyright © 2021 Oracle and/or its affiliates 58
  59. Copyright © 2021 Oracle and/or its affiliates Appendix. Oracle Blockchain

    Platformのご紹介 59
  60. 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 60
  61. 5つの特長によりエンタープライズでのブロックチェーン活用を加速 Oracle Blockchain Platform Copyright © 2021 Oracle and/or its

    affiliates Oracle Blockchain Platform ✓ ✓ ✓ 61
  62. • 数ステップ、数分で構築完了 • 必要なブロックチェーンネットワーク構成要素は自動でセットアップ • 構築後すぐにコンソール画面の利用やスマートコントラクトのデプロイが可能 Pre-Assembled:簡単、高速に高機能なインフラを構築 Copyright © 2021

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

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

    設定の変更 • ブロックチェーンネットワークのメンバー追加 • 監視とトラブルシューティングも: • ネットワークの視覚化 • リソース使用状況やノード死活情報 • トランザクション処理状況 Easy to Use:運用、管理の手間を削減 Copyright © 2021 Oracle and/or its affiliates 64
  65. • 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 65
  66. オンプレミス、マルチクラウド、ハイブリッドクラウドでの構成が可能 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 66
  67. 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 67
  68. エンタープライズ活用で重要なシステム間の連携をサポートする機能を提供 Quick Integration:他システムとの連携を迅速に実現 Copyright © 2021 Oracle and/or its affiliates

    • REST APIでブロックチェーンが利用可能。 アプリケーション開発および既存システムと の連携が容易に • Oracle Integration Cloudの事前定義済アダプ ターを用いることで、ERPなどの基幹システ ムや各種SaaSとの連携を更に迅速に実現 • ブロックチェーン上のデータをデータベース に複製する機能が付属。複雑な集計、分析な ども高速かつ容易に開発可能 • ブロックチェーンのデータと他システムの データをデータベース上で統合することで、 より高度なデータ活用も可能に Blockchain Integration Database BI 68
  69. REST APIでのブロックチェーン利用でアプリケーション開発が容易に REST REST API Fabric SDK Quick Integration:他システムとの連携を迅速に実現 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 69
  70. リッチヒストリーデータベース:Oracleデータベースにブロックチェーンのデータを複製 • 台帳のデータをブロックチェーン外部のリレーショナルデータベースに複製 • ブロックチェーンが苦手とする複雑な参照処理(集計、分析)を、 データベース側で実装可能に • 多くの開発者が慣れ親しんでいるOracleデータベースでの開発 • Oracle

    Analytics Cloudをはじめとした多種多様なBIツールの利用 • 他システムとのデータ統合も一般的なツールとノウハウで容易に実現可能 • ERP、SCMなどの基幹システムとブロックチェーンのデータを 統合することで、データの価値を最大限に活用 Quick Integration:他システムとの連携を迅速に実現 Copyright © 2021 Oracle and/or its affiliates State DB World State 台帳(Ledger) 70
  71. 現在および過去のデータを複製することで、様々な用途と角度で利用可能 リッチヒストリーデータベースによるブロックチェーン上のデータの複製 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 71
  72. 複製先テーブルとしてBlockchain Tableに対応&チャネルごとにDBを分けられるように • データベース上にデータを複製する際に、格納先と してBlockchain Tableを選択可能に • 複製データにも更新や削除をできない耐改ざん性、更 新や削除されていないデータとしての証跡性を付与 •

    複製データもブロックチェーン台帳上のデータと同 様、信頼に足る情報、証跡として扱うことが可能に • 対象は履歴を追記で蓄積していくHistoryおよび Transaction Details • 併せて、チャネルごとに複製先に別々のデータベー スを 設定可能に • 分析用データベース、監査証跡蓄積用データベースな ど、チャネルのデータのタイプごとに用途別データ ベースを使い分けるなど リッチヒストリーデータベースの機能拡張(2021年2月Update) 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 複 製 複 製 72 72
  73. 台帳上のレコード(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 73 Copyright © 2021 Oracle and/or its affiliates 73
  74. 台帳上のレコードの値の履歴(過去バージョン~現在バージョン)を格納 リッチヒストリーデータベースのテーブル: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 74 Copyright © 2021 Oracle and/or its affiliates 74
  75. 台帳上のトランザクションの履歴を格納 リッチヒストリーデータベースのテーブル: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 75 Copyright © 2021 Oracle and/or its affiliates 75
  76. 台帳上のトランザクションの履歴を格納 リッチヒストリーデータベースのテーブル: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 76 Copyright © 2021 Oracle and/or its affiliates 76
  77. Chaincodeのオンチェーンアクセス権限制御ライブラリを提供 • ブロックチェーン台帳上のデータへのアクセス権限を ブロックチェーン台帳上に記述して管理 • Hyperledger Fabricの標準機能よりも細かく、かつ、 扱いやすいアクセス権限制御を容易に実現 以下の要素で権限を制御 •

    リソース:アクセスを制御する対象 • アイデンティティ:アクセスする企業やユーザー • グループ:アイデンティティのグループ • アクセス制御リスト: • どのアイデンティティ/グループに • どのリソースに対し • どのような操作(CREATE、READ、UPDATE、DELETE、etc.)を • 許可する/しない 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 77 77
  78. 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 78 78
  79. 利用料金の構成は、選択したインスタンスタイプにより ① or(②+③)のどちらかになります: • 2つのインスタンス・タイプ(CPU数×使用時間) • ①Standard:2 OCPUで固定、ストレージは50GB付属で追加不可、非HA構成 • ②Enterprise:OCPU拡張可能(最小4

    OCPU)、ストレージは150GB付属で追加可能、HA構成可能 • ③追加ストレージ(TB/月) インスタンス停止中のOCPU分の料金は25%に低減されます • 例:インスタンスを月20日×8時間稼働(残りは停止)させた場合の月額: • ( 15789.6 • ( 63173.088 Oracle Blockchain Platform Cloud Service (Gen 2)の価格体系(2021年5月時点) Copyright © 2021 Oracle and/or its affiliates 79
  80. Oracle Blockchain & PoC 1/2 Copyright © 2021 Oracle and/or

    its affiliates 80
  81. Oracle Blockchain & PoC 2/2 Copyright © 2021 Oracle and/or

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

    https://youtu.be/HZ0Si8Xcz_8 Copyright © 2021 Oracle and/or its affiliates 82 Copyright © 2021 Oracle and/or its affiliates 82
  83. 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 83 Copyright © 2021 Oracle and/or its affiliates 83
  84. 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 84 Copyright © 2021 Oracle and/or its affiliates 84
  85. Thank you Copyright © 2021 Oracle and/or its affiliates 85

  86. None