open blockchain in a nutshell

Open Blockchain in a nutshell ( Open Blockchain 概要 )

Created Date : 2016/03/19Created By : Takeshi Matsubara

disclaimer

2

本資料の記載内容は、著者が個⼈的に調べた内容であり、正式なIBM, 日本IBMのテストやレビューを受けておりません。内容についてはできる限り正確を期するよう努⼒しましたが、「現状のまま」提供され、明⽰または暗⽰にかかわらずいかなる保証、責任を負いかねます。

本資料の情報は、使⽤先の責任において使⽤されるべきものであることを予めご了承下さい。

(本資料またはその他の資料の使⽤によって、あるいはその他の関連によって、いかなる損害が⽣じた場合も、著者は責任を負わないものとします)

また、本資料に記載内容で⽰された意⾒、感想は全て著者個⼈のものであり、所属する組織を代表するものではありません。

目次

� はじめに

� Open Blockchainの概要(1)

� Open Blockchainの概要(2)

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

� IBM Bluemix の Blockchainサービス

� Open Blockchainにおけるチェーンコード開発とデプロイ

� まとめ

3

4

はじめに

想定読者

� 以下のいずれかまたは全てに合致する方

– “ブロックチェーン”という⾔葉は良く聞くが、概念ばかりで、システムとして中⾝が分からない• 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の概要(1)

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の概要(2)

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社ノード群


C社ノード群


イベントベースでのメッセージデータ送受信

イベントベースでのメッセージデータ送受信

閑話休題：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)

� OBCの「ブロックチェーン」


50

{

"height":6,"currentBlockHash":"zyHqhxj+1nbOaRerTPbYOmuet+HV5kZrLkrrm/bdEj/aunH1d083LLW1UwFNKwEVqyl/iGynvh6l89YbxfuCUw==","previousBlockHash":"ERJgDxMaKMoobV8uRySDB2uWHpUkRWE4IS66PAvrxGqw8xepq3SJmC1F7e9z+ptdFspo/rzlBpTmsLK9dYWvAw=="

}

OBCブロックチェーン情報データ例(例：REST API「/chain」への GETリクエスト結果のJSONデータ)

uint64の上限値は 2^64。(事実上、heightの桁あふれは気にしないで良い)

� OBCの「ブロックチェーン」

– 1つのブロックチェーンネットワーク(=ピア群から構成されるネットワーク)は、ただ1つのブロックチェーンを共有している

• 1つのピアプロセスが複数(2つ以上)のブロックチェーンを共有する、ということはない� 例えるなら、“複数のノードが、RDBMSの1個のテーブルだけを共有する”ようなイメージ

• もう1個別の台帳が必要 → もう1個別のブロックチェーンが必要 → もう1セット、ピア群が必要


51

Open Blockchainにおけるブロック

� OBCの「ブロック」– OBCにおけるブロックは、ブロックチェーンでいう「ブロック」そのもの

• チェーンにおける(自分からみて)「その1つの前の」ブロックのハッシュ値を含んでいる各ブロックの一連のリンクリスト構造のデータとして定義されている� ある1つのブロックは、複数の「トランザクション」と、そのブロックの全てのトランザクションを実⾏した後の「ワー

ルドステートのハッシュ」をその1つのブロックの内部に保持

52

ブロック内に含んでいるトランザクションの情報

(仕様上は複数格納可能)

ブロック情報

トランザクション情報

1つ前のブロックのハッシュ情報

非ハッシュデータ(ハッシュ計算対象外)

ワールドステートの最終状態ハッシュ

“ブロックチェーン”の名前の由来

Bitcoinのブロックデータのようなアプリ固有仕様の属性は含まれていない

プロトコル仕様のバージョン番号

タイムスタンプ

トランザクションデータ群に対するハッシュ

コンセンサス用メタデータ

トランザクション結果トランザクションの

UUID、実⾏結果戻り

値、エラーコード、エラー⽂字列

ローカル台帳コミット時タイムスタンプ


� OBCの「ブロック」とそのチェーン構造

53

Genesisblock

block1

block2

block3

blockn

トランザクション

ハッシュ値ハッシュ値

トランザクショントランザクション

ハッシュ値ハッシュ値ハッシュ値

ブロックチェーンの説明でよく⾒かける図「ブロックチェーンは、「ハッシュ値」で過去のトランザクションの情報を保護し、改竄できないようにしている」

ハッシュ値


� OBCのブロック (1個のブロックデータを取得した時のJSONデータ表現)–自分の1つ前のブロックへのハッシュ値を持っている & ステートハッシュを持っている

54

