ブロックチェーン開発のプラットフォーム選択とサンプルアーキテクチャ

目次

  • 前提
  • 利用者側のメリット
  • 主要なプラットフォーム
  • プラットフォームを選択する際のポイント
  • ユースケース別のサンプルアーキテクチャ
  • 総論

前提

本レポートでは企業がブロックチェーンを利用したアプリケーションやシステムを開発する際に利用するプラットフォームの選択肢といくつかのユースケースでのサンプルアーキテクチャについて紹介します。
まず、オンプレミスとクラウドのどちらを選択するかですが、要件として問題がなければクラウドを利用するのがお勧めです。オンプレミスとはシステムを構成するハードウェアも含めて自社内に設置して運用する形態を指します。一方で、クラウドは大手IT企業がサーバーやストレージ、ネットワークを運用し、利用者は必要に応じてリソースを使用し、従量課金で支払いをする形態を指します。
近年、クラウドで簡単にブロックチェーンを利用することができるBlockchain as a Service(BaaS)を提供する事業者が増えています。特にMicrosoft、Amazon、IBMなどの大手IT企業がなぜBaaSを提供しているのかについては下記の過去レポートでも考察しています。
BaaS(Blockchain as a Service)の概観および なぜMicrosoftやAmazon、IBMなどはBaaSに積極的なのか
https://hashhub-research.com/articles/2020-02-17-baas-overview

利用者側のメリット

ブロックチェーンの実ビジネスでの利用は急速に拡大しており、世界中の企業や組織が、サプライチェーン、金融、ヘルスケア、リテールなどの分野でブロックチェーンを利用したソリューションに取り組んでいます。しかし、こうしたソリューションを構築するためにはブロックチェーン開発者を採用または育成するコストやノード運用のコストなどがかかります。企業にとって、クラウドで提供されるBaaSなどのサービスを利用することは、下記のようなメリットがあります。
  • ブロックチェーンの迅速な導入
    クラウドサービスを利用することで、構成済みのブロックチェーン基盤をすぐに作成して、アプリケーションやソリューションの開発を始めることができます。また、サービスによってはアプリケーションやソリューションも、サンプルやテンプレートとして用意されている場合があり、ユーザー企業は要件に合わせたカスタマイズをするだけで利用を開始することができます。
  • 低コストでの利用開始
    ハードウェアを調達してブロックチェーン基盤を自社で構築したり、熟練したブロックチェーン開発者を採用したりせずとも低コストでアプリケーションやソリューションの構築を始めることができます。また、万が一方向転換したりプロジェクトを途中で断念したとしても、従量課金で利用した分のみベンダーに支払うだけで済みます。

主要なプラットフォーム

Microsoft Azure

Amazon Web Service

  • Amazon Managed Blockchain
    https://aws.amazon.com/jp/managed-blockchain/
    Amazon Managed Blockchainは、Amazon Web Serviceが提供するBaaSのマネージドサービスで、Hyperledger Fabricをサポートしています。また、2020年12月21日にプレビューでEthereumのパブリックチェーンのサポートも開始されました。
  • Amazon Quantum Ledger Database(QLDB)
    https://aws.amazon.com/jp/qldb/
    Amazon Quantum Ledger Databaseは、Amazon Web Serviceが提供する中央集権的な台帳データベースのマネージドサービスです。データの履歴は不変で暗号学的に検証が可能になっており、企業の経済活動や財務活動の履歴を記録するために使用できます。

IBM Cloud

他にもOracle、Hewlett Packard Enterprise、SAP、AlibabaなどがBaaSなどのプラットフォームを提供しています。

プラットフォームを選択する際のポイント

