OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容＋おまけ資料

‸
Copyright © 2018, Oracle and/or its affiliates. All rights reserved. |
OCHaCafe #4
Hyperledger Fabric
アプリケーション設計入門ガイド
日本オラクル株式会社中村岳
2019年3月28日

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, timing, and pricing of any
features or functionality described for Oracle’s products may change and remains at the
sole discretion of Oracle Corporation.

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

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

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

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

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

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

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

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

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

代表的なブロックチェーン/DLT基盤
Bitcoin Ethereum Corda
Enterprise
Ethereum
Hyperledger
Fabric
用途送金汎用金融機関間取引汎用汎用
主要ガバナンス開発者コミュニティ開発者コミュニティ R3社 EEA Linux財団
参加形態 Permission-less Permission-less Permissioned Permissioned Permissioned
プライバシー公開公開限定限定可能限定可能
コンセンサス PoW PoW 当事者間方式選択可能方式選択可能
暗号通貨 BTC ETH なしなしなし
スマートコントラクトなし Solidity、
Vyper
Kotlin、Java Solidity、
Vyper
GO、Node.js、
Java（&EVM）
備考 ― PoSへの移行予定金融以外の分野
での活用も
Ethereumの
Permissioned版
フォーク
12

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

• Organization
• Peer
– Endorser / Committer
– Gossip
• Anchor / Leader
• Intra Org / Inter Org
• Ordering Service
– Type: Solo / Kafka
– Block Generation Settings
• MSP
• Ledger
– State DB / Blockchain
• Endorsement Policy
– Chaincode Level / Key Level
• Transaction Flow
• Channel
– Capability Requirements
• Private Data
– Auto Purge / Delete
• Identity Mixer
• Peer Event Service
– Transaction/Network/
Channel /Custom
• Service Discovery
14
• Chaincode Lifecycle
• Chaincode Techniques
– Get State / Put State
– Ranged Query / Rich Query
– Transient Map
– Custom Event
– Attribute-based AC
– Key History / Transaction
History
– Inner CC Invocation
• Intra / Inter Channel
– Ethereum VM (Burrow)
• Fabric SDK
Hyperledger Fabricのお勉強要素
赤字：理解が必須の基礎知識
青字：知ってると便利、応用編
それ以外：必要に応じて学ぶ

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

Peer
16
Hyperledger Fabricネットワーク
Peer
LedgerChain
codeApp
MSP
PeerPeer
LedgerChain
code
App
MSP
PeerPeer
LedgerChain
code
AppMSP
O O
O O
Ordering

Peer
17
Peer
LedgerChain
codeApp
MSP
PeerPeer
LedgerChain
code
App
MSP
PeerPeer
LedgerChain
code
AppMSP
O O
O Of
Ordering
Fabricで言う「ネットワーク」は
ひとつのOrdering Serviceを
共有する範囲

Peer
18
Peer
LedgerChain
codeApp
MSP
PeerPeer
LedgerChain
code
App
MSP
PeerPeer
LedgerChain
code
AppMSP
O O
O O
Ordering
ノードやMSP、クライアントアプリケーション
のネットワーク構成要素を管理する
（責任を持つ）単位として
Organizationがある
通常、企業などのコンソーシアムに
参加する組織と対応する

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

State DB
• StateDBはKey-Valueストアで、Valueには任意のバイナ
リを格納可能
• State DBにはLevelDBかCouchDBを選択可能
• LevelDB：シンプルなValueを扱う場合向け
• CouchDB：複数の属性を持つValueを扱いやすい
– JSON形式でValueを格納すると、Attributeを条件に指定して
クエリできる（リッチクエリ）
– LevelDBに比べてかなり低速
– Phantom Read問題に注意が必要
• 台帳に更新をかけるトランザクションでリッチクエリを使うな、の制約あり
20
Key:
marble1234567
Value：
{
“color”:”red”,
“size”:12,
“price”:200,
“owner”:”Bob”
}

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

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 22
情報共有範囲制御①：チャネル
• チャネルはサブネットワークの分割単位であり、データ共有範囲である
• チャネルごとに台帳が存在し、そのチャネルに参加するPeerノード間で共有される
• あるPeerノードはひとつ～複数のチャネルに参加できる
– 即ち、あるPeerノードは参加しているチャネルの数だけ台帳を保持することになる
ノードA ノードB ノードC
チャネル1 L1
L2
L1 L1
L2
L3 L3
チャネル2
チャネル3
• ノードAはチャネル1と2に参加しており、
台帳(Ledger)1と2を保持する
• ノードBはチャネル1,2,3の全てに参加しており、
台帳1,2,3を保持する
• ノードCはチャネル1,3に参加しており、
台帳1と3を保持する
• 台帳1のデータはノードA,B,C全てに共有される
が、台帳2はAとB、台帳3はBとCのみ

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

