ブロックチェーンとビッグデータの医療データ活用

ブロックチェーン技術はビットコインだけでなく、金融、会計、サプライチェーン、物流、保険など、さまざまな業界に浸透しています。例えば、金融機関は証券決済を数日ではなく数分で行うことができます。製造業者（OEM）や規制当局など、より速く、より少ないリスクで、商品や支払関連業務のようなセクションを効果的に管理することができます。

ビジネスにおけるブロックチェーンの採用には、上記のように多くの理由があります。ハイパーレッジャー・ファブリックとビッグチェーンDBは、ブロックチェーンのビジネスプロセスで最も広く使われているフレームワークです。

現在、ビジネス プロセスは単にデータを生成するだけではなく、多種多様で膨大な量のデータを驚異的な速度で生成します。このような種類のデータをブロックチェーンに配置した後、これらのデータを効率的な方法で処理および分析することが非常に重要です。

処理と分析の効率を高め、多数の機能を提供するには、Hadoop が古典的なエコシステムになります。 Hadoop プラットフォームには、これらのデータを分析および処理するための多くのビジネス ロジックが存在します。だからこそ、ブロックチェーンのスケーラブルなフレームワークが Hadoop エコシステムとともに存在すれば、業界はブロックチェーン技術を採用することがはるかに容易になるでしょう。この目的に向けて、HBase チェーン DB は、Hadoop エコシステムにスケーラブルなブラック チェーン フレームワークを提供するための第一歩です。 HBase チェーン DB は、EMI 基盤のハイパフォーマンス コンピューティングとデータ グループによって開始されます。これは、不変性と分散化というブロックチェーンの特性を HBase データベースにインポートすることで実現されます。

私たちのEMI基盤は、スケーラブルなフレームワークプロトコルを導入し、コンセンサスの促進に焦点を当てたアプローチを採用しています。分散型データベースであるMongoDBから始まり、デジタル資産の作成と移動をサポートしながら、分散制御、不変性というブロックチェーンの特徴を追加し、スケーラブルな分散型データベースであるBigChainDBを提供します。

このスケーラビリティを可能にするBigchainDBの大きな貢献は、ブロックチェーンパイプライニングの概念で あります。ブロックチェーンのパイプライン化では、現在のブロックが他のノードによって合意されるのを待たずにブロックがブロックチェーンに追加さ れます。コンセンサスは基礎となるデータベースが担当します。ブロックの検証はブロックの追加中に行われるのではなく、最終的にはノード間の投票プロセスによって行われます。これには大きなパフォーマンス向上があり、BigchainDBは毎秒100万トランザクションを超えるトランザクション・スループットと秒以下のレイテンシーを実現しています。

このスケーラビリティを可能にする BigchainDB の主な貢献は、ブロックチェーン パイプラインの概念です。ブロックチェーン パイプラインでは、現在のブロックが他のノードによって合意されるのを待たずに、ブロックがブロックチェーンに追加されます。コンセンサス メカニズムは、基礎となるデータベースによって処理されます。ブロックの検証はブロックの追加中には行われませんが、最終的にはノード間の投票プロセスによって行われます。これによりパフォーマンスが大幅に向上し、BigchainDB は 1 秒あたり 100 万トランザクションを超えるトランザクション スループットと 1 秒未満のレイテンシを実現します。

フレームワークの説明: HDBChain (Hadoop DataBase Chain) は、ノードの連合を使用して動作する最上級のピアツーピア ネットワークです。連合内のすべてのノードは同等の特権を持ち、これにより HDBChain に分散化が提供されます。このような最上級のピアツーピア ネットワークは、インターネット ドメイン ネーム システムからインスピレーションを受けて誕生しました。どのクライアントもトランザクションまたはブロックを送信または取得できますが、ブロックチェーンを変更できるのは連合ノードのみです。連合は、HDBChain の運用中に拡大または縮小する可能性があります。 n 個の連合ノード N1、N2…Nn があるとします。クライアントがトランザクション t を送信すると、そのトランザクションは連合ノードの 1 つ、たとえば Nk に割り当てられます。ノード Nk は、このトランザクションをブロックチェーンに入力する責任を負います。 Nk はまずトランザクションの正当性をチェックします。トランザクションの有効性には、正しいトランザクション ハッシュ、正しい署名、トランザクションへの入力 (存在する場合) の存在、および入力がまだ使用されていないことが含まれます。 Nk は一連のトランザクションを検証すると、それらを 1 つのブロックにまとめてブロックチェーンに追加します。どのブロックにも、指定された最大数のトランザクションのみを含めることができます。 t がブロック B に追加されたとします。