このように様々な事業者がBaaSなどのプラットフォームを提供していますが、利用者側としてはどのようにしてプラットフォームを選択すれば良いのでしょうか?以下にいくつかポイントを挙げてみます。
  • サポートしているブロックチェーン
    それぞれのBaaSやプラットフォームがサポートしているブロックチェーンは異なるため、使用したいブロックチェーンをサポートしているプラットフォームがまず選択候補となるでしょう(どのブロックチェーンを選択するかは難しい問題で、かつ重要なポイントですが、これについて本レポートでは詳しく述べません)。
  • バージョン対応、アップデートの早さ
    使いたいバージョンが利用可能かどうかも重要です。例えば、BaaSによってはHyperledger Fabricのバージョン1系に対応しているが、バージョン2系は未対応というケースがあります。また脆弱性が発見された場合にアップデートまでの時間がどれくらいかかるのか事前に確認できると良いでしょう。
  • プロジェクトチームのスキルセットとの親和性
    自社プロジェクトチームの開発者やインフラ担当者などが精通しているクラウドサービスを使用すれば、学習のための時間を節約することができるでしょう。もしくは、短時間で習熟できるような使いやすいプラットフォームが選択候補となるでしょう。
  • 自社システムとの統合の容易さ
    企業がブロックチェーンを導入する場合、ブロックチェーンアプリケーションを単体で運用するケースは少なく、販売管理システム、購買管理システム、物流管理システム、会計システム、ID管理基盤などの既存システムとの統合が必要なケースが多いはずです。システムを統合するためのAPIやService Bus/Message Queue(MQ)、ID連携のような仕組みが組み込まれていたり、容易に実装できるような支援機能が用意されていたりすると開発期間の短縮や開発コストの低減に役立つでしょう。
  • セキュリティ
    ブロックチェーンのトランザクションに署名するための秘密鍵の安全な管理や、コンソーシアム参加者の認証認可など、ブロックチェーンのセキュリティは重要です。
  • 価格
    もちろん、コストもプラットフォームを選択する上で重要なポイントとなります。本番稼働時の構成も考慮した上で、どれくらいのコストがかかるか料金体系などを把握しておくと良いでしょう。
  • どのようなサポートが受けられるか
    利用しようとしているプラットフォームで、どのようなサポートが受けられるか事前に確認しておくことも重要です。サービスによってはプレビュー版のため正式なサポートが受けられない場合もあります。その場合でもどのレベルまでのサポート(技術支援)が受けられるのか、プラットフォームを提供する事業者に確認しておくのが良いでしょう。
例えば、筆者の場合であれば、Microsoft AzureとAmazon Web Serviceでの開発経験とEthereumおよびQuorumでSolidity言語を使用した開発経験があることから、コンソーシアム型のブロックチェーン開発であればMicrosoft Azureが現時点で候補に挙がりやすく、次で紹介するサンプルアーキテクチャもMicrosoft Azureを使用した構成となっています。もちろん、これは他の開発メンバーの構成や開発するアプリケーションの要件によっても左右されます。

ユースケース別のサンプルアーキテクチャ

サプライチェーンのトラッキング

ブロックチェーンを利用してサプライチェーンのトラッキングを行うユースケースを見てみましょう。ここではコーヒー豆のサプライチェーンを例示していますが、他の農産物や工業製品のサプライチェーンでも同じようにトラッキングができるでしょう。
サプライチェーンの各ステップは下記のようになります。
  1. 農家はオーガニックとフェアトレードの認証を取得するために、特定の条件の下でコーヒー豆を生産する
  2. 輸送業者はコーヒー豆を農家から製造業者へ輸送する
  3. 製造業者はコーヒーの処理と袋詰めを行う
  4. 流通業者は高い品質保証ルールの下、流通網を通じて小売業者へ配送する
  5. コーヒーの袋は今までの過程を記録された状態で小売業者へ届く
  6. 消費者はQRコードなどを利用して原産地や品質の詳細などを確認できる
これらの過程の記録は、様々な時点でIoTデバイスによるブロックチェーン上の状態変更や、必要に応じて状態参照の処理が行われます。
オーガニック認証やフェアトレード認証では農家、輸送業者、製造業者・食品加工業者、小売業者などの関係者それぞれが認証基準を満たしている必要があります。また、フェアトレード認証などはそもそもトレーサビリティの確保が認証の基準として要求されています。品目によっては品質を保証するために輸送中の温度や湿度を記録しておく、といった対応を行う必要もあるでしょう。

サンプルアーキテクチャ