情報共有範囲制御②：プライベートデータ
• 共有されるデータの内容のうち、一部の項目のみについて共有するノードを限定
することができる
• プライベートデータ（PD）は台帳の外（Side DB）に保持される
– 手動削除可能な他、予め決めた期間後に自動削除（パージ）することができる
ノードA ノードB ノードC
チャネル1 L1
PD1
L1 L1
PD1
PD2 PD2
PD1の
共有範囲
PD2の
共有範囲
【お客様情報レコード】
“ID : 1234567890”
“生年月日 : 1987年1月1日”
“性別 : 男性”
“名前 : 鈴木太郎”
“住所 : 東京都千代田区X-X-X”
“電話番号 : 080XXXXXXXX”
“年収 : XXX万円”
“勤務先 : XX株式会社”
PD1
PD2

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

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

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

トランザクションフロー：図
28
クライアントアプリ
Fabric SDK
Keys
MSP
Peerノード（複数）
Endorser
StateDB
Committer
Ordering Service
Certificate
Authority
2.1 –ブロックの配布
署名の検証、認証
トランザクションの
順序を確定し
バッチ（ブロック）
を生成2.0 – Transactionの送付
（Endorsementを含む）
ブロック
チェーン
3.0 – Validation
4.0 – 結果通知（Event）
Chaincode
1.1 – Chaincodeの実行
3.1 – 台帳に書き込み

Endorsement Policy
• Endorsement：Chaincode実行結果にPeerが署名したもの
• Endorsement Policy：あるChaincodeのトランザクションを台帳に反映するため
に、どのようなEndorsementを集めてこなければならないかを定める条件
（どうしたらコンセンサスが取れたことになるか）
– Chaincode×チャネル単位で設定可能（Chaincode Instantiate/Update時に設定）
– 単純なEndorsementの数による条件から重みづけまで、柔軟な設定が可能
– EndorsementはPeer単位ではなく、Organization単位でカウントされる
– 例：Org A,B,Cで構成されるネットワークの場合に、「3つのOrgのうち、任意の2つのOrg配
下の任意のPeerからEndorsmentの取得」といったような条件
29

Endorsement Policyの例
AND、OR、OutOfの組合せで定義
• AND(‘Org1.member’, ‘Org2.member’, ‘Org3.member’) 全Org必須
• OR(‘Org1.member’, ‘Org2.member’) どっちかのOrgでOK
• OutOf(2, ‘Org1.member’, ‘Org2.member’, ‘Org3.member’) いずれか2つOrg
• AND(OR(‘Org1.member’, ‘Org2.member’), ‘Org3.member’)
Org1かOrg2のどっちか + Org3必須
※memberとadminはPeerのRole（Peerノード構築時に定義）
30

Peerのふたつの役割：Endorser / Committer
• あるトランザクションに関してChaincodeを実行する、つまりEndorsementを行う
PeerをEndorser（Endorsing Peer）と呼ぶ
• Validation/Commitを行うPeerをCommitter（Committing Peer）と呼ぶ
• Endorsementを行うPeerはValidation/Commitも行うが、
Validation/Commitだけを行うPeerも存在できる
• EndorsementをしないPeerにはそのChaincodeをインストールしなくてよい
• EndorsementとValidation/Commitの負荷分散のための仕組み
31

From: https://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html
Peerへの
Transaction
Proposal送付 Chaincode実行
Endorsement返却
Endorsement収集
Transaction送信
ブロック生成
→配布
Validation
→CommitTx Event通知
（Validation後）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

