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

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のネットワーク構成を設計する • パフォーマンスあれこれ •

    Chaincodeあれこれ • 整合性あれこれ ※なお、文中のHLF=HyperLedger Fabric 資料の内容 Copyright © 2021 Oracle and/or its affiliates 5
  6. • はじめに;入門編の振り返り • 設計の前提を整理する • Hyperledger Fabricのネットワーク 構成を設計する • パフォーマンスあれこれ

    • Chaincodeあれこれ • 整合性あれこれ 補足 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 Chaincodeあれこれ 59

  60. ステートマシン • 現在の状態(State)と入力条件によって次の状態に遷移 • 入力条件とはたとえば処理内容(e.g. 起動する、停止する、値を増やす/減らす)や、処理内容に対 して外部から与えられる引数(e.g. いくつ値を増減する) Chaincode Taboos①:非-決定性

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

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

    全てのノードがそれぞれスマートコントラクトを実行してステートを遷移させる • 一部(単一または複数)のノードでスマートコントラクトをシミュレーション実行し、 事後状態となるステートを伝播する • Hyperledger Fabricのコンセンサスモデルはこちら(EndorsementでSC実行 ⇒ Orderingでブロック配布 ⇒Validationでコミット) Chaincode Taboos ①:非-決定性 Copyright © 2021 Oracle and/or its affiliates 62
  63. Chaincodeの決定性がなぜ必要か • Chaincodeにはそのインプットとして常に台帳の現在ステートとクライアントからの入力値(引数) が存在する • 複数ノードでそれぞれChaincodeが実行された結果に含まれる事後ステート=Write-Setが同一になっ ていないとならない • 異なるWrite-Setを集めてきてもEndorsement Policyを満たさない

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

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

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

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

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

    このような要求に対して、中立かつ信頼できるかたちでネットワーク外部の情報を提供するサービス をオラクル(Oracle、託宣)と呼ぶ • オラクルが確定した(不変の)情報を自身の署名付きで提供することで、偽装や改ざんが不能でコン センサスに取り入れられる外部情報が利用できる • しかし署名の検証をどう行うかまで考慮が必要となるなど、オラクル利用はすごく難しい Chaincode Taboos①:非-決定性 Copyright © 2021 Oracle and/or its affiliates 68
  69. • 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” • 対処法は一時変数を用意するだけなので簡単だが、知らないとたまにハマるので注意 Chaincode Taboos②:Read My Writes Copyright © 2021 Oracle and/or its affiliates 69
  70. CouchDBでのリッチクエリ使用時のPhantom Read問題にかかる制約 • HLFではState DBとして利用しているデータベース側の機能を利用し、そのデータベースネイティブ のクエリ文によりWorld StateおよびPrivate Dataの検索を行うリッチクエリを利用することができる • どのようなリッチクエリを使えるかはState

    DBとして利用するデータベースに依存する • リッチクエリはレンジクエリの一種であり、ゼロ~複数の結果セットを取得することができる • CouchDBを利用している場合は、ValueをJSONにして格納しておくことにより、JSONの属性を指定 し、その値を条件にフィルタするクエリ(⇨JSONリッチクエリ)をChaincode内で利用することがで きる • 例:{“owner” : “Bob”, “color” : “Red”, “size” : “100” }というような項目を持ったmarbleアイテムに 対して、ownerがBobである、colorがRedでない、sizeが50より大きいといった条件で検索す • Chaincodeのロジック表現力を拡大できる便利なリッチクエリではあるが、CouchDBでのJSONリッ チクエリには後述する問題があり、(特別に対策を設けない限り)更新トランザクションの中で利用 してはならないという制約がある Chaincode Taboos③:Phantom Read問題 Copyright © 2021 Oracle and/or its affiliates 70
  71. HLFではEndorsement・Ordering・Validationコンセンサスモデルをとっており、更新トランザクション の場合、基本的な流れは以下となる • Endorsement:Chaincodeを実行し、更新するレコードを抽出したうえで、そのRead/Writeの値 セット(更新前後の値)を採取 ※ここではコミットしない • Ordering:トランザクションの順序を決定 • Validation:Read値がEndorsement時から変更されていないか検証したうえで、Write値を台帳にコ

    ミット 「どのレコードを更新すべきか」の決定がEndorsement時に行われるが、EndorsementとValidationの 間に他のトランザクションによるコミットが入る場合があるため、Validationでは更新すべきレコード セットを確認するためにクエリを再実行するべきである CouchDBのPhantom Read問題:説明① Copyright © 2021 Oracle and/or its affiliates 71
  72. State DBがCouchDBであり、かつ、更新すべきレコードセットの抽出にリッチクエリを使用している場 合、Validation時にリッチクエリは再実行されない • これにより後述の例で説明するような「取りこぼし」が生じる可能性がある • 現状HLFではこのCouchDBのPhantom Read問題は解決が困難であるとして、更新を伴うトランザク ションでのリッチクエリ使用上の制約として扱われている なお、Oracle

    Blockchain PlatformではState DBとしてBerkeley DBを採用しており、リッチクエリを使用 する場合もValidation時にクエリが再実行される • 再実行時に抽出したレコードセットとEndorsement時に抽出したレコードセットが異なる場合には トランザクションはinvalidと判定され、コミットは中止される • 「取りこぼし」は検知可能なため、更新トランザクションでもリッチクエリ使用可 • Oracle Blockchain PlatformのBerkeley DBではJSONをValueとして格納しておくと、以下ふたつの形 式のリッチクエリを利用可能(いずれについてもPhantom Read問題は回避) • CouchDB互換のJSONリッチクエリ • SQLリッチクエリ CouchDBのPhantom Read問題:説明② Copyright © 2021 Oracle and/or its affiliates 72
  73. 物の所有権をHLFの台帳上で管理しており、初期状態は以下とする CouchDBのPhantom Read問題:事象の例① Item ID (Key) Owner (Valueの一部) Item1 Alice

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

    初期状態 中間状態(Tx1後) 結果(Tx2後) Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Bob Item ID 初期状態 中間状態(Tx1後) 意図しない結果 Item1 Alice Alice Bob Item2 Bob Bob Bob Item3 Carol Alice Alice 取りこぼし Copyright © 2021 Oracle and/or its affiliates 74
  75. トランザクションが以下の時系列で処理されると意図しない結果が発生する • 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 75
  76. V2 でAliceの持ち物であるにもかかわらず、Item3の取りこぼしが生じている 更新レコードを決定するE2 時点でAliceの持ち物ではなかったため 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 76
  77. Tx2 での更新対象はItem1のみであり、Item3はTx2 の更新対象ではないため、 V2 でのRWセットの検証にはItem3は含まれず「取りこぼし」は検知できない 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 V2 Validation Copyright © 2021 Oracle and/or its affiliates 77
  78. • 単一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されていることが必 要 • 単一Channel上であれば複数のChaincodeが絡んでも単一トランザクションとなり、RWSetも共有し ている Chaincode Tips①:単一チャネル上での複数Chaincodeの相互呼び出し Copyright © 2021 Oracle and/or its affiliates 78
  79. • 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 Tips②:クロスチャネルのChaincode呼び出しに関わる制約 Copyright © 2021 Oracle and/or its affiliates 79
  80. • クライアント側から複数ChannelのChaincodeを同時、並列にInvokeすることは可能 • ただし複数ChannelをまたぐアトミックトランザクションはHLFの機能としては実現できない • そもそもHLF内のトランザクションはロールバックできず、したがって2フェーズ/3フェーズコミッ トなどの分散トランザクション制御の仕組みも適用できない • トランザクション順序はChannelごとにしか保証されない •

    複数Channelでトランザクションを並列実行した場合、それぞれのChannelのトランザクション結 果が台帳に反映される順序は保証されない(個々のPeerによって異なる可能性がある) • あるChannelのトランザクション事前&事後ステートに依存して別のChannelでのトランザクション を並列実行すると、同時に他のクライアントが逆の依存関係で並列実行していた場合にハマるパター ンがある • 基本的にはトランザクションChannelごとに順次、直列に実行していく(あるChannelでの結果が CommitされたEventを待ってから次のChannelでのトランザクションを実行する)ようにしたほうが よい Chaincode Tips③:複数チャネルでのトランザクション並行起動時の注意 Copyright © 2021 Oracle and/or its affiliates 80
  81. • Chaincodeから台帳のBlockchain部分に記録されているキー履歴、トランザクション履歴を利用する ことができる • が、これらの履歴はValidationでのトランザクション保護に含まれない(Read Setに載らないため、 Read Set Validationの対象ではない) •

    クライアントアプリケーション側で安全を保証できない限りは、台帳を更新するトランザクション内 でのChaincodeで履歴を利用することは避ける Chaincode Tips④: 更新トランザクションでのキー履歴、トランザクション履歴の利用 Copyright © 2021 Oracle and/or its affiliates 81
  82. Copyright © 2021 Oracle and/or its affiliates 整合性あれこれ 82

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

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

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

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

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

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

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

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

    its affiliates 90
  91. • 複数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 91
  92. 複数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 92
  93. Copyright © 2021 Oracle and/or its affiliates Appendix. Oracle Blockchain

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

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

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

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

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

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

    Analytics Cloudをはじめとした多種多様なBIツールの利用 • 他システムとのデータ統合も一般的なツールとノウハウで容易に実現可能 • ERP、SCMなどの基幹システムとブロックチェーンのデータを 統合することで、データの価値を最大限に活用 Quick Integration:他システムとの連携を迅速に実現 Copyright © 2021 Oracle and/or its affiliates State DB World State 台帳(Ledger) 104
  105. 現在および過去のデータを複製することで、様々な用途と角度で利用可能 リッチヒストリーデータベースによるブロックチェーン上のデータの複製 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 105
  106. 複製先テーブルとして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 複 製 複 製 106 106
  107. 台帳上のレコード(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 107 Copyright © 2021 Oracle and/or its affiliates 107
  108. 台帳上のレコードの値の履歴(過去バージョン~現在バージョン)を格納 リッチヒストリーデータベースのテーブル: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 108 Copyright © 2021 Oracle and/or its affiliates 108
  109. 台帳上のトランザクションの履歴を格納 リッチヒストリーデータベースのテーブル: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 109 Copyright © 2021 Oracle and/or its affiliates 109
  110. 台帳上のトランザクションの履歴を格納 リッチヒストリーデータベースのテーブル: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 110 Copyright © 2021 Oracle and/or its affiliates 110
  111. 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 111 111
  112. 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 112 112
  113. 利用料金の構成は、選択したインスタンスタイプにより ① 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 113
  114. Oracle Blockchain & PoC 1/2 Copyright © 2021 Oracle and/or

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

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

    https://youtu.be/HZ0Si8Xcz_8 Copyright © 2021 Oracle and/or its affiliates 116 Copyright © 2021 Oracle and/or its affiliates 116
  117. 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 117 Copyright © 2021 Oracle and/or its affiliates 117
  118. 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 118 Copyright © 2021 Oracle and/or its affiliates 118
  119. Thank you Copyright © 2021 Oracle and/or its affiliates 119

  120. None