Bブロックが追加された時点でその有効性が決まるわけではありません。連合は動作中に拡大または縮小できるため、HDBCHain ブロックには現在の連合に基づいて投票されたリストも含まれます。ブロックの投票者リスト内のすべてのノードが、その有効性について B に投票します。ブロックに投票すると、ノードはブロック内のすべてのトランザクションを検証します。投票は、投票されたノードの以前のトランザクションが有効であることが判明した場合にのみ有効であり、そうでない場合、この投票は無効になります。投票の大部分が有効なノードからのものである場合、トランザクションは有効になり、投票の大部分が無効なノードからのものである場合、トランザクションは未決定になる可能性が高くなります。有効な投票ブロック内のトランザクションのみがブロックチェーンに記録されたとみなされます。無効なブロック内のブロックはまとめて無視されました。ただし、チェーンには有効なブロックと無効なブロックの両方が保持されます。ブロックが無効であることは、ブロック内のすべてのトランザクションが無効であることを意味するわけではありません。したがって、他のフェデレーション ノードはその無効なブロック トランザクションを取得し、ブロックチェーンに含まれる可能性がさらに高まります。この再割り当てはランダムに行うことができます。したがって、特定の再試行ノードが無効なトランザクションをブロックチェーンに含めようとした場合、このトランザクションは、別のノードを別の機会に割り当てるために先送りされ、考慮から拒否される可能性があります。したがって、B ブロックが有効投票のほとんどを獲得した場合、トランザクション t は元帳に不可逆的に追加されることになります。並行している間、B が無効な場合、チェーンに追加されるかコンセンサスによって完全に拒否されるまで、t は連合内の他のノードに繰り返し割り当てられます。

ご存知のように、チェーンはブロックが作成された時点では形成されていません。ブロックがHbasechainテーブルに入ると、ブロックはIDの辞書順でHBaseに格納さ れます。チェーンは投票時に形成さ れます。ブロックがノードから投票を受けると、さらに投票された先行ブロックが記載さ れます。このように、すべての連合ノードが現在のブロックを評価して新しいブロックの作成に進むのを待つにもかかわらず、ブロックは検証に関係なく生成さ れます。これがブロックチェーンのパイプライン化で実現する技術です。ブロックチェーンは徐々に、有効なブロックと無効なブロックの両方を蓄積していきます。チェーンを不変に保つため、無効なブロックは削除されることがありません。HBaseChainDBでは、HBaseの強力な一貫性と、投票されるブロックがタイムスタンプに基づいて並べられるという事実のため、実際にはこのようなことは起こりません。したがって、すべてのノードが見るブロックの順序は1つだけであり、異なるノードで同じチェーンビューを見ることができます。

ブロックチェーン内のブロックを改ざんするには、敵対者はブロックを変更する必要があり、その結果、そのハッシュが変更されます。この変更されたハッシュは、投票テーブル内のブロックの投票情報と一致せず、さらに、前のブロックであるためこのブロックをチェックする後続の投票でも一致しません。そのため、敵対者は投票データを現在に至るまで変更する必要があります。ただし、ノードによって追加される投票にはそれぞれ署名が必要になる傾向があります。したがって、敵対者がノードの署名を偽造しない限り、つまり暗号的に面倒な場合を除き、ノードの投票を変更することはできません。実際、ブロックチェーン内の変更に影響を与え、状態が変化する可能性を防ぐには、複数の署名を偽造する必要があります。この方法により、HBasechainDB は HBase 上で改ざん防止ブロックチェーンを提供します。