正常系
63

異常系①
Proposalでエラー
64

異常系②：
Validationでエラー
65

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

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

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

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

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

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

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

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

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

• Validation/Commitの処理量はチャネルでのトランザクション数に依存
• Peerごとに所属するチャネルを分け、トランザクション数を平準化させる
75
Validation/Commitの負荷分散
Peer
CH1 CH2 CH3
Block
Peer
CH1
Block
Peer
CH2
Peer
CH3
Block Block

• Chaincodeでの役割分担：PeerごとにインストールするChaincodeを分けておく
• チャネルでの役割分担：Peerごとに所属するチャネルを分けておく
76
Endorsement負荷分散：Peer側の役割分担
Peer
CH1CC1
CC2 CH2
Proposal
Peer
CH1
CC1
Peer
CH2
CC1
Peer
CH1
CC2
Peer
CH2
CC2
Prop
osal
Prop
osal
Prop
osal
Prop
osal

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

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

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

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

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

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

Berkeley DB（BDB）の採用でパフォーマンス＆クエリを強化
Oracle Blockchain Cloud ServiceはState DBとして
Berkeley DBを採用
※標準のHLFではLevelDB or CouchDB
• パフォーマンスの向上
– スマートコントラクトの同時実行性の強化
• SQLリッチクエリのサポート
– JSONの属性を指定してのSQL-Likeクエリが可能
– CouchDB形式のJSONクエリへの互換性も保持
• CouchDB適用時の技術的な問題の解決／回避
– リッチクエリ使用時のPhantom Read問題を解消
– 大量レコード取得時のPagination指定が不要に
83
＋
トランザクションと
値の履歴を格納
State DB
（World State）：
現在の値を格納する
データベース
Hyperledger Fabricにおける
台帳（Ledger）
… 以下ふたつから構成

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

豊富なREST API Framework – Transactions/Queries/Events
Transactions and Queries Events
• Get version (of REST proxy)
• Query chaincode function
• Get transaction ID
• Invoke transaction
synchronously
• Invoke transaction
asynchronously
• Subscribe to event, event type:
“transaction”: concerned with events on a particular transaction ID
“txOnChannel”: returns a transaction object for every new transaction on a particular
channel
“txOnNetwork”: returns a transaction object for every new transaction in the entire network
“blockOnChannel”: returns a block header for every new block on a particular channel
“blockOnNetwork”: returns a block header on creation of a new block in the entire network
“chaincodeEvent”: returns custom events emitted from chaincode
• Unsubscribe event

豊富なREST API Framework – Admin/DevOps
Channels Statistics Chaincodes Nodes Organizations
• Create channel
• Get channel list
for chaincode
for a peer
• Update channel
configuration
• Get channel info
• Get ledger block
by block ID
• Get blocks by ID
range
• Get blocks by
time range
• nodeResUsage (CPU,
Mem, Disk)
• nodeHealth
• channelInfo
• channelsJoined
• chaincodeInstalled
• chaincodeInstantiated
• userTrans
• billableTrans
• Endorsements
• Commits
• Blocks
• proxySyncInvocation
• proxyAsyncInvocation
• proxyConfiguredCC
• Get list of installed
cc’s
• Get a list of
chaincodes on a
specific peer
• Get list of
chaincodes on a
channel
• Install chaincode
• Instantiate
chaincode
• Get chaincode info
• Get node list
• Get a list of peers on a channel
• Get a list of peers for a specific
chaincode
• Add a peer node
• Start/Stop a peer node
• Remove a peer node
• Get/Set a peer node’s
attributes
• Join a peer to a channel
• Export/Import peers
• Start/Stop an orderer
• Get/Set an orderer’s attributes
• Start/Stop a CA node
• Get/Set a CA’s attributes
• Start/Stop REST proxy
• Get/Set REST proxy’s
configuration
• Get org certificates
• Get org admin
credentials
• Get ordering service
setting in a founder
org
• Join a new org to a
founder org
• Set ordering service
to a participant org

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

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 88
Oracle Code Tokyo 2019
Sheraton Miyako Hotel Tokyo
2019/5/17 10:00 – 18:00

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

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

