目次


Hyperledger Composer の基礎, パート 1

ブロックチェーン・ネットワークをモデル化してテストする

Hyperledger Composer Playground 内で迅速、簡単にブロックチェーンを導入する

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Hyperledger Composer の基礎, パート 1

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Hyperledger Composer の基礎, パート 1

このシリーズの続きに乞うご期待。

このチュートリアルで、皆さんがブロックチェーン・アプリケーションの開発を始められるよう手ほどきします。今回は、Hyperledger Composer の概要と、そのユーザー・インターフェースである Hyperledger Composer Playground を紹介します。Hyperledger Composer Playground では、Docker と Web ブラウザーさえあれば、ブロックチェーン・ネットワークをモデル化してテストすることができます。

続くパート 2 では、ブロックチェーン・ネットワークを改良してデプロイする方法を説明します。パート 3 では、Hyperledger Fabric をコンピューター上にインストールして、ビジネス・ネットワークをローカル・インスタンスにデプロイする方法と、サンプル・ネットワーク・ブロックチェーン・アプリケーションを操作する方法を説明します。

前提条件

このチュートリアルに従うには、お使いのコンピューターに以下のソフトウェアがインストールされている必要があります。

Hyperledger Composer とは何か

Hyperledger プロジェクトの 1 つとして The Linux Foundation によってホストされている Hyperledger Composer は、ブロックチェーン・アプリケーションを容易に構築できるようにするためのツール一式です。具体的には、以下のツールで構成されています。

  • CTO モデリング言語。CTO とは、元のプロジェクト名 Concerto に敬意を表した名前です。
  • Hyperledger Composer Playground。ビジネス・ネットワークを迅速に構成、デプロイ、テストするためのユーザー・インターフェースです。
  • コマンド・ライン・インターフェース (CLI) のツール。Hyperledger Composer を使用してモデル化したビジネス・ネットワークを Hyperledger Fabric ブロックチェーン・ネットワークの実行中インスタンスに統合する際に使用します。

このチュートリアル・シリーズの今回のパートでは、CTO モデリング言語と Hyperledger Composer Playground を紹介します。CLI については、シリーズのパート 2 で他の多くのトピックと併せて詳しく説明します。

Hyperledger Composer モデリング言語 (CTO)

Hyperledger Composer には、ビジネス・ネットワークをモデル化するために使用する独自のモデリング言語 (CTO) があります。このパート 1 で、CTO を使用して Perishable Goods というサンプル・ネットワークをモデル化する方法を説明します。このサンプル・ネットワークは、生産者、輸送業者、輸入業者の間で結ばれる生鮮食料品の価格に関する契約を、輸送コンテナーの温度測定値に基づいて定義する例を説明するものです。

Hyperledger Composer Playground

ビジネス・ネットワークをモデル化するには、Hyperledger Composer Playground というブラウザー・ベースのインターフェースを使用できます。このインターフェースでは、取引対象とする価値のある商品 (資産)、資産の取引に関与する参加者、資産を保護する方法 (アクセス制御)、取引のプロセスに伴うビジネス・ロジック (トランザクション) をはじめ、さまざまな要素を定義できます。

Hyperledger Composer Playground (以降、Playground と略称) ではブラウザーのローカル・ストレージを使用してブロックチェーン・ネットワークの状態を保管するストレージをシミュレーションします。したがって、Playground を使用するために、実際の検証ピア・ネットワークを実行する必要はありません。

今回のチュートリアルでの皆さんの課題

  • ビジネス・ネットワークの概念について学ぶ
  • コンピューター上で Docker を使用して Playground を実行する
  • モデリング言語に慣れ親しむ
  • モデリング言語を使用してビジネス・ネットワークをモデル化 (記述) する
  • ビジネス・ネットワークをテストする

パート 2 では、Hyperledger Composer 開発ユーティリティー一式をインストールする方法、CTO 言語のより高度なフィーチャー (イベントを含む) を処理する方法、JavaScript スマート・コントラクトの単体テストを行う方法、そしてコマンド・ライン・インターフェース (CLI) を使用して実際の Hyperledger Fabric ブロックチェーン・ネットワークを操作する方法を説明します。

パート 3 では、Composer の高度な側面に目を向け、Yeoman を使用して REST インターフェースと GUI を生成する方法、ブロックチェーン・ネットワーク・アプリケーションを IBM Cloud にデプロイする方法を説明します。

ビジネス・ネットワークの概念

大局的に見ると、ビジネス・ネットワークとは、特定の目標を達成するために協力し合うエンティティーのグループということになります。目標を達成するためには、ビジネス・ネットワークのメンバーの間で、以下の点に関する合意が必要です。

  • 取引対象とする商品とサービス
  • 取引を行う方法 (支払いおよびペナルティーを規定するビジネス・ルールを含む)
  • 取引への参加を許可するグループ内のメンバーと参加のタイミング