下記の図はサプライチェーンのトラッキングシステムをAzureで構築する場合のサンプルアーキテクチャになります。このアーキテクチャのベースはAzure Blockchain Workbenchで作成することが可能です。
参考:Microsoft のブロックチェーンに対する取り組みとサービス全体像の概観②
https://hashhub-research.com/articles/2020-10-21-microsoft-blockchain-services-02
  • サプライチェーン上の過程でIoTデバイスから送信されたメッセージをIoT Hubが受け取り、非同期処理でメッセージ変換とトランザクション発行を実行して、ブロックチェーン上にトラッキング情報を記録します。
  • トランザクションに署名を行う秘密鍵はKey Vault(鍵管理サービス)で安全に管理します。
  • 業務システムからデータの更新を行う場合は、更新系API経由で非同期処理を行いブロックチェーン上で記録・更新を行います。参照する場合は参照系API経由でブロックチェーン上の状態や、データベース上の情報を参照します。
  • ブロックチェーン上でトランザクションが発行されてトラッキング情報などが記録された場合、DLT Watcher経由でイベントが処理され、メール通知やデータベースの情報を更新します。
  • クライアント端末からは、Webアプリケーション経由でデータベース上のトラッキング情報を参照することができます。
  • ビジネスインテリジェンスツールであるPower BIを使用して、データベース上の情報を可視化したり、分析したりすることができます。
  • 上記の図では省略していますが、ブロックチェーンにトラッキング情報を書き込んだ後に、連携が必要な業務システムのデータを更新することも可能です。関連システムとの連携については、下記の手段から要件にあった手段を選択することができます。
    • Service Busを使用したメッセージング
    • Functionsを使用して関連システムのAPIに更新リクエストを送信
    • Logic Appsを使用して連携処理を実施
また、現実世界の物体とブロックチェーン上のデジタルデータとの紐付けを工夫する必要がありますが、似たような仕組みで真贋証明のユースケースなども対応することができるでしょう。

リワードプログラム

航空会社のマイレージのようなリワードプログラムのユースケースを見てみましょう。単独の企業ではなく、複数の企業が参加するリワードプログラムでは、組織の壁を超えて真正性のあるデータを迅速に共有することが可能となります。
リワードプログラムの流れは下記のようになります。
  1. 顧客はアプリからリワードプログラムの参加申し込みを行い、 航空券を購入する
  2. 航空会社はフライトの距離をポイントに換算し、顧客へリワードとして提供する
  3. 顧客はデジタルウォレットで貯めたポイントを確認できる
  4. 顧客はリワードプログラムの加盟店でポイントと引き換えに商品やサービスを受け取ることができる
  5. 加盟店は支払いに利用されたポイントに応じて、航空会社から収益を得る

サンプルアーキテクチャ

下記の図はリワードプログラムをAzureで構築する場合のサンプルアーキテクチャになります。
  • Webサイトでリワードプログラムの申し込みを行うと、API経由で非同期処理を行いブロックチェーン上でコントラクトを作成します。また、加盟店でポイントを利用した際には、API経由で非同期処理を行いブロックチェーン上のコントラクトの状態を更新します。
  • トランザクションに署名を行う秘密鍵はKey Vault(鍵管理サービス)で安全に管理します。
  • 業務システムからデータの更新を行う場合は、更新系API経由で非同期処理を行いブロックチェーン上で記録・更新を行います。参照する場合は参照系API経由でブロックチェーン上の状態や、データベース上の情報を参照します。
  • ブロックチェーン上でトランザクションが発行されてコントラクトが作成されたり、コントラクトの状態が更新されたりした場合には、DLT Watcher経由でイベントが処理され、メール通知やデータベースの情報を更新します。
  • クライアント端末からは、Webアプリケーション経由でデータベース上のポイント残高を参照することができます。
  • ビジネスインテリジェンスツールであるPower BIを使用して、データベース上の情報を可視化したり、分析したりすることができます。
  • 上記の図では省略していますが、ブロックチェーン上でコントラクトが作成されたり、コントラクトの状態が更新されたりした後に、連携が必要な業務システムのデータを更新することも可能です。関連システムとの連携については、下記の手段から要件にあった手段を選択することができます。
    • Service Busを使用したメッセージング
    • Functionsを使用して関連システムのAPIに更新リクエストを送信
    • Logic Appsを使用して連携処理を実施

企業間決済システム