Endorsementフェーズ
• クライアントアプリケーションがTransaction Proposalを1～nのPeerノード
（Endorser）に送信する
• Peerノードが指定されたChaincodeを実行
– 実行結果をここでは台帳にコミットしないため、仮実行、Simulationとも呼ばれる
• PeerノードはProposal Response（RWセットとEndorsement）返却
• クライアントアプリケーションはRWセットを（他Peerのものと）比較
• Endorsement Policyを満たすだけのEndorsementが集まれば、（全Peerからの
応答を待たずとも）クライアントはOrderingフェーズに進むことができる
91

Endorsement、Endorsement Policy、Endorser
• Endorsement：EndorseしたPeerのID、署名（over RWSet）
• Endorsement Policy：あるChaincodeのトランザクションを台帳に反映するため
に、どのようなEndorsementを集めてこなければならないかを定める条件
（どうしたらコンセンサスが取れたことになるか）
– Chaincode×チャネル単位で設定可能（Chaincode Instantiate/Update時に設定）
– 単純なEndorsementの数による条件から重みづけまで、柔軟な設定が可能
– EndorsementはPeer単位ではなく、Org単位でカウントされる
– 例：Org A,B,Cで構成されるネットワークの場合に、「3つのOrgのうち、任意の2つのOrg配
下の任意のPeerからEndorsmentの取得」といったような条件
• Endorser：Chaincodeを実行し、Endorseを行うPeer（コミットも行う）
⇔Chaincodeを実行せずコミットだけ行うPeer：Committer
92

Endorsement Policyの例
AND、OR、OutOfの組合せで定義
• AND(‘Org1.member’, ‘Org2.member’, ‘Org3.member’) 全Org必須
• OR(‘Org1.member’, ‘Org2.member’) どっちかのOrgでOK
• OutOf(2, ‘Org1.member’, ‘Org2.member’, ‘Org3.member’) いずれか2つOrg
• AND(OR(‘Org1.member’, ‘Org2.member’), ‘Org3.member’)
Org1かOrg2のどっちか + Org3必須
※memberとadminはPeerのRole（Peerノード構築時に定義）
93

RWSet（Read-Write-Set）
• かんたんに言うとChaincode実行のBefore/Afterの状態セット
• EndorserがChaincodeを（仮）実行するなかで：
– State DBから読み取った値があればそのKeyとバージョンのセット（Read-Set）
– 台帳に書き込む（予定の）値があればそのKeyとValueのセット（Write-Set）
• Read-Setはない場合がある（新規Keyインサートのトランザクション、Keyの現在
Valueを無視して更新を行うトランザクションなど）
• Write-Setもない場合がある（参照トランザクション）
94

Transaction Proposalメッセージの構造
95
SignedProposal {
Proposal Proposal {
ChannelHeader ChannelHeader {
ChannelId string // 指定するチャネル
ChaincodeName string // 指定するChaincode
ChaincodeVersion string // Chaincodeのバージョン
TxId string // トランザクションID（App側で生成
}
SignatureHeader SignatureHeader {略}
Args [][]byte // Chaincodeに与える引数
}
Signature []byte // クライアントの署名
}

Proposal Responseメッセージの構造
96
ProposalResponse {
ProposalResponsePayload ProposalResponsePayload{
ProposalHash []byte // ProposalのHash値
ChaincodeName string
ChaincodeVersion string
RWSet []byte
RV []byte // Chaincodeで明示的に指定した戻り値
}
Endorsement Endorsement{
Endorser []byte // EndorseしたPeerのID
Signature []byte // Payload＋Endorserに対しての署名
}
}

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

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

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

Validationフェーズ
• ブロックを受け取った各Peerは、含まれるTransactionそれぞれを検証する
– Endorsement Policyを満たしているか（含：各Endorserの戻したRWSetの比較）
– 各署名（クライアント、Endorser、Orderer）の検証
– Read-Setに含まれるKeyのバージョンが自身のState DBのそれと一致しているか
…Chaincode実行時点で読み取られたKeyが、ここまでに更新されていないことをチェック
• すべてのTxの検証後、ブロックを保存
– Valid/Invalidの判定結果はブロックのメタデータ部にも保存
• 合わせて、ValidのTxのみをState DBに反映（コミット）
– ここで反映される値はWrite-Setに含まれるValueそのもの
– Chaincodeを再実行して書き込んでいるわけではない
100