HBaseの悪用：このセクションではMongoDBとHBaseの違いを説明します。また、提案されたシステム設計でより高いパフォーマンスを達成する方法を説明します。

MongoDBはドキュメントストアデータベースです。ドキュメントは特定のスキーマやフォーマットのない大きなJSONブロックです。これにより、動的なユースケースや変更するアプリケーションに適しています。MongoDBはトリガーを提供しません。MongoDBには独自の利点がありますが、MongoDBのドキュメントストア特性は次の操作のパフォーマンスを低下させます：

•    個々の列を処理すること。
• 結合操作を実行すること。

HBaseはワイドカラムストアデータベースです。分散型でスケーラブルで信頼性があり、バージョン管理されたストレージシステムであり、リアルタイムでランダムな読み書きアクセスを提供することができます。HBaseは大量の疎なデータを格納する耐障害性のある方法を提供します。HBaseには列ごとの圧縮、インメモリ操作、およびBloomフィルターの機能があります。

パフォーマンスを導き出すために、HBaseの以下のような特徴を多用しています： 

1. HBase はテーブルにパーティション化され、テーブルはさらに列ファミリーに分割されます。列ファミリーはスキーマで宣言する必要があり、特定の列セットをグループ化できます。ブロックチェーントランザクションにおける主要な操作の 1 つは、二重支払いのチェックです。二重支出のチェックをより効率的にするために、これらすべてのトランザクションの入力列を別の列ファミリーに保持できます。これにより、リージョン サーバーはトランザクションの入力を含む 1 つの列ファミリーのみを読み込む必要があるため、二重支出のチェックをより迅速に実行できるようになります。 MongoDB などのデータベースの場合、データベース サーバーは入力列をフィルタリングして二重支出チェックを実行する前にドキュメント全体をロードする必要があります。

2. HBase は読み取り用に最適化されており、単一書き込みマスターによってサポートされているため、厳密な一貫性モデルが実現します。また、Ordered Partitioning の使用により、行スキャンがサポートされます。ブロックチェーンでは、トランザクションの書き込みは 1 回だけですが、二重支出のチェックや改ざんが行われたかどうかのチェックの実行など、さまざまな目的で何度も読み取られるため、1 回の書き込みと複数回の読み取り操作が必要になります。3. HBase は、リージョン サーバー上でカスタム コードを実行できるさまざまな方法を提供します。 HBase コプロセッサとカスタム フィルターは、そのような 2 つの方法です。 HBase コプロセッサはデータベース トリガーとして機能します。私たちの実装では、これらの機能を次の方法で使用します。

a.二重支出のチェックは通常、トランザクションをフェデレーション ノード (つまり、クライアント システム) にロードすることによって行われます。これほど多くのトランザクションをリージョン サーバーからフェデレーション ノード システムにロードすることは、システム スループットの大きなボトルネックになります。私たちのアプローチでは、二重支出チェックに必要なデータをクライアント システムにプルする代わりに、HBase カスタム フィルターを使用して計算チェックをリージョン サーバーにプッシュします。このアプローチにより、次の 2 つの方法でパフォーマンスが向上します。

i.データは計算ノードに向かって移動するのではなく、計算がデータ ノードに向かって移動します。コードサイズはデータサイズに比べて指数関数的に小さいため、通信時間を短縮することでシステムを改善します。

ii.二重支出の計算は、単一のクライアント ノードでチェックする従来のアプローチと比較して、複数のリージョン サーバーで並行して実行されます。

1. Changefeed は、ブロックチェーン フレームワークに大きなメリットをもたらします。 HBase コプロセッサを使用して、ハッカーがデータベースのコンテンツを変更または削除しようとするとすぐに通知するチェンジフィードを実装します。

実装の詳細： HBasechainDBのフェデレーションノードはキーペアと署名システムで初期化される。トランザクションとブロックのハッシュ化にはSHA3-256ハッシュスキームを使用します。現在のHBasechainDBの実装では、6つのHBaseテーブルを使用しています。HBaseテーブルの領域分割とスキャンは、行キーの辞書順で行われるためで有ります。行キーのパターンは、Hbaseテーブルのデータのアクセスパターンに依存します。

