まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:blockchain

マンホールマップの新バージョンを開発中です。暇を見つけて開発しているので、作業が進む時期も進まない時期もあったりしていましたが、とりあえず最低限の機能の実装はできつつあり、だんだんアプリケーションとしての形になってきました。まだ開発中なので、画面は変更する可能性もありますが、一部の機能をチラ見せしつつ予告編のような形で紹介します。


【新バージョンのテーマ】
ずばり「地図へのこだわり」と「技術の無駄遣い」です。現行版もおなじテーマで開発しており、マップのネーミング通り、地図機能にこだわりつつも、人工知能など比較的あたらしい技術要素を含んだりしていましたが、自分的にはそろそろ更に新しい技術テーマにも挑戦したいと考えていました。既存バージョンからの機能拡張では済まないような、基盤よりの新技術テーマにも挑戦したかったので、新バージョンという形でまったくゼロからのスクラッチ開発に取り組みました。

ちなみに開発言語は現行版が Java でしたが、新バージョンでは Node.js を使います。過去のマンホールマップのプラットフォームは Google App Engine だったり、J2SE だったりしましたが、開発言語はずっと Java を使っていました。その意味でも全くのゼロからの作り直しとなります。


【新バージョンの技術目標】
大きなものは以下の3つです:
- レスポンシブ対応を含めた新ユーザーインターフェース
- ハイブリッドクラウド化
- ブロックチェーン対応

「レスポンシブ対応」とは「PC ブラウザでもスマホブラウザでも、使っているデバイスの画面サイズにあわせてそれなりに使えるようにする」ことを意味しています。現行版も一応スマホ対応していますが、これはスマホ用の画面を PC 用とは別に作っていて、「スマホの人はこっちのページ」という対応でした。 この方法はメンテナンス時に互いの影響を少なくすることはできますが、2つのアプリを同時に開発するような側面もあって、開発する側としては面倒なものでもありました(現実的にはスマホからは使えない機能も多くあります)。 今回ははじめからレスポンシブ化を目指して開発を進めています。今の所 100% レスポンシブ対応できるようになるかどうかは微妙な予感がしていますが(苦笑)、数カ所を除いてなんとかがんばる予定です(←既に数箇所諦めています (^^;)

なお、現在開発中の画面の一部を公開します:
2019091601


2019091602


このカレンダー機能は実は現行版にも含まれていますが「隠し機能」的な位置づけでした。新バージョンではメニューから表示できるようにします:
2019091603


ゲーム要素にも新しい画面を取り入れる予定です。これは「アタック25」モードのページ:
2019091604



次に「ハイブリッドクラウド化」。まず現行版は私の自宅にある ThinkPad 内にアプリケーションサーバーとデータベースサーバーをインストールして動いています。要は(一部の機能は外部APIを使っていますが)ほとんどを自宅内のリソースで提供しています。クラウド時代をある意味で逆行しているものです(ただ個人開発者としては今でもこの形のアドバンテージはあると思っています)。これを一部パブリッククラウドに移して(一部は自宅に残して)コンテナ化するようなハイブリッドシステムを構築する方向で進めています。詳しいシステム構成は後述します。

最後の「ブロックチェーン対応」、これは改ざんが困難な仕組みである「ブロックチェーン」の技術を使い、利用者がマンホールマップにアップロードしたデータが正しいものである(改ざんされていないものである)ことを保証する仕組みを提供するつもりです。


【新バージョンのシステム構成(予定)】
上記の要素を取り入れ、マンホールマップのシステム構成は現行のこの形から、
2019091501


最終的にはこのような形に変更する予定です。今まで以上に公私混同具合が大きくなります(苦笑):
2019091502
(↑ブロックチェーン部分のネットワーク構成は面倒なのでかなり省略)


なお、データベースサーバーのみ独立して自宅サーバーで稼働し続ける形になりますが、これもいずれはパブリッククラウド化を考えています(当面自宅に残す理由はコストパフォーマンスの問題です。クラウドのデータベースサービスは高い・・)。


リリースを優先する意志もあるので、新バージョン公開段階でどこまで実装できているかはまだ不確定要素もありますが、この最終形を目指して開発を進めていくつもりです。なお UI はまだ変更の可能性が高いのですが、ハイブリッドクラウド化とブロックチェーン対応は試験的にはもう動いていて、技術的な目処はついています。


【新バージョンの公開予定】
新バージョンは現時点では令和元年11月2日に開催予定の「マンホールナイト11」にてお披露目予定です。可能であれば(そして大きなトラブルがなければ)この日に前後する形でシステム公開するつもりでいます。




 

ブロックチェーンの特徴の1つに「対改ざん性(一度格納した情報は、たとえ管理者権限を持っている人でも改ざんができない)」があります。その改ざんを困難にするためのマイニングと呼ばれる仕組みをゲーム感覚で学べるサービスを作ってみました:
https://dotnsf.github.io/nonce/
2019012800


少しだけ補足すると、これはブロックチェーンのマイニングの仕組みをシミュレーションするサービスです。実際のマイニングよりもかなりシンプルなマイニング作業を実際に行いながら、nonce やハッシュの仕組みを理解し、ブロックチェーンがなぜ改ざんできない仕組みと言われているのかを遊びながら理解することを目的に作りました。

なお、画面含めて今後変更が加わる可能性があることを申し上げておきます。以下は 2019/01/28 時点でのサービス内容をもとに紹介しています。


ではチュートリアルっぽく、このサービスを紹介していきます。まず上記 URL に(PC の)ウェブブラウザでアクセスすると、以下のような画面が表示されます(スマホのブラウザで見えないことはないと思いますが、情報量の多いページで横スクロールも併用する必要があり、現状スマホからはかなり使いにくいと思っています。どうしてもスマホで利用する場合は画面を横にしてお使いください):
2019012800


この画面は目的別のパーツに分かれています。ここからは各パーツの意味も含めて順に紹介していきます:
2019012801



#パーツ意味
1オプションの内容このゲームのパラメータ(この図では初期値のまま Mining Level = 1 と Goal = 3 となっている)
2ブロック番号何番目のブロックかを示す数値。
上図の場合、1なのでこれが最初のブロック
3body 値これからブロックチェーンに格納したいと思っている内容
4nonce 値整数値(詳しくは後述、最初は1)
5hash 値body と nonce(ブロック番号が2以上の場合は1つ前のブロックに格納されたハッシュ値も)から計算したハッシュ値
6格納されたブロック上記の nonce 値とハッシュ値の値が確定してブロックチェーンに格納されたブロック(この図では空なので、まだ格納していない)


↑の表や意味は後でもう一度確認するとして、まずは一度ゲームを進めてみます。

その前に1つだけ、ゲームスタート時点で hash 値のボタンが上図のように赤ではなく、稀に緑になっている可能性があります。その場合は(本当はゲーム的にはすごくラッキーなんですが・・・)hash 値のボタンが赤くなるまで何度か nonce 値の、初期状態で1と書かれているボタンを押してください(ボタンを押すたびに数値が増えていきますが、とりあえずは無視してください)。以下の説明では hash 値のボタンが赤で始まることを想定しています。このボタンの色の意味は後述します。


【ゲームの目的】
一定の数(オプション Goal の値、デフォルトでは3)のブロックをブロックチェーンに格納することが目的です。なるべく短い時間でブロックチェーンを完成させましょう。

ブロックはマイニングルールと呼ばれるある条件を満たせばブロックチェーンに格納することができます。マイニングルールを満たしていないブロックはブロックチェーンに格納できません。その条件を満たすよう、注意しながら操作し、条件を満たしたタイミングでブロックチェーンに格納します。これを一定の数繰り返すことでゲームをクリアできます。


【ゲームの遊び方】
ややこしい話は後回しにして、とりあえずゲームとしての遊び方を紹介します。すごくシンプルです。

nonce 値のボタンを1回押すごとに nonce 値は1つ増え、同時に hash 値が変化します:
2019012802


そして nonce 値を増やしていくと hash 値がある条件を満たした時にボタンは緑色になります
2019012803


そして hash 値のボタンを緑色の時に押すとブロックがブロックチェーンに格納されます。なお、赤の時に押してもマイニングルールを満たしていないためブロックは格納されません。以下のようなメッセージが表示されます。このままマイニングを続ける場合は「キャンセル」を選択してください:
2019012809


表の一番右の列にブロックが格納されます(通常、この時点でブロックは暗号化されて格納されますが、このサービスでは暗号化せずにそのままマイニングしてそのまま格納しています)。1つのブロックが格納されると、次のブロックが下段に表示されます。このブロックも同様に hash 値のボタンが緑になるまで nonce 値のボタンを押し、緑になったら押してブロックチェーンに格納します:
2019012804


これを繰り返して、ブロックをブロックチェーンに格納していきます:
2019012806


一定数(デフォルトでは3)のブロックがブロックチェーンに格納できたらゲームクリアとなります。ゲームクリア時にゲーム開始からクリアまでかかった時間と合わせてゲームクリアの情報が表示されます:
2019012807


なお途中で赤のボタンを押して、「自動計算しますか?」の問いに「OK」を選択するとギブアップしたことになります。ギブアップすると hash 値のボタンを緑にすることはできますが、クリア時に「途中で自動計算を使いました」というメッセージが表示されます):
2019012808


また hash 値のボタンがいちど緑になった後、そのボタンを押す前に nonce 値のボタンを押してしまった場合、nonce 値を戻すことはできません。そのまま更に nonce 値を1つずつ増やして、再度マイニングルールを満たす nonce 値を探す必要があります。


と、こんな感じのゲーム感覚でマイニングを体験するサイトです。サービスそのものは Github Pages を使って、(CDN 以外は)1枚の HTML で作りました:
https://github.com/dotnsf/nonce/tree/gh-pages


本当は別の機会にちゃんと説明したいのですが、長くなりそうなのでシンプルに「なぜブロックチェーンに記録されたデータの改ざんが難しいのか」を説明しておきます。要するに記録したデータに対して、マイニングというそれなりに CPU パワーを必要とする処理を施した上でのチェックビットのような仕組みを加え、かつそのマイニング結果を前後のブロックに持たせてつなげる(「ハッシュポインタ」)ことが対改ざん性としての鍵になっているのです(更に実際にはデータに暗号化を加えることもあります)。 この仕組みによって、記録したデータを単純に(例えば振込額を増やすとか、振込先を変えるとか)書き換えるとその hash 値が変わり、記録内容とは異なってしまうので、書き換えたことがすぐにバレてしまいます。書き換えをごまかすためには hash 値を再計算する必要があるのですが、マイニングルールを満たす条件があるため、ここでそれなりの処理能力が必要になります。更に1つのブロックのマイニングが完了して書き換えに成功したとしても、次のブロックは1つ前の(つまり今書き換えたばかりの)ブロックの hash 値を持っているので、やはりここでも書き換えがバレてしまいます。これをごまかすためにはこのブロックの hash も書き換える必要があり、ここを書き換えると再度マイニングが必要になり・・・ とブロックチェーンの最後のブロックまで全てマイニングし直して書き換える必要がでてきてしまいます。マイニングルールが1桁とか2桁程度であればまだ処理できるかもしれませんが、実際の仮想通貨取引では 10 桁以上のマイニングルールが課せられており、全てのブロックを書き換えることは事実上不可能とされているのでした。



このサービスではマイニングが完了したブロックを仮想的なブロックチェーンに格納していますが、近い将来にこのページの HTML を改良して認証を加え、自動計算なしでクリアしたら本当にその記録をブロックチェーンに格納する、というものをリリースする予定です。お楽しみに。


BMXUG(IBM Cloud ユーザー会)の勉強会がきっかけで知り合いになる機会のあった MonAmie さんが今月出版した SF 小説、「H -アッシュ- 仮想通貨BLOODとAIになった歌姫」を読了しました:



近未来である西暦 2025 年、ブロックチェーンと AI の技術が普及した東京を舞台としています。この作品最大の特徴の1つ(と思っている)血液と交換可能な仮想通貨 "BLOOD" を巡るストーリーです。ここでは世の中のいたるところに AI が活用されていて、またそのセキュリティシステムにも話が及び、ひとりの IT エンジニアとして読んでいても興味深い内容でした。

感想として、まず何よりもこれを伝えたいのですが、血液という(現代の日本では法律でお金との交換が禁じられているものの)非常に高価なアイテムを電子的に取引する、というブロックチェーンのユースケースが非常にユニークであり、かつ技術的には実現が不可能と思えるほどでもなく、いろいろな意味で興味深い仕組みが描かれていました。「そうか、血液が扱えるなら○○だって・・・」とブロックチェーンの応用アイデアを刺激される内容でした。

次にこの小説の中では「ブロックチェーン」、「人工知能」、「セキュリティ」という IT の中でも比較的ホットな3つの分野がテーマとして描かれています。この3つの分野全てに精通したエンジニアの存在だけでも珍しいのではないかと思っていますが、(フィクションとはいえ)それらの近未来ユースケースと考えると IT の読み物としても先進的で面白いと感じる人が多くいるのではないかと思いました。

また西暦 2025 年の東京という舞台から見た、現在である西暦 2018 年がブロックチェーンや仮想通貨の黎明期として描かれていて(どこかで聞いたような流出事件が過去事例になっていたりして)、タイムリーな話題が物語の中で自然に取り込まれて紹介されていました。この点も面白く読み進められた理由だったと感じています。気の早い話かもしれませんが、次回作を読んでみたいと思いました。


ブロックチェーンに携わる機会のあるエンジニアや、ブロックチェーンで新しいビジネスを興そうと考えている人にとっては興味深い近未来のユースケースとしても是非読んでいただきたいと感じた一冊でした。


僕自身はオープンソース製品である Hyperledger FabricHyperledger Composer を使ったブロックチェーンプラットフォームや、その対応アプリケーションを業務で開発する機会が多くあります。

ありがたいことに実際に作る機会も多いのですが、「作る」という決断に到達する前に方針を変更することも少なくありません。よくある理由としては「(現行の)ブロックチェーンに向かない要件」であるというケースです。パフォーマンス要件だったり、検索機能の要件だったり、現在のブロックチェーンでは本格運用に向かないケースが前提になっていたりすると、そのことを伝えた上で「それでも作るかどうか」を判断していただいています。そして「作らずに検討し直す」と判断されることもある、という意味です。

でも、これはブロックチェーンを使いたいと思いながらも「現在のブロックチェーン技術」では向かない、と判断されたからです。需要としては存在していることも意味しています。

そんな場面を多く見ている中で「だったらブロックチェーンといえるかどうかはともかく、同じような仕組みで耐改竄性を高めながら、この要件も満たせるようなデータストアの仕組みを作れないか?」と考えるようになりました。それが今回紹介するものです。


【「ブロックチェーン」の定義】
まず最初に、以下で紹介するアプリケーションは「ブロックチェーン」と呼べるものかどうかと言われると、私個人的には「呼べないのではないか」と考えています。これは「ブロックチェーンの定義」をどのようにするか、という問題にも関わってくるのですが、ここでは1つの目安として、JBA("Japan Blockchain Association" 日本ブロックチェーン協会)が定義した以下の2つの定義を満たすものをブロックチェーンと定義するものとします:

・ビザンチン障害を含む不特定多数のノードを用い、時間の経過とともにその時点の合意が覆る確率が0へ収束するプロトコル、またはその実装をブロックチェーンと呼ぶ。
・電子署名とハッシュポインタを使用し改竄検出が容易なデータ構造を持ち、且つ、当該データをネットワーク上に分散する多数のノードに保持させることで、高可用性及びデータ同一性等を実現する技術を広義のブロックチェーンと呼ぶ。

(参照)
http://jba-web.jp/archives/2011003blockchain_definition

2018062901



要するに「ブロックチェーンとは『ブロック』が『チェーン』のようにつながって格納される仕組み」というゆるい定義ではなく(注 私個人的にはこれがブロックチェーンの定義でもいいと思ってます)、「ハッシュポインタを用いて接続し、データを複数のノード上に分散して保持し、かつその複数ノードが耐ビザンチン障害性を持っている実装」のことを「ブロックチェーン」と定義する、ということです。 そしてこの定義の上で考えた場合、以下で紹介するものはブロックチェーンではない、ということになることを予め伝えておきます。

自分の考えは、上記のものだと耐ビザンチン障害性をもたせるためのコンセンサスアルゴリズムに問題が発生したり(最近だと「51%攻撃」と呼ばれる手法が話題になりました)、そのためにトランザクションのパフォーマンスを高く実現するのが難しかったりする、と思っています。なのでこの要件が必須でないケースでは、この条件を確保しないことでパフォーマンスや検索機能など他の要件機能を向上させることができるのではないかと考えました。


【色々出てきている】
現状のブロックチェーンにはパフォーマンス遅延や電力消費など当初は想定していなかったことが問題になっていることもあって、それらの苦手部分に対処した新しい仕組みも生まれています(それらが上記ブロックチェーンの定義を満たしているかどうかはともかく)。例えば全参加者のコンセンサスを得る上でのパフォーマンス遅延を解決するために、ランダムに選ばれた一部参加者のコンセンサスを得るように改良したものも出ているようです:
ブロックチェーンを超える?ハッシュグラフ(Hashgraph)とは?


【作ってみようと思ったもの】
今回、自分は以下4つの特徴を持つようなデータストアシステムを新たに開発してみようと思いました:
(1)ハッシュポインタを利用した、改竄検出が容易なブロックチェーンの仕組みはそのまま取り入れる
(2)データは中央集権管理型とする。これによりコンセンサスアルゴリズムや耐ビザンチン障害性の問題を発生させなくした上で、トランザクションパフォーマンスの向上を実現する
(3)データそのものは分散データストアに格納して(格納可能にして)高可用性を実現する。つまり単なる1ピア運用とは異なる
(4)バイナリデータやファイル添付を含む大きなレコードのデータストアへの格納や全文検索機能、データを読み書きするための REST API を標準装備する



(2)の時点で上記ブロックチェーンの定義を満たさなくなっています(ブロックチェーンは非中央管集権管理型)。(3)ただ単に1ピアにデータを格納するのではなく、論理的な1データストアが実際には複数のロケーションに分散できるようにしており、これにより特定ロケーションが単一障害点とはならないようにします。そして(4)ブロックチェーンが比較的苦手とする巨大オブジェクトの格納や検索機能もこのシステムでは標準装備することを目標としています。加えて標準で REST API を準備することで(導入すればすぐ使えるようになって)導入時の負担軽減も実現するつもりです。

2018062902



【作っているもの】
上記仕組みを実現するためのソフトウェア(というかプラットフォームというか、API 群というか・・)を開発中です。まだ開発中ですが Github にて MIT ライセンスで公開しています:
https://github.com/dotnsf/hashchainsolo


上記の事情もあり、開発コード名には「ブロックチェーン」は含めず「ハッシュチェーンソロ」という表現にしました。レコードのブロックをチェーンのようにつなげていくものではあるのですが、上述の定義を満たすようなものではなく(むしろそこを犠牲にしている)、自分も「ブロックチェーン」という表現にこだわるわけではないので「ハッシュチェーン」という表現にしたかったのですが、これはこれで別の意味に使われており、ややこしいことになりそうだったので(ブロックチェーンだと単一ピアに相当する設計になるという意味で)「ハッシュチェーンソロ」と命名しています。某○icrosoft Office 365 Solo の影響とかではありませんw

インフラとして、分散データストアには IBM Cloudant を採用しています。Apache CouchDB をベースとした NoSQL 型のマネージド DBaaS で、容量・トランザクションパフォーマンスに制約があるものの無料プランを選択することもできるので、「とりあえず動作確認してみる」ためのハードルは低く実現できると思っています。一方でプランを見直して容量やパフォーマンスを変えたり、要件によってはプライベートクラウド版やオンプレミスソフトウェア版を使うことも可能です。またこの Cloudant 自体がバイナリ(添付ファイル)格納や検索インデックスといった機能を内包しているので、ブロックチェーンでいうところの「ステート DB」に相当する仕組みや外部ファイルシステム等がなくても各種データを格納することができ、上述の4つの特徴を兼ね備えた単独の仕組みを比較的作りやすいと思っています。

#現時点では実装していない余談ですが、IBM Cloudant をデータストアに使っていることで、携帯版の PouchDB と組み合わせてモバイルプラットフォームへの移植も想定しやすい設計にしています。

ハッシュポインタを使って耐改ざん性を高める部分は全てスクラッチで実装しています。タイムスタンプと nonce を併用してマイニングを行い、特定条件(変更可)を満たした時だけハッシュを採用できるようにしています。

2018/Jun/30 の現時点での開発状況は「とりあえず一通りの REST API は動くようになっている」レベルです。時間を見つけてぼちぼちと改良中です。


【Call for Code】
この製品で Call for Code に参加予定です。自然災害の支援を目的としたソリューションのコンテストで、ブロックチェーンを使う事例は多く存在すると思いますが、そのブロックチェーン技術の選択肢の1つとして、既存技術では難しいものも場合によっては解決できる、と思っていて、その実装として提供・参加予定です。




 

この記事の続きです:
IBM Cloud のブロックチェーンサービスを使う(前編)
IBM Cloud のブロックチェーンサービスを使う(中編)


IBM Cloud から提供されているマネージド・ブロックチェーン・サービスを使う手順を紹介しています。前編ではベータ版で無料(2018/03/27 時点)のサービスインスタンスである Starter Membership Plan の作成手順を紹介し、中編ではこのサービスインスタンスを Hyperledger Composer のカードファイルを使ってセットアップしました。今回の後編ではこのインスタンスに実際にビジネスネットワークをデプロイして動かすまでの手順を紹介します。なおあくまでベータ版であり、今後の仕様変更等により以下の内容は正しい情報ではなくなる可能性もあります。以下の内容は 2018/03/27 時点での情報であることをご了承ください。


【BNA(Business Network Archive)ファイルの準備】
まずはデプロイするビジネスネットワークを用意します。IBM Cloud のブロックチェーンサービスはオープンソースのブロックチェーン基盤である Hyperledger Fabric をベースとしており、関連プロダクトである Hyperledger Composer もサポートしています。ビジネスネットワークは Hyperledger Composer や Hyperledger Composer Playground を使うと BNA(Business Network Archive)ファイルとして比較的簡単に定義することができるので、今回はこの方法を使います。

すでに BNA ファイルをお持ちであれば、そのファイルを使っていただいても構いません。お持ちでない場合は私が github.com で公開しているこちらのコードを使ってください:
https://github.com/dotnsf/bcdev-basickit

↑この公開プロジェクトは名前の通り、bcdev(BlockChain DEVelopment) の BasicKit として開発・公開したものです。Hyperleger Fabric & Hyperledger Composer を使って、ごくシンプルなビジネスネットワークを作り、そのビジネスネットワーク上で動作する API とサンプルアプリケーションが含まれています。簡単に言えば「ブロックチェーン開発の雛形キット」として開発したものです。


上記リポジトリを(Node.js を導入したシステムに)ダウンロードするか git clone して、一連のファイルを手元に用意してください。そしてこの中の /api/bcdev-basickit-network.bna というファイルが Hyperledger Composer 用のビジネスネットワーク定義ファイルになっています。以降の説明はこの bcdev-basickit-network.bna ファイルを前回説明&作成した IBM Cloud のブロックチェーンサービスにデプロイすることを目的に説明します:
2018032601



【BNA(Business Network Archive)ファイルのデプロイ】
まずは中編のおさらいを兼ねて、ここまでに設定した内容と、この bcdev-basickit アプリケーションを動かすために設定する内容を記載しておきます。まずは前回の設定内容がこちら:
項目設定値
作成した管理者向けのカード名admin@fabric-network
上記管理者の公開鍵ファイル~/.identityCredentials/admin-pub.pem
上記管理者の秘密鍵ファイル~/.identityCredentials/admin-priv.pem
接続プロファイル~/mychannel1/connection.json


そして、今回動かそうとしている bcdev-basickit アプリケーションが想定しているブロックチェーン上のビジネスネットワークの設定がこちらです:
項目設定する値
アプリケーションの実行ユーザーのカード名※admin@bcdev-basickit-network
アプリケーションの BNA ファイル./api/bcdev-basickit-network.bna


※Hyperledger Composer に慣れていないとわかりにくいかもしれませんが、/api/settings.js の中でカード名を指定していて、ここで指定したカード名でビジネスネットワークにアクセスできるよう設定されている前提でアプリケーションが作られています。またビジネスネットワークそのものは api/ フォルダの下にある bcdev-basickit-network.bna ファイルで定義されています。このファイルを指定してデプロイします。

では composer コマンドを順次実行して設定していきます。まず最初に admin@fabric-network の管理者でビジネスネットワークアーカイブファイルをデプロイします:
$ composer runtime install --card admin@fabric-network --businessNetworkName bcdev-basickit-network
  (↑空のビジネスネットワークを作成)
$ composer network start --card admin@fabric-network --networkAdmin admin --networkAdminEnrollSecret adminpw --archiveFile ./api/bcdev-basickit-network.bna --file admin@fabric-network.card
  (↑空のビジネスネットワークにユーザー名(admin)と BNA ファイルを指定してデプロイ)

【アクセス用カードファイルの準備とインポート】
ここまでの作業が成功すると、ブロックチェーンサービス上でビジネスネットワークが稼働している状態になります。このままでも使えないことはないのですが、一般的には個別のビジネスネットワークにアクセスするための個別のユーザー(カード)を作って利用します。特にこの bcdev-basickit-network というアプリケーションでは(デフォルト状態では)admin@bcdev-basickit-network というカードでアクセスすることを想定して開発されているので、このカードを作ってインポートします:
$ composer card create -n bcdev-basickit-network -p connection.json -u admin -c ~/.identityCredentials/admin-pub.pem -k ~/.identityCredentials/admin-priv.pem
  (↑このビジネスネットワークにアクセスするためのカード(admin@bcdev-basickit-network)を作成)
$ composer card import -f admin@bcdev-basickit-network.card
  (↑新たに作成したカードをインポート)
$ composer card list
  (↑カードの一覧を表示して、結果に admin@bcdev-basickit-network が含まれることを確認)

カードの一覧に admin@bcdev-basickit-network が含まれていることを確認します:
2018032602


最後に admin@bcdev-basickit-network がビジネスネットワーク上で正しく動いている(アクセスできる)ことを確認します:
$ composer network ping -c admin@bcdev-basickit-network
  (↑admin@bcdev-basickit-network への ping が成功することを確認)

この結果が "Command succeeded" になればデプロイされたビジネスネットワークを使う準備が整ったことになります:
2018032603


【ブロックチェーンアプリケーションの利用】
ここまでの準備が整っていればアプリケーションからビジネスネットワークを利用することができます。今回用意したモジュールには Swagger ベースの API Document が含まれているので、これを動かしてみましょう。

Swagger API Document は api/public/doc フォルダ内にあります。つまり api フォルダ内でアプリケーションを実行するのですが、一部設定項目があります。そのためにまずは一度アプリケーションを実行します:
$ cd api
  (↑ api/ フォルダへ移動)
$ npm install
  (↑ライブラリのインストール)
$ node app
  (↑アプリケーション実行)

実行が成功すると "server starting on XXXX ..." というメッセージが表示されます。この "XXXX" という部分(下図の場合 6017)をメモします:
2018032604


一旦アプリケーションを終了し(Ctrl+C)、api/public/doc/swagger.yaml ファイルをテキストエディタで開きます。そして6行目の host: で始まる行の続きを このシステムの IP アドレス:XXXX という内容に書き換えて保存します:
2018032605


もしこのアプリケーションを手元のシステムではなく IBM Cloud などのパブリッククラウド上のアプリケーションサーバーにデプロイして実行する場合は、この host の値をアプリケーションサーバー名に書き換えて保存してください。

保存後、あらためてアプリケーションを実行し、ウェブブラウザで /doc/ パスにアクセスすると、Swagger Open API ドキュメントの画面が表示されます(Basic URL の値が swagger.yaml で編集した host の値になっていることを確認してください):
2018032606


(注 IBM クラウドの Cloud Foundry ランタイムで実行している場合は、API ドキュメントのスキーマを HTTP から HTTPS に変更してから以下を実行してください)
2018032705



この画面はブロックチェーンサービスと接続された API サーバーのインタラクティブドキュメントになっているので、実際に動かすことが可能です。一例としていくつかの処理を実行してみましょう。まずは管理ユーザーを作成するために POST /api/adminuser と書かれた項目をクリックして展開します。するとこの API に関する説明が表示されると同時に、"Try it out" というボタンが表示され、ここをクリックすると実際に実行することができます:
2018032605a


この API では管理ユーザー(admin)のパスワードを生成します。仮にパスワードを P@ssw0rd とする場合は { "password": "P@ssw0rd" } という JSON を指定します。最後に Execute をクリックします:
2018032607


実行結果や実行内容が画面下部に表示されます。ここで行った処理を curl コマンドで実行する場合のコマンドなども表示されます。以下の例では実行結果として HTTP コード 200 が返り、{ "status": true } という本文が戻されました。API 実行コマンドは成功して、このアプリケーションの管理者をブロックチェーン内に作成することができたようです:
2018032608


では作成したユーザーでログインしてみましょう。API Document 画面の1つ下に POST /api/login という API があり、この API でログイン処理を行うことができます。この項目を選択して展開し、同様に "Try it out" をクリックします:
2018032701


この API では { "id": "ユーザーID", "password": "パスワード" } というフォーマットの JSON でログインパラメータを渡します。最初はわざと間違えてみることにするので、{ "id": "admin", "password": "string" } というパラメータを指定して、"Execute" をクリックしてみます(正しいパスワードは上記で設定した値 "P@ssword" です):
2018032702


この API が実行されて、結果が出力されます。HTTP コードは 401、実行結果本文は { "status": false, "message": "Not valid id/password." } が得られました。一応期待通りの結果といえます:
2018032703


改めて正しい内容でログインしてみます。実行パラメータを { "id": "admin", "password": "P@ssw0rd" } に変更して再び "Execute" をクリックします:
2018032704


今度は成功して、HTTP ステータス 200 が返ってきました:
2018032705


なお、このログインに成功した時の実行結果本文は以下のような JSON になっています:
{
  "status": true,
  "token": "XXXXXXXXXXXXX(トークン文字列)XXXXXXXXX"
}

この token の値がログインに成功した証となるトークンで、他の API 実行時に必要になります(実際のアプリケーションではセッションなどに保管して使うことを想定しています)。例えばユーザーの一覧を取得する API である GET /api/users ではここで取得したトークン文字列をパラメータとして指定する必要があります:
2018032706


わざと何も入力しなかったり、適当な文字列を入力してこの API を実行しても、{ "status": false, "message": "Invalid token" } とだけ返ってきます:
2018032707


一方、先程のログイン時に取得したトークンの値をここに指定してから実行すると、ユーザーの一覧(この時点では admin ユーザーのみ)が取得できることが確認できます:
2018032708


【ブロックチェーンの管理】
こんな感じでブロックチェーンを読み書きできるような REST API を定義するアプリケーションがデプロイ/実行できることが分かりました。実際にはこれ以外にもユーザーを新規に作成したり(POST /api/user)、ユーザーが所有する商品を新規に作成したり(POST /api/item)、その商品の一覧を取得したり(GET /api/items)する API が提供されています。興味があればこれらも使ってみてください。


最後に、何回かブロックチェーンに対してトランザクションを実行した後でブロックチェーンサービス側がどのようになっているかをダッシュボードから確認する方法を紹介します。ダッシュボード画面でチャネルメニューを選択すると、利用中のチャネル一覧が表示されますが、その中の「ブロックの高さ」という数値がブロックチェーン上に記録されているブロックの数を表しています(前回の画面ではここは2でしたので、いくつか積み重なっていることがわかります):
2018032701


該当行をクリックして先に進むと、更に詳細な情報を見ることが出来ます。例えば下図の一番上にあるブロックの ">" をクリックして展開します:
2018032702


「アクション」メニューから「詳細の表示」を選択すると:
2018032703


このブロックで実行された内容や実行結果を確認することもできます。こういった管理機能が初めから提供されていたり、ストレージなどのインフラ環境を意識する必要がなくなることもマネージドサービスのメリットと考えることができます:
2018032704


【感想】
以上、ここまで3回に渡って IBM Cloud のマネージド・ブロックチェーンサービスの使い方を紹介してきました。最後にこのサービスを使ってみた上での感想に触れておきます。

まず、これまで自分は業務内外で Hyperledger Fabric ベースのブロックチェーン環境やアプリケーションを構築・開発・運用してきました。慣れもあって構築作業(正確には「開発用途での構築作業」)そのものはあまり苦にならないレベルの作業になっています。ただ起動や停止、再起動といったプリミティブな作業も含めて、構築したブロックチェーン環境のインフラを管理するのはやはり面倒で、本来の目的(この場合は開発用途)を考えると苦痛を伴うものでした。その点から開放されて、開発やテストに注力できる意味や意義は小さくないと感じています。

また「ブロックチェーン内の各ブロックの様子を確認する」というよくある要望に対する機能もサービス内に標準装備されています(これまではそのための参照アプリを別途用意する必要があった)。これによってデバッグの効率も上がりました。このあたりは「マネージドサービスらしい」機能が提供されていると感じます。

一方で、個別アプリケーションをデプロイするまでの手順についてはもう少し簡略化できるのではないかとも考えます。(2018/03/27 時点での)現状の「空の管理者ユーザーを一度作って、ファイルをダウンロードしたら、ユーザーを消してまた管理者ユーザーを作り直してアップロードし直して・・・」という作業は改善の余地があるようにも感じています。この辺りは時間が解決してくれることを期待します。


改めて、このようなブロックチェーンのマネージドサービスが(ベータ版とはいえ)無料で提供されていることは素晴らしいです。興味ある方は是非使ってみていただきたいです。


このページのトップヘ