次のセクションで、よく使われるビジネス・ネットワーク用語を紹介します。皆さんが初めてのビジネス・ネットワークで対処するビジネス問題として、生鮮食料品の輸送を扱います。要点として、モノのインターネット、温度センサー、そしてクラウドを使用して、生鮮食料品が理想的な状態で輸送されるようにする方法 (そして理想的な状態で輸送されなかったときの措置) に対処します。

Perishable Goods ネットワーク

モノのインターネット (IoT) ベースの Perishable Goods ネットワークは、以下の要素が関与するビジネス・ネットワークです。

  • バナナ、洋ナシ、コーヒーなどの生鮮食料品
  • 生産者、輸送業者、輸入業者などのビジネス・パートナー
  • 生鮮食料品の輸送
  • 取引条件を規定する、当事者間での合意
  • 商品およびサービス受領の確認応答

チュートリアル・シリーズ全体を通して、このビジネス・ネットワークを例として使用します。シリーズを読み進めていくと、このアプリケーションが次第に複雑化していくことがわかるでしょう。今後のパートで、Hyperledger Composer の概念をさらに追加し、それらの概念がブロックチェーンと IBM Cloud にどのように関連するのかを説明していく予定です。

資産:

ビジネス契約の当事者間で取り引きできる価値のあるものは、いずれも「資産」と呼ぶことができます。したがって、資産という用語の意味はかなり広義です。以下に、いくつか例を挙げます。

  • ボート
  • 在庫の数量
  • 木箱につめたバナナ
  • バナナの輸送
  • 条件 {X, Y, Z} に基づく価格 X で 1000 箱のバナナを輸送する契約

このように、ありとあらゆるものが資産になります。知覚価値があり、当事者間で交換できるものであれば、それはすべて資産です。Perishable Goods ネットワークの場合、資産には、生鮮食料品自体と、生鮮食料品の輸送、取引の際に行われるさまざまなアクティビティーを規定する契約が含まれます。

参加者

「参加者」とは、ビジネス・ネットワークのメンバーを意味します。Perishable Goods ネットワークの場合、参加者に該当するのは、生鮮食料品を生産する生産者、生鮮食料品を生産者から港まで配送する輸送業者、生鮮食料品の配送を港で受け取る輸入業者です。明らかに、あまりにも単純化されたモデルですが、このモデルから、ビジネス・ネットワークの用語を使用して実際のアプリケーションをモデル化する方法を把握できるはずです。

アクセス制御

ビジネス・ネットワーク内では、すべての参加者がすべての要素にアクセスできるわけではありません。例えば、輸送業者と輸入業者との間で結ばれた契約に生産者がアクセスすることはできません。どの参加者がどの要素にアクセスできるか (そして、どのような条件でアクセスできるか) を制限するには、「アクセス制御」を使用します。

トランザクション

資産に「作用が働く」と、その相互作用によってブロックチェーン・レジャーの状態に影響が及ぶ可能性があります。このような相互作用を、Hyperledger Composer では「トランザクション」としてモデル化します。

Perishable Goods ネットワーク内でのトランザクションとしては、以下の例が挙げられます。

  • 輸送コンテナー内の IoT センサーによって温度測定値が記録される
  • 輸入業者が生鮮食料品の配送を受け取る
  • IoT GPS センサーによって輸送コンテナーの現在の位置が記録される

つまり、トランザクションは、システムのビジネス・ロジック (スマート・コントラクト) なのです。

イベント

「イベント」は、ブロックチェーン・アプリケーションによって生成されて、外部エンティティーによって使用される、パブリッシュ/サブスクライブ形式の通知です。

システム内で資産の取引が行われるとブロックチェーン・レジャーが更新されますが、この処理は内部 (システム) プロセスです。一方、レジャーの状態が変更された場合、あるいはそれとはまた別の注目すべきことがシステム内で行われた場合 (あるいは行われるべきことが行われなかった場合)、それを外部エンティティーに通知しなければならないことがあります。このような場合は、ブロックチェーン・アプリケーションでイベントを使用できます。

Perishable Goods ネットワーク内でのイベントとしては、以下の例が挙げられます。

  • 温度測定値が上限または下限を X 回超えた (このイベントは、例えば、輸送コンテナー自体の問題を示す可能性があります)。
  • 配送品が受領された
  • 配送品が港に到着した (例えば IoT GPS センサーからこのイベントが報告されることが考えられます)。

次のセクションでは、資産、参加者、トランザクションからなる Perishable Goods ネットワークをモデル化する方法を説明します。アクセス制御については触れるだけにとどめます。また、イベントについてはシリーズのパート 2 で取り上げます。

コンピューター上で Docker を使用して Playground を実行する

Playground の概要

Playground は、ブロックチェーン・ビジネス・ネットワークを迅速に構築してテストするための環境です。Playground を使用するのに実行中のブロックチェーン・ネットワークは必要ないことから、ネットワークを定義、検証、テストするという複雑さが軽減されます。

Playground は Docker コンテナー内で稼働するため、以下のいずれかのモードでコンピューターにインストールできます。

  • Hyperledger Fabric 検証ピア・ネットワークとの連動モード
  • ブラウザー専用モード

Hyperledger Fabric 検証ピア・ネットワークとの連動モード

このモードでは、Playground を Hyperledger Fabric 検証ピア・ネットワークと一緒にインストールし、Playground 用の Docker コンテナーの他に Hyperledger Fabric 検証ピア・ネットワークを実行するためのすべての Docker コンテナーを環境に組み込みます。

チュートリアルのパート 2、パート 3 に進むと、完全な Hyperledger Fabric 検証ピア・ネットワークが必要になってきますが、パート 1 ではどのアクティビティーも実行しないため、現段階で検証ピア・ネットワークを導入するのは、やり過ぎです。

ブラウザー専用モード

ブラウザー専用モードでは、ブラウザーのローカル・ストレージ内の疑似ブロックチェーン・レジャーを使用してビジネス・ネットワークをモデル化、テストすることができます。

パート 1 では、このモードを使用します。

Playground を実行する

ターミナル・ウィンドウ (Mac/Linux の場合) またはコマンド・プロンプト (Windows の場合) から、以下のコマンドを実行します。

                docker run --name composer-playground --publish 8080:8080 hyperledger/composer-playground

上記のコマンドによって Docker が対話モードで起動します。私がこのように Playground を実行する方法を選ぶのは、STDOUT に記録される出力を確認できるからです。

$ docker run --name composer-playground --publish 8080:8080 hyperledger/composer-playground
0|composer | PlaygroundAPI            :createServer()            > 8080
0|composer | ConnectionProfileManager :constructor()             Created a new ConnectionProfileManager {"fs":{"constants":{"O_RDONLY":0,"O_WRONLY":1,"O_RDWR":2,"S_IFMT":61440,"S_IFREG":32768,"S_IFDIR":16384,"S_IFCHR":8192,"S_IFBLK":24576,"S_IFIFO":4096,"S_IFLNK":40960,"S_IFSOCK":49152,"O_CREAT":64,"O_EXCL":128,"O_NOCTTY":256,"O_TRUNC":512,"O_APPEND":1024,"O_DIRECTORY":65536,"O_NOATIME":262144,"O_NOFOLLOW":131072,"O_SYNC":1052672,"O_DIRECT":16384,"O_NONBLOCK":2048,"S_IRWXU":448,"S_IRUSR":256,"S_IWUSR":128,"S_IXUSR":64,"S_IRWXG":56,"S_IRGRP":32,"S_IWGRP":16,"S_IXGRP":8,"S_IRWXO":7,"S_IROTH":4,"S_IWOTH":2,"S_IXOTH":1,"F_OK":0,"R_OK":4,"W_OK":2,"X_OK":1},"F_OK":0,"R_OK":4,"W_OK":2,"X_OK":1}}
0|composer | PlaygroundAPI            :createServer()            Playground API started on port 8080 
0|composer | PlaygroundAPI            :createServer()            < 
0|composer | Composer                 :main()                    >

Playground を分離して実行したい場合は、以下のように --detach を追加するだけで、分離モードで Playground を実行できます。

                docker run --name composer-playground --publish 8080:8080 --detach hyperledger/composer-playground

ブラウザーを開いて http://localhost:8080 にアクセスすると、図 1 に示すような画面が表示されます。

図 1. Playground のウェルカム画面
Hyperledger Composer Playground のウェルカム画面のスクリーンショット
Hyperledger Composer Playground のウェルカム画面のスクリーンショット

Playground を実行し終えたら、Ctrl+C を押して対話モードのコンテナーをキルします。分離モードで実行している場合は、以下のコマンドを実行します。

                docker stop composer-playground

Playground が停止したら、Docker コンテナーをクリーンアップします (こうしておかないと、次に実行しようとするときにエラーになります)。

                    docker rm --force composer-playground

動画: Playground を実行して UI を見て回る

この動画で、私が Docker を使用して Playground を実行する方法を実演し、皆さんを Playground の UI ツアーにご案内します。

Hyperledger Composer のモデリング言語

Hyperledger Composer を使用してブロックチェーン・ネットワークをテスト、デプロイするには、その前に、そのネットワークのモデルを作成しなければなりません。Hyperledger Composer には、ネットワークをモデル化するための固有のモデリング言語があります。

また別の言語を学ばなければならないことに苦痛を感じるかもしれませんが、ご安心ください。この CTO モデリング言語は至って単純です (さらに、オブジェクト指向の概念を扱ったことがあれば、直感的でもあります)。

CTO モデリング言語は (ビジネス・ネットワークをモデル化するための) 少数のキーワードを使用して的を絞っているため、学ばなければならないことはそれほど多くはありません。ビジネス・ネットワークのモデルは、ファイル拡張子 .cto が付いたファイルに格納されます。モデル内には以下の要素の定義が含まれます。

  • 名前空間
  • リソース
  • 他の名前空間からのインポート (必要な場合)

モデルのサイズがかなり大きい場合は、必要に応じて複数の .cto モデル・ファイルに分けることもできます。ただし、すべての .cto モデル・ファイル内に単一の名前空間と 1 つ以上のリソース定義が含まれることが要件となります。

名前空間

名前空間によって引かれる境界線内部では、名前は一意であると見なされます。すべての .cto モデル・ファイルには名前空間が必要です。つまり、.cto モデル・ファイル内のすべての名前は一意でなければならないことを意味します。

自分では気付いていないかもしれませんが、皆さんはすでに名前空間の概念に馴染みがあります。ファイル・システムではディレクトリーを名前空間として使用して、同じディレクトリー内の 2 つのファイルが同じ名前を持てないようになっています。ただし、それぞれ別のディレクトリー内にある 2 つのファイルは、異なる名前空間の中にあるので、同じ名前を持つことができます。

要するに、CTO モデル・ファイル (名前空間の境界) 内にある 2 つのリソースに同じ名前を付けることはできません。

リソース

リソースは以下のいずれかです。

  • 資産: ビジネス・ネットワークの資産
  • 参加者: ビジネス・ネットワークの参加者
  • トランザクション: ビジネス・ロジック
  • イベント: 興味の対象となる、システム内で起こっている事象の通知
  • 列挙型: 名前付き値のセット
  • 概念: 他のタイプには当てはまらない、モデル化対象のオブジェクト

それぞれのリソース・タイプは、同じ名前を持つモデル・タイプに対応します (例えば、資産をモデル化するには asset を使用し、参加者をモデル化するには participant を使用するなど)。

リソースには、以下のプロパティーがあります。

  • リソースが定義されている名前空間
  • 名前 (名前空間内で一意でなければなりません)
    • リソースが asset または participant の場合、identified で示した識別子フィールドの後に、フィールドの名前を続ける必要があります。
  • (任意) リソースの親タイプ (スーパー・タイプ)。該当する場合は、extends でこのプロパティーを示した後に、親タイプの名前を続けます。
  • (任意) abstract キーワード。リソースをインスタンス化せずに、同じタイプを持つ他のリソースのスーパー・タイプとして使用する場合は、このキーワードを指定します。

Perishable Goods ネットワークでは、Shipment 資産が以下に示すようにモデル化されます。

                /**
                  * A business network for shipping perishable goods
                  * The cargo is temperature controlled and contracts
                  * can be negociated based on the temperature
                  * readings received for the cargo
                  */
                namespace org.acme.shipping.perishable
                .
                .
                /**
                 * A shipment being tracked as an asset on the ledger
                 */
                asset Shipment identified by shipmentId {
                  o String shipmentId
                  o ProductType type
                  o ShipmentStatus status
                  o Long unitCount
                  o TemperatureReading[] temperatureReadings optional
                  --> Contract contract
                }

上記の例を見ていきましょう。ここには指摘すべき点がいくつかあります。

名前空間は org.acme.shipping.perishable です。

asset キーワードで Shipment が資産であることを示しています。shipmentId プロパティー (プロパティーは小文字の「o」で示されます) は String 型であり、(identified で示された) Shipment を識別します。

リソースのプロパティーにはそれぞれ型があります。型には、基本型 (String など)、列挙型 (ProductType など)、またはトランザクション (TemperatureReading の配列など) を使用できます。

Contract の参照 (参照は --> で示されます) は「関係」と呼ばれ、一方向でのみ適用されます (単向性)。

列挙型

所定のプロパティーに有効な値のセットがあらかじめわかっている場合は、そのセットを列挙型としてモデル化してください。このようにすると値を制約しやすくなるため、検証するのも簡単になります。

列挙型を宣言するには、以下のようにします。

               /**
                 * The type of perishable product being shipped
                 */
                enum ProductType {
                  o BANANAS
                  o APPLES
                  o PEARS
                  o PEACHES
                  o COFFEE
                }

概念

ビジネス・モデル内に存在するエンティティーが資産、参加者、トランザクション、イベントのいずれでもない場合は、そのエンティティーを「概念」としてモデル化します。

                /**
                 * A concept for a simple street address
                 */
                concept Address {
                  o String city optional
                  o String country
                  o String street optional
                  o String zip optional
                }

住所はビジネス・モデルに含まれる重要な概念の 1 つですが、他のどのカテゴリーにも当てはまりません。したがって、住所は概念としてモデル化します。

インポート

.cto モデル・ファイル内のインポートは、そのモデル・ファイル内のエンティティーと別のモデル・ファイル内のエンティティーとの関係を示すために使用します。

このチュートリアルで扱うモデルは極めて小さいものなので、ここではインポートについて詳しく説明しませんが、その概念は Java 言語での import、C++ での #include と同様です。

CTO 参照

いったん基本的な構文を理解すれば (ほとんどの場合、基本的な構文はコンテキストによって明確です)、モデリング言語を習得するのは簡単なはずです。オブジェクト指向の概念を扱ったことがあれば、なおさら簡単に習得できるでしょう。

この言語の詳細を知りたいとしたら、このリンク先のページに掲載されている CTP モデリング言語の完全な資料を読むことをお勧めします。

ビジネス・ネットワークをモデル化する

前にお見せした動画で、Playground を使用してビジネス・モデルを作成する方法を紹介しました。このセクションでは、Perishable Goods ネットワークを Playground 内でモデル化していきます (心配しないでください。組み込み perishable-network テンプレートの助けを借ります)。

ブラウザーの localhost ストレージを削除する

図 1 に示すようなウェルカム画面が表示されたら、この先のセクション「Playground 内で新規モデルを作成する」までスキップできます。

Hyperledger Composer では、ブラウザー専用モードで一度に処理できるモデルを 1 つに制限しています。すでに他のモデルがブラウザーにロードされている場合、ブラウザーのローカル・ストレージを削除するまでは別のモデルをロードできません。

Playground には現在のモデルを新しいモデルで置き換える機能があります。けれどもエラーが発生した場合、ブラウザーのローカル・ストレージを削除することで「ゼロから」始めることができます。削除する手順は、ブラウザーによって異なります。

例えば Chrome では、「Settings (設定)」 > 「Advanced (詳細設定)」 > 「Content Settings (コンテンツの設定)」 > 「Cookies」 > 「All cookies and site data (すべての Cookie とサイト・データを表示)」 > 「localhost」を表示して、ゴミ箱アイコンをクリックすれば、ローカル・ストレージを削除できます。別のブラウザーを使用している場合は、そのブラウザーに固有の手順に従ってローカル・ストレージ全体を削除してください。

Playground 内で新規モデルを作成する

Playground 内で新しい空のビジネス・ネットワークを作成する方法と、Playground 内をナビゲートする方法は、前の動画で紹介したので、ここで説明を繰り返すことはしません。動画を見る機会がなかったとしたら、動画を見てから、以下の手順に従ってください。

「Let's Blockchain (ブロックチェーンを開始)」ボタンをクリックして開始します (図 1 を参照)。次に、perishable-network テンプレートから新しいビジネス・ネットワークを作成します。perishable-iot-network という名前を付けて、「Deploy (デプロイ)」をクリックします。

「admin (管理者)」ID カード上にある「Connect now (今すぐ接続)」リンクをクリックします。図 2 のような画面が表示されるはずです。

図 2. Perishable Goods ネットワーク
Perishable Goods ネットワークを示すページのスクリーンショット
Perishable Goods ネットワークを示すページのスクリーンショット

「FILES (ファイル)」の下にある項目に注目してください。

  • README.md。この Markdown ファイルには、Perishable Goods ネットワークの概要が記載されています。
  • models/perishable.cto。ビジネス・モデルを格納するファイルです。
  • lib/logic.js。ビジネス・ロジック (スマート・コントラクト) を格納するファイルです。トランザクションの実装もここに格納されます。

「FILES (ファイル)」の下にある 4 つのファイルのいずれかを選択すると、そのファイルが右側のエディター・ウィンドウ内に開きます。モデルを格納するモデル・ファイル (perishable.cto) を開いてください。

Grower 資産は以下のようにモデル化されています。

                /**
                 * An abstract participant type in this business network
                 */
                abstract participant Business identified by email {
                  o String email
                  o Address address
                  o Double accountBalance
                }
                
                /**
                 * A Grower is a type of participant in the network
                 */
                participant Grower extends Business {
                }

Shipper は以下のようにモデル化されています。

                /**
                 * A Shipper is a type of participant in the network
                 */
                participant Shipper extends Business {
                }

Contract 資産のモデルは以下のとおりです。

                /**
                 * Defines a contract between a Grower and an Importer to ship using
                 * a Shipper, paying a set unit price. The unit price is multiplied by
                 * a penality factor proportional to the deviation from the min and max
                 * negociated temperatures for the shipment.
                 */
                asset Contract identified by contractId {
                  o String contractId
                  --> Grower grower
                  --> Shipper shipper
                  --> Importer importer
                  o DateTime arrivalDateTime
                  o Double unitPrice
                  o Double minTemperature
                  o Double maxTemperature
                  o Double minPenaltyFactor
                  o Double maxPenaltyFactor
                }

モデルに慣れ親しんで、エディター内でさまざまなリソースがどのように表示されるのかを理解してください。lib/logic.js についても同じ作業を繰り返して、JavaScript コードをよく理解してください。

モデルをインスタンス化する

画面の上部にある「Test (テスト)」タブをクリックすると、図 3 のような画面が表示されます。

図 3. perishable-network - 「Test (テスト)」タブ
perishable-network - 「Test (テスト)」タブのスクリーンショット
perishable-network - 「Test (テスト)」タブのスクリーンショット

モデルに含まれている資産と参加者は画面の左側に表示されていますが、画面の中央にはレジストリーが空であると伝えるメッセージが表示されています。どうなっているのでしょうか?

動画で説明したように、ビジネス・ネットワークが作成された時点では、資産レジストリーも参加者レジストリーも空の状態です。資産と参加者のインスタンスを作成すると、それらのインスタンスがレジストリー内に保管されます。

次のセクションで、モデルをインスタンス化してテストする方法を説明します。

ビジネス・ネットワークをテストする

構築しようとしているアプリケーションでは、モデルがある種のブループリントのような役割を果たしますが、モノのモデルとなると、(どこかの時点で) モデルが実際のモノにならなければ、それほど役立ちません。例えば、超高層ビルを建築しようとする場合はビルのブループリント一式が不可欠です。けれども、ある時点で実際のビルを建築するためにそれらのブループリントを使用するのでなければ、ブループリントを用意しても意味はありません!

話をビジネス・モデルに戻すと、モデルを有用なものにするためには、モデルをインスタンスにする必要があります。けれども、ブロックチェーン・アプリケーションにとって、モデルのインスタンス化とは何を意味するのでしょうか?

資産レジストリーと参加者レジストリー

Grower 参加者、Shipment 資産などのモデルはすでに記載しました。これから、これらのリソースをインスタンス化して、それぞれのレジストリー内に保管されるようにします。資産インスタンスは資産レジストリーに保管され、参加者インスタンスは参加者レジストリーに保管されます。

perishable-network モデルの lib/logic.js モジュール内に、setupDemo() という JavaScript 関数として実装されているトランザクションがあります。この関数を使用すると、モデルをインスタンス化して資産および参加者レジストリー内にエントリーを作成することができます。この関数は、手作業でモデルを入力するよりも短時間で、テンプレートからビジネス・ネットワークを稼働中にさせる手段として用意されています。

ここには setupDemo() 関数を記載しませんが、この関数が実行する 3 つの処理を指摘しておきます。

  1. モデルに含まれるすべての資産と参加者のインスタンスを作成する
  2. 作成したインスタンスにプロパティー値を設定する
  3. インスタンスをそれぞれ該当するレジストリー内に保管する

エディターで lib/logic.js ファイルを開いて、その内容を自分の目で確かめることをお勧めします。

モデルをインスタンス化する

SetupDemo トランザクションを実行するには、「Submit Transaction (トランザクションの送信)」ボタンをクリックします。これによって、図 4 に示すようなモーダル・ダイアログが表示されます。

図 4. トランザクションの送信 - SetupDemo
トランザクションの送信 - SetupDemo を示す画面のスクリーンショット
トランザクションの送信 - SetupDemo を示す画面のスクリーンショット

「Transaction Type (トランザクションのタイプ)」ドロップダウン内に SetupDemo が含まれていることを確認してから、「Submit (送信)」ボタンをクリックします。トランザクションが正常に実行されると、そのことを伝える簡潔な通知メッセージが表示されます。

左側の「ASSETS (資産)」ペインで「Grower」を選択すると、そのインスタンスが右側に表示されます (図 5 を参照)。他のリソースについても同じです (試してみてください)。

図 5. Grower 資産のインスタンス
Grower 資産のインスタンスを示す画面のスクリーンショット
Grower 資産のインスタンスを示す画面のスクリーンショット

ビジネス・ネットワークが定義され、資産と参加者がそれぞれのレジストリーに保管されました。これで、ネットワークのテストを開始できます。

トランザクションについて

このセクションではこれまでのところ、資産と参加者については説明しましたが、ビジネス・モデルに含まれるトランザクションについてはどうなっているのでしょうか?また、トランザクションはどこで目にすることができるのでしょうか?

最初の質問に対する答えとして、トランザクションはアプリケーションのビジネス・ロジック (スマート・コントラクト、またはチェーンコード) を表すものです。setupDemo() によって生成されるスマート・コントラクトが適用するビジネス・ロジックは、以下の契約条件を規定します。

  1. 輸送コンテナー内の温度が常に摂氏 6℃ に保たれること。輸送コンテナー内の温度が合意された範囲 (+/- 5℃) から外れると、範囲を下回った場合は 1℃ につきユニットあたり 0.20 ドル、範囲を上回った場合は 1℃ につきユニットあたり 0.10 ドルの割合で配送品 (単価 0.50 ドル) の価格が下げられる。
  2. 配送品の到着が遅れた場合、生産者に配送品に対する支払いはないこと。

次に、トランザクションはどこで目にすることができるのかと言うと、トランザクションは本質的にインスタンス化されません。インスタンス化されるのではなく、lib/logic.js 内の JavaScript コードとして姿を現します。

図 6 に、上記の契約から 2 番目の条項を適用するスマート・コントラクトのコード (lib/logic.js から抜粋) を記載します。

図 6. スマート・コントラクト: 配送遅延のペナルティー
スマート・コントラクト 配送遅延のペナルティーを示す画面のスクリーンショット
スマート・コントラクト 配送遅延のペナルティーを示す画面のスクリーンショット

アクセス制御について

アクセス制御は、モデルに含まれる permissions.acl という名前のファイルによって管理されます。「ビジネス・ネットワークの概念」のセクションで、主要な概念の 1 つとしてアクセス制御を紹介しました。この極めて重要なトピックについてはパート 2 とパート 3 で取り上げ、ブロックチェーン・アプリケーションに対するアクセスを制御する方法を詳しく説明します。

モデルの「Define (定義)」タブ内に表示される permissions.acl を見てみましょう。perishable-network テンプレートに含まれるアクセス制御 (ACL) ファイルは、以下のような内容になっています。

                /**
                 * Sample access control list.
                 */
                rule Default {
                    description: "Allow all participants access to all resources"
                    participant: "ANY"
                    operation: ALL
                    resource: "org.acme.shipping.perishable.*"
                    action: ALLOW
                }
                
                rule SystemACL {
                  description:  "System ACL to permit all access"
                  participant: "org.hyperledger.composer.system.Participant"
                  operation: ALL
                  resource: "org.hyperledger.composer.system.**"
                  action: ALLOW
                }

ACL ファイルに格納されるルールによって、ブロックチェーン・アプリケーション内のリソースに対するアクセスを制御することができます。あえて言うなら、セキュリティーに関しては Hyperledger Composer が引き受けてくれます。これについては、このチュートリアルの以降のパートで明らかにします。

現時点では、上記で定義されているアクセス制御ルールはかなり寛容にアクセスを許可しますが、Hyperledger Composer を使い始めたばかりなので、今のところはこのままにしておきます。

モデルをテストする

モデルがインスタンス化されたので、モデルのテストを開始します。つまり、コードを実行するということです。この例の場合、実行するコードは、lib/logic.js 内の JavaScript コードになります。

テストをセットアップする前に、スマート・コントラクト (setupDemo() 関数の中でインスタンス化されています) を調べて条件を確認しましょう。図 7 に、Contract 資産をインスタンス化するために使用される JavaScript コードを示します。

図 7. スマート・コントラクト: 契約条件
スマート・コントラクト: 契約条件を示す画面のスクリーンショット
スマート・コントラクト: 契約条件を示す画面のスクリーンショット

これで、スマート・コントラクトをテストする準備が整いました。ブラウザー内で稼働中の Playground で、Playground UI の上部にある「Test (テスト)」タブをクリックします。

以下のシナリオをテストしましょう。

  1. IoT 温度センサーから以下の測定値が送信される (数値は摂氏の温度です)。
    1. 5
    2. 7
    3. 1
    4. 4
  2. 配送品が受領される。

このシナリオのコンポーネントを 1 つずつ見ていきましょう。まずは、温度センサーのデータです。

実際のアプリケーションでは、IoT 温度センサーからこのデータが例えば IBM Cloud に送信されると、これらのトランザクションを記録するために、ブロックチェーンに対してスマート・コントラクト・コードが呼び出されます。

Playground では、ブロックチェーンがブラウザーのローカル・ストレージ内に維持されますが、ブロックチェーンがどこに置かれているかに関係なく、実行するトランザクション・コードは同じです (Playground がテストの場所として最適なのは、このためです)。

lib/logic.js 内の temperatureReading() 関数を見てください。

                /**
                 * A temperature reading has been received for a shipment
                 * @param {org.acme.shipping.perishable.TemperatureReading} temperatureReading - the TemperatureReading transaction
                 * @transaction
                 */
                function temperatureReading(temperatureReading) {
                
                    var shipment = temperatureReading.shipment;
                
                    console.log('Adding temperature ' + temperatureReading.centigrade + ' to shipment ' + shipment.$identifier);
                
                    if (shipment.temperatureReadings) {
                        shipment.temperatureReadings.push(temperatureReading);
                    } else {
                        shipment.temperatureReadings = [temperatureReading];
                    }
                
                    return getAssetRegistry('org.acme.shipping.perishable.Shipment')
                        .then(function (shipmentRegistry) {
                            // add the temp reading to the shipment
                            return shipmentRegistry.update(shipment);
                        });
                }

実際のアプリケーションでは、輸送コンテナー内の IoT センサーから測定値が送信される際は、そのセンサー・データは (輸送船のネットワークを介して) クラウドに送信されます。すると、例えば OpenWhisk 内で実行されるサーバーレス関数が、クラウド内でデータを取得して、temperatureReading() 関数を呼び出します。

この動作を Playground 内でシミュレーションするには、以下のようにします。

  1. 「Submit Transaction (トランザクションの送信)」ボタンをクリックします (setupDemo() 関数を呼び出したときと同じ操作です)。
  2. 「Transaction Type (トランザクションのタイプ)」ドロップダウン内に TemperatureReading が含まれていることを確認します。
  3. 「JSON Data Preview (JSON データのプレビュー)」ウィンドウで、「centigrade」の測定値を 0 から 5 (送信したい最初の測定値) に変更します。
  4. 配送品 ID が SHIP_001 に設定されていることを確認します。
  5. 「Submit (送信)」をクリックします。
  6. 残りの 3 つの測定値について、以上の手順を繰り返します。

実際のアプリケーションで配送品を受け取るには、輸送業者の携帯端末上で実行されているアプリケーションが、IBM Cloud 内で実行されているアプリケーション (または、OpenWhisk 内で実行されるサーバーレス関数) に配送品が受領されたことを伝えます。これによって生産者に支払う金額が計算されます。

Playground 内で配送品の受領をシミュレーションするには、Playground 内で ShipmentReceived トランザクションを実行し、配送品 ID が入力されていることを確認してから、「Submit (送信)」をクリックします。

動画: モデルをテストしてトランザクションを確認する

ここまで多岐にわたる内容を説明してきたのはわかっています。けれども、ご心配なく。この 2 番目の動画で、モデルをテストする方法を紹介し、実行するすべてのトランザクションの結果をブラウザーの JavaScript コンソール内で確認します。

モデルを処理する

素晴らしいブロックチェーン・ビジネス・モデルが完成しましたが、この後の段取りはどうなっているのでしょうか?

モデルをエクスポートする

例えば、チームの他のメンバーもモデルを使用できるようにするか、あるいは本番環境にある実際のブロックチェーンにデプロイするためにモデルをエクスポートする必要があるとします (デプロイ方法については、パート 2 で説明します)。

その場合、Playground に備わっているエクスポート機能を使用して、共有可能なビジネス・ネットワーク・アーカイブ (BNA) ファイルを作成します。モデルをエクスポートするには、「Define (タブ)」で、画面の左下にある「Export (エクスポート)」リンクをクリックします。すると、Playground によってビジネス・ネットワーク・アーカイブ (BNA) ファイルが生成されて、そのファイルがコンピューターにダウンロードされます。

モデルをインポートする

ビジネス・ネットワーク・アーカイブ (BNA) ファイルをチーム・メンバーから提供されており、Playground 内で処理する必要があるとします。

BNA ファイルを Playground に取り込むには、まず、Playground が稼働中であることを確認してから、「Define (定義)」タブで「Import/Replace (インポート/置換)」を選択します。表示される「Import/Replace Network (ネットワークのインポート/置換)」画面で「Drop here to upload or browse (ここにドロップしてアップロードするか、参照する)」をクリックし、参照ダイアログを使ってインポート対象の BNA を見つけて選択し、「Open (開く)」を選択します。次に、「Import (インポート)」をクリックし、現在のモデルを、インポートするモデルで置き換えることを確認します。

: BNA ファイルのインポートで問題が発生した場合は、ブラウザーのローカル・ストレージを消去してから、もう一度インポートを試してください。詳細については、このチュートリアルのセクション「ブラウザーの localhost ストレージを削除する」で説明しています。

パート 1 のまとめ

このチュートリアル・シリーズのパート 1 では、Docker を使用して Playground を実行する方法を説明し、Hyperledger Composer モデリング言語 (CTO) の基礎を紹介しました。また、Playground Docker イメージによって提供される perishable-network テンプレートをベースに新しいビジネス・ネットワークを作成し、Playground 内で単純なビジネス・ネットワーク・モデルがどのような内容になっているのかを確認しました。

これに続き、この単純なモデルをテストするために、さまざまな温度測定値のトランザクションをブロックチェーンに保管してモデルをテストする方法を説明しました。また、配送品の受領時に、スマート・コントラクトがトランザクションを使用して契約条件に基づく決定を下す仕組みも説明しました。

最後に、同僚や他のメンバーとモデルを共有するために、Playground からモデルをエクスポートする方法、Playground にモデルをインポートする方法を説明しました。

次はパート 2 に進んで、このパートで作成したビジネス・ネットワークを基に、既存のビジネス・ネットワークを改良する方法、改良したビジネス・ネットワークの単体テストを行ってから IBM Cloud にデプロイする方法を学んでください。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Internet of Things, Cloud computing
ArticleID=1062224
ArticleTitle=Hyperledger Composer の基礎, パート 1: ブロックチェーン・ネットワークをモデル化してテストする
publish-date=07262018