3. ユースケース例¶

Hyperledger Irohaで運用・導入できる多くのユースケース例と具体的な利点を挙げています。 Hyperledger Irohaを使用したこれらのアプリケーションやユースケース例が、開発者やクリエイターによってさらに革新させられることを願っています。

3.1. 教育やヘルスケア分野における証書¶

ハイパーレジャーいろは（Hyperledger Iroha）は、大学、学校、医療機関などさまざまな認証を必要とする機関のシステムへ組み込むことができます。 Hyperledger Irohaで用いられる柔軟な権限モデルによって、アイデンティティ認証や証書作成、証明書の付与が可能になります。ユーザーアカウントに明示的および暗黙的な情報を格納することにより、さまざまな評判・信用およびIDシステムを構築することができます。

Hyperledger Irohaを使用することにより、各教育機関または医療証明書が、特定の認証機関によって発行されたということを確認することができます。データの不変性と明確な検証規則によって、偽の証明書の使用を大幅に減らし、健康と教育分野へ透明性を提供します

3.1.1. 例¶

例えば、Hyperledger Iroha上に「病院」ドメインとして登録された医療機関を想像してみてください。このドメインには、認定され登録された従業員がいます。医師、療法士、看護師など、それぞれがそれぞれの役割を持っています。病院の各患者はそれぞれのアカウントを保有しており、それらに過去のすべての病歴が記載されています。各医療記録は、血液検査結果のように、JSON key/valuesとして各患者の口座に安全かつ機密的に保管されます。「病院」ドメインのルールは、認定された医療従事者とユーザーだけが個人情報にアクセスできるように定義されています。クエリによって返された医療データは、信頼できるソースから取得されたものであるのかが確認されます。

病院は、例えば特定の地域内でにのみ個人情報を保存するといったように、その場所における個人情報保護に関する法的規則に従って、特定の場所に結ばれます（「プライバシー規則」_）。 Hyperledger Irohaのマルチドメインアプローチでは、法的ルールに違反を犯さずに複数の国々間での情報共有を可能にします。例えば、 "makoto @ hospital"というユーザが他の国の医療機関と個人の病歴を共有することを決定した場合、ユーザは `` can_get_my_acc_detail``で許可した上で `` grant``コマンドを使用して行うことができます。

医療機関でのケースと同様に、Hyperledger Irohaに登録された大学機関には、卒業生に情報を送信・公開する権限を持つことができます。卒業証書または証明書は、いわば認定された大学の署名付きの卒業証明です。こうした方法を利用すると、採用プロセスを簡素化するのにも役立ち、例えば雇用主は採用候補者がこれまで獲得したスキルや能力に関する情報を得るためにHyperledger Irohaに問い合わせを行います。

3.2. 国際間の資産移転（授受）¶

Hyperledger Irohaは、マルチサインアカウントとアトミックエクスチェンジ機能を用いて、迅速かつ明確な取引環境、および決済規則を提供します。資産管理においては、中央集中的に管理されたシステムのように簡単で、必要なセキュリティ保証を提供します。資産の作成や移転に必要なルールとコマンドを簡素化することで、システム内への侵入障壁を低く抑え、同時に高いセキュリティ水準を保証、維持します。

3.2.1. 例¶

たとえば[＃f1] _のように、あるユーザーは車の所有権を譲渡したいという場合があるかもしれません。ユーザーの``haruto``は``sora``というブランド名の車（資産）に対する所有権が登録されています。関連するパラメーターはそれぞれ、 {"id": "34322069732074686520616E73776572", "color": "red", "size": "small"}``です。この所有権は、システムの基盤となるデータベースに固定的に記録されており、各々の検証ピアにその写しが記録されています。資産の移転を行うために、ユーザー``haruto``は、別のユーザー``haru``宛てにオファーを行います。つまり``haru``宛てに車の識別子を「転送」するのと、 haru``から `` haruto``へ `` usd``のトークンを「転送」するという2つのコマンドが含まれた複数署名トランザクションを生成します。``haru``はマルチ署名トランザクションに署名することで``haruto``からのオファーを受け取ります。この場合、このトランザクションはシステム内でコミットされます（アトミックエクスチェンジ機能）。