以下はHBaseテーブルの説明で表します：

1. backLog: トランザクションがフェデレーション ノードに送信されると、トランザクションはノードの 1 つにランダムに割り当てられます。このように割り当てられたトランザクションはすべてバックログ テーブルに保存され、各トランザクションは 1 行に保存されます。バックログ テーブルをスキャンするノードは、それ自体に割り当てられたトランザクションを読み取るだけで済みます。したがって、バックログ テーブルの行キーの最初のセグメントは、トランザクションが割り当てられたノードの公開キーであり、ノードが独自の公開キーである行プレフィックスを使用してバックログ テーブルをスキャンできるようにします。行キーの最後のセグメントには、トランザクション参照 ID が含まれます。したがって、行キーは次のようになります: <publicKey>_<transactionId>

2. ブロック: これは、ブロックチェーン内のすべてのブロックを含むテーブルです。各ブロックは、ブロック内に存在するトランザクションの ID のみを含む論理ブロックです。実際のトランザクションの詳細は「hbasechaindb」テーブルに保存されます。このテーブルのアクセス パターンはブロック ID に基づいてブロックを検索するため、このテーブルの行キーはブロック ID のみです: <blockId>

3. hbasechaindb: これは、トランザクションがブロックチェーン上に置かれた後に、すべてのトランザクションの詳細が保存されるテーブルです。このテーブルでは、各行が 1 つのトランザクションに対応します。このテーブルのアクセス パターンはトランザクション リンク ID に基づいてトランザクションを検索するため、このテーブルの行キーは <トランザクション リンク ID> になります。トランザクション リンク ID は、<block_id>_<transaction_id> で構成されます。以前の出力のこのトランザクション リンク ID は、資産の支出中に現在のトランザクションの入力で使用されます。

4. toVote: 作成されたすべての新しいブロックは、フェデレーション ノードによって投票される必要があります。このためには、新しく作成されたブロックに投票する必要があることをフェデレーション ノードに通知する必要があります。この目的を達成するために、作成されたすべてのブロックがこのテーブルに追加され、ノードに投票の信号を送ります。ノードが投票を完了すると、テーブルから削除されます。このテーブルの行キーは次のとおりです: 

5. 投票: これはすべての投票が記録されるテーブルです。それぞれのブロックに投票するすべてのフェデレーション ノードにエントリが必要です。テーブルの行キーは、

6. 参照: トランザクションリンク ID とトランザクション ID のマップを格納するテーブルです。このテーブルは、トランザクションの詳細がクエリされるときのインデックスとして機能します。テーブルのアクセス パターンはトランザクション参照 ID であるため、このテーブルの行キーはトランザクション参照 ID のみです: <transacation_link_Id>

トランザクションが HBasechainDB に送信されると、最初に backLog テーブルに追加されます。フェデレーション ノードは、特定の時間間隔で backLog テーブルからトランザクションを選択し、トランザクションの有効性をチェックして、それらをブロックにバンドルし、それらのブロックをブロックチェーンに追加します。図 1 に示すように、フェデレーション ノードがブロックを形成すると、3 つの HBase テーブルが更新されます。ブロックテーブルでは、すべてのトランザクションのtransaction_Idを別のブロックとして作成して格納します。 hbasechaindb テーブルには、すべてのトランザクションの詳細が保存されます。 toVote テーブルには、新しく作成されたブロックに関する情報が保存されます。フェデレーション ノードは、この toVote テーブルを参照して、ブロックに投票します。すべてのフェデレーション ノードは、特定の時間間隔で toVote テーブルをチェックし、ブロックの有効性を確認した後に投票します。すべての投票は投票テーブルに保存されます。ブロックが有効になった後、すべてのトランザクションに対応するエントリが参照テーブルに作成されます。

HBasechainDB の完全な実装は Java を使用して行われます。これは、Java 用の HBase API のパフォーマンスが、さまざまな言語用の HBase API の中で最高であるためです。 HBase API for Java には、カスタム フィルターとコプロセッサを作成するという利点もあります。