Open blockchain in a nutshell

Open Blockchain in a nutshell ( Open Blockchain 概要 )
Created Date : 2016/03/19
Created By : Takeshi Matsubara

disclaimer
2
本資料の記載内容は、著者が個⼈的に調べた内容であり、正式なIBM, 日本IBMのテストやレビューを受けておりません。内容についてはできる限り正確
を期するよう努⼒しましたが、「現状のまま」提供され、明⽰または暗⽰にかかわらずいかなる保証、責任を負いかねます。
本資料の情報は、使⽤先の責任において使⽤されるべきものであることを予めご了承下さい。
(本資料またはその他の資料の使⽤によって、あるいはその他の関連によって、いかなる損害が⽣じた場合も、著者は責任を負わないものとします)
また、本資料に記載内容で⽰された意⾒、感想は全て著者個⼈のものであり、所属する組織を代表するものではありません。

目次
はじめに
Open Blockchainの概要(1)
Open Blockchainの詳細(主な要素)
IBM Bluemix の Blockchainサービス
Open Blockchainにおけるチェーンコード開発とデプロイ
まとめ
3

想定読者
以下のいずれかまたは全てに合致する方
– “ブロックチェーン”という⾔葉は良く聞くが、概念ばかりで、システムとして中⾝が分からない
• Bitcoinのアレ？
• Buzz Wordっぽいアレ？
• FinTechというキーワードと共に出てきたりするアレ？
– IBM Bluemix 「Blockchain」サービス(試験サービス)を理解したい
• 2016/03/03に公開 (InterConnect 2016にて発表)
5

なぜブロックチェーンは大きく取り上げられるか
– ブロックチェーンが対象とする「台帳(=Ledger)」は、System of Record の中核(その
最たるもの)だから
– そしてそのSoRに対し、ブロックチェーンは“破壊的な要素技術” と目されているから
ところで…
6

ブロックチェーンの頻出用語
– これらについてはそういう専門⽤語だと押さえておくと良い
• 但し、あくまでこの⽤語は概念的なもの
実装上の⽤語とは切り離して理解した⽅が良い
ブロックチェーン関連全般の主な用語 (5+1)
7
# ブロックチェーンでの頻出用語説明
1
アセット/資産
(Asset)
• 所有の概念があり、価値を⽣み出すもの(であれば何でも)
• お⾦、財貨もアセットの一種とされる
• 以下の概念
• A.有形資産 (例：不動産)
• B.無形資産 (例：抵当権)
• B-1. ⾦融資産
• B-2. 知的資産
• B-3. デジタル資産
2
参加者
(Participants)
• あるビジネスネットワークのメンバー(顧客、サプライヤー、法的機関、…)
3
台帳(レジャー)
(Ledger)
• システムの記録(THE System of Record)
• 参加者同士での、「アセット」の転送(transfer)を記録したもの
• 例：「AさんがBさんに⾞を受け渡した」
4
トランザクション
(Transaction)
• アセットが転送(transfer)されること
5
契約
(Contract)
• トランザクションが発生する諸条件(1つまたは複数条件の集合)
• 条件例1:「AさんがBさんに⾞を受け渡したら、BさんはAさんに代⾦を⽀払う」
• 条件例2:「⾞が⾛らなかったら、代⾦の⽀払いは⾏われない。⾞が⾛らないかどうかは
第三者が判定する」

ブロックチェーンの頻出用語
– “スマートコントラクト”
• ブロックチェーン関連で特に目⽴つ(そして直感的に分かりづらい)用語
ブロックチェーン関連全般の主な用語 (5+1)
8
# ブロックチェーンでの頻出用語説明
6
スマートコントラクト
(Smart Contract)
• "Smart?" 契約(Contract) → 一体何がSmartなのか?
• ここでいう "契約" は前ページの契約のこと
• その意味合いとしては、「わざわざ"契約書"(書類等)を作らなくても、それと同等の内容・
裏付けが暗黙的に達成・実現され、処理が機械化・⾃動化されること」
• 事前の認証をベースとし、あるトランザクション要求がブロックチェーン上に投入されたというこ
とをもって、その参加者がその内容に同意(契約締結)したと⾒なすことができる、という発想
が下敷き
• このあたりの概念をスキップして、結局なんなのかという観点では、「ブロックチェーン上のトラ
ンザクションによって実⾏されるビジネスロジックであり、物理的にはそのロジックが記述された
ソースコード」と理解しても良い
• 別視点で、「⾃動的に契約を実⾏するようなコンピュータプログラム」という表現もある
• 同じブロックチェーンを共有する参加者同⼠は、「その都度個別の契約書を交わす」こと
の代わりに、最初にその内容を表現する同一の「ソースコード」を使うことを受け入れるこ
と、といえるかもしれない (とても面白い考え方！)

よくあるブロックチェーンの説明の流れ
良くあるブロックチェーンの説明
– 概ね、以下のストーリー
– ① Bitcoinを取り上げつつ、ブロックチェーン技術への現実社会での注目と影響度を示す
• Bitcoinのような仮想通貨と、ブロックチェーン技術はイコールではないことを示す
• ブロックチェーンは、IT業界内だけではなく社会インフラに関わるインパクトをもたらす、といったトーン
– ② 適用が想定されるユースケースとして、幾つか取り上げる
• 海外送⾦、…
• 公的記録の台帳(不動産登記、⾃動⾞登録・リース)、取引履歴の保全、知的財産管理…
• IoTによる自動取引…
• ⾃動⾞や⾶⾏機等の製造物保守・破棄を含むライフサイクル管理(サプライチェーン)、…
– ③ それの何が嬉しいか(ビジネス上の恩恵)を示す
• 非集中型での台帳管理による分散運⽤と保守コストの削減
• ビジネスにおける中間層の除去、ビジネスプロセスの簡素化・効率化
• 台帳自身の信頼性の向上
– ④ ブロックチェーンの今後にご期待下さい！
9

それらの説明から得られるもの
それだけではこんなイメージしか湧かない…
– 「分散台帳」といっているのだから、データベースがあるんだろう (多分)
• データベースってPostgreSQLとかMySQLとかそういうものなのかな？
– “分散”台帳なのだから、どうにかしてデータを送受信してコピーしあうのだろう (多分)
• P2Pといっても、何かしらハブっぽいノードはあるんだろう？どうやって送受信するのかな？
• 「データ」ってどんな構造とか決まっているのかな？
– ビジネスロジックもどうにかして取り扱うのだろう (多分)
• 台帳なのだから「データ」って数値？その増減は結局SQL操作なのかな？
– コンセンサスは、分散環境におけるシステムの整合性を扱うのだろう (多分)
10
A社システム B社システム
C社システム
??
?? ??
多分DBがある
分散だから多分N/W
的に別々
多分DBテーブルが台帳
何らかのプロトコルでやり取り。
多分ファイアウォール透過？
どういうタイミングか知らな
いけど多分双方向で通信
「多分」だらけ → 何も分かっていない

別のアプローチを取る
諦めて、別の⽅向から理解しよう
– この資料では Open Blockchain (OBC) の実装や、そこで定められている仕様を通じ
て、ボトムアップ的に「ブロックチェーン」の理解を試みる
• もちろん、両者はイコールではない
Open Blockchain (OBC) の実装が「こうなっている」からといって、それがブロックチェーンという概念や要
素技術にすべからく当てはまる訳ではない
• しかし、得られるものも、とても多いはず
11
ブロックチェーン
(概念・要素技術)
Open Blockchain
(実装)
<<use>>
<<realize>>
これを通じてこれを(これも)理解する

12

Open Blockchain
ご注意
– 資料は、作成資料時点でのOpen Blockchainの内容に基づく
– 日々開発が進んでいるので、今後大きく変わる部分も多い
• 実際に、既にI/F仕様レベルでの変更も発生している
例：REST API 「/devops/deploy」等のURLが deprecated → 「/chaincode」へ集約
» 同時に、JSON-RPCスタイルの採用へ
13

Open Blockchain
"Open Blockchain"とは
– IBMが開発し、Hyperledgerプロジェクトに提供(contribute)してOSS化したもの
• Blockchainの動作基盤ノード群(=ファブリック)を実現するための基盤ソフトウェア
ライセンスは Apache Software License Version 2.0
開発言語は Go言語(Golang)
• 様々な業界のユースケースに対応できるように設計されている
汎用性がある (←ここがポイント)
• コンセンサスモデルについては追加・切り替え可能なアーキテクチャを採⽤
「コンセンサスモデル」については、後に説明
– ところで…
• ○IBM Blockchain ："IBMのブロックチェーン(関連の何か)"。製品名ではない
• ○Open Blockchain ：OSSの名前
• ×Open Block Chain ：Blockchainは一単語として表記
14