企業間決済のユースケースを見てみましょう。下記の図では、会計業務の効率化として一定期間内に発生した互いの債権・債務を相殺して差額を決済するネッティングを例示しています。
企業間決済の流れは下記のようになります。
  1. 企業間決済システムに参加している企業同士で取引が発生すると、債権債務をブロックチェーンに記録
  2. 互いの取引で一定期間内に発生した債権債務を相殺
  3. 差額を銀行経由で振り込み

サンプルアーキテクチャ

下記の図は企業間決済システムをAzureで構築する場合のサンプルアーキテクチャになります。
  • 会計システムで債権債務が記録されると、API経由で非同期処理を行いブロックチェーン上にも記録します。
  • トランザクションに署名を行う秘密鍵はKey Vault(鍵管理サービス)で安全に管理します。
  • 会計システムからブロックチェーン上のデータを参照する場合は、参照系API経由でブロックチェーン上の状態や、データベース上の情報を参照します。
  • ブロックチェーン上でトランザクションが発行されてコントラクトが作成されたり、コントラクトの状態が更新されたりした場合には、DLT Watcher経由でイベントが処理され、メール通知やデータベースの情報を更新します。
  • クライアント端末からは、Webアプリケーション経由でデータベース上の債権債務を参照したり、ネッティングによる決済を実行したりすることができます。
  • ビジネスインテリジェンスツールであるPower BIを使用して、データベース上の情報を可視化したり、分析したりすることができます。
  • 上記の図では省略していますが、ブロックチェーン上でコントラクトが作成されたり、コントラクトの状態が更新されたりした後に、連携が必要な業務システムのデータを更新することも可能です。関連システムとの連携については、下記の手段から要件にあった手段を選択することができます。
    • Service Busを使用したメッセージング
    • Functionsを使用して関連システムのAPIに更新リクエストを送信
    • Logic Appsを使用して連携処理を実施

デジタルコンテンツの著作権とロイヤリティ管理

デジタルコンテンツの著作権とロイヤリティ管理のユースケースを見てみましょう。ゲームのようなデジタルコンテンツは、クリエイター(映像や音楽)、開発者、マーケティング会社、販売会社など関係者が多く、ロイヤリティ計算も煩雑になりがちです。ブロックチェーン上で著作権や契約情報、販売情報を共有し、ロイヤリティ計算と支払いのプロセスを自動化することで、コストの削減やビジネスのスピードアップが期待できます。

サンプルアーキテクチャ

下記の図はデジタルコンテンツの著作権とロイヤリティ管理のシステムをAzureで構築する場合のサンプルアーキテクチャになります。
  • 著作権や契約書が登録されると、API経由で非同期処理を行いブロックチェーン上にも記録します。
  • 業務システムで販売情報や、ロイヤリティの支払いが更新された場合は、更新系API経由で非同期処理を行いブロックチェーン上で記録・更新を行います。
  • トランザクションに署名を行う秘密鍵はKey Vault(鍵管理サービス)で安全に管理します。
  • 業務システムからブロックチェーン上のデータを参照する場合は、参照系API経由でブロックチェーン上の状態や、データベース上の情報を参照します。
  • ブロックチェーン上でトランザクションが発行されてコントラクトが作成されたり、コントラクトの状態が更新されたりした場合には、DLT Watcher経由でイベントが処理され、データベースの情報を更新します。
  • また、上記のブロックチェーン上のイベントを元に業務システムのAPIに更新リクエストを送信し、業務システム側で支払い処理を実行します。
  • クライアント端末からは、Webアプリケーション経由でデータベース上の著作権情報、契約情報、販売情報、ロイヤリティ支払いの情報などを参照します。
  • ビジネスインテリジェンスツールであるPower BIを使用して、データベース上の情報を可視化したり、分析したりすることができます。

総論

本レポートでは企業がブロックチェーンを利用したアプリケーションやシステムを開発する際に利用するプラットフォームの選択肢といくつかのユースケースでのサンプルアーキテクチャについて紹介しました。ブロックチェーンのプラットフォームも進化し続けているため、プラットフォーム選択時には必ず最新情報をチェックすることをお勧めします。また、ユースケース別のサンプルアーキテクチャを見ていただければ分かりますが、ベースとなる部分は似たような構成になりやすいので、紹介していないユースケースの場合でもある程度参考になるかと思います。

タグ