{"transactions": [

{"type": 1,"chaincodeID":

"CjlodHRwczovL2dpdGh1Yi5jb20vaWJtLWJsb2NrY2hhaW4vbWFyYmxlcy1jaGFpbmNvZGUvcGFydDISgAE4ZmU3YjNkOWEzZDQzYzViNmI5MWQ2NWIwNTg1MzY2ZmEzZDU2MGQ1MzYyZTExZjBlZWExMWZmNjE0YTI5NmZkZWM4NjA3YjE3ZGU0MjljOTE5OTc1ZDUzODY5NTNlNGRhYzQ4NmEwOWNlNmM5NjVmNTg0NGQ3ZDE4MzgyNWVmYg==",

"payload": "Cs8BCAESvgEKOWh0dHBzOi8vZ2l0aHViLmNvbS9pYm0tYmxvY2tjaGFpbi9tYXJibGVzLWNoYWluY29kZS9wYXJ0MhKAAThmZTdiM2Q5YTNkNDNjNWI2YjkxZDY1YjA1ODUzNjZmYTNkNTYwZDUzNjJlMTFmMGVlYTExZmY2MTRhMjk2ZmRlYzg2MDdiMTdkZTQyOWM5MTk5NzVkNTM4Njk1M2U0ZGFjNDg2YTA5Y2U2Yzk2NWY1ODQ0ZDdkMTgzODI1ZWZiGgoKBGluaXQSAjk5",

"uuid": "8fe7b3d9a3d43c5b6b91d65b0585366fa3d560d5362e11f0eea11ff614a296fdec8607b17de429c919975d5386953e4dac486a09ce6c965f5844d7d183825efb",

"timestamp": {"seconds": 1457158085,"nanos": 678795931

},"cert":

"MIICDzCCAZWgAwIBAgIBATAKBggqhkjOPQQDAzApMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMQwwCgYDVQQDEwN0Y2EwHhcNMTYwMzA1MDYwNjQ2WhcNMTYwNjAzMDYwNjQ2WjA7MQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMR4wHAYDVQQDDBV1c2VyX3R5cGUxXzQwMDM0NWI4YTAwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAARe1jrgbvituggektmbgypZdDkZhcvSB0wbRw+6Rj3UH4xvdg47947pqrR9pBxn8uo2VZIiSvhcMdIina2GE5H5+tsOusLyCZ5S2TJLHoVveb+oA2q/gmZTLUaorkXlOACjfzB9MA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMA0GA1UdDgQGBAQBAgMEMA8GA1UdIwQIMAaABAECAwQwPQYGKgMEBQYHAQH/BDCb4leuD60A7bXV19zXYA4/b1f2NFOn+KdQP23Po/Sm42WYid1cKcjFUTntMs2CzBUwCgYIKoZIzj0EAwMDaAAwZQIxANplH0Dwtmp/oHk3sPVEe62AccVOl2+iHZF5cc4COB9MyNKfQfflhnOVwrZ3b5CrKwIwaez/9YnSSuNWzQkMWI6QxPhugFcPvPGc8HGZ/dYu7zUfW6msVGoVNn29JZXmLDnf",

"signature": "MGUCMBxFWcjZ/smGFV2uzRa5uDzEmE462Uv296QD9S2b4urnfstjbZIVlVe92n1bWjAGowIxAMTpDs2IYqOFirhFdhDTAAP7UM6V+qxWS1F9QwFHuUqJD5SM1Y9jWTfQROUMUvzXIg=="

}],"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


� OBCのチェーンコード

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. 引数(⽂字列配列)

� OBCのチェーンコード– チェーンネットワークとチェーンコードの論理的な関係を図⽰すると、以下のようになる

• 注意：下図の「処理(関数)」は論理的なものであり、Go⾔語プログラム上の実際の物理的な関数(func)に必ずしも直接紐付けられるわけではない


60

チェーンネットワーク

チェーンコード1

…

…チェーンコード2 チェーンコードn

初期化⽤処理(関数)

更新あり処理1(関数)

:

更新あり処理n(関数)

参照のみ処理1(関数)

:

参照のみ処理n(関数)



:



:




:



:


1つのチェーンネットワークには、複数のチェーンコードをデプロイできる

チェーントランザクター

チェーンコード内には、大別して「初期化用処理」、「更新あり処理」、「参照のみ処理」

の関数を複数個用意できる

チェーンコードの呼び出しトランザクション実⾏時には、

1.どのチェーンコードの(チェーンコードID)2.どの更新あり処理なのか(関数名を1つ)or どの参照⽤処理なのか(関数名を1つ)

の2つの情報と、「関数への引数」を指定して実⾏する

(複数のチェーンコードや関数を1回で呼出すことは不可)

デプロイトランザクション実⾏時には、デプロイの⼀環として合わ

せて実⾏する初期化⽤処理も指定する(関数名と引数を指定)


� OBCのチェーンコード– 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) errorstart(ctxt context.Context, id string, args []string, env []string, attachstdin bool, attachstdout bool) errorstop(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 •未使用


� OBCのpeer間メッセージ (2/4)

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」となる


� OBCのpeer間メッセージ (3/4)– 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•あるピアがローカルでブロックを更新/コミット後に、ブロックが追加されたことを他ピアに通知するためにブロードキャストするタイプ

13SYNC_STATE_GET_SNAPSHOT •現在のワールドステートのスナップショットを要求するメッセージタイプ

SYNC_STATE_SNAPSHOT• SYNC_STATE_GET_SNAPSHOTへの応答メッセージであることを示すタイプ14

15 SYNC_STATE_GET_DELTAS •一連のブロックの範囲の差を要求する

16 SYNC_STATE_DELTAS•GET_DELTASへの応答メッセージであることを示すタイプ•ワールドステートの差分を返す


� OBCのpeer間メッセージ (4/4)– 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 の実体 = obc-peerプロセス– 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を使うかの設定とその証明書や秘密鍵ファイル


� OBCのpeer の実体 = obc-peerプロセス– (続き)

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.99Aさん 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) •ワールドステートから指定キーの値を取得する