• Endorsement：
• Ordering：
• Validation：
101
まとめ
トランザクションの3フェーズ：Endorsement、Ordering、Validation

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

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

Read-Set Validationで防げる残高の二重使用の例②
• トランザクションが以下の時系列で処理されると、 E2の段階では二重使用が発
生するが、 V2 でのRead-Set ValidationによってTx2がInvalidと判定される
– Tx1のEndorsementをE1、ValidationをV1、Tx2も同様にE2とV2とし、OrderingをOと表記
104
E1 E2 O V2V1
Item ID 初期状態～V1前まで V1後 V2後
Item1 Alice Bob Bob

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

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

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

CouchDBのPhantom Read問題：事象の例①
• 物の所有権をHLFの台帳上で管理しており、初期状態は以下とする
108
Item ID (Key) Owner (Valueの一部)
Item1 Alice
Item2 Bob
Item3 Carol
• この状態からふたつの更新トランザクションを間を置かずに発行する
–Tx1:Carolの持ち物をすべてAliceに譲渡する
–Tx2:Aliceの持ち物をすべてBobに譲渡する
• State DBとしてCouchDBを使用しており、Owner値による更新すべきレコードの
抽出にはリッチクエリを使用する前提とする

CouchDBのPhantom Read問題：事象の例②
• まずCarolの持ち物をすべてAliceに譲渡したのちにAliceの持ち物をすべてBobに
譲渡したいので、Tx1とTx2の実行後の期待される結果は以下
109
• しかしCouchDBではPhantom Read問題により以下の結果になる場合がある
Item ID 初期状態中間状態（Tx1後）結果（Tx2後）
Item1 Alice Alice Bob
Item2 Bob Bob Bob
Item3 Carol Alice Bob
Item ID 初期状態中間状態（Tx1後）意図しない結果
Item2 Bob Bob Bob
Item3 Carol Alice Alice
取りこぼし

CouchDBのPhantom Read問題：事象の例③
• トランザクションが以下の時系列で処理されると意図しない結果が発生する
– Tx1のEndorsementをE1、ValidationをV1、Tx2も同様にE2とV2とし、OrderingをOと表記
110
E1 E2 O V2V1
Item2 Bob Bob Bob

CouchDBのPhantom Read問題：事象の例④
• V2でAliceの持ち物であるにもかかわらず、Item3の取りこぼしが生じている
• 更新レコードを決定するE2時点でAliceの持ち物ではなかったため
111
E1 E2 O V2V1
Item2 Bob Bob Bob

CouchDBのPhantom Read問題：事象の例⑤
• Tx2での更新対象はItem1のみであり、Item3はTx2の更新対象ではないため、
V2でのRWセットの検証にはItem3は含まれず「取りこぼし」は検知できない
112
E1 E2 O V2V1
Item2 Bob Bob Bob
V2 Validation

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

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

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

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

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

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

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

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

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

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

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

Chaincode Tips
• 単一チャネル上で複数Chaincodeを稼働させることが可能
• あるChaincodeが台帳に書き込んだレコードは、そのChaincodeからしかアク
セスできない
– Chaincode A on Channel Xが書き込んだレコードは、Chaincode B on Channel Xからは
アクセスできない
– State DB上の現在ステートおよびブロックチェーン上のキー履歴、トランザクション履歴のいず
れにもこの制約がある
• Chaincodeから同一チャネル内の別のChaincodeを呼び出すことは可能
– Chaincode A on Channel X⇒Chaincode B on Channel Xは可能
• 単一トランザクションとなり、ステート、RWSetも共有している
124
単一チャネル上での複数Chaincodeの相互呼び出し

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

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

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

OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容＋おまけ資料

More Related Content

What's hot

Similar to OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容＋おまけ資料

More from オラクルエンジニア通信

OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容＋おまけ資料