Hypeledger Iroha自体にトークンは組み込まれていませんが、さまざまな資産とそれらを保有するクリエイターのタイプを扱うことができます。こうしたアプローチによって、分散型の交換市場を構築することが可能になります。例えば、このシステム上で異なる国における中央銀行がそれぞれの資産を発行するといったことができます。

[1]	現段階では実装されていません

3.3. 金融業務におけるアプリケーション¶

Hyperleger Irohaは、監査業務で非常に役立ちます。各情報はそれぞれのビジネスルールによって検証され、異なるネットワーク参加者によって常時管理されます。いくつかの暗号化機能と共に、アクセス制御に関するルールによって所望のプライバシーが維持されます。アクセス制御ルールは、ユーザーレベル、ドメインレベルまたはシステムレベルといった異なるレベルで定義することができます。ユーザーレベルでは、特定個人向けのプライバシールールが定義されています。ドメインまたはシステムレベルでのアクセスルールが定義されると、ドメイン内のすべてのユーザーにそれらが適用されます。 Hyperledger Irohaでは、各役割ごとに特定の権限が付与されるといった役割ベースの便利なアクセス制御ルールが提供されています。

トランザクションは、ローカルデータベースを使用して追跡できます。 Iroha-API Auditorを使用すると、データに対してクエリを実行し、分析を実行し、特定の監査ソフトウェアの機能を行うことができます。 Hyperledger Iroha（いろは）は、分析ソフトウェアを展開する上でさまざまなシナリオをサポートしています。ローカルコンピュータ上での実行や、特定のミドルウェアでコードを実行することもできます。こうしたアプローチにより、HadoopやApacheなどのビッグデータアプリケーション分析を行うことができます。 Hypeledger Irohaは、データの完全性と機密性を保証する役割を果たします（クエリ権限の制限による）。

3.3.1. 例¶

たとえば、監査は金融アプリケーションにおいて役立つかもしれません。監査役アカウントは、ユーザーを悩ますことなく、ドメイン内のユーザー関連情報にアクセスする権限を有する「監査役」の役割を担います。アカウントハイジャックの確率を減らし、監査人が悪意のあるクエリを送信するのを防ぐため、監査人は通常、複数署名アカウントとして定義されます。つまり、監査人は複数の異なるIDからの署名を持つクエリのみを作成することができます。監査人は、口座データおよび残高情報を取得するだけでなく、ユーザーの全取引情報も取得できます（例えば、ドメイン "konoha"内のユーザー "haruto"が行ったすべての移転取引といった具合）。イロハの各ノードは、分析ソフトウェアと連携して100万ユーザーのデータを効率的に分析することができます。

複数署名取引は、Hyperledger Irohaの強力なツールであり、既存の税制を混乱させる可能性があります。特定のドメイン内の各トランザクションは、ユーザーからの署名（例えば、資産の譲渡の際）と課税権限を有する特殊なノード（課税ノード）からの第2署名を含んだマルチ署名トランザクションとして扱うことができます。課税ノードには、Iroha-APIを使用して書かれた特別な検証ルールが規定されています。例えば、商品売上の際に加盟店は税金を支払わなければならないようにするといった事案です。つまり、有効とみなされる購入取引には、店舗への送金（商品購入）と政府への送金（納税）の2つのコマンドが含まれている必要があります。

3.4. アイデンティティマネジメント¶

Hyperledger Irohaには、ID管理のための本質的なサポートがあります。システム内の各ユーザーは、個人情報が関連づけられ、かつ一意に識別されたアカウントを保有し、各取引はその都度署名され、特定のユーザーに関連付けられます。こうすることで、Hyperledger IrohaはKYC（本人確認）機能を持つさまざまなアプリケーションに最適なソリューションを提供します。

3.4.1. 例¶