Open Blockchain
"Open Blockchain"とは
– 補足：Hyperledger Project (https://www.hyperledger.org/)とは
• Linux Foundation内の、「オープンソースでのブロックチェーン技術推進コミュニティー」
• IBMから同プロジェクトへOpen Blockchainを提案/寄贈
• IBMはプロジェクト⽴ち上げ時30社(のPremierメンバー)の中に名前を連ねている
15

Open Blockchain
"Open Blockchain"とは(補足)
– Linux Foundation?
• 仕様は別だが、OBCの「現在の実装」はLinux環境上であることを前提としている
• 例えば、Dockerコンテナを内部的に利⽤
– OSS化?
• 「IBMの」「Open Blockchain」であり、それをOSSとして寄贈
• InterConnect2016にてIBMから発表・OSSとして公開された以下と手法が似ているといえるか
もしれない
Kitura (Swift言語でのWebアプリ用フレームワーク。JS言語での"express"のクローン)
OpenWhisk (Scala言語でのMicroserviceフレームワーク)
16

Open Blockchain
"Open Blockchain"とは(補足)
– Go言語(Golang)?
• Googleが開発した言語 (2009年11月にOSS化され公開)
スクリプト言語、関数型言語の影響が色濃いコンパイル型言語
Linuxを含む、ネイティブプログラム開発言語としてのトレンド
• OBCにおいて、ビジネスロジック=スマートコントラクト=チェーンコード(後述)を実装するための言語
もGo言語である
しかし、チェーンコードの開発言語としては2016年内にはJavaScript, Javaへの対応が記載されている
» チェーンコード開発者の⽴場としては、Go言語は必須ではなくなる可能性がある
17
Go言語の公式マスコットキャラクター「Go Gopher(Goのリス)」

Open Blockchain
Open Blockchainの狙い
– 初期のブロックチェーン技術は、目的特化型で、汎用性が無かった
• 特定の目的にはかなうものの、別の業務の必要性にはうまく合致しない
例：Bitcoinのブロックチェーン技術は、あくまでBitcoinというアプリケーションと一体化
– 現在の市場要求を満たすべく、以下に配慮した汎用的な基盤を提供しようとするもの
• 汎用性
業界特化型ではない
• スケーラビリティ
• セキュリティ
プライバシー、機密性といった面に配慮
18
アプリケーションレイヤ
基盤レイヤ
(Fabric)
(アプリ)
企業間台帳、
企業間仮想通貨、…
(ミドルウェア)
Open Blockchain
OS
Linux
ここをターゲット
ブロックチェーンの世界 …例えるなら…
(アプリ)
様々なWebアプリ
(ミドルウェア)
WebSphereAS
(JavaEE)
AIX

Open Blockchainが想定するネットワークトポロジー
3種類のネットワークトポロジーモデル
– OBCでは、下表の3つのネットワーク構成モデルが想定されている
• ある1つの同じブロックチェーンを共有するシステムがどう構成されているか
「分散台帳」のイメージ(世間一般?)そのままでいくと、「#3」
但し、実際には「#1」か「#2」が主に想定されている
19
# トポロジーのモデル説明
1
• クラウド上にホストされた1つのネットワーク
(Cloud hosted one network)
• 一番単純なモデル
• 各参加者(A社、B社、C社…)は、幾つかの自分用のノード(Peer)を所有
している
• しかし、それらはある単⼀のクラウドベンダが保有する物理H/W & ネット
ワーク内にホストされている
• 参加者は、そのクラウドベンダとの契約上、それらの計算機資源を制御でき
る
2
• クラウド上にホストされた複数のネットワーク
(Cloud hotsted multiple network)
• 複数のクラウドベンダのネットワーク上に、それぞれ参加者が所有するpeer
ノードを持つ。
• それらのノードは、HTTPSで他のノードと通信が可能である
3
• 参加者によってホストされたイントラネット
• (Participant hosted intranet)
• 参加者⾃⾝が所有するネットワーク環境を利⽤する
• いわゆるオンプレミス環境
• それらは、HTTPSで他のノードと通信が可能である

補足：#1(クラウド上にホストされた1つのネットワーク)の概念図
20
クラウドベンダ(X社)
A社向けノード群 B社向けノード群
C社向けノード群

補足：#2(クラウド上にホストされた複数のネットワーク)の概念図
21
クラウドベンダ(X社)
A社向けN/W B社向けN/W
C社向けN/W
クラウドベンダ(Y社)
クラウドベンダ(Z社)

補足：#3(参加者によってホストされたイントラネット)の概念図
22
A社オンプレミス環境(データセンター) B社オンプレミス環境(データセンター)
C社オンプレミス環境(データセンター)

Open Blockchain
Open Blockchainにおける通信プロトコル
– 各ノード間通信は、gRPC (Google RPC)を利⽤する
• Google が開発・公開しているRPC(リモートプロシージャコール)のライブラリとフレームワーク
Javaにおける、Java RMIのような位置づけ (但し、HTTP/2)
» サーバ側メッセージ(I/F)定義 → 呼び出し側スタブ生成 → クライアントはスタブを介しサーバへRPC
• HTTP/2を利⽤(標準サポート)
通信層は HTTP/2 を介して⾏われる
» HTTP/2は、HTTP/1.1 と互換性あり
FW透過性があるといえる
» ※但し、OBCのデフォルト設定では80や443のようなwell-knownポートで待ち受けるわけではない
通信ライブラリとしては、C、C++、Java、Go、Node.js、Python、Ruby に対応
– Googleが開発した「プロトコルバッファ」という形式でデータはシリアライズされ送受信される
• 仕様上、gRPCはシリアライズフレームワークを切り替え可能だが、実際はプロトコルバッファを利⽤
構造化データのシリアライズ部分について、gRPCはプラットフォーム非依存で拡張可能なメカニズムを提供
プロトコルバッファ自体も、開発言語に対して中⽴的
• gRPCのGo言語実装(ライブラリ)として、「grpc-go」が存在
23

Open Blockchain
Open Blockchainにおけるデータベース
– 各ノードの台帳(Ledger)のデータストアには、「RocksDB」が利⽤されている
• http://rocksdb.org/
• facebook社が実装し、OSSとして公開しているkey-value型高速データストア
開発言語はC++
内部的には、Google社の「LevelDB」をベースに拡張
» Bitcoinの実装が内部的にLevelDBを使っている
FlashSSDメモリ/RAMを使った高速アクセスに適した組込み志向のデータベース
» CPUコアが多いサーバでスケーラブルに実⾏可能
» IO-bound / in-memory / write-once な作業に向く
トランザクションサポート(そういう機能をサポートする形式のDBタイプを利⽤すれば)
» BEGIN / COMMIT / ROLLBACK
– つまり、RDBMSではない。いわゆるNoSQL DBである
• SQLで扱うものではない
24

OBCのコンセンサスモデル
– OBCはプラガブルアーキテクチャを採用しているので、コンセンサスアルゴリズムを切替可能
• とはいえ、リリース初期時点で対応しているコンセンサスアルゴリズムは次ページの実装のみ
– コンセンサスモデルは奥深く分散コンピューティング分野における昔からの研究テーマの一つ
• 深⼊りする必要は無いが、以下の⽤語だけは理解しておくと良い (OBC実装上も登場するから)
– 「ビザンチン耐故障」(Byzantine Fault Tolerance)
ビザンチン・フォールトトレラント性を備えるための仕組み・アルゴリズムのこと
ネットワークを介したコンピュータ(ないしプロセス)が、故障や悪意によって正しくない情報を伝達しうる状況
になったときでもシステム全体としては正しい合意(状態)に至ることができるようにしておかねばならない
» ⾔葉の由来は、
「ビザンチン帝国(東ローマ帝国)の将軍達n人が、(都市攻撃の成否を判断するため)お互いの兵⼒
を知りたい。正しく判断しないと、都市攻撃に失敗して全滅してしまうから。そのうちm⼈の将軍は裏
切り者であり、嘘の情報を流して合意に⾄ろうとするとする。忠実な(=裏切り者ではない)将軍達はど
うやって正しい合意(情報を得る)に至ることができるか」という問題から。
回復⼒が⾼いもの(=裏切り者の数がある程度多くても全体として正しい合意に⾄れるもの)ほど優秀
なアルゴリズムであるということになる。
» この問題のことを BGP (Byzantine Generals Probrem, ビザンチン将軍問題)という
?
Open Blockchain
25
次ページのコンセンサスアルゴリズム一覧に「PBFT」という名
前がでてきたときに、「？？？」とならないように、基本用語
を押さえておきましょう

Open Blockchain
OBCがサポートするコンセンサスモデルとその決定ロジック
– 以下のどちらかで、その中でのパラメータの組合せで決定される(※環境変数が優先)
• ① 環境変数
OPENCHAIN_PEER_VALIDATOR_CONSENSUS
» "obcpbft" or "noops" を指定
OPENCHAIN_OBCPBFT_GENERAL_MODE
» "classic" , "sieve" or "batch" を指定
• ② 設定ファイル(openchain.yaml & config.yaml)
obc-peer用設定ファイル(openchain.yaml)内
» peer.validator.consensus
OBCPBFTコンセンサスプラグイン用設定ファイル(config.yaml)内
» general.mode
26
OBCがサポートするコンセンサスモデル説明
No-op
(consensus ignored)
• 何もしない。コンセンサスを無視。
• 開発ローカルPCで、検証ノードが1台のみ(コンセンサスが不要)な場合のためのもの
Classic PBFT
• 昔からある(Classic)、ビザンチン耐故障性を備え、それを実現するアルゴリズム
• PBFTとは、「Practical Byzantine Fault Tolerance」の意味。
• 参加者は事前に決まっていることが現実的には前提
• 全体の1/3までは回復⼒がある
Batch • Classic PBFTをベースに、複数トランザクションで1ブロックにする
SIEVE
• Classic PBFTの拡張版。「シーブ」と読む。
• OBCにおけるデフォルトのコンセンサスアルゴリズム
• 実装上も、Classic PBFTのコードを再利⽤している

Open Blockchain
SIEVEコンセンサスの動き
– 前提として、OBC基盤は、どのようなチェーンコードの実⾏も許容する仕様
• チェーンコードというアプリケーションロジックを受け⼊れ、それを実⾏する
実際にデプロイされるまで、それがどのようなロジックであるのか、OBC基盤は知るすべがない
– 一方で、チェーンネットワーク上のロジックの大原則がある
• 「非決定的(non-deterministic)なトランザクションは排除されなければならない」
ここでの非決定的の意味 … 同じ⼊⼒、同じロジック(ソースコード)であっても、出⼒が同じにならないもの
排除⼿段の例：注意深くチェーンコードのコードインスペクションする、DSL(ドメイン記述言語)の採用、…
• SIEVEは、この「非決定的なトランザクションからの保護」と、「コンセンサス処理」を分離して⾏う
– SIEVEはVPのうち1つが「リーダー(leader)」となる
• PBFT primaryのどれかがその役割を担う
• このリーダーが、トランザクションリクエストを受け付けると「仮の実⾏(tentative exeution)」として
OBC基盤を構成するノード(検証ピアプロセス=VP)に配布する
受信したノードは、そのそれぞれでこのトランザクションが改竄されていないかを検証し、OKであればチェーン
コードを実⾏し、実⾏結果(ハッシュ)をリーダーに返す
– リーダは、これら戻された「仮の実⾏結果(ハッシュ)」を集めてverify-setとする
• 「正しく実⾏した」結果であるにもかかわらず、ノード間で実⾏結果(ハッシュ)が異なっている場合、
そのトランザクションは「非決定的」と判断される
そのトランザクションは破棄され、各ノードのDB内容はロールバックされる(そのようにリーダーが指示)
• 「仮の実⾏」の結果が全てのノード(core PBFTノード)で一致していてれば、リーダーはトランザク
ションの確定をノードに通知する
どれだけのノードが合意すれば全体としてOKとするか、などはPBFTアルゴリズムに沿って決定される
27

Open Blockchain
補足：Bitcoin のコンセンサスモデル
– Bitcoinでは、このコンセンサスモデル(Proof of Work)が特徴的で有名になった
• OBC仕様も、こういったコンセンサスモデルに対する言及もある
• しかし、現在のOpen Blockchainはこのような「匿名の多数の参加者でチェーンを共有する」こと
を前提としたものではない (かつ、コンセンサスプラグインの現場開発は非現実的)
28
その他のコンセンサスモデル例説明
Proof of Work
(PoW)
• 仕事量(投⼊した計算量 = マイニングコスト)を元に正当性を決めるという考え方
• 難しい計算(仕事)を計算機資源を投入して実施したということに報酬が与えられる
ことでブロックチェーンを積み増すためのモチベーションを維持させる
• ブロックチェーンを⻑くすることが、チェーン全体の安全性を⾼めることと⼀体化
• マイニングとは…
• 次の「ブロック」のヘッダのハッシュ値が「difficulty targetの値以下」になるようなハッ
シュ値を、nonce値を変えながら、ひたすら計算して得る⾏為。⾒つかると、そのノー
ドが次の新しいブロックを作る権利を得、その間のトランザクションを格納する
• このdifficulty targetは、この「マイニング=次のブロックを発⾒する」⾏為に、10分
程度で⾒つかるように定期的 = ブロック数の一定数追加毎に調整される
• この「次の新しいブロック」を⾒つけたノード(=マイナー、採掘者)が…
• 報奨⾦としてのBitcoinを入手する(coinbase報酬=現在は25BTC + そ
のブロックに含まれるトランザクションの⼿数料合計のBTC)
• チェーンネットワークに、次のブロックをP2P送信する。ネットワークに参加してい
るノードがブロックを"検証"し、問題なければブロックチェーンに追加して別の
ノードに転送する。合意が形成されると、次のブロック探しがまた開始する
• 全体の51%を占める複雑な計算量を投⼊するための労⼒が膨⼤なものになるので、結果
として悪意を持つ誰かが実際にそれを実現してしまうリスクを下げる。
• マイニングという仕組みにシステム全体が依存するので、本質的に、電⼒(エネルギー)消費
が⼤量にならざるを得ないので非経済的。

Open Blockchain
ここまでで分かったことを元に整理
29
#1のパターン
A社向けノード群 B社向けノード群
C社向けノード群
??
通信プロトコルはgRPC/HTTP2で原理的には
ファイアウォールを超えて通信可能。データの中身はまだ
不明
Go言語で開発された
Linuxサーバプロセス
データベースは、NoSQL DBの「RocksDB」
Go言語で開発された、Linux上のネ
イティブプロセス

30

Open Blockchain
Open Blockchainのアーキテクチャ
– 公式の絵としてよく登場する図
• しかし、最初の理解のためにはむしろ忘れた⽅が良い
31

Open Blockchainの概念・⽤語
OBCにおけるロール(Roles)関連用語
– 3種類のロール
• 基本的には、トランザクションの発生と、その内容が正当(valid)かどうかを審査する観点で区別
• あくまでロールであって、実際には1つのノードが複数のロールを持つということがある
概念上の定義であり、OBCの実装上は特にこれらの用語は登場しない
32
カテゴリ用語説明
ロール
チェーントランザクター
(Chain Transactor)
• ブロックチェーンネットワークに対して何らかの「トランザクション」を作成したり、ネット
ワークデータをクエリ(現在値の取得)したりすることが許可されているエンティティ(実
体)のことを指す。
チェーンバリデーター
(Chain Validator)
• チェーンネットワークへの参加権(stake)を持つエンティティ(実体)を指す。
• バリデーターであること = コンセンサスネットワークの参加者
• 各チェーンバリデーターは、ある1つのトランザクションが正当(valid)かどうかを決定
する投票権を持っている。
• そのため、チェーンバリデータは、その参加するチェーンに送信された全てのトランザク
ションを審査することができる。
• チェーンバリデーターは、秘匿性のあるチェーンコードを実⾏することができる。
チェーンオーディター
(Chain Auditor)
• トランザクションを審査・審問(interrogate)する権利を持つエンティティを指す。

OBCにおける参加者(Participants)関連用語
– 4種類の参加者
• 基本的には、ユーザー、アプリ提供者、ブロックチェーン基盤提供者、といった趣
概念上の定義であり、OBCの実装上は特にこれらの用語は登場しない
33
カテゴリ用語説明ロール
参加者
ソリューションユーザー
(Solution User)
• チェーンネットワークの詳細には特に興味が無い、エンドユー
ザーのこと。
• ソリューションユーザーは、典型的には、ソリューションプロバイ
ダによって利⽤可能になっているアプリケーションを通じて、あ
るチェーンネットワークにおけるトランザクションを開始する
• (n/a)
ソリューションプロバイダ
(Solution Provider)
• エンドユーザー(=Solution User)向けに、モバイル端末
and/or ブラウザベースのアプリケーションを開発して提供す
る組織のこと。
• 幾つかのアプリケーションオーナーや、ネットワークオーナーでも
ある場合があり得る。
• チェーントランザクター
ネットワークプロプライエター
(Network Proprietor)
• チェーンネットワークの目的を定義して、そのためにセットアップ
する組織のこと。そのネットワークのステークホルダーである。
• チェーントランザクター
• チェーンバリデーター
ネットワークオーディター
(Network Auditor)
• トランザクションの内容を審査する権限を持つ個人または組
織のこと。
• チェーンオーディター

OBCにおけるビジネス観点でのネットワーク(Business network)関連用語
– 3種類のネットワーク
• 概念上の定義であり、OBCの実装上は特にこれらの用語は登場しない
34
ビジネス
ネットワーク
業種/業界ネットワーク
(Industry Network)
• 特定の業種/業務(industry)向けにソリューションを提供するチェーンネット
ワークのこと。
地域別業種/業界ネットワーク
(Regional Industry Network)
• 特定の業種/業務(industry)&地域向けにソリューションを提供するチェー
ンネットワークのこと。
適用業務ネットワーク
(Application Network)
• ある1つのソリューションのみを提供するチェーンネットワークのこと

OBCにおけるチェーン種別関連用語
– 2種類のチェーン
35
チェーンの
種別
メインチェーン
(Main Chain)
• ビジネス上のネットワークのこと。
• 同じ組織に所属するグループによって、各メインチェーンは1つまたは複数の検証済みの
アプリケーション/ソリューションを操作する。
• ※注意：Bitcoin上では、「最も⻑くブロックが続いているチェーン(正当となるチェー
ン)」のことを main chain と呼ぶので、異なる意味定義である
機密チェーン
(Confidential Chain)
• その契約のステークホルダによってのみアクセス可能な、機密性のあるビジネスロジックを
実⾏するための特別な目的を持ったチェーンのこと。

OBCにおけるトランザクション種別関連用語
– 2種類のトランザクションがある
• OBCのチェーンネットワーク(ブロックチェーンシステム)に何かを要求することをトランザクションという
そして、そのトランザクションには2種類ある
• 重要：これは概念だけではなく、OBC実装上の話に直結する
36
トランザクションの種別
デプロイメントトランザクション
(デプロイトランザクション)
(Deployment Transaction)
• チェーンに対して、新しいチェーンコード(chaincode, cc)をデプロイ
するトランザクションのこと。
• トランザクションの要求は、REST APIで⾏う
呼び出しトランザクション
(Invocation Transaction)
• チェーンコード上の関数を呼び出し実⾏するトランザクションのこと。
• トランザクションの要求は、REST APIで⾏う

OBCにおけるトランザクションの機密性種別関連用語
– 2種類のトランザクションがある
37
トランザクションの
機密性種別
パブリックトランザクション
(Public Transaction)
• ペイロードが誰にでも公開されているトランザクション。
• そのチェーンネットワークにアクセス可能な人であれば、誰でもパブリックト
ランザクションの詳細を⾒ることができる
機密トランザクション
(Confidential Transaction)
• 暗号化されたペイロードを持つトランザクション。
• トランザクションの種類が、「デプロイメントトランザクション」である場合は、
デプロイした後、それを「呼び出しトランザクション」で呼び出すことができ
る。その場合、その呼び出しトランザクションもまた、機密トランザクション
なければならない。

OBCにおけるチェーン間トランザクション種別関連用語
– 2種類のチェーン間トランザクションがある
38
チェーン間トランザク
ションの種別
ネットワーク間トランザクション
(Inter-Network
Transaction)
• 2つのビジネスネットワーク(=メインチェーン)間のトランザクションのこと
ネットワーク内トランザクション
(Inter-Chain Transaction)
• 機密チェーンとメインチェーン間のトランザクションのこと。
• 機密チェーン内のチェーンコード(cc)は、1つまたは複数のメインチェー
ンにおけるトランザクションをトリガーできる

OBCにおける台帳(Ledger、レジャー)データ関連用語
– OBCにおいて、台帳は3種類のデータから構成されている
39
台帳データ
チェーンコード状態
「別名：ワールドステート」
(Chaincode-state)
(a.k.a World state)
• OBCは、状態(ステート、state)をサポートしている (※注目点)
• チェーンコードはステートAPIを通じて、内部の「状態ストレージ」にアクセスすること
ができる
• 状態は、「ワールドステートへのアクセスロジックを持つチェーンコード関数」を呼び出
す「トランザクション」によって生成/更新される
トランザクションリスト
(Transaction List)
• 全ての処理済みのトランザクションは、台帳(Ledger)内に、そのオリジナルの状態
で保持されている
• (機密トランザクションであれば、ペイロードは暗号化された状態)
• そのため、ネットワーク参加者は、アクセス権があるものに対しては、過去のトランザ
クションに対してもその情報を参照できる
台帳のハッシュ
(Ledger Hash)
• Ledgerの現在のスナップショットをキャプチャしているハッシュデータ
• 台帳生成のための最初のトランザクション(=genesis transaction。“創世記の”
トランザクション)から、ネットワークによって処理されて検証され受け付けられた全て
のトランザクションに至るまでのデータを元に生み出されているもの
• 台帳は全てのトランザクションがひたすら上に一直線に積み重なったイメージ。その
最後の順序位置を「高さ」(height)という属性値で表現する
チェーンコード状態
(ワールドステート)
トランザクションリスト
(Blockのリスト)
台帳のハッシュ
(を含む、メタデータ)

OBCにおけるチェーンコード(Chaincode,cc)種別関連用語
– チェーンコードとは、OBCにおける「スマートコントラクト」の表現で、ビジネスロジックのこと
40
チェーンコー
ド種別
パブリックチェーンコード
(Public Chaincode)
• パブリックトランザクションによってデプロイされるチェーンコード。
• この種類のチェーンコードはネットワーク上のどのメンバーにも実⾏出来るも
のとなる。
機密チェーンコード
(Confidential Chaincode)
• 機密トランザクションによってデプロイされるチェーンコード。
• この主のチェーンコードは、ネットワークへの権利を持つメンバー(=チェーン
バリデーター)によってのみ実⾏することができる
アクセスコントロールチェーンコード
(Access Controlled Chaincode)
• 機密トランザクションによってデプロイされたチェーンコードで、invokerに
よってapproveされたトークンを埋め込まれている。
• この"Access Controlled Chaincode"を実⾏出来るinvokerは、例
え自分自身がバリデーターではなかったとしても、機密チェーンコードを実
⾏できることになる。

OBCにおけるネットワークエンティティ関連用語 (1/2)
– ブロックチェーンを(広義に)構成するネットワークシステム上のノードの種類
• ポイント：
「非検証ノード(NVP)も、台帳(Ledger)のコピーを持つ」
「非検証ノード(NVP)も、検証ノード(VP)と同様にチェーンネットワークの構成メンバーである」
41
ネットワーク
エンティティ
アプリケーションバックエンド
(Application Backend)
• 目的:
• モバイル端末やブラウザベースのアプリケーションをサポートし、提供するもの
• 主な役割：
• エンドユーザとそれらの登録を、メンバーシップサービスを利⽤しつつ管理する。トラ
ンザクション要求を開始し、そのリクエストをノードに送信する
• 所有者：
• ソリューションプロバイダ, ネットワークプロプライエター
非検証ノード(非検証ピア)
(NonValidationg
Node(Peer))
• 目的:
• トランザクションを組み⽴てて、それを検証ノードに転送する
• Peerノードは、全てのトランザクションレコードのコピーを維持し、ソリューションプロ
バイダがローカルでそれらに対してクエリできるようにする
• NVP - Non Validating Peerと呼ぶ
• 主な役割：
• メンバーシップサービスによって発⾏された、「ユーザーの認証情報」を管理/維持
する。トランザクションを組み⽴てて、それらを検証ノードへ転送する
• 台帳(Ledger)のローカルコピーを維持する
• そして、アプリケーションオーナーがそれらをローカルでクエリできるようにする
• 所有者：
• ソリューションプロバイダ、ネットワークオーディター

OBCにおけるネットワークエンティティ関連用語 (2/2)
– ブロックチェーンを構成するネットワークシステム上のノードの種類のこと
• とても重要
42
ネットワーク
エンティティ
検証ノード(検証ピア)
(Validating Node Peer)
• 目的:
• トランザクションを生成したり、検証したりする
• そして、チェーンコードのstate(状態)を維持する
• VP - Validating Peerと呼ぶ
• 主な役割：
• メンバーシップサービスによって発⾏された、「ユーザーの認証情報」を管理/維持
する
• トランザクションを作成するネットワーク上の他の検証ノード共に、トランザクションを
実⾏・検証する
• 台帳(Ledger)のローカルコピーを維持する
• コンセンサスに参加し、その結果を受けて台帳(ledger)を更新する。
• 所有者：
• ソリューションプロバイダ、ネットワークプロプライエター
メンバーシップサービス
(Membership Service)
• 目的:
• エンドユーザーと組織のID(identity)を発⾏・管理する
• 主な役割：
• 各エンドユーザーや組織に対して、enrollment cetificateを発⾏する
• 各エンドユーザーや組織に対して、transaction certificates を発⾏する
• OBCエンティティ間のセキュアな通信に必要なTLS証明書を発⾏する
• チェーン固有のキーを発⾏する
• 所有者：
• サードパーティのサービスプロバイダ

OBCにおけるメンバーシップサービスのコンポーネント用語 (1/2)
– 認証を司るノード(CA) = メンバーシップサービスを提供するノードのコンポーネント
43
メンバーシッ
プサービス
のコンポー
ネント
Registration Authority
• ネットワークの参加者に対して、登録名とパスワードのペアを割り当てる。
• このユーザー名/パスワードペアは、ECAからenrollment certificationを取得する
ために利⽤される
Enrollment Certificate
Authority (ECA)
• ネットワーク参加者に、enrollment証明書 (ECert) を発⾏する。
• これによって、メンバーシップサービスに登録済みであることが証明される。
• ECertsは1つまたは複数のネットワークで、参加者を一意に特定するための証明書
として⻑期間利⽤される
Transaction Certificate
Authority (TCA)
• enrollment証明書(ECert)の所有者に対してトランザクション証明書(TCerts)
を発⾏する。
• TCertsの番号は、各Ecertから無限に生成される。
• TCertはネットワーク参加者によって、トランザクションを送信するために利⽤される。
• セキュリティ要件のレベルによっては、ネットワーク参加者は各トランザクション毎に新し
いTCertを利⽤することを選ぶかもしれない。
TLS-Certificate
Authority (TLS-CA)
• チェーンネットワーク内で、システムがメッセージ転送をするためのTLS証明書を発⾏
する。
• TLS証明書は、システム間での通信チャネルをセキュアにするために使われる。

OBCにおけるメンバーシップサービスのコンポーネント用語 (2/2)
– OBCのあるチェーンネットワークの参加者は、同一のルートCAを使うことが大前提
• 基本的に、OBCはプライベート型(自社内)、あるいはコンソーシアム型(会社間)のチェーンネットワ
ークを前提としたソフトウェアであるといえる
44

ここまでで分かったこと
ここまでで分かったことを元に整理 (パターン#1で、A社にフォーカスを当てた状態)
45
ネットワークパターン#1の場合
A社ノード群
アプリケーション
バックエンド
ノード
チェーンネットワークの参加者間
で共有される認証サービス提供ノード(CA)
メンバーシップ
サービス
非検証ピア
ノード(NVP)
検証ピア
ノード(VP)
チェーンバリデーター
チェーントランザクターチェーンオーディター
ソリューションユーザー
(クライアント)
ソリューションプロバイダー
B社ノード群
検証ピア
ノード(VP)
C社ノード群
検証ピア
ノード(VP)
イベントベースでの
メッセージデータ送受信
イベントベースでの
メッセージデータ送受信

閑話休題：Open Blockchainのパフォーマンス目標
OBCのパフォーマンス目標
– 以下が一旦のゴールとして取り組まれている
• 標準的な本番環境で「近接する15台のValidating Nodeで100,000トランザクション/秒」を
達成できること
– 引用元：
• https://github.com/openblockchain/obc-
docs/blob/master/FAQ/usage_FAQ.md
46
What are the expected performance figures for OBC?
“The current performance goal for OBC is to achieve 100,000 transactions per second in a standard
production environment of approximately 15 validating nodes running in close proximity. The OBC team is
committed to continue to invest in improving the performance and the scalability of the system.”

ブロックチェーンに不向きなもの
「ブロックチェーンに不向きなこと」
• ハイパフォーマンスな取引(ミリ秒)が必要な領域
• ただ一人の参加者向けの何か(ビジネスネットワークがないもの)
• データベースレプリカ(の代替手段)
• メッセージングソリューション(の代替手段)
• トランザクション処理システム(の代替)
• 価値が低く、かつ、トランザクション量が⼤量な領域
47

48
Open Blockchainの詳細 (主な要素)

OBCの「ブロックチェーン」
– OBCにおけるブロックチェーンは、トランザクションのリストである
• ブロックチェーンに関する情報としては、以下の構造体が定義されている
Open Blockchainにおけるブロックチェーン
49
ブロックの積み重なり
=ブロックチェーン
ブロックチェーン情報
message BlockchainInfo {
uint64 height = 1; //高さ(height)
bytes currentBlockHash = 2; //「現在のブロック」を表現する情報(ハッシュ。バイト配列)
bytes previousBlockHash = 3; //「1つの前のブロック」を表現する情報(ハッシュ。バイト配列)
}
OBCブロックチェーン情報の構造体
現在のブロックを示すハッシュ値
1つ前のブロックを示すハッシュ値
ブロックの高さ(height)

50
{
"height":6,
"currentBlockHash":"zyHqhxj+1nbOaRerTPbYOmuet+HV5kZrLkrrm/bdEj/aunH1d083LLW1UwFNKwEVqyl/iGynvh6l89Ybxf
uCUw==",
"previousBlockHash":"ERJgDxMaKMoobV8uRySDB2uWHpUkRWE4IS66PAvrxGqw8xepq3SJmC1F7e9z+ptdFspo/rzlBpTmsL
K9dYWvAw=="
}
OBCブロックチェーン情報データ例
(例：REST API「/chain」への GETリクエスト結果のJSONデータ)
uint64の上限値は 2^64。(事実上、heightの桁あふれは気にしないで良い)

– 1つのブロックチェーンネットワーク(=ピア群から構成されるネットワーク)は、ただ1つのブロック
チェーンを共有している
• 1つのピアプロセスが複数(2つ以上)のブロックチェーンを共有する、ということはない
例えるなら、“複数のノードが、RDBMSの1個のテーブルだけを共有する”ようなイメージ
• もう1個別の台帳が必要 → もう1個別のブロックチェーンが必要 → もう1セット、ピア群が必要
51

Open Blockchainにおけるブロック
OBCの「ブロック」
– OBCにおけるブロックは、ブロックチェーンでいう「ブロック」そのもの
• チェーンにおける(自分からみて)「その1つの前の」ブロックのハッシュ値を含んでいる各ブロックの一
連のリンクリスト構造のデータとして定義されている
ある1つのブロックは、複数の「トランザクション」と、そのブロックの全てのトランザクションを実⾏した後の「ワー
ルドステートのハッシュ」をその1つのブロックの内部に保持
52
ブロック内に含んでいるトラ
ンザクションの情報
(仕様上は複数格納可能)
ブロック情報
トランザクション情報
1つ前のブロックのハッシュ情報
非ハッシュデータ(ハッシュ計算対象外)
ワールドステートの最終状態ハッシュ
“ブロックチェーン”の名前の由来
Bitcoinのブロックデータのようなアプ
リ固有仕様の属性は含まれていない
プロトコル仕様のバージョン番号
タイムスタンプ
トランザクションデータ群に対するハッシュ
コンセンサス用メタデータ
トランザクション結果
トランザクションの
UUID、実⾏結果戻り
値、エラーコード、エラー
⽂字列
ローカル台帳コミット時タイムスタンプ

OBCの「ブロック」とそのチェーン構造
53
Genesis
block
block
1
block
2
block
3
block
n
ハッシュ値ハッシュ値
トランザクショントランザクション
ハッシュ値ハッシュ値ハッシュ値
ブロックチェーンの説明でよく⾒かける図
「ブロックチェーンは、「ハッシュ値」で過去のトランザクションの情報を保護し、改竄できないようにしている」
ハッシュ値

OBCのブロック (1個のブロックデータを取得した時のJSONデータ表現)
– 自分の1つ前のブロックへのハッシュ値を持っている & ステートハッシュを持っている
54
{
"transactions": [
{
"type": 1,
"chaincodeID":
"CjlodHRwczovL2dpdGh1Yi5jb20vaWJtLWJsb2NrY2hhaW4vbWFyYmxlcy1jaGFpbmNvZGUvcGFydDISgAE4ZmU3YjNkOWEzZDQzYzViNmI5MWQ2
NWIwNTg1MzY2ZmEzZDU2MGQ1MzYyZTExZjBlZWExMWZmNjE0YTI5NmZkZWM4NjA3YjE3ZGU0MjljOTE5OTc1ZDUzODY5NTNlNGRhYzQ4NmEw
OWNlNmM5NjVmNTg0NGQ3ZDE4MzgyNWVmYg==",
"payload":
"Cs8BCAESvgEKOWh0dHBzOi8vZ2l0aHViLmNvbS9pYm0tYmxvY2tjaGFpbi9tYXJibGVzLWNoYWluY29kZS9wYXJ0MhKAAThmZTdiM2Q5YTNkNDNj
NWI2YjkxZDY1YjA1ODUzNjZmYTNkNTYwZDUzNjJlMTFmMGVlYTExZmY2MTRhMjk2ZmRlYzg2MDdiMTdkZTQyOWM5MTk5NzVkNTM4Njk1M2U0Z
GFjNDg2YTA5Y2U2Yzk2NWY1ODQ0ZDdkMTgzODI1ZWZiGgoKBGluaXQSAjk5",
"uuid":
"8fe7b3d9a3d43c5b6b91d65b0585366fa3d560d5362e11f0eea11ff614a296fdec8607b17de429c919975d5386953e4dac486a09ce6c965f5844d7
d183825efb",
"timestamp": {
"seconds": 1457158085,
"nanos": 678795931
},
"cert":
"MIICDzCCAZWgAwIBAgIBATAKBggqhkjOPQQDAzApMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMQwwCgYDVQQDEwN0Y2EwHhcNMTYw
MzA1MDYwNjQ2WhcNMTYwNjAzMDYwNjQ2WjA7MQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMR4wHAYDVQQDDBV1c2VyX3R5cGUxXzQw
MDM0NWI4YTAwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAARe1jrgbvituggektmbgypZdDkZhcvSB0wbRw+6Rj3UH4xvdg47947pqrR9pBxn8uo2VZIiSvh
cMdIina2GE5H5+tsOusLyCZ5S2TJLHoVveb+oA2q/gmZTLUaorkXlOACjfzB9MA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMA0GA1UdDg
QGBAQBAgMEMA8GA1UdIwQIMAaABAECAwQwPQYGKgMEBQYHAQH/BDCb4leuD60A7bXV19zXYA4/b1f2NFOn+KdQP23Po/Sm42WYid1cKcjFUT
ntMs2CzBUwCgYIKoZIzj0EAwMDaAAwZQIxANplH0Dwtmp/oHk3sPVEe62AccVOl2+iHZF5cc4COB9MyNKfQfflhnOVwrZ3b5CrKwIwaez/9YnSSuNW
zQkMWI6QxPhugFcPvPGc8HGZ/dYu7zUfW6msVGoVNn29JZXmLDnf",
"signature":
"MGUCMBxFWcjZ/smGFV2uzRa5uDzEmE462Uv296QD9S2b4urnfstjbZIVlVe92n1bWjAGowIxAMTpDs2IYqOFirhFdhDTAAP7UM6V+qxWS1F9QwF
HuUqJD5SM1Y9jWTfQROUMUvzXIg=="
}
],
"stateHash": "NiS1Z0Bu54d2qlTMB2i48hcTUp79PsBxpqIgw8PlyBwdSCqo6Ua3XEILSb4hjrLVHitINBQWurnOFEdnqh27+w==",
"previousBlockHash": "RrndKwuojRMjOz/rdD7rJD/NUupiuBuCtQwnZG7Vdi/XXcTd2MDyAMsFAZ1ntZL2/IIcSUeatIZAKS6ss7fEvg==",
"nonHashData": { "localLedgerCommitTimestamp": { "seconds": 1457158106, "nanos": 629024431 }
}
}
実際のブロックデータ例

OBCの「ブロック」
– OBCにおいて、「トランザクション」は以下の3種類(①-a, ②-a, ②-b)が存在する
• ① 「チェーンコードのデプロイ」
①-a. Deploymentトランザクション：新規にチェーンコードをデプロイ&初期化メソッドを呼出
• ② 「チェーンコードの実⾏要求」
②-a. Invokeトランザクション：デプロイ済みのチェーンコードのRunメソッドを呼出
②-b. Queryトランザクション：デプロイ済みのチェーンコードのQueryメソッドを呼出
• よって、トランザクションデータは、「チェーンコードのデプロイ情報」か、「チェーンコードの実⾏情報」の
どちらかを保持していることになる
但し、②-bはトランザクションではあるものの、ブロックには記録されない
– いずれにしても、トランザクションは、台帳(Ledger)にブロックとして記録が確定される前に
実⾏される
– トランザクションによって実⾏されるチェーンコードの処理によって、ワールドステート内の値は
変更される場合がある
• 上記「①-a. Deploymentトランザクション」と「②-a. Invokeトランザクション」が値を更新する
②-b は、更新しない (更新しないものが②-aではなく②-bとして開発される、といった⽅が理解しやすい)
• ワールドステートのハッシュ値の変更が⾏われたあと、トランザクションはブロックに記録される
55

Open Blockchainにおけるトランザクション
OBCのトランザクション
– OBCにおける“トランザクション”は、「台帳(Ledger)上の関数を実⾏するよう」ブロックチェ
ーンネットワークへ要求する、その1つのリクエストのことを指す
• その台帳上の関数(=つまり、ビジネスロジック)は、チェーンコードとして実装される
56
message Transaction {
enum Type {
UNDEFINED = 0;
CHAINCODE_NEW = 1;
CHAINCODE_UPDATE = 2;
CHAINCODE_EXECUTE = 3;
CHAINCODE_QUERY = 4;
CHAINCODE_TERMINATE = 5;
}
Type type = 1;
string uuid = 5;
bytes chaincodeID = 2;
bytes payloadHash = 3;
ConfidentialityLevel confidentialityLevel = 7;
bytes nonce = 8;
bytes cert = 9;
bytes signature = 10;
bytes metadata = 4;
google.protobuf.Timestamp timestamp = 6;
}
message TransactionPayload {
bytes payload = 1;
}
enum ConfidentialityLevel {
PUBLIC = 0;
CONFIDENTIAL = 1;
}
OBCトランザクションデータ構造仕様
トランザクション種別としては、予約されているものを含めて6種類が定義されている。
1. UNDEFINED :将来のために予約。
2. NEW :チェーンコードの新規デプロイをする(①-aに相当)
3. UPDATE :将来のために予約(チェーンコードの更新をする?)
4. EXECUTE :ステートを更新しうるチェーンコードを実⾏する (②-aに相当)
5. QUERY :ステートを更新せず読取だけのチェーンコードを実⾏(②-bに相当)
6. TERMINATE :将来のために予約。チェーンコードを無効化する(呼び出せなくする)
ある1つのトランザクションは、UUIDを持ち⼀意に識別される
あるトランザクションが実⾏対象とするチェーンコードは、チェーンコードIDで指定される
トランザクションのペイロードは、バイト配列であり、その構造⾃体はOBCは規定していない
機密レベルは「PUBLIC」と「CONFIDENTIAL」の2種類

Open Blockchainにおけるステート(ワールドステート)
OBCの「ワールドステート」
– 簡単にいうと、key-valueペアのデータベース
• key
{チェーンコードIDのUTF-8⽂字列, チェーンコード内における⼀意な値を⽰すバイト配列}の tupple
» チェーンコードIDが含まれることによって、単一のkey-valueデータベースであっても、チェーンコードが別
なら同じキー名を利⽤することができる
• value
バイト配列(データ構造に決まり事はない。完全にアプリケーション設計に委ねられている)
» ⽂字列データであっても、内部的にはバイト配列として保存される
– トランザクションによってチェーンコードが実⾏された状態を格納するためにも使用できる
• Bitcoinなどで持つ情報は「トランザクションデータのみ」であり、結果値(現在値)が格納されている
わけでは無い
• しかし、OBCでは永続データとして台帳データベース内のワールドステートとして、key-valueペア
のデータベースを持つ
チェーンコードは、単純に、例えば「Aさんの現資産残は10, Bさんの現資産残は20」といった結果値(現
在値)を保持することができるということ
57

Open Blockchainにおけるチェーンコード
OBCのチェーンコード
– OBCにおけるチェーンコードとは、アプリケーションコード(いわゆるスマートコントラクト)である
• 「(Business) Logic = Chaincode = Smart contracts」
• チェーンコードは、ワールドステートの状態(keyに対応するvalue)を変更できる唯一の手段
– 実体はソースコード(ビジネスロジック)であり、OBC基盤に「デプロイされるもの」である
• GitHubのような共有ソースコードリポジトリにコードを配置して、そのURLを指定しOBC基盤にデ
プロイする
• OBCネットワークの各ノード(peer)は、デプロイメントトランザクションを受け取ると、指定された
URLからソースコード(Go言語)をダウンロードして取り込む
• デプロイについてもコンセンサス処理が実⾏される
デプロイが成功すると、チェーンコードIDが割り振られる
» このIDは、チェーンネットワーク間(VP間)で同一
– あるチェーンネットワークに対し、チェーンコードは複数デプロイできる
• デプロイされたそれらのチェーンコードのうち、どのチェーンコードを実⾏するかは、トランザクション実⾏
を依頼する側(=チェーントランザクター)が要求時にその一意なIDを指定する
58

59
message ChaincodeSpec {
enum Type {
UNDEFINED = 0;
GOLANG = 1;
NODE = 2;
}
Type type = 1;
ChaincodeID chaincodeID = 2;
ChaincodeInput ctorMsg = 3;
int32 timeout = 4;
string secureContext = 5;
ConfidentialityLevel confidentialityLevel = 6;
}
OBCチェーンコード定義体構造仕様
チェーンコード仕様としては、以下が定義されている。
0 : 未定義
1 : Go言語
2 : Node.js
ChaincodeID型は、以下2つから構成される構造体
1. デプロイメントトランザクションが参照することになる、ソースコードが配置されているパス
2. チェーンコードのハッシュ値
ChaincodeInput型は、以下の2つから構成される構造体
1. 実⾏するチェーンコード内でさらに分岐するためのヒントになる関数名
2. 引数(⽂字列配列)

– チェーンネットワークとチェーンコードの論理的な関係を図⽰すると、以下のようになる
• 注意：下図の「処理(関数)」は論理的なものであり、Go⾔語プログラム上の実際の物理的な関
数(func)に必ずしも直接紐付けられるわけではない
60
チェーンネットワーク
チェーンコード1
…
…チェーンコード2 チェーンコードn
初期化⽤処理(関数)
更新あり処理1(関数)
:
更新あり処理n(関数)
参照のみ処理1(関数)
:
参照のみ処理n(関数)
:
:
:
:
1つのチェーンネットワークには、複数のチェー
ンコードをデプロイできる
チェーントランザクター
チェーンコード内には、大別して「初期化用処
理」、「更新あり処理」、「参照のみ処理」
の関数を複数個用意できる
チェーンコードの呼び出しトランザクション実⾏時には、
1.どのチェーンコードの(チェーンコードID)
2.どの更新あり処理なのか(関数名を1つ)
or どの参照⽤処理なのか(関数名を1つ)
の2つの情報と、「関数への引数」を指定して実⾏する
(複数のチェーンコードや関数を1回で呼出すことは不可)
デプロイトランザクション実⾏時には、デプロイの⼀環として合わ
せて実⾏する初期化⽤処理も指定する(関数名と引数を指定)

– OBCにおけるチェーンコードは、「各検証ピアノードでのサンドボックス環境で実⾏される」
• 仮想マシン環境は、現在はDockerのみがサポートされる
• Dockerコンテナは、起動元ホストである検証ピアノードと、gRPCで通信して以下を⾏う
コードの実⾏ (Invoke / Query)
結果の返却 (エラー有無、またはクエリ結果データ)
• 実際のチェーンコード(.go)内のどの関数を呼び出すかは、⽂字列で関数名と⽂字列配列の引数
を指定
61
type VM interface {
build(ctxt context.Context, id string, args []string, env []string, attachstdin bool, attachstdout bool, reader
io.Reader) error
start(ctxt context.Context, id string, args []string, env []string, attachstdin bool, attachstdout bool) error
stop(ctxt context.Context, id string, timeout uint, dontkill bool, dontremove bool) error
}
チェーンコード用チェーンコード用
仮想マシンを扱うために定義されているGoインターフェース仕様
type Chaincode interface {
Invoke(stub *ChaincodeStub, function string, args []string) ([]byte, error)
Query(stub *ChaincodeStub, function string, args []string) ([]byte, error)
}
OBCにおいてチェーンコードを表現するインターフェース仕様
Query関数 … ワールド関数の内容を更新せず、参照する処理
Invoke関数… ワールドステートの内容を変更しうる処理
Query関数 … ワールド関数の内容を更新せず、参照する処理

Open Blockchainにおけるpeer間メッセージ
OBCのpeer間メッセージ (1/4)
– OBCピア間でやり取りされるデータは、OpenchainMessageという構造体で表現される
• ここから、ピア間のやり取りをうかがい知ることができる
• 大別してメッセージタイプは4種類ある
Dicovery(5つ)、Transaction(4つ)、Synchronization(7つ), Consensus(1つ)
• そのタイプに基づいて、ペイロードのデータ構造が変わる
62
# カテゴリーメッセージタイプ意味
1
Discovery
DISC_HELLO
• peerノードは、起動時に
OPENCHAIN_PEER_DISCOVERY_ROOTNODEパラ
メータが設定されていると、そのノードに対して、自ノードの情報
を添えて、他の全てのPeerノードのエンドポイントと種別(non-
validatingか、validatingか)を知るためにHELLOメッセージ
を送信
• 同パラメータ(環境変数)には、「<ホスト名>:<ポート番号
>」の形式で、ルートノードのobc-peerプロセスの待ち受け
場所を指定する
• HELLOに対する応答メッセージのペイロードとして受け取ったブ
ロックチェーンのheightが、「自分が持つものより大きければ」すぐ
に同期プロトコルを開始する
2 DISC_DISCONNECT • ピアが明示シャットダウンする際
3 DISC_GET_PEERS
• 各peerノードは定期的にこのメッセージを送信する
(自分のノード情報と共に他のノードが知るpeerノードを要求)
4 DISC_PEERS • 各peerノードはGET_PEERSを受けると応答としてこれを返す
5 DISC_NEWMSG • 未使用

63
6
Transaction
CHAIN_STATUS
7 CHAIN_TRANSACTION
• チェインコードの実⾏要求として送信されるメッセージ
• ペイロードとしてTransactionデータを持つ
• そのTransactionデータのtype値で、実際に種類が決
定される。
• チェーンコードのデプロイ、実⾏(invoke)
8 CHAIN_GET_TRANSACTIONS • CHAIN_TRANSACTIONへの応答メッセージのタイプ
9 CHAIN_QUERY
• チェインコードのクエリ要求として送信されるメッセージ
• ペイロードとしてTransactionデータを持つ
• そのTransactionデータのtype値は常に
「CHAINCODE_QUERY」となる

– Syncカテゴリは、HELLOを起点として開始される「同期処理」を実際に⾏うメッセージ
• 自分の台帳データの「現在のブロック(currentBlock)」が、他のノードが持つ「現在のブロック」と
異なる場合は、以下のいずれかをブロードキャストする
SYNC_GET_BLOCKS
SYNC_STATE_GET_SNAPSHOT
SYNC_STATE_GET_DELTAS
• どのように同期処理を⾏うかは、そのノードでインストールされ設定されているコンセンサスアルゴリズ
ムプラグインによって決定され、処理される
64
10
Sync
SYNC_GET_BLOCKS
• ペイロードで指定した開始点のheightと終了点のheightまでのブ
ロックを要求するメッセージタイプ(終端は含まれる)
11 SYNC_BLOCKS
• SYNC_GET_BLOCKSへの応答メッセージを示すタイプ
• ブロックデータの差分を返す
12 SYNC_BLOCK_ADDED
• あるピアがローカルでブロックを更新/コミット後に、ブロックが追加され
たことを他ピアに通知するためにブロードキャストするタイプ
13
SYNC_STATE_GET_SNAPSHOT • 現在のワールドステートのスナップショットを要求するメッセージタイプ
SYNC_STATE_SNAPSHOT
• SYNC_STATE_GET_SNAPSHOTへの応答メッセージであること
を示すタイプ14
15 SYNC_STATE_GET_DELTAS • 一連のブロックの範囲の差を要求する
16 SYNC_STATE_DELTAS
• GET_DELTASへの応答メッセージであることを示すタイプ
• ワールドステートの差分を返す

– CONSENSUSタイプのメッセージは、ピアノードがCHAIN_TRASACTIONタイプのメッセ
ージを受け取ると、コンセンサスフレームワークによって内部的に発⾏される
• CHAIN_TRANSACTIONの内容をCONSENSUSメッセージへと変換し、同じペイロードを持っ
たメッセージを他の検証ピアノードにブロードキャストする
• コンセンサスプラグインは、このメッセージを受け取ると、その内部メカニズムに基づいて処理を⾏う
コンセンサスプラグインは、内部的なコンセンサス状態を管理するための有限ステートマシンを管理するため
、独自のサブタイプを作成する場合がある
65
17 Consensus CONSENSUS
• コンセンサス要求を⾏うメッセージ
• メッセージのペイロードは、CHAIN_TRANSACTIONの内容と同じ

閑話休題
– P2P型のソフトウェアであるOBCはどうやって他ノードを知るのか? (特に初回起動時)
• 答：明示的にパラメータ(環境変数、または設定ファイル)で指定する
起動時に、OPENCHAIN_PEER_DISCOVERY_ROOTNODEパラメータに設定値(<IPアドレス
>:<port>)があれば、そこに対してDISC_HELLOメッセージを送信し、そこから情報を得る
» つまり、システム管理者が、「適切な、常時動作しているであろうルートノードを知っている」ことが前提
デフォルトでは、その後動作中に「知った」他のピアの通信先は、DBに永続化し保持する
» 以降の再起動時には、それらを使う
⼀度他のノードと通信が成功すれば、後は定期的にDISC_GET_PEERSを送りあって情報を交換する
つまり、OBCはチェーンネットワークを構成するノードを「基本的に良く知っている」ことを前提としたモデル
– 参考：では、匿名・不特定多数を前提とするBitcoinのソフトウェアでは?
• 答1：Public DNSを利⽤する
DNSドメイン「seed.bitcoin.sipa.be」など(6つある)に対して Aレコードを問い合わせる
DNS応答として、ランダムにBitcoinノードのIPアドレスのリストが帰ってくるので、そのどれかを利⽤する
» あとは、そのノードから他のBitcoinノードの情報を得る
• 答2：固定のIPアドレス情報を利⽤する
Bitcoinリポジトリのテキストファイルに書いてあるIPアドレスを利⽤する
66

Open Blockchainにおけるobc-peerプロセス
OBCのpeer の実体 = obc-peerプロセス
– ここまでの説明に登場している「VP(検証ピア)」、「NVP(非検証ピア)」の実体は、
obc-peerというGoプログラム(常駐プロセス)である
– obc-peerコマンドに、サブコマンドpeerを指定して実⾏することで起動する
• 結果、OSプロセスとしてobc-peerプロセスが起動する
• 同プロセスは、openchain.yaml を設定ファイルとして利⽤し、各種の動作を決定する
67

– obc-peerは設定ファイル openchain.yamlを利⽤
• 同ファイルは、以下の設定項目を持つ (⼀部省略)
68
カテゴリ設定パラメータ名設定内容の概要
cli address • CLIコマンドとしての実⾏時に接続するgRPC通信先
rest enabled • REST APIの有効・無効化
address • REST APIの待ち受けアドレスとポート
logging peer, crypto, vm, chaincode, … • 各コンポーネント名に対するログ出⼒レベル設定
peer version • ピア間のバージョン確認用
id
• コンセンサス処理⽤のピアID。"vpX"の形式でなければならない。
• Xは0からの整数 (0,1,2,3,…)
privateKey • このピアの秘密鍵
networkId • 論理ネットワーク分離のためのID⽂字列(prodとかdevなど)
Dockerfile • Dockerコンテナの設定。同名ファイルの中身そのもの。
listenAddress • このピアのgRPC待ち受けアドレスとポート
gomaxprocs, workers • Go言語におけるGoroutineの設定
sync • 同期処理に関する設定
validator, consensus
• 検証ノード(VP)が非検証ノード(NVP)かを決定するパラメータ。
• consensusにはコンセンサスプラグイン名を指定(obcpbftなど)
tls • ピア間通信でTLSを使うかの設定とその証明書や秘密鍵ファイル

– (続き)
69
カテゴリ設定項目意味
peer pki
• メンバーシップサービスへの通信先アドレスやルート証明書ファイルへのパスなど
• ピアはCAへの通信先をここで得ている
discovery
• このピアが他のピアをどのように⾒つけるかに関する設定
• ルートノード(rootnode)のアドレスや、通信間隔(period)、発⾒した他Peer
の情報をDBに保持するか(persist)
• 最大ノード接続数(touchMaxNode)など
fileSystemPath • デフォルトは /var/openchain/production
vm endpoint
• VM(=チェーンコード用のDocker)を管理するための通信エンドポイント
• デフォルト値は「unix:///var/run/docker.sock」
docker
chaincode golang • チェーンコード実⾏⽤DockerコンテナのDockerfile内容
installpath • チェーンコードのインストールパス(デフォルト値は「/go/bin/」)
ledger blockchain • ブロックチェーンのジェネシスブロックに関する設定
state • ワールドステートの差分保持数やデータ保存形式(デフォルト「buckettree」)
security enabled • VP,NBP,クライアントがCAに登録されていることを前提にするか
enrollID, enrollSecret • このピア自体をCAに登録するときに⼀度だけ使われる
privacy • プライバシーモードを有効にするかどうか
tcert • トランザクション証明書の保持サイズなどの情報

OBCのチェーンコードにおいて、「アセット(資産)」の保持を実現する方法：
– ブロックチェーンソリューションでは、アセットを定義する方法として主に2つのアプローチがある
• ① ステートレスなUTXOモデル
アカウント残高は過去のトランザクション記録に封じ込められる
• ② アカウントモデル
アカウント残高は、台帳の状態(=ステート)として保存される
– どちらにも⻑短がある
• OBCは、どちらか一方に肩入れはしない⽴場
• OBCにおいては、両方のアプローチを実装できるようにする方針
(但し、サンプルは②のモデルがほとんど)
70

閑話休題：Bitcoin の UTXOモデル
補足：UTXO = Unspent Transaction Output (未使⽤出⼒)
– Bitcoinが採用しているトランザクションデータモデル
– 概略：
• 「最終 (現在の) 残高」が記録されているのではなく、消費された分と、⼊⾦された分のデータが
記録される
イメージ的には、「20ビットコイン(以上)のUTXOを持っていて、1ビットコインを支払いたい場合は、その「
20ビットコイン分の自分のBitcoinアドレスにロックされたUTXO」を消費(アンロック)して、2つの出⼒(新規
のUTXO)を作る。一つは、1ビットコインを宛先のユーザーへ、もう一つは、18.9ビットコインをお釣りとして
⾃分へ。残りは⼿数料。当初の20ビットコイン分のUTXOは消費され、誰も利⽤できなくなる(無効化)」
» トランザクションにより消費されたUTXOを、トランザクション⼊⼒と呼ぶ
» トランザクションにより作られた新たなUTXOを、トランザクション出⼒と⾶ぶ
» 現在の所有者の署名でアンロックすることで、トランザクションはUTXOを消費する
» 新しい所有者のビットコイン・アドレスに対してロックすることで、UTXOを作り出す
• あるユーザーの「現在残高」は、過去の全ての分散記録されているUTXOのデータから、そのユーザ
ーに(今も)所有され有効なUTXOデータをまとめることで計算する、というモデル
71
Bitcoinのトランザクションデータモデル
⼊⼒
UTXO : 20
出⼒ (to B)
UTXO:1
Aの署名(でロック解除)
出⼒ (to A)
UTXO:18.99
Aさん Bさん
AさんがBさんに1BTCを送⾦
A
B
• Bさんに1ビットコインを送⾦したい
• ⽀払いに⼗分⾜りる、例えば20ビッ
トコイン額のUTXOをもっている

OBCのチェーンコード実装言語
– 理論上は、チェーンコードはどんなプログラミング⾔語によってでも実装されうる
– しかし…
• 現時点でOBCがサポートするチェーンコード用開発言語は Go言語(Golang)のみ
• JavaScriptとJavaについては、2016年に対応が表明されている
但し、現在のOBCのインターフェース上は、Go言語とNode.js(JavaScript)の2つが明示的にあるだけ
ということは、先にNode.js(JavaScript)が対応される可能性が高い
– チェーンコードは、OBCサンドボックス(=Dockerコンテナ)内で実⾏される
• チェーンコードの実⾏はサンドボックスとしてのDockerコンテナ環境へ切り離される
• 仕様レベルでは「仮想マシン(VM)」というインターフェースが定義されている
実装としてDockerを利⽤
• Apache Velocityのようなテンプレート言語(DSL)を開発するという構想もある
チェーンコードへコンパイルするか、
チェーンコードコンテナへと埋め込まれるインタプリタで解釈されるようなもの
– ここで、チェーンコードのサンプル実装(Go言語プログラム)を⾒てみましょう
72

OBCのチェーンコード実装 (ソースコードを⾒て)
– OBCにおけるチェーンコードとは、「完全性のあるスタンドアロンGoプログラム」である
• “パッケージmainの、main関数”をエントリポイントとして動作する「普通のGoプログラム」
github.com/openblockchain/obc-peer/openchain/chaincode/shim パッケージをimport
» 現状では、何もしなければ、shimパッケージはDEBUGレベルでログ出⼒する
• main関数ではすぐにshim.Start(new(SimpleChaincode))して処理を委ねる
この結果、下記のどちらかが、実質的なチェーンコードとしてのエントリーポイントとして呼び出される
» Invokeトランザクション、デプロイトランザクションの場合は、
Run(stub *shim.ChaincodeStub, function string, args []string) ([]byte, error)
» Queryトランザクションの場合は、
Query(stub *shim.ChaincodeStub, function string, args []string) ([]byte, error)
第2引数に、"呼び出したい関数名"が渡されるので、チェーンコード内でif/switchで分岐して処理する
» 「関数名」とあるが、その名前のGo関数を本当に用意しなければならない訳では無い
(普通はそうするが)
※なぜInvokeとQueryと2種類のトランザクションがあるのか?
» Invokeはブロック⽣成・各ピアに配布されコンセンサスが実⾏される(ブロックチェーンのheightが増)
» Queryはブロック生成されることはない。よって、ブロックチェーンのheightは変わらない
• 第1引数(shim.ChaincodeStub型へのポインタ)にAPIが提供されており、ワールドステートへの
操作を⾏う(次ページ)73

OBCのチェーンコードAPI (チェーンコード内部で利⽤可能なAPI)
– 現在、チェーンコードにて利⽤可能なAPI
• これは初期時点であり、将来的に追加される
» 例：CreateTable(name string, columnDefinitions []*ColumnDefinition)
» 例：GetRows(tableName string, key []Column) (<-chan Row, error) など
• 例：トランザクションやブロックをクエリする、以前の状態をクエリする、など
• 利⽤時は、RunまたはQueryメソッドの引数として渡されるshim.ChaincodeStubへのポインタ
型を使う
– このAPIを呼び出すと、内部的には「ホストのobc-peerプロセス⇔Dockerコンテナで起動
するチェーンコード」間で、gRPC(&プロトコルバッファ形式)でメッセージ通信が発生する
74
# Chaincode API・引数戻り値の型説明
1 GetState(key string) ([]byte, error) • ワールドステートから指定キーの値を取得する
2
PutState(key string,
value []byte)
error
• ワールドステートに指定キーに値をセットする
3 DelState(key string) error • ワールドステートから指定キーの値を削除する
4
InvokeChaincode(chainco
deName string, function
string, args []string)
([]byte, error) • チェーンコード内から、他のチェーンコードIDを指定して、実⾏する
• そのチェーンコードのRunメソッドが呼び出しされる
5
QueryChaincode(chainco
deName string, function
string, args []string)
([]byte, error) • チェーンコード内から、他のチェーンコードIDを指定して、実⾏する
• そのチェーンコードのQueryメソッドが呼び出しされる

Open BlockchainにおけるREST API
OBC (obc-peer) が提供するREST API
– 現在利⽤可能なAPI
• これは初期時点であり、APIは将来的に追加されることが予告されている
例：トランザクションやブロックをクエリする、以前の状態をクエリする、など
75
カテゴリー REST API 説明
Block GET /chain/blocks/{BlockNum} • 指定したブロック番号(uint64数値)の情報を取得
Blockchain GET /chain • ブロックチェーン全体の現在の状態/情報を取得
Devops
POST /devops/deploy (deprecated)
(→ /chaincode)
• 新しいチェーンコードをチェーンにデプロイするデプロイメントトラ
ンザクション実⾏
POST /devops/invoke (deprecated)
(→ /chaincode)
• デプロイ済みチェーンコードを実⾏(Runメソッド)
POST /devops/query (deprecated)
(→ /chaincode)
• デプロイ済みチェーンコードを実⾏(Queryメソッド)
Network GET /network/peers
• エンドポイントのPeerがその時点でコネクションを維持している
他のピアノードの情報を取得する(検証ノード、非検証ノード
の両方を含む) (※試した限り、Bluemixでは利⽤不可)
Registrar
POST /registrar • 認証局(CA)にenrollIDとenrollSecretを元に登録
DELETE /registrar/{enrollmentID} • 登録済みのenrollIDを削除
GET /registrar/{enrollmentID} • 登録済みのenrollmentIDについての情報を取得
GET /registrar/{enrollmentID}/ecert • 指定enrollmentIdのEcert(E証明書)を取得
GET /registrar/{enrollmentID}/tcert • 指定enroolmentIdのTcert(Trx証明書)を取得
Transactions GET /transactions/{UUID} • 指定したトランザクションID(UUID)の情報を取得

OBCのチェーンコード実装
– チェーンコードのデプロイトランザクションを呼び出す手段
• obc-peerコマンド (deployサブコマンド)
• REST API (「/devops/deploy」へのPOST)
– チェーンコードのデプロイ時には、初期化用関数と引数も同時に指定する
• デプロイ処理の⼀環として呼び出される関数を指定
通常、関数名は "init" などとする
チェーンコードの実装上は、デプロイ時には(Invoke時と同様に) Runメソッドが呼ばれる
ワールドステートの更新処理 (初期値のセット)などを⾏うことができる
76

Open Blockchain IBM Client SDK
OBC が提供するクライアント向けSDK (Node.js用)
– Node.jsのnpmモジュール"ibm-blockchain-js"が提供・公開されている
• https://github.com/IBM-Blockchain/ibm-blockchain-js
• Webアプリ(Node.jsアプリ)が、OBC REST APIを利⽤して、obc-peerプロセスにアクセスする
ためのラッパーライブラリ
チェーンコードの呼び出し(=Invokeトランザクションの投入) 等をJavaScriptで記述できる
npmモジュールであり、ソースコードもGitHub上で公開されている
» このモジュール自体が、OBC REST APIをどう呼び出したら良いのか、という良いサンプルになる
• 注意点(モジュール仕様)
OBC RESTエンドポイント = 通信先の検証ノード(VP)、または非検証ピアノード(NVP) を指定する
» 1つのクライアントSDKインスタンス(ibc)がリクエストを送信する相手先(ピア)は、常に1つ
1つのクライアントSDKインスタンス(ibc)で利⽤できる「チェーンコード」は常に1つ(初期化時に設定)
» チェーンコードのデプロイ処理は、モジュールの内部で隠蔽される
(明⽰的にチェーンコードのデプロイ処理を⾏うAPIは提供されていない)
自前でGoソースコードをファイルで"SimpleChaincode"の⽂字列をGrepして関数名を得るなどやや
Ad-hocな処理をしている
77

OBC が提供するクライアント向けSDK (Node.js用)
– Node.jsのnpmモジュール"ibm-blockchain-js"が提供・公開されている
• Node.jsアプリからの使い方は、概ね以下の通り
npm コマンドでnpmリポジトリから取得(インストール。-gオプションでグローバルインストールしても良い)
» $ npm install ibm-blockchain-js
Node.jsプログラムで、ibm-blockchain-jsモジュールを読み込み & コンストラクタ関数としてnew
» var ibc_constructor = require('ibm-blockchain-js');
» var ibc = new ibc_constructor();
初期化用load関数を呼び出して初期化(引数にピアノードへのREST APIエンドポイント情報)をセット
» ibc.load(options, callback_ready);
コールバック関数に渡すことで得られるチェーンコード呼び出し用オブジェクトを使ってやり取り
• 注意点：
load関数を実⾏して初期化したibcオブジェクトは、結果的に1つのチェーンコードに束縛される
» そのチェーンコード内の処理(関数)を呼び分けすることはできるが、1つのibcオブジェクトで複数のチェー
ンコードを扱うことはできない
78

OBC が提供するクライアント向けSDK (Node.js用) (1/3)
– IBC関数(requireでロードしたモジュール=ibcオブジェクトが提供する関数)
79
種類 JavaScript API 説明
IBC関数
ibc.load(options, [callback])
• 典型的なOBCクライアントSDKスタートアップ処理の為のラッパー関数
• 以下を順番に呼び出す
• ibc.network()
• ibc.register() ※各ピアに対して(options.network.users
がセットされていた場合)
• ibc.load_chaincode()
• callback() 最後にコールバック
ibc.network(arrayPeers) • ピアノードへの接続情報の配列を指定する
ibc.register(peerIndex, enrollID,
enrollsecret, [callback])
• 指定したピアに、指定したエンロールIDとパスワード(シークレット)を登
録する
ibc.load_chaincode(options,
[callback])
• 使用したいチェーンコードを、ロードする(これは、OBCネットワークにデ
プロイメントトランザクションを投入することになる)
ibc.monitor_blockheight(callback)
• チェーンのheightが変化したら呼び出されるコールバックを登録する
• 内部的にはsetIntervalで10秒または0.5秒間隔をベースに調整
ibc.save(path [callback]) • チェーンコードのサマリー情報ファイルを、指定したパスに保存する
ibc.clear([callback])
• チェーンコードリポジトリからダウンロードしてローカルにDLしたチェーン
コードファイル、チェーンコードサマリー情報ファイルをクリア
ibc.chain_stats([callback])
• チェーンの状態を取得する。内部的には REST API 「/chain」を
GETしているのと同じ
ibc.block_stats(id, [callback])
• 指定したIDのブロック情報を得る。内部的にはREST API
「/chain/blocks/<id>」の呼び出し結果と同じ

– (続き)
80
IBC関数 ibc.switchPeer(peerIndex)
• デフォルトではSDKは peer[0] の情報を通信先として使うが、明示
的に指定した順番のPeerに通信をするように設定を変更する

– チェーンコード関数
• load または load_chaincode 関数のコールバックに対して渡されるオブジェクト(引数)
これは、ロード(デプロイ)したチェーンコードに対してInvoke/Queryする処理をラップした関数を提供する
81
チェーン
コード関
数
chaincode.read(name, [callback])
• チェーンコードのワールドステートに格納されているnameをキーとした値
を得る
• 内部的にはREST API「/devops/query」を呼び出す
• チェーンコードの引数としては、[name] が渡される
chaincode.query(args, [callback])
• カスタム⼊⼒引数でもってQuery関数を呼び出す
• 通常、args は⽂字列の配列である
• 内部的にはREST API「/devops/query」を呼び出す
chaincode.write(name, val,
[callback])
• チェーンコードのワールドステートにnameをキーとして、値valを書き込む
• 内部的にはREST API「/devops/invoke」を呼び出す
chaincode.remove(name,
[callback])
• チェーンコードのワールドステートのnameキーを削除
• 内部的にはREST API「/devops/invoke」を呼び出す
chaincode.deploy(func, args,
[save_path], [callback])
• チェーンコードをデプロイする
• Go言語チェーンコード内の、funcという名前が呼び出されることになる。
引数はargsとして渡される
• オプションとして、チェーンコードサマリー情報ファイルを指定したパスに書
き込むことができる
• 内部的には、REST API「/devops/deploy」を呼び出す
chaincode.CUSTOM_FUNCTION_N
AME(args, [callback])
• チェーンコードに指定したカスタム関数を呼び出す(チェーンコード側の引
数funcに、CUSTOM_FUNCTION_NAMEが渡される)
• 通常、args は⽂字列の配列である

Open BlockchainにおけるREST API
OBC (obc-peer) が提供するサーバープロセス兼 CLIコマンド obc-peer
– go言語で記述されたコマンド
• gRPCによって、指定されたPeerノードに対して処理を⾏う
– OBCピアサーバープロセスの起動コマンドでもある
• 起動すると、下記のエンドポイントで待ち受ける(listenする)
1. gRPC 待受アドレス：ピア間でデータ通信するための待受アドレスとポート
2. REST APIエンドポイント : gRPCとは別の、バックエンドアプリケーション向けのAPIを提供
» (※設定ファイルの指定により、RESTエンドポイントは提供されないように構成されることもある)
デフォルトでは 80や443ではない
これらポート設定等は、obc-peerプロセスの設定ファイルである openchain.yaml に記述される
82
# サーバー状態説明
1 UNDEFINED • 未定義
2 STARTED • 始動済み
3 STOPPED • 停止済み
4 PAUSED • 一時停止済み
５ ERROR • エラー
6 UNKNOWN • 不明

ここまでで分かったことを元に整理 (チェーンコードにフォーカス)
検証ピア
ノード
(obc-
peer)
Dockerコンテナ
アプリケーションバックエンドノード
台帳(Ledger)
ブロックのリスト
ここまでで分かったこと
83
ブロックチェーン
開発者
アプリケーション
(例:Webアプリ)
チェーンコードA
(Validating Peer
にデプロイされる
Go言語プログラム)
実⾏(invoke)またはクエリ(query)
=チェーンコード呼出トランザクションを
ブロックチェーンに追加
開発
ワールドステート
ブロック
ブロックブロック
key=valueデータを値取得・セット
チェーンコードの実⾏(invoke)情報が
「1つのトランザクション」として記録される
設定ファイル
(openchain.yaml
& config.yaml)
開発
共有ソースコードリポジトリ
(GitHub.comなど)
チェーンコードA
(Validating Peer
にデプロイされる
Go言語プログラム)
デプロイメントトランザクションにより、
VP(リーダー)から指示されて
各検証ノードが取得し、デプロイされる
REST
エンドポイント
検証ピア
ノード
(obc-
peer)
イベントの送受信
(gRPC)
gRPC
ListenPort
gRPC
ListenPort
Dockerコンテナとのチェーンコードメッセージ
送受信(gRPC)
JS ClientSDK
HTTPS (REST)
トランザクショントランザクション
チェーンコードB
：

84
IBM Bluemix Blockchainサービス

以下は、2016/03/19時点のBlockchainサービス
– 内容としては、デモ用ツール、Sandbox
• experimental(試験的)なサービス
• 事実上、「Marbles Demo」アプリを動作させるためのデモ環境
85

InterConnect2016発表での「Blockchainサービス」を自分のBluemixスペース
上に「作成」すると、一体何が起きるか?
– Bluemix(CloudFoundry)内の「Blockchainサービス領域」に以下が1セット追加
• ① 2つの検証ピアノード(VPプロセス×2)
• ② 1つのCA(Certificate Authority)ノード(プロセス) ：つまりメンバーシップサービス
• ③ 10人分のユーザー(user_type<0〜4>_<ランダム⽂字列>)とそのパスワード(secret)
つまり、自分だけの箱庭的な世界に、OBCインフラとしての最小構成が作られる
– Bluemixダッシュボードの同サービスインスタンス画⾯に管理⽤ダッシュボード画⾯が追加
– どんな設定で動いているのかは不明 (コンセンサスアルゴリズム設定など)
Bluemix Blockchainサービスインスタンス
86
検証ピアノード#1(VP1)
obc-peerプロセス
検証ピアノード#2(VP2)
obc-peerプロセス
認証局(CA)
obcca-serverプロセス
Blockchain
ログコンソール
10人分のユーザー
(secret生成済)

このサンドボックス環境を使う「Marbles App」デモアプリ
– http://www.ibm.com/blockchain/for_developers.html
• OBCの挙動を理解する上で非常に参考になる
– このアプリを自スペースにデプロイする
• Blockchainサービスまで自動的にインスタンス化してくれる仕組みも用意されている
(下記の「Deploy to Bluemix」リンク)
• Bluemix IDを持ち自org & spaceがあれば、デプロイまでは容易
87
これ
ここ

「Marbles App」デモアプリの中身解説
– クライアントSDKを使ったNode.jsアプリがCloudFoundryアプリとしてデプロイされる
• 「ビー玉(おはじき、Marble)」が個人の「アセット(資産)」であるという位置づけ
– デモアプリが実現していること
• 初期設定：OBC JSクライアントSDKを利⽤したクライアントアプリのセットアップ
• シナリオ① ：ビー玉の属性(サイズ、色)を設定して、台帳に新規保存・削除する
内部的には、トランザクションによって起動されるチェーンコードがワールドステートにPUT or DELETE
• シナリオ② ：2人のユーザー(BobとLeroy)で、ビー玉を単純に転送、あるいは「交換」する
条件に基づくアセットの転送を、チェーンコードで実現
– 注意：
• WebSocket通信を使用。N/W環境やPC環境によってはアプリが正常に動作しないことも
Bluemix 自分のスペース
88
Node.js アプリ(express FW)
(CFアプリケーション)
ユーザー
OBC JS
Client
SDK
app.js
#1検証ピアノード #1 検証ピアノード#2
認証局(CA)
台帳台帳トランザクション
実⾏要求
(REST通信)
チェーン
コード
REST
エンドポイント
WebSocket通信
• Node.jsアプリの起動時、クライアントSDKを初期化
• RESTエンドポイントを指定し、チェーンコードをデプロイトラ
ンザクションを(必要なら)実⾏
Blockchain
ログコンソール
Blockchain
サービスインスタンス
バインド

「Marbles App」デモアプリの中身解説
– デモアプリ
• Node.jsアプリとしての起動時、クライアントSDK(ibm-blockchain-jsモジュール)をロード
var ibc1 = require('ibm-blockchain-js');
• VCAP_SERVICES環境変数値(JSONテキスト)を参照
サービス名が"ibm-blockchain"で始まっているキーに対応する値⽂字列(複数あろうが最初の1つのみ)
を元に、OBC RESTエンドポイントURLを取得
• 上記で得た情報を元に、クライアントSDKを初期化
var ibc = new Ibc();
var options = { 各種ネットワーク設定、利⽤するチェーンコード情報(ZIP場所,GitHubURLなど) };
ibc.load(options, cb_ready); //初期化処理の開始ポイントとなるloadメソッドを呼び出し
• これによって、さらにSDK内部で以下が処理される
通信先のピアとして、ピアノード情報配列の先頭(0番目=VP1)を利⽤するように内部的にセット
チェーンコードがまだ1つもデプロイされていなかったら、デプロイトランザクションをVP1に実⾏要求
指定されたURL(GitHub)からZIPファイルをDLし、解凍(Node.jsの"admzip"モジュールを利⽤)
» https://github.com/ibm-blockchain/marbles-chaincode/archive/master.zip
» 指定された一時ディレクトリ(./tmp/unzip/)に、ZIPファイル内容を解凍
» ソースコード(.goファイル)の中⾝を⽂字列検索し、関数名を得る
ラッパーとしてのchaincodeオブジェクトを生成する
REST APIを呼び出し、コールバック関数 cb_readyを呼び出す(成功時、chaincodeを渡す)
89

Open blockchain in a nutshell

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (18)

Similaire à Open blockchain in a nutshell

Similaire à Open blockchain in a nutshell (20)

Open blockchain in a nutshell