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

Blockchain GIG#9 Hyperledger Fabric(再)入門

Blockchain GIG#9 Hyperledger Fabric(再)入門

2021/5/25 Blockchain GIG#9でしゃべった内容
Hyperledger Fabric入門

4b09160b087e45103b210ef95079cee4?s=128

gakumura

May 25, 2021
Tweet

Transcript

  1. Blockchain GIG #9 今度こそわかる! Hyperledger Fabric(再)入門 中村 岳 日本オラクル株式会社 2021/5/25

  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を構成する基本的な要素 • トランザクションフロー • ChannelとPrivate Data

    ※なお、文中のHLF=HyperLedger Fabric 本セッションの内容 Copyright © 2021 Oracle and/or its affiliates 5
  6. Copyright © 2021 Oracle and/or its affiliates 6 はじめに

  7. エンタープライズ用途を目的として開発されたブロックチェーン Hyperledger : Linux財団がホストするオープンなコミュニティ • 世界で最も成功したOSS=Linuxでの成功実績に基づいた運営 • さまざまな業種の企業およびIT企業、研究機関が240以上参加 • Fabricをはじめ、複数ブロックチェーン/DLT基盤およびツール等をOSSとして開発

    Fabric : エンタープライズ領域汎用用途のためのブロックチェーン基盤 • メンバー管理サービスを備えたパーミッションドブロックチェーンを実装 • セキュリティ、機密性/プライバシーを強化するための多様な機能 • スマートコントラクトによって業務を自動化 • 大量処理をサポートするためのスケーラブル、プラガブルな設計 • マイニングなどの大規模コンピューターパワー投入は不要&ファイナリティ有 Hyperledger Fabric Copyright © 2021 Oracle and/or its affiliates 7
  8. Hyperledgerのラインナップ Copyright © 2021 Oracle and/or its affiliates 8 The

    Hyperledger Greenhouse From:https://www.hyperledger.org/
  9. ネットワーク参加の制限有無によるブロックチェーンの分類 Copyright © 2021 Oracle and/or its affiliates 9 •

    誰でもネットワークに参加しノードを持てる (公開制、オープン、匿名性) • 経済的インセンティブによって不正を抑止する 比較的低速なトランザクション処理 パーミッションレス a.k.a. パブリック • 招待されたメンバーのみが参加しノードを保持 (許可制、クローズド、顕名) • メンバーを識別、一定程度信頼できることに依拠した 高速なトランザクション処理 パーミッションド a.k.a. プライベート
  10. ネットワークの参加者によるブロックチェーンの分類 Copyright © 2021 Oracle and/or its affiliates パブリック 公開制のネットワークを

    不特定多数で運用 コンソーシアム 許可制のネットワークを 複数組織で運用 プライベート 許可制のネットワークを 単一組織で運用 パーミッションレス← →パーミッションド 10
  11. よく比較検討されるエンタープライズブロックチェーン基盤 a.k.a.「3大エンタープライズブロックチェーン」 • 共通点は… • 許可制のネットワークを構成できる • コンソーシアムでの活用を意図した機能を備えている • すでに多くの利用実績がある

    • 基盤によって思想、個性の違いがあり、その結果としてユースケー スの得意不得意がある 11 Copyright © 2021 Oracle and/or its affiliates Quorum (& Besu) Hyperledger Fabric Corda
  12. しばしば「Hyperledger Fabricは難しい」と言われがちだが、「難しい」点は概ね以下3つ: • 機能が多く、要素と構造が多層的に絡みあっており複雑 • トランザクションフローが独特 • サンプルネットワーク構築チュートリアルのステップ数、必要となる前提知識が多い 理解を妨げるありがちなパターンは: •

    そもそも(エンタープライズ)ブロックチェーンに親しんでおらず、なぜコンセンサス取らないとい けないのか、など前提からわかっていない • EthereumやQuorumを知っているが故に、そちらに引きずられてHLF独特の要素に混乱する • トランザクションフローの仕組みの意図、理由がわからない • 要素と構造同士の関係がこんがらがる なぜ「Hyperledger Fabricは難しい」のか Copyright © 2021 Oracle and/or its affiliates 12
  13. • 機能が多く、要素と構造が多層的に絡みあっており複雑 • トランザクションフローが独特 • サンプルネットワーク構築チュートリアルのステップ数、必要となる前提知識が多い 「難しい」要素の傾向と対策 Copyright © 2021

    Oracle and/or its affiliates 13 Docker、NW設定など引っかかるところが多くネットワーク構築でめげてしまいがち • クラウド上で利用できるテンプレートやBaaSを利用してスキップしてしまうのがオススメ • 最近は公式ドキュメントやブログなどの情報も徐々に充実、親切になってはきている • 背景にある目的、思想をまずは抑えておくと理解しやすくなる • 他ブロックチェーン基盤にはないHLF独特なポイントを意識して学ぶと混乱しにくい
  14. なぜ複雑なトランザクションやデータ構造などの仕組みが必要になるのか? • ブロックチェーン/DLTは一般に、 (単一の管理体ではなく)複数の個人や組織が分散して所有・管理 するノード間でのデータ複製を確実に行う という「お題」に取り組んでいる(と捉えられる) • 故障やミスだけでなく悪意にも備える必要がある • 他参加者のノードは不正に改造されたものかも

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

    • ネットワークメンバー数とトランザクション処理能力のスケーラビリティを確保する Hyperledger Fabricの特色 Copyright © 2021 Oracle and/or its affiliates 15
  16. Copyright © 2021 Oracle and/or its affiliates 16 1. Hyperledger

    Fabricを構成する基本的な要素
  17. 凡例 D社 C社 B社 A社 ノード シンプルなコンソーシアム型ブロックチェーンの ネットワーク超概観図 Copyright ©

    2021 Oracle and/or its affiliates 17 SC L ノード SC L ノード SC L ノード SC L 個社 アプリ ブロックチェーン ネットワーク 個社 アプリ 共有 アプリ オペレーター 他システム SC スマート コントラクト L 台帳
  18. Orderer Hyperledger Fabricネットワークの概観図 18 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
  19. 独特な点:ブロック生成専用のノードの分離と階層型アイデンティティの採用 Organization • ネットワークに参加するメンバーの 「組織」を表す抽象的な単位 • コンポーネントやユーザーが所属 Peerノード • 台帳(World

    StateとBlockchain)を保持 • Chaincodeをリクエストに応じて実行する Ordererノード • ひとつ~複数のOrdererノードでOrdering Serviceを構成 • トランザクションの順序を確定し、ブロック を生成しPeerノードに配布 Chaincode(スマートコントラクト) • 台帳の更新、照会のビジネスロジック クライアントアプリケーション • Hyperledger Fabricを利用するアプリ CA(Certificate Authority) • 各コンポーネントやユーザーのアイデンティ ティ(証明書)を発行するPKIの認証局 • 通常、Fabric CAを利用するが他の実装も利用 可能 登場する要素、コンポーネント 19 Copyright © 2021 Oracle and/or its affiliates
  20. Orderer Organization 20 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
  21. コンポーネント、ユーザーが所属するアイデンティティレイヤー • HLFにはネットワークに参加する主体(多くの場合は企業などの組 織の単位、時には個人)を表現するための抽象アイデンティティレ イヤーであるOrganization(Org)がある • Ordererノード、PeerノードおよびCAのコンポーネント、また、ア プリケーションが用いるユーザーのアイデンティティは、 必ずいずれかひとつのOrgに属する •

    (他の基盤のように具体的な秘密鍵単位ではなく) 「どのOrg配下のコンポーネント/ユーザーか」に基づいて オペレーション、ガバナンス、ネットワーク構成を設計できる • PKIの階層構造と結びついている • 自身のOrg配下のコンポーネントやユーザー用の秘密鍵/証明書 は自身のCAで発行する Organization Copyright © 2021 Oracle and/or its affiliates 21 Network Organization A Ordererノード Peerノード Adminユーザー Clientユーザー Organization B Ordererノード Peerノード Adminユーザー Clientユーザー Ordererノード Peerノード Adminユーザー Clientユーザー CA
  22. Peer Peerノードが保持する分散台帳の1コピー Hyperledger Fabricにおける「台帳」 22 • 台帳は以下ふたつの要素から構成される + Blockchain:履歴 •

    トランザクションの履歴が格納される ハッシュチェーンで連結されたブロックのファイル • 追記オンリーで蓄積していく World State:状態 • 各Keyに対する現在(最新)バージョンの値を保持 • レコードは更新、削除が可能 (履歴はBlockchainに残っている) • State DBと呼ばれるDBに格納される Ledger Peer Ledger Peer Ledger Peer Ledger Copyright © 2021 Oracle and/or its affiliates
  23. 台帳に保存される「現在の値(ステート)」とそれを保持するデータベース 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 23 Copyright © 2021 Oracle and/or its affiliates
  24. ある程度柔軟なデータ構造を扱え、State DBによる検索の表現能力もそこそこ World Stateで扱うデータ構造の例 Copyright © 2021 Oracle and/or its

    affiliates 24 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のアセットを全件取得)
  25. State DB内ではレコードにはKeyとValueの他にも以下の情報が付随している • Channel、Chaincode ID…どのChannelのどのChaincodeのレコードかを表し、名前空間として機能 (Channel+Chaincode ID+Keyで一意) • Version…そのレコードはどのBlockのどのTransactionにより書き込まれたものかを示し、トランザク ションの整合性検証に使用される(後で説明)

    State DB内に保持されているデータの付随情報 Copyright © 2021 Oracle and/or its affiliates 25 Channel Chaincode ID Key Value Version ch1 accountCC 1020345 10,000,000 Block17,Tx5 ch1 motorCC car^aaa111 {hogehoge... Block3,Tx1 ch2 marbleCC marble123 {fugafuga... Block1,Tx3 ch2 accountCC 3040567 300 Block1,Tx4
  26. Hyperledger Fabricにおけるスマートコントラクト • 所謂「スマートコントラクト」だが、単に「台帳の読み書きのロジック」と考えるとわかりやすい • 「RDBにおけるストアドプロシージャのようなもの」という説明もある • HLFでは多くの場合、Chaincodeはそれほど複雑にも大規模にもならない • 認証認可やプライバシーを基盤機能で担当するのでChaincode側でやるロジックはそれほどない

    • Ethereumにおけるスマコン(ERC、Open Zeppelin、etc.の学習が必須)とは事情はかなり異なる • 専用のライブラリを組み込んで台帳(World StateおよびBlockchain)にアクセス • 機能数は限られており習得は難しくない • Chaincode開発言語の選択肢:Node.js、Go、Java Chaincode Copyright © 2021 Oracle and/or its affiliates 26 Peerノード Ledger Chaincode
  27. • 各々が自身のPeerにInstallした後に、Channelで有効化することで実行可能に • 有効化の手続きはv1.x系とv2.x系で異なる(v2.x系ではオペレーションが一層分権化) • バージョンアップ可能:Chaincodeはバージョンアップできるため、稼働後も修正や改善が可能 • 新バージョンで旧バージョンのChaincodeが書いたレコードにもアクセスできる Chaincodeのライフサイクル Copyright

    © 2021 Oracle and/or its affiliates 27 Install 有効化 Upgrade 新バージョン のInstall 各Orgで行う ローカルな オペレーション ネットワークの オペレーション 新バージョン 稼働
  28. Hyperledger Fabricの種々の機能を利用するアプリケーション • クライアントアプリケーションはFabric SDKを通じてHLFの機能を使う • 基本的には台帳に関する読み書き関連の機能を利用 • Peerノードに対してChaincode実行を依頼する •

    Peerノードから返ってきたEndorsementを集める • Ordering ServiceにTransactionを送付する • 機能の利用にあたってはCAから発行された秘密鍵/証明書を用いて認証する • Fabric SDKはNode.js版とJava版が正式リリース クライアントアプリケーション Copyright © 2021 Oracle and/or its affiliates 28 Client App Fabric SDK Peerノード Ledger Chaincode 証明書
  29. メッセージのデジタル署名とその検証 Copyright © 2021 Oracle and/or its affiliates 29 Client

    App Orderer Orderer Client App Peer Peer MSP MSP MSP MSP • HLFの各種モジュール間でやり取りされるメッセー ジにはデジタル署名が付与されている • これにより、不正な送信者の介入や、メッセー ジ内容の中途での改ざんを防いでいる • 署名の検証は各コンポーネントの持つMSP (Membership Service Provider)というモジュー ルが担う
  30. 独特な点:ブロック生成専用のノードの分離と階層型アイデンティティの採用 Organization • ネットワークに参加するメンバーの 「組織」を表す抽象的な単位 • コンポーネントやユーザーが所属 Peerノード • 台帳(World

    StateとBlockchain)を保持 • Chaincodeをリクエストに応じて実行する Ordererノード • ひとつ~複数のOrdererノードでOrdering Serviceを構成 • トランザクションの順序を確定し、ブロック を生成しPeerノードに配布 Chaincode(スマートコントラクト) • 台帳の更新、照会のビジネスロジック クライアントアプリケーション • Hyperledger Fabricを利用するアプリ CA(Certificate Authority) • 各コンポーネントやユーザーのアイデンティ ティ(証明書)を発行するPKIの認証局 • 通常、Fabric CAを利用するが他の実装も利用 可能 (再掲)登場する要素、コンポーネント 30 Copyright © 2021 Oracle and/or its affiliates
  31. Copyright © 2021 Oracle and/or its affiliates 31 2. トランザクションフロー

  32. • HLFのトランザクションはフローが独特で「まわりくどい」「わかりづらい」と言われがち • ここでトランザクションとは、台帳を更新する一連の(1セットの)処理 • しかしトランザクションの流れの理解は必須(細部はさておき) • トランザクションフローの理解が不足していると… • 発生するエラー(無効なトランザクション)の原因が理解できず対処できない

    • 不適切なChaincodeロジックおよびアプリケーションロジックを設計してしまう • パフォーマンスに問題が生じたときにボトルネックが特定できず対処できない • 各フェーズでのアクションが何のために行われているのか、全体としてどうしてそのような作りに なっているのか、の目的を意識して学ぶと理解しやすい トランザクションフローをなぜ理解するべきか、どう学ぶべきか Copyright © 2021 Oracle and/or its affiliates 32
  33. • 「Hyperledger FabricのコンセンサスアルゴリズムはPBFT」はまちがい • HLF v0.6ではPBFT(Practical Byzantine Fault Tolerant)だった •

    HLF v1.0以降はPBFTではない • 「Hyperledger FabricのコンセンサスアルゴリズムはRaft」も微妙 • RaftはOrdering Serviceのコンセンサスアルゴリズム(のオプションのひとつ)である • Q. 「じゃあHLF のコンセンサスアルゴリズムはなんなんですか?」→A. 「……。」 • HLFの公式ドキュメントでは「コンセンサスアルゴリズム」という語は使わず、 「トランザクションフロー」として説明しているのでここでもそれに倣う • 一応書き添えておくとPoWなどにある多大な電力消費とは無縁 説明に入る前に… Copyright © 2021 Oracle and/or its affiliates 33
  34. Endorsement・Ordering・Validationの3フェーズから構成 Endorsement:トランザクションの内容について合意する • クライアントアプリケーションからPeerにChaincode実行依頼(Transaction Proposal)を送付 • PeerノードがChaincodeを実行(※)し署名を付けて結果(Endorsement)を返却 • クライアントはEndorsement Policyで定められた必要な分のEndorsementを収集する

    (※)この時点では台帳に反映しないため「シミュレーション実行」と言われることもある Ordering:トランザクションの順序を確定しブロックを生成・配布する • Endorsementを集め終えたクライアントアプリケーションがTransactionを送付 • 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布 Validation:トランザクションの有効性を検証したうえで反映する • Peerがブロック内のTransactionを検証し台帳に反映(コミット) 3フェーズのトランザクションフロー 34 Copyright © 2021 Oracle and/or its affiliates
  35. トランザクションフローの図 Copyright © 2021 Oracle and/or its affiliates 35 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
  36. 36 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
  37. 何を、何のためにやっているのか? 再掲)Endorsement:トランザクションの内容について合意する • クライアントアプリケーションからPeerにChaincode実行依頼(Transaction Proposal)を送付 • PeerノードがChaincodeを実行(※)し署名を付けて結果(Endorsement)を返却 • クライアントはEndorsement Policyで定められた必要な分のEndorsementを収集する

    (※)この時点では台帳に反映しないため「シミュレーション実行」と言われることもある Endorsementフェーズの意図 • 別の組織が所有する複数のPeerで同一のChaincode(=事前合意されたロジック)を実行し、同一の 結果になること(=トランザクション内容についての合意)を担保する • 以下のような事態を防ぐことができる • 自身の所有するPeerのみに依頼し、都合よく改変した不正なロジックを実行させ、その結果を正 としてトランザクションが進んでしまう • 単一のPeerの持つなんらかの不具合、ミス、障害あるいは悪意により不正な状態になった台帳の データをもとにトランザクションが進んでしまう Endorsementフェーズ 37 Copyright © 2021 Oracle and/or its affiliates
  38. トランザクション内容へのPeerの「裏書」 Endorsement:Chaincode実行結果にPeerが署名したもの • クライアントは複数Peerから「同一の」実行結果を集める必要がある (値がバラバラだと無効) Endorsement Policy:あるトランザクションを台帳に反映するために、どのようなEndorsementを集め てこなければならないかを予め定義した条件(どうしたらコンセンサスが取れたことになるか) • 柔軟な設定が可能

    • EndorsementはPeer単位ではなく、Organization単位でカウントされる • 単一のOrg配下の複数Peerから取ってきても意味がない シンプルなEndorsement Policyの例:Org 1,2,3で構成されるネットワークの場合に、 • AND(‘Org1.member’, ‘Org2.member’, ‘Org3.member’) // 全Org必須 • OR(‘Org1.member’, ‘Org2.member’) // Org1かOrg2どちらかひとつ • OutOf(2, ‘Org1.member’, ‘Org2.member’, ‘Org3.member’) // いずれか2つ EndorsementとEndorsement Policy Copyright © 2021 Oracle and/or its affiliates 38
  39. 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 39
  40. ある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 40 • K1とK2のレコードを読んでいる • それぞれバージョンは”1” • K1に”V1”という値を、K3に”V2”という値を それぞれ書き込もうとしている • K4のレコードを削除しようとしている
  41. 再掲)Ordering:トランザクションの順序を確定しブロックを生成・配布する • Endorsementを集め終えたクライアントアプリケーションがTransactionを送付 • 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布 Ordering Service内にもコンセンサスがある: • Ordering

    Serviceは1~複数のOrdererノードから成るクラスター • このクラスターの中で受け取ったTransactionの順序を合意し決定している(現在はRaftを利用) Orderingフェーズ Copyright © 2021 Oracle and/or its affiliates 41 Client App Orderer Orderer Orderer Client App Client App Tx1 Tx2 Tx3 Block Tx1 Tx2 Tx3 Peer Peer Peer
  42. ブロック生成ノードを分権で持つ+冗長性により耐障害性を確保 Ordering Serviceのクラスターとコンセンサス(Raftの場合) Copyright © 2021 Oracle and/or its affiliates

    42 Peer Chain Code Ledger Client App Orderer Orderer Orderer Client App Client App Peer Chain Code Ledger Peer Chain Code Ledger L Raft コンセンサス どのOrdererノードに到達して もクラスター内で共有される その時点でLeaderの役割 を持っているノードが Blockを生成する
  43. Peer Ledger トランザクションの有効性を検証したうえで台帳に反映する • Validation:Blockを受け取った各Peerは、含まれるTransactionそれぞれを検証する • Endorsement Policyを満たしているか(含:各Endorserの戻したRWSetの比較) • 各署名(クライアント、Endorser、Orderer)は正しいか

    • Read-Set Validation:Read-Setに含まれるKeyのバージョンが自身の現在のWorld Stateのそれと 一致しているか • Commit:ValidなTransactionについてはWrite-Setの値をWorld Stateに反映 • 併せて、Block、Transactionの内容およびメタデータをBlockchain部に保存 Validationフェーズ Copyright © 2021 Oracle and/or its affiliates 43 Block Tx1 Tx2 Tx3 World State
  44. 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 44 World State <read key=“A", version=“3"> <write key=“A", value=“800”> Key Value Version A 0 4 不一致
  45. ロジックとデータの整合性がおかしくなってしまう例 例:残高1000円の口座Aから1000円引き落とすTx1と200円引き落とすTx2をほぼ同時に発行 • Endorsement: • Tx1:1000円の状態を読んで1000円マイナスし0円に更新する(予定、Write-Set) • Tx2:1000円の状態を読んで200円マイナスし800円に更新する(予定、Write-Set) • Ordering:Tx1→Tx2の順序に決定

    • Validation: • Tx1反映後:0円を書き込み • Tx2反映後:800円を書き込み←1000円の口座から計1200円引き落としたはずなのに… こういう場合はTx2は無効になってほしいのでRead-Set Validationで検出する もしRead-Set Validationをしていなかったら… Copyright © 2021 Oracle and/or its affiliates 45
  46. 同一レコードに対して頻繁に読み書きするとタイミング次第でしばしば発生する Read-Set Validationで無効になるパターンのシーケンス Copyright © 2021 Oracle and/or its affiliates

    46 レコード 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
  47. Endorsement・Ordering・Validationの3フェーズから構成 Endorsement:トランザクションの内容について合意する • クライアントアプリケーションからPeerにChaincode実行依頼(Transaction Proposal)を送付 • PeerノードがChaincodeを実行(※)し署名を付けて結果(Endorsement)を返却 • クライアントはEndorsement Policyで定められた必要な分のEndorsementを収集する

    (※)この時点では台帳に反映しないため「シミュレーション実行」と言われることもある Ordering:トランザクションの順序を確定しブロックを生成・配布する • Endorsementを集め終えたクライアントアプリケーションがTransactionを送付 • 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布 Validation:トランザクションの有効性を検証したうえで反映する • Peerがブロック内のTransactionを検証し台帳に反映(コミット) (再掲)3フェーズのトランザクションフロー 47 Copyright © 2021 Oracle and/or its affiliates
  48. どうしてこのようなフローになっているのか • スマートコントラクトロジック実行とブロック生成を分離できる • 比率的に重いChaincode実行はPeerノードに、トランザクション順序の決定とブロック生成は Ordering Serviceにそれぞれ分離することによる処理能力向上 • ネットワーク規模拡大がスマートコントラクトロジック実行の処理負荷増大に直結しない •

    Endorsement Policy次第で、必ずしもネットワーク参加メンバー拡大に比例したかたちで冗長に Chaincode実行をするPeerノードが増えていかない(→スケーラビリティ) • トランザクションの並列実行可能性の向上 • Chaincode実行の処理量を複数Peerで水平分散できる • (更新するレコードが十分に分散している限りにおいて)同時/並列に処理できるトランザク ション量を増やすことができる Endorsement・Ordering・Validationフローの主な利点 Copyright © 2021 Oracle and/or its affiliates 48
  49. Copyright © 2021 Oracle and/or its affiliates 49 3. ChannelとPrivate

    Data
  50. • ブロックチェーン/DLTはネットワーク内のすべてのノードで同一のデータを複製し共有するという のが基本のアイディア • 一方で、エンタープライズ領域ではあるデータをネットワークのうち一部の参加者にしか見せたくな い、というニーズが頻出する • エンタープライズ用ブロックチェーン基盤ではこうしたニーズに応えるため、データ共有範囲をネッ トワークの一部に限定するための機能を備えているものが多い エンタープライズブロックチェーン基盤のデータ共有範囲制御

    Copyright © 2021 Oracle and/or its affiliates 50 A B D C A B D C 全データを全ノードで共有 一部のデータは限られたノードで共有
  51. ChannelとPrivate Dataのふたつの機能の使い分け/組み合わせが可能 Channel ネットワークをサブネットワークに分割し、 トランザクションそのものの(すなわち、そこで 扱われるデータの)共有範囲を限定 Private Data Channel内で共有されるトランザクションのう ち、一部のデータ項目を更に範囲を限定して共有

    できる HLFのデータ共有範囲制御 51 L1 L2 L3 【お客様情報レコード】 “ID : 1234567890” “生年月日 : 1987年1月1日” “性別 : 男性” “名前 : 鈴木太郎” “住所 : 東京都千代田区X-X-X” “電話番号 : 080XXXXXXXX” “契約コース : 従量制A” “契約日時 : 2019/1/21” Channel内の 一部のメンバーのみ データを共有 (他のメンバーには 秘匿) Copyright © 2021 Oracle and/or its affiliates
  52. • HLFネットワーク内のサブネットワークである • あるChannelにはネットワークのうち一部~全部のOrganizationが所属する • 更にPeerノードやOrdererノードにもChannelへの参加/不参加がある • Channelごとに台帳が存在する、すなわちChannelが台帳の共有範囲である • Channelごとにトランザクションが実行される

    Channelの概要 Copyright © 2021 Oracle and/or its affiliates 52 OrgA Peer OrgB Peer OrgC Peer CH1 L1 L2 L1 L1 L2 L3 L3 CH2 CH3 Org A Org B Org C
  53. HLFにとってChannelは多くの要素の基礎となる構造 • Orgの参加/不参加 • Orgの権限(ReadOnly/ReaderWriter) • Peerノードの参加/不参加 • Ordering Serviceクラスター

    • 参加するOrdererノード • Ordering Serviceの設定 • Chaincodeの稼働 • Endorsement Policy • トランザクション • Chaincode実行 • ブロック生成 • ブロック配布 • 整合性 • 台帳 • World State • Blockchain • Private Data • Private Data Collection定義 Channelをスコープとする主な要素(設定、定義、処理など) Copyright © 2021 Oracle and/or its affiliates 53
  54. ChannelとOrg、Ledger、Peer、Orderer、Chaincodeの関係の例 Copyright © 2021 Oracle and/or its affiliates 54 P1

    P2 P3 P4 P5 P6 Ch1 Peer Orderer Organization Channel Org A Org B Org C O1 O2 O3 O4 O5 O6 Ch2 CC1 L1 L2 CC2 L2 CC2 L2 CC2 L2 CC2 L1 CC1 L1 CC1 CC2 CC1 CC1 CC1 CC1
  55. Channel作成、ノード追加、Chaincodeインストール、Chaincode稼働の順序 ChannelとOrg、Ledger、Peer、Orderer、Chaincodeの関係の例 Copyright © 2021 Oracle and/or its affiliates 55

    P1 P2 P3 P4 P5 P6 Ch1 Peer Orderer Organization Channel Org A Org B Org C O1 O2 O3 O4 O5 O6 CC1 L1 L1 CC1 L1 CC1 ①Ch作成& 参加Org定義 ②OrgがChに ノードを追加 ③Chに参加したPeerは Ledgerを保持 ④OrgがPeerにCC をインストール ⑤ChでCCを稼働
  56. ChannelとOrg、Ledger、Peer、Orderer、Chaincodeの関係の例 Copyright © 2021 Oracle and/or its affiliates 56 P1

    P2 P3 P4 P5 P6 Ch1 Peer Orderer Organization Channel Org A Org B Org C O1 O2 O3 O4 O5 O6 Ch2 CC1 L1 L2 CC2 L2 CC2 L2 CC2 L2 CC2 L1 CC1 L1 CC1 CC2 CC1 CC1 CC1 CC1 CCのInstall有無は Peer個別に選択 Peerは ・複数Chに参加可 ・複数CCを保持可 Chは複数CCを 稼働可能 同一CCを複数Chで 稼働可能 (台帳は別)
  57. • あるトランザクションのうち一部のデータを一部のChannelメンバーに限定して共有する (他のメンバーからは隠す)オプショナルな機能としてPrivate Dataがある • 共有先Orgは事前に定義しておく…Private Data Collection定義 • Private

    Dataの内容は台帳の外で保持され(※)、削除(Purge)が可能 • つまりWorld Stateに載らない、Blockchainにも残らない Private Dataの概要 Copyright © 2021 Oracle and/or its affiliates 57 OrgA Peer OrgB Peer OrgC Peer Channel 1 L1 PD1 L1 L1 Private Data Collection 1 PD1 ※Private Dataが台帳に含まれるかどうかはHLFの 公式ドキュメント内でも記載がブレているが、台帳 外であるとしたほうがわかりやすいのでここではそ のように整理する
  58. • Private Dataを格納する容れ物をPrivate Data Collectionと呼ぶ • Private Data CollectionはWorld Stateとは別の領域のKey-ValueストアとしてState

    DB内に保持される • Chaincodeの中で利用するPrivate Data Collectionは、ChaincodeをChannelで稼働させる際に定義 (宣言)する必要がある • この中でChannelメンバーのうちどのOrgのPeerがそのPrivate Data Collectionを保持するかを設定 する Private Data Collection(PDC) Copyright © 2021 Oracle and/or its affiliates 58 { "name": "collectionMarbles", "policy": "OR('Org1MSP.member’, 'Org2MSP.member’)”, ... } Peer Ledger Blockchain State DB PDC World State Private Data Collection定義の例
  59. • PDの内容はトランザクションに載らずPDC保持メンバーのPeerのみに共有 • PD内容はOrdering Serviceを通らず、Peer間のGossipで伝播する • 内容(KeyとValueそれぞれ)をハッシュ化したもの(Private Data Hash)はPDC保持メンバー以外 のChannelメンバーにも共有される

    • PD Hashはトランザクションに載り、World Stateにも格納される • PD HashによりPrivate Dataの存在有無および内容は検証可能になる • 必要に応じてPDC保持メンバーはPrivate Dataが改ざんされていないことをPD Hashと突合するこ とで確認、証明できる Private Data(PD)の内容とPrivate Data Hash(PD Hash) Copyright © 2021 Oracle and/or its affiliates 59 Ledger Block Tx World State PD Hash PD Hash PDC PD内容 ハッシュ化
  60. Private Dataの絡むトランザクションフローの図 Copyright © 2021 Oracle and/or its affiliates 60

    Client App Peer PDC PD内容 Chain Code Peer Ledger Chain Code Ordering Service 1 1.5 2 Ledger Peer PDC Chain Code Ledger Peer PDC Chain Code Ledger PD内容 1.5 1 2 3 3.5 4 5 PD内容 4 5 5 4 4 5 1)Transaction Proposal 送付 1.5)Chaincode実行 2) Endorsement返却 3)Transaction送付 (PD Hashを含むがPD内容は含まない) 3.5)Block生成 2.5) Endorsement収集 2.5 PD内容を伝播 (Gossipプロトコル)
  61. Copyright © 2021 Oracle and/or its affiliates 61 まとめの振り返り

  62. Orderer ポイントはOrganization Hyperledger Fabricネットワークの概観図 62 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
  63. 流れと各フェーズの目的を理解しておく 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から成るトランザクションフロー 63 Copyright © 2021 Oracle and/or its affiliates
  64. ChannelはHLFの基礎の一部、Private Dataはオプショナル Channel ネットワークをサブネットワークに分割し、 トランザクションそのものの(すなわち、そこで 扱われるデータの)共有範囲を限定 Private Data Channel内で共有されるトランザクションのう ち、一部のデータ項目を更に範囲を限定して共有

    できる ChannelとPrivate Data 64 L1 L2 L3 【お客様情報レコード】 “ID : 1234567890” “生年月日 : 1987年1月1日” “性別 : 男性” “名前 : 鈴木太郎” “住所 : 東京都千代田区X-X-X” “電話番号 : 080XXXXXXXX” “契約コース : 従量制A” “契約日時 : 2019/1/21” Channel内の 一部のメンバーのみ データを共有 (他のメンバーには 秘匿) Copyright © 2021 Oracle and/or its affiliates
  65. なぜこんな設計になってるのか?と思ったらここに立ち戻る HLFの多くの機能や独特の仕様には、以下のような目的、背景があると考えると理解しやすくなる • 複数の企業/組織から成るコンソーシアム型のユースケースに最適化する • ネットワークの中で更にデータ共有範囲を分割/制御する • 重大なオペレーションの安全かつ分権したガバナンスを実現する • 耐障害性と可用性をブロックチェーン基盤の機能として確保する

    • ネットワークメンバー数とトランザクション処理能力のスケーラビリティを確保する Hyperledger Fabricの特色 Copyright © 2021 Oracle and/or its affiliates 65
  66. Thank you Copyright © 2021 Oracle and/or its affiliates 66

  67. Copyright © 2021 Oracle and/or its affiliates 67 Appendix. Oracle

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

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

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

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

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

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

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

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

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

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