例えば、保険会社におけるユースケースでは、取得情報の真実性を心配することなく、ユーザーの取引情報を照会するといった便利なことが可能になります。一方ユーザーは、認証された個人情報をブロックチェーンに登録しておくことで、保険請求処理に要する時間を短縮されるといった便益を享受することができます。ユーザーがローンを組みたいといった状況を想像してみてください。現在のローン事前審査は、収入や借入状況の収集およびそれらの情報検証に多大な時間がかけられています。 Hyperledger Irohaの各ユーザーは、保有資産、職位、債務状況などの認証済み個人情報が関連づけられたアカウントを保有しています。ユーザーの所得や借入状況と言いた情報は、 `` GetAccountTransactions`のクエリーを使用して、保有資産は `` GetAccountAssets``のクエリーで、ユーザーの職位に関すること情報は`` GetAccountDetail``を使用して追跡・管理することができます。各クエリは検証済みの情報を返すため、ローン審査に要する処理時間が劇的に短縮されます。個人情報を共有するようユーザーにインセンティブを与えるために、さまざまな企業がそれぞれのビジネスプロセスを考え出すことができます。例えば、保険会社はフィットネスを行っているユーザーに対してボーナス割引を適用することができます。フィットネスアプリケーションは、個人の活動証明をシステムにプッシュすることができます。ユーザーは事後的に、 `` can_get_my_acc_detail``で情報共有許可を与え、 `` GrantPermission``で保険会社と情報を共有することができます。

3.5. サプライチェーン¶

分散システムのガバナンスと法規制をシステムコードとして規定することは、あらゆるサプライチェーンシステムにおいて不可欠な組み合わせです。 Hyperledger Irohaで使用される認証システムでは、物理的なアイテムのトークン化とそれらのシステムへの埋め込みが可能です。各項目には「何を、いつ、どこで、なぜ」といった関連情報が付けられています。

許可システムと安全かつその数が制限された主要なコマンド群は、攻撃ベクトルを狭め、基本的なプライバシーを提供します。各トランザクションはハッシュ値を持ち、作成者の証明書または証明書によってシステム内で追跡できます。

3.5.1. 例¶

食品分野におけるサプライチェーンは、農家、食品倉庫、食料品店、顧客など、複数の異なる人たちが共有するシステムです。その最終的な目標は、農家の畑から顧客のテーブルに食品を配達することです。製品は多くの段階を経て、各段階において共有空間に記録されます。顧客は、モバイルデバイスを介してイロハクエリが埋め込まれた製品コードを読み取ります。コードに含まれるイロハのクエリ情報によって、全段階、製品情報そして農家に関する情報を含む全履歴が提供されます。

例えば、「gangreen」は登録農家のひとつで、「トマト」という資産の生産者であり、イロハシステム内での「トマト」という項目情報と実際のトマトを関連付ける、言い換えれば、物理的な品物をトークン化する保証人です。資産の新規作成と配布に関わるプロセスは、ネットワーク参加者にとって完全な透明性が実現されます。こうして、イロハ上の「トマト」は多数のベンダーを通る旅に出て、ついに一人のユーザー「チャド」に届けられます。

いろはでは、複雑なスマートコントラクトを作成せずに、新たなアセットの作成を「CreateAsset」という単一のコマンドによって集約し、単純化しました。 Hyperledger Irohaの主な利点の1つは、開発者がアプリケーションを提供することで生まれる価値に集中できるようになることです。

3.6. Fund Management¶

With the support of multisignature transactions it is possible to maintain a fund by many managers. In that scheme investment can only be made after the confirmation of the quorum participants.

3.6.1. 例¶

The fund assets should be held at one account. Its signatories should be fund managers, who are dealing with investments and portfolio distributions. That can be added via AddSignatory command. All of the assets should be held within one account, which signatories represent the fund managers. Thus the concrete exchanges can be performed with the multisignature transaction so that everyone will decide on a particular financial decision. The one may confirm a deal by sending the original transaction and one of managers' signature. Iroha will maintain the transaction sending so that the deal will not be completed until it receives the required number of confirmation, which is parametrized with the transaction quorum parameter.