2PutState(key string, value []byte)

error •ワールドステートに指定キーに値をセットする

3 DelState(key string) error •ワールドステートから指定キーの値を削除する

4InvokeChaincode(chaincodeName string, function string, args []string)

([]byte, error) •チェーンコード内から、他のチェーンコードIDを指定して、実⾏する•そのチェーンコードのRunメソッドが呼び出しされる

5QueryChaincode(chaincodeName 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>」の呼び出し結果と同じ


� OBC が提供するクライアント向けSDK (Node.js用) (2/3)– (続き)

80


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


� OBC が提供するクライアント向けSDK (Node.js用) (3/3)– チェーンコード関数

• 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_NAME(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)

gRPCListenPort

gRPCListenPort

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 JSClientSDK

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


� 「Marbles App」デモアプリ– https://github.com/IBM-Blockchain/marbles

• ビー玉を作成し、ドラッグアンドドロップでBob⇔Leroy間で「アセットの転送」を表現� http://xxxx.mybluemix.net/p1/home

90


� 「Marbles App」デモアプリ– ビー玉作成画面

• 内部的に、JS SDK の ibc.writeが実⾏され、Node.jsアプリからOBCにREST呼び出しが発生• REST 呼び出しを受け付けたVP1ノードが、Invocationトランザクションをチェーンネットワークに

発生させる

91


� 「Marbles App」デモアプリ–交換(トレード)画面

• 交換条件(個数、色、サイズ)を⼊⼒しトレードを作成する� 条件に合致しているビー玉が双方にあると、交換される

» スマートコントラクト的、“資産”の移動

92


� 「Marbles App」デモアプリの中身解説– ワールドステートに、以下のデータ構造で保持することで、「ビー玉資産台帳」を表現

• 固定key 「”_marbleindex"」の値として、⽂字列配列(のUTF-8テキストのバイト配列表現)� その要素値自体が、ワールドステートのキーになっている

� そのキーの値として、ビー玉のデータが入っている• ※重要：

� 「このデータ構造自体は、OBCは何らの規定もしていない、アプリ任せであるということ」を想起してみよう

93

{"_marbleindex" : ["<ビー玉のインデックス値1>", "<ビー玉のインデックス値2>", …],

"_opentrades" : {"open_trades" : [

:]

} ,"<ビー玉のインデックス値1>” : {

"name" : "<keyと同じ値(ビー玉のインデックス値)>","color" : "<ビー玉の色(blueなど)>","size" : "<サイズ(large or small)>","user" : "<所有者の名前(Bob or Leroy)>"

},:

}

Marbles Appデモアプリのワールドステート構造ワールドステート


� Blockchainサービスが提供するログコンソール(1/3)– https://broker-prod.blockchain.ibm.com/blockchain

• URLを⾒る限り、コンソールのUI部分はBluemix全体で共有されている–挙動はいささか不安定

• 上手く情報がVP/CAから得られていないような動作をすることがある

94

2つのVPと1つのCAがあること、その状態が分かる

チェーンにデプロイ済みのチェーンコードのID

ホスト(インターネットからアクセス可能なIPアドレス) gRPC通信の待受ポート番号

REST エンドポイントのポート番号


� Blockchainサービスが提供するログコンソール(2/3)

95

VPがダウンしているようにみえる?ことも頻繁に発生

このIDはあくまでBluemixのBlockchainサービスインスタンスのIDであり、OBC実装上に関わるものではない


� Blockchainサービスが提供するログコンソール(3/3)

96

97

Open Blockchainにおけるチェーンコード開発とデプロイ


� OBC チェーンコードの開発環境– 今日の仮想化ツールをフル活用

• ローカルPCに以下をインストールして開発。仮想マシン内でコンパイル� Gitクライアント (チェーンコード配置場所としてGit / Githubが想定されている)

� Go 1.6以降

� Vagrant 1.7.4以降 & Oracle VirtualBox 5.0以降 & 仮想マシン(Ubuntu trusty) にDocker

» 仮想マシン(Box)イメージはVirtualBoxイメージリポジトリの「obc/dev-env」を利⽤する

98


� 開発環境(obc-peerコマンドを実⾏するためにも必要)– obc-peerプロセス起動時に開発モード起動オプション(--peer-chaincodedev)を指定

• ※注意：� obc-peerコマンドは、gRPCによりobc-peerプロセスと通信する(RESTではない)

– 開発したチェーンコードをテストしたら、Github(ソースコードリポジトリ)にコミット

99

ローカルPC ホストOS (Windows/Mac)

Vagrant ツール

チェーンコード開発者

実⾏

VirtualBox (仮想マシン)

(obc-peerプロセスを起動)SSHターミナル1(obc-peerプロセスを起動)

(チェーンコードプロセスを起動)SSHターミナル2(チェーンコードプロセスを起動)

(obc-peer invokeでチェーンコード起動)SSHターミナル3(obc-peer invokeでチェーンコード起動)

Linux (Ubuntu Trusty) [obc/dev-env]

obc-peer peerプロセス(チェーンコード開発モードで動作)

設定ファイル(Vagrantfile)

& プロセスチェーンコードバイナリ

& プロセス

3000/tcp 5000/tcp

ホスト側：$GOPATH/src ⇔ VM側：/opt/gopath/src

起動(vagrant up)とプロビジョニング

ホスト側：$WORKSPACE ⇔ VM側：/openchain

Webブラウザ

VirtualBoxの機能でホストOSと仮想OSとでディレクトリ共有

ソースコードエディタホスト側で$GOPATH/src以下にチェーンコード(.go)をコーディング

VM側で go buildを実⾏して、チェーンコード(.go)をコンパイル

vagrant sshでログイン GoランタイムDockerエンジン

RocksDB

obc-peerコマンド


� チェーンコードの開発とBluemix Blockchainサービス環境へのデプロイ– 開発したチェーンコードをIBM Bluemix Blockchainサービス環境に追加(デプロイ)

• 先⽴ってCAに登録されているユーザーID(enrollId)とシークレット(enrollSecret)を添えて、VPのREST API「/registrar」にPOSTし、そのVPがそのユーザーIDでECertを持つ状態にする� つまり、ログインする

100

Bluemix Blockchainサービスの、VP1のRESTエンドポイントを指定してPOST

REST API仕様で定められたデータ形式で、POST(CA上のenrollIdとenrollSecretを指定)

ログイン成功として応答JSONメッセージが帰ってくる

画⾯例はFirefoxのHttpRequesterプラグインを利⽤。(RESTクライアントなら何でも良い)


� チェーンコードの開発とBluemix Blockchainサービス環境へのデプロイ–次に、実際に開発したチェーンコードを追加(デプロイ)

• この例では、OBCがGithub上にサンプル公開しているチェーンコード(chaincode_example02)をそのまま利⽤

• ログイン済みのユーザーID(=enrollId)を指定しつつ、REST API「/devops/deploy」にPOST� デプロイ時にも、初期化関数名(下記例ではinit)と、その関数への引数を指定する

101

Bluemix Blockchainサービスの、VP1のRESTエンドポイントを指定してPOST

REST API仕様で定められたデータ形式で、POST(チェーンコードの配置場所(path)、初期化関数名、引数配列、ユーザーID(secureContext)を指定)※path指定のURL形式にはプロトコルなどは含めない

デプロイに成功すると、IBM Blockchainサービス側で一意なチェーンコードID(チェーンコードパスなどから生成されたハッシュ)が採番され、応答JSONメッセージの中のmessage値として返される


�デプロイしたチェーンコードの実⾏と動作確認– Blockchainログコンソールから、VP1のチェーンコード実⾏ログを⾒てみる

• デプロイと同時に初期化関数が実⾏されるので、ログが出⼒されていることが分かる

102

ERR - 2016/03/30 08:20:02 Peer address: x.x.x.x:38038ERR - 2016/03/30 08:20:02 os.Args returns: [/go/bin/ec1c8c62a9bc689d1903a4c51220d0b285b3027cc6b9b48f8428f23423a640fd3818df25eb3d17934f4f967ce9d407609271e08e13c4a618eb15de478b394339 -peer.address=169.44.38.100:38038]ERR - 2016/03/30 08:20:02 Registering.. sending REGISTERERR - 2016/03/30 08:20:02 []Received message REGISTERED from shimERR - 2016/03/30 08:20:02 []Handling ChaincodeMessage of type: REGISTERED(state:created)ERR - 2016/03/30 08:20:02 Received REGISTERED, ready for invocationsERR - 2016/03/30 08:20:02 [ec1c8c62]Received message INIT from shimERR - 2016/03/30 08:20:02 [ec1c8c62]Handling ChaincodeMessage of type: INIT(state:established)ERR - 2016/03/30 08:20:02 Entered state initERR - 2016/03/30 08:20:02 [ec1c8c62]Received INIT, initializing chaincodeERR - 2016/03/30 08:20:02 [ec1c8c62]Inside putstate, isTransaction = trueERR - 2016/03/30 08:20:02 [ec1c8c62]Sending PUT_STATEOUT - Aval = 100, Bval = 200：(中略)ERR - 2016/03/30 08:20:02 [ec1c8c62]before sendERR - 2016/03/30 08:20:02 [ec1c8c62]after sendERR - 2016/03/30 08:20:02 [ec1c8c62]Received RESPONSE, communicated (state:init)ERR - 2016/03/30 08:20:02 [ec1c8c62]Received RESPONSE. Successfully updated stateERR - 2016/03/30 08:20:02 [ec1c8c62]Init succeeded. Sending COMPLETEDERR - 2016/03/30 08:20:02 [ec1c8c62]Move state message COMPLETEDERR - 2016/03/30 08:20:02 [ec1c8c62]Handling ChaincodeMessage of type: COMPLETED(state:init)ERR - 2016/03/30 08:20:02 [ec1c8c62]send state message COMPLETED


�デプロイしたチェーンコードの実⾏と動作確認– Blockchainログコンソールから、VP2のチェーンコード実⾏ログを⾒てみる

• VP1に1秒遅れて、チェーンコードがデプロイ(&初期化関数の実⾏)されていることが分かる

103

ERR - 2016/03/30 08:20:03 Peer address: x.x.x.x:39521ERR - 2016/03/30 08:20:03 os.Args returns: [/go/bin/ec1c8c62a9bc689d1903a4c51220d0b285b3027cc6b9b48f8428f23423a640fd3818df25eb3d17934f4f967ce9d407609271e08e13c4a618eb15de478b394339 -peer.address=169.44.63.212:39521]ERR - 2016/03/30 08:20:03 Registering.. sending REGISTERERR - 2016/03/30 08:20:03 []Received message REGISTERED from shimERR - 2016/03/30 08:20:03 []Handling ChaincodeMessage of type: REGISTERED(state:created)ERR - 2016/03/30 08:20:03 Received REGISTERED, ready for invocationsERR - 2016/03/30 08:20:03 [ec1c8c62]Received message INIT from shimERR - 2016/03/30 08:20:03 [ec1c8c62]Handling ChaincodeMessage of type: INIT(state:established)ERR - 2016/03/30 08:20:03 Entered state initERR - 2016/03/30 08:20:03 [ec1c8c62]Received INIT, initializing chaincodeOUT - Aval = 100, Bval = 200ERR - 2016/03/30 08:20:03 [ec1c8c62]Inside putstate, isTransaction = trueERR - 2016/03/30 08:20:03 [ec1c8c62]Sending PUT_STATEERR - 2016/03/30 08:20:03 [ec1c8c62]Received message RESPONSE from shimERR - 2016/03/30 08:20:03 [ec1c8c62]Handling ChaincodeMessage of type: RESPONSE(state:init)ERR - 2016/03/30 08:20:03 [ec1c8c62]before send: (中略)ERR - 2016/03/30 08:20:03 [ec1c8c62]Handling ChaincodeMessage of type: RESPONSE(state:init)ERR - 2016/03/30 08:20:03 [ec1c8c62]before sendERR - 2016/03/30 08:20:03 [ec1c8c62]after sendERR - 2016/03/30 08:20:03 [ec1c8c62]Received RESPONSE, communicated (state:init)ERR - 2016/03/30 08:20:03 [ec1c8c62]Received RESPONSE. Successfully updated stateERR - 2016/03/30 08:20:03 [ec1c8c62]Init succeeded. Sending COMPLETEDERR - 2016/03/30 08:20:03 [ec1c8c62]Move state message COMPLETEDERR - 2016/03/30 08:20:03 [ec1c8c62]Handling ChaincodeMessage of type: COMPLETED(state:init)ERR - 2016/03/30 08:20:03 [ec1c8c62]send state message COMPLETED


�デプロイしたチェーンコードの実⾏と動作確認– IBM Bluemix Blockchainログコンソールに、デプロイしたチェーンコードが表示され、チェーンネットワークで認識されていることが分かる• 「VP1に対してしか実⾏要求していないのに、VP1,VP2の両⽅にチェーンコードが配置され実⾏さ

れた」� 台帳(Ledger)=トランザクションリストが伝播した

� チェーンコードのデプロイも、デプロイトランザクションとしてチェーンネットワークに対するトランザクションである

� VP1、VP2が能動的に、指定されたパスのGo言語ソースコードを取得して、コンパイル & 実⾏している

104

Upということは、正常にデプロイトランザクションが成功し、デプロイ処理としてチェーンコード

(Go)が実⾏されたということ

Marble Appデモアプリによってデプロイされたチェーンコードの情報

チェーンコードIDが採番された結果、増えた(2⾏表⽰されている)

�デプロイしたチェーンコードの実⾏と動作確認– チェーンコード実⾏前にチェーン状態をクエリしてみる

• REST API「/chain」に対してGET要求� 現在のheight値が得られる


105

この時点では、heightは 16 である

�デプロイしたチェーンコードの実⾏と動作確認– デプロイされたチェーンコードを実⾏する

• REST API「/devops/invoke」を呼び出す� UUIDを指定し、実⾏したいチェーンコードを指定する


106

Bluemix Blockchainサービスの、VP1のRESTエンドポイントを指定 (チェーンコード実⾏要求)

REST API仕様で定められたデータ形式で、チェーンコード呼び出し要求データをPOST(チェーンコードID、実⾏関数、引数、ユーザーID(enrollId)などを指定)

チェーンコードの実⾏に成功したことを⽰す応答JSONメッセージが返される。Invokeトランザクションに対して採番されたUUIDが、messageの値として返されている。この例では、「99051601-8b3b-4a6a-9c3b-ee07740f1891」

�デプロイしたチェーンコードの実⾏と動作確認– チェーンコード実⾏後にチェーン状態をクエリしてみる

• REST API「/chain」に対してGET要求� heightが +1 されている


107

heightは 17 になった(と同時に、currentBlockHashの値が新しいものに、previousBlockHashが以前のcurrentBlockHashの値になっていることも分かる)

�デプロイしたチェーンコードの実⾏と動作確認– トランザクションUUIDを元に、クエリしてみる

• REST API「/transactions/{UUID}」に対してGET要求


108

Bluemix Blockchainサービスの、VP1のRESTエンドポイントを指定(トランザクションUUIDを指定)してGET

指定したトランザクションの情報が返される：• type : トランザクションの種類(3 は CHAINCODE_EXECUTE を意味)• chaincodeID : チェーンコードのID⽂字列• payload：呼び出しペイロード• uuid：このトランザクションに対して採番されたUUID• timestamp：このトランザクションが発生した(コミットされた?)時点のタイムスタンプ• cert：証明書

�デプロイしたチェーンコードの実⾏と動作確認–再び、Blockchainログコンソールからチェーンコードの実⾏ログを表⽰してみる


109

ERR - 2016/03/30 09:16:19 [99051601]Received message TRANSACTION from shimERR - 2016/03/30 09:16:19 [99051601]Handling ChaincodeMessage of type: TRANSACTION(state:ready)ERR - 2016/03/30 09:16:19 [99051601]Received TRANSACTION, invoking transaction on chaincode(Src:ready, Dst:transaction)：中略

ERR - 2016/03/30 09:16:19 [99051601]Received RESPONSE, communicated (state:transaction)ERR - 2016/03/30 09:16:19 [99051601]GetState received payload RESPONSEERR - 2016/03/30 09:16:19 [99051601]Sending GET_STATEERR - 2016/03/30 09:16:19 [99051601]Received message RESPONSE from shimERR - 2016/03/30 09:16:19 [99051601]Handling ChaincodeMessage of type: RESPONSE(state:transaction)ERR - 2016/03/30 09:16:19 [99051601]before sendERR - 2016/03/30 09:16:19 [99051601]after sendERR - 2016/03/30 09:16:19 [99051601]Received RESPONSE, communicated (state:transaction)ERR - 2016/03/30 09:16:19 [99051601]GetState received payload RESPONSEERR - 2016/03/30 09:16:19 [99051601]Inside putstate, isTransaction = trueERR - 2016/03/30 09:16:19 [99051601]Sending PUT_STATEOUT - Aval = 90, Bval = 210ERR - 2016/03/30 09:16:19 [99051601]Received message RESPONSE from shimERR - 2016/03/30 09:16:19 [99051601]Handling ChaincodeMessage of type: RESPONSE(state:transaction)ERR - 2016/03/30 09:16:19 [99051601]before sendERR - 2016/03/30 09:16:19 [99051601]after sendERR - 2016/03/30 09:16:19 [99051601]Received RESPONSE, communicated (state:transaction)ERR - 2016/03/30 09:16:19 [99051601]Received RESPONSE. Successfully updated stateERR - 2016/03/30 09:16:19 [99051601]Received RESPONSE, communicated (state:transaction)ERR - 2016/03/30 09:16:19 [99051601]Received RESPONSE. Successfully updated stateERR - 2016/03/30 09:16:19 [99051601]Transaction completed. Sending COMPLETEDERR - 2016/03/30 09:16:19 [99051601]Move state message COMPLETEDERR - 2016/03/30 09:16:19 [99051601]Handling ChaincodeMessage of type: COMPLETED(state:transaction)ERR - 2016/03/30 09:16:19 [99051601]send state message COMPLETED

チェーンコードのロジックの中で、ワールドステートの更新後の値内容がデバッグログ的に出⼒

されている (fmt.Printlnメソッド)

�デプロイしたチェーンコードの実⾏と動作確認– ログの「OUT - Aval = 90, Bval = 210」とはなんだったか？

– チェーンコード(デプロイしたchaincode_example2)のロジックと実⾏時引数を確認• 引数は以下の通り：

� 関数名："invoke"

� 引数：["a", "b", "10"] ← 「aさんからbさんへ資⾦を10移動」のイメージ• チェーンコード内のロジックは以下の通り：

� Invokeトランザクションなので、チェーンコードの func (t *SimpleChaincode) Run(stub *shim.ChaincodeStub, function string, args []string) ([]byte, error)が呼び出される

» この中で引数function(⽂字列型)に"invoke"が渡される。if文で分岐し下記の関数を呼び出す

� func (t *SimpleChaincode) invoke(stub *shim.ChaincodeStub, args []string) ([]byte, error)関数

» 引数は3つ受け取る (でないとエラー) (第1引数のキー名から第2引数のキー名へ資産を移送)

» 第1引数のキーの値から、第3引数の値ぶんだけ減算する

» 第2引数のキーの値から、第3引数の値ぶんだけ加算する

� 実⾏前のワールドステートに記録されているデータは以下だった。第3引数には"10"を指定した。

» "a" : "100"

» "b" : "200"

� そのため、

» "a" : "90"

» "b" : "210"になった。


110

�デプロイしたチェーンコードの実⾏と動作確認– チェーンコード実⾏後のワールドステートのキー"a"の値をクエリしてみる

• REST API「/devops/query」に対してPOST要求• 内部的には以下のチェーンコード内関数が呼び出される

� func (t *SimpleChaincode) Query(stub *shim.ChaincodeStub, function string, args []string) ([]byte, error)

» args[0]の値をキーとしてワールドステートから値を取得してそれを返すように実装している


111

Bluemix Blockchainサービスの、VP1のRESTエンドポイントを指定(ワールドステートの読み取り)してPOST

key "OK"に対して、value に"90" が返される。チェーンコード実⾏により更新された後のワールドステートのキー"a" に格納されている値が取得できた。

ctorMsgで、functionに"query", argsに ["a"] を指定

�デプロイしたチェーンコードの実⾏と動作確認– チェーンコード実⾏後にチェーン状態をクエリしてみる

• REST API「/chain」に対してGET要求� height は変わっていないことが分かる


112

heightは 17 のまま

� ここから理解できること

– チェーンコードの呼び出しは、あくまで非同期に⾏われる• REST API「/devops/invoke」の応答⾃体に「実⾏結果」は含まれない

� 「invokeに成功したかどうか」と、チェーンコードロジック内部でエラーになったかどうかは異なる

� 例：引数指定ミスを含め、チェーンコード内部でエラーになっていたとしても分からない

– チェーンコード内部処理の結果(エラーかどうか)に関わらずトランザクションは1つ生成される• invokeトランザクションはそれが発⽣したこと⾃体が「台帳の更新」であり、それはピアにブロードキャストされる

• デフォルトのコンセンサスプラグインでは1トランザクションで1ブロック生成する� 結果としてブロックチェーンの height が +1 される

� 注意：仕様上は、「1ブロックに複数トランザクション格納できる」ことと混同しないように• queryトランザクションはワールドステートを更新しないという取り決め・規約がある

� 実⾏しても height は変わらない → トランザクションをブロードキャストしない

– チェーンコード内部のワールドステートへのPUT処理は、全て単⼀のUOWに含まれている• ログからは、RocksDBのトランザクション機能(BEGIN-COMMIT)が使われている模様• NoSQL DBの特徴として、valueの更新は「全体更新」(⼀部のフィールドだけを更新ではない)• そのため、keyに対するvalueは、基本的に以下の処理が必要

� 最新のvalueを読み込み(GET_STATE)し、そして更新後のvalueを書き込み(PUT_STATE)


113

114

まとめ

まとめ

� Open Blockchainは、汎用的なブロックチェーン基盤を目指しているOSSプロダクト–⼀つ⼀つ⾒ていくと、その実体は意外と理解しやすい

� OBCとは何か– あえて誤解を恐れずに例えて⾔うなら…

「レプリケーション機能付きNoSQL DBが組み込まれた、アプリケーションサーバ」• チェーンコードという、フレームワーク仕様に基づいたアプリケーションロジックを開発 & デプロイ

– 何が嬉しいか• ブロックチェーンとしての基盤部分は隠蔽されている

� 開発者・利⽤者は基本的に「ブロックチェーンとしての部分」は気にしないで良い

» ビジネスロジック(=チェーンコード開発)に専念できる

– 何を考えなくてはいけないか• プログラム(チェーンコード)を開発 & デプロイしないと、何もしないし、できない

� そういった意味でも、アプリケーションサーバー(ミドルウェア)

� チェーンコードのソースコードが、チェーンネットワーク参加者全員にとってのいわば「契約書」

» 高品質なチェーンコードを開発できるプログラマー = 有能な契約書作成の司法書士!?

» 自社内のブロックチェーンではなく、真に組織を跨がって共有し実⾏する場合、その開発・レビュー責任

は通常のプログラム開発とは意味合いと次元が異なるものになる

• 「ビー玉デモ」だけであれば、ブロックチェーン&チェーンコード上に開発する意味はない� 当然、それだけなら“普通のWebアプリケーション”として開発すれば良い

� では、どういうものならブロックチェーンとして(チェーンコード上で)開発する意味・価値があるか115

まとめ

� ディスカッション (1/2)

– ソフトウェアとして：「資産」を管理するソフトウェアとして求められる信頼性の確⽴

–利⽤者・開発者として：チェーンコード開発ルールの整備

• 「非決定的なロジック」であってはならない。言い換えると、純粋関数として作らなければならない� 「⾔うは易し」の典型

» 現実世界の複雑なビジネスロジックを実現するためにチェーンコード以前での「前さばき」としてのビジネスロジックが必須になり、チェーンコードだけで完結できない可能性も

• ワールドステートに保持するデータ設計� 単純なkey-valueストアであるため、インデックスや検索なども何もない

» SQL的な発想で操作はできない。(部分更新、複数value間での横串検索、名寄せ等…)

» 最初のデータ設計が全て

• チェーンコードの置き場所、バージョン管理� チェーンコード開発ガイド、チェーンコード命名規約、etc,…

� デプロイしてチェーンネットワークに取り込まれた時点の内容でチェーンコードIDが振られる

� 現在のOBC仕様に、⼀度デプロイしたチェーンコードを更新・削除する機能(API)はまだない

• チェーンコード呼び出し側アプリ開発ルール� 何を使うか、結果をどう得るか

116

まとめ

� ディスカッション (2/2)

– システム運⽤者として：運⽤系ノウハウの確⽴と蓄積

• 耐障害性、ログ、バックアップ、監視、実際のパフォーマンス、メンテによる停止、etc... � 特に、複数の企業を跨がってチェーンネットワークを構成しノードを運用したとき(コンソーシアム型)

• チェーンネットワークを始めることは容易としても、「終わらせること」ができるか� OBCはあくまでプライベート or コンソーシアム型を志向

� 本当に「運用コストの削減」に繋がるか

– etc, etc…

117

最後に

� この資料を参照する前と⽐べて、

もやもやとしていたブロックチェーンおよびOpen Blockchainが、具体的なものとしてイメージを掴めるようになりましたか?– この資料が何らかのお役に⽴てていれば幸いです

� Open Blockchainは、obc-peer、 obc-docs のGitHubリポジトリで開発/更新が⾏われています– "watch"登録をお薦めします

118

(End of file)

119