ダミー用ハイパーレジャーファブリック

企業向けブロックチェーンプラットフォーム

こんにちは、読者の皆さん、私の名前はニコライ・ネフェドフです。私はIBMの技術スペシャリストです。この記事では、ブロックチェーンプラットフォームであるHyperledger Fabricを紹介します。 このプラットフォームは、エンタープライズレベル（エンタープライズクラス）でビジネスアプリケーションを構築するように設計されています。 記事レベル-ITテクノロジーの基本的な知識を持つ未熟な読者向け。

Hyperledger Fabricは、Linux FoundationコンソーシアムであるオープンソースプロジェクトHyperledgerのブランチの1つであるオープンソースプロジェクトです。 Hyperledger Fabricは、もともとDigital AssetsとIBMによって開始されました。 Hyperledger Fabricプラットフォームの主な機能は、企業アプリケーションに重点を置いていることです。 したがって、プラットフォームは、すべての参加者の識別だけでなく、トランザクションの高速性と低コストを考慮して開発されました。 これらの利点は、トランザクション検証サービスの分離と分散レジストリの新しいブロックの形成、および認証機関の使用と参加者の承認によって達成されます。

私の記事は、大学に入学する学生の会計システムの設計を説明するフレームワークのHyperledger Fabricに関する一連の記事の一部です。

一般的なハイパーレジャーファブリックアーキテクチャ

Hyperledger Fabricは、ネットワークノードにインストールされるさまざまな機能コンポーネントで構成される分散ブロックチェーンネットワークです。 Hyperledger Fabricコンポーネントは、DockerHubから無料でダウンロードできるDockerコンテナーです。 Hyperledger FabricはKubernetes環境でも実行できます。

スマートコントラクト（Hyperledger Fabricのコンテキストでのチェーンコード）を記述するために、Golangを使用しました（Hyperledger Fabricでは他の言語を使用できます）。 私たちのケースでは、Node.jsに対応するHyperledger Fabric SDKを使用して、カスタムアプリケーションを開発しました。

ノードでは、ビジネスロジック（スマートコントラクト）が実行されます-チェーンコード、分散レジストリの状態（元帳データ）が保存され、プラットフォームの他のシステムサービスが実行されます。 ノードは論理ユニットにすぎず、同じ物理サーバー上に異なるノードが存在できます。 さらに重要なのは、ノードがどのようにグループ化されるか（信頼されるドメイン）、およびそれらが関連付けられているブロックチェーンネットワークの機能です。

一般的なアーキテクチャは次のとおりです。

写真1. Hyperledger Fabricの一般的なアーキテクチャ

ユーザーアプリケーション（クライアントの送信）-ユーザーがブロックチェーンネットワークで作業するアプリケーション。 動作するには、認証を通過し、ネットワーク上のさまざまな種類のアクションに対する適切な権限を持っている必要があります。

ピアにはいくつかの役割があります。

• Endorsing Peer-トランザクションの実行をシミュレートするノード（スマートコントラクトコードを実行）。 スマートコントラクトの検証と実行の後、ノードはクライアントアプリケーションの結果とその署名を返します。
• 注文サービス-いくつかのノード上の分散サービスは、分散レジストリの新しいブロックを形成し、一連のトランザクションを作成します。 Ordering Serviceは新しいブロックをレジストリに追加しません（パフォーマンスを向上させるために、この機能はCommitting Peersに転送されました）。
• コミットピア-分散レジストリを含み、レジストリに新しいブロックを追加するノード（Ordering Serviceが形成）。 すべてのコミットピアには、分散レジストリのローカルコピーが含まれています。 コミットピアは、新しいブロックをローカルに追加する前に、ブロック内のすべてのトランザクションの有効性をチェックします。

推奨ポリシーは、トランザクション検証ポリシーです。 これらのポリシーは、トランザクションが有効であると認識されるためにスマートコントラクトを実行する必要があるノードの必要なセットを決定します。

分散レジストリ-Lerger-2つの部分で構成されています：WolrldState（状態データベースとも呼ばれます）とBlockChain。

BlockChainは、分散レジストリオブジェクトで発生したすべての変更の記録を保存するブロックのチェーンです。

WolrldStateは、分散レジストリ内のすべてのオブジェクトの現在の（極端な）値を格納する分散レジストリのコンポーネントです。

WorldStateは、基本バージョンのデータベースです-LevelDBまたはより複雑です-キーと値のペアを含むCouchDB。例：名-Ivan、姓-Ivanov、システムへの登録日-12/12/21、生年月日-12/17/1961など WorldStateと分散レジストリは、このチャネルのすべてのメンバーと一貫している必要があります。

Hyperledger Fabricはすべての参加者が認識および認証されるネットワークであるため、ここでは専用の認証機関であるCA（認証機関）が使用されます。 CAは、X.509標準および公開キーインフラストラクチャ（PKI）に基づいています。

メンバーシップサービスは、参加者が特定の組織またはチャネル内のオブジェクトの所有権を確認するためのサービスです。

トランザクションは、ほとんどの場合、分散レジストリ内の新しいデータの記録です。
チャネルまたはスマートコントラクトを作成するためのトランザクションもあります。 トランザクションは、ユーザーアプリケーションによって開始され、分散レジストリ内のレコードで終了します。

チャネルは、ブロックチェーンネットワークの2人以上の参加者で構成される閉じたサブネットであり、限られているがよく知られている参加者のサークル内で機密トランザクションを実行するように設計されています。 チャネルは、参加者、その分散レジストリ、スマートコントラクト、注文サービス、WorldStateによって決定されます。 各チャネルメンバーは、チャネルへのアクセスを許可され、さまざまな種類のトランザクションを実行する権利を持っている必要があります。 承認は、メンバーシップサービスを使用して実行されます。

典型的なトランザクション実行シナリオ

次に、プロジェクトを例として使用して、典型的なトランザクション実行シナリオについてお話したいと思います。

内部プロジェクトの一環として、大学に入学する学生を登録および記録するために設計されたHyperledger Fabricネットワークを作成しました。 私たちのネットワークは、大学Aと大学Bに属する2つの組織で構成されています。各組織には、クライアントアプリケーションとそのコミットメントおよび承認ピアが含まれています。 また、一般的なサービスであるOrdering Service、Memebership Service、Certification Authorityも使用しています。

1）トランザクションの開始

ユーザーアプリケーションは、Hyperledger Fabric SDKを使用して、トランザクションリクエストを開始し、スマートコントラクトでノードにリクエストを送信します。 要求は、変更または分散レジストリ（元帳）からの読み取りのためのものです。 会計大学生向けのシステムのテスト構成の例を検討すると、クライアントアプリケーションは、トランザクション要求を大学AおよびBのノードに送信します。これは、呼び出されたスマート契約の承認ポリシーに含まれています。 ノードAは、入学する学生を登録する大学にあるノードであり、ノードBは別の大学にあるノードです。 トランザクションを分散レジストリに保存するには、ビジネスロジックに従って、トランザクションを承認する必要があるすべてのノードが同じ結果でスマートコントラクトを正常に実行する必要があります。 Hyperledger Fabric SDKツールを使用して、ノードAユーザーアプリケーションは承認ポリシーを受信し、どのノードがトランザクションリクエストを送信する必要があるかを見つけます。 これは、特定のデータを分散レジストリに読み書きするために特定のスマートコントラクト（チェーンコード関数）を呼び出す要求です。 技術的には、クライアントSDKは対応する関数を使用します。APIはオブジェクトにトランザクションパラメータを渡し、クライアント署名を追加し、gRPCを介してプロトコルバッファを介してこのデータを対応するノード（承認ピア）に送信します。

写真2.トランザクションの開始

2）スマート契約の履行

トランザクションのリクエストを受信したノード（エンドポイントピア）は、クライアントの署名を確認し、すべてが正常な場合、リクエストデータを使用してオブジェクトを取得し、このデータを使用してスマートコントラクト実行（チェーンコード機能）のシミュレーションを開始します。 スマートコントラクトとは、取引のビジネスロジック、特定の条件と指示のセットです（この場合は、学生の検証、これは新規学生、または既に登録されている、年齢検証など）。 スマートコントラクトを実行するには、WorldStateのデータも必要です。 推奨ピアでスマートコントラクトをシミュレートした結果、読み取りセットと書き込みセットの2つのデータセットが取得されます。 読み取りセットと書き込みセットは、WorldStateの元の値と新しい値です。 （新規-スマートコントラクトのシミュレーション中に得られた意味で）。

写真3.スマートコントラクトの実行

3）クライアントアプリケーションにデータを返す

スマートコントラクトのシミュレーションの後、エンドースピアはクライアントアプリケーションに初期データとシミュレーション結果、および証明書で署名されたRWセットを返します。 この段階では、分散レジストリは変更されません。 クライアントアプリケーションは、承認ピアの署名を確認し、送信されたトランザクションのソースデータと返されたデータを比較します（つまり、トランザクションがシミュレートされたソースデータが歪んでいるかどうかを確認します）。 トランザクションがレジストリからのデータの読み取りのみである場合、クライアントアプリケーションはそれに応じて必要な読み取りセットを受け取り、通常、分散レジストリを変更せずにトランザクションを正常に完了します。 レジストリ内のデータを変更することになっているトランザクションの場合、クライアントアプリケーションは、承認ポリシーの実装をさらにチェックします。 クライアントアプリケーションは推奨ポリシーの結果をチェックしない可能性がありますが、この場合のHyperledger Fabricプラットフォームは、レジストリにトランザクションを追加する段階で、ノード（Comitting Peers）のポリシーをチェックします。

図4.クライアントアプリケーションにデータを返す

4）注文セットへのRWセットの送信

クライアントアプリケーションは、トランザクションと関連データをOrderingサービスに送信します。 これには、RWセット、承認ピア、およびチャネルIDが含まれます。

注文サービス-名前に基づいて、このサービスの主な機能は、着信トランザクションを正しい順序で構築することです。 分散レジストリの新しいブロックの形成と、すべてのコミットノードへの新しい形成ブロックの配信の保証とともに、分散レジストリ（コミットピア）を含むすべてのノードのデータの一貫性を確保します。 同時に、Orderingサービス自体はレジストリを変更しません。 Ordering Serviceはシステムの重要なコンポーネントであるため、複数のノードのクラスターです。 注文サービスは、トランザクションの有効性をチェックせず、特定のチャネル識別子を持つトランザクションを受け入れ、特定の順序で着信トランザクションを配置し、それらから分散レジストリの新しいブロックを形成します。 1つの注文サービスで複数のチャネルを同時に提供できます。 Ordering Serviceには、正しい（変更されていない）トランザクションキューをサポートするKafkaクラスターが含まれています（条項7を参照）。

写真5.注文セットにRWセットを送信する

5）形成されたブロックをCommitting Peerに送信する

Ordering Serviceで形成されたブロックは、すべてのネットワークノードに送信されます。 新しいブロックを受信した各ノードは、承認ポリシーへの準拠を確認し、スマートコントラクトのシミュレーションの結果としてすべての承認ピアが同じ結果（書き込みセット）を受信したことを確認し、初期値が変更されたかどうかも確認します（つまり、読み取りセット-トランザクションが開始されてから、WorldStateからスマートコントラクトによって読み取られたデータ）。 すべての条件が満たされた場合、トランザクションは有効とマークされ、それ以外の場合、トランザクションは無効なステータスを受け取ります。

図6.形成されたブロックをCommitting Peerに送信する

6）レジストリへのブロックの追加

各ノードは、分散レジストリのローカルコピーにトランザクションを追加し、トランザクションが有効な場合、書き込みセットがWorldState（現在の状態）に適用され、それに応じて、トランザクションの影響を受けたオブジェクトの新しい値が記録されます。 トランザクションがマーカーを受け取った場合-無効（たとえば、同じブロック内の同じオブジェクトで2つのトランザクションが発生した場合、元の値は他のトランザクションによって既に変更されているため、トランザクションの1つは無効になります）。 このトランザクションは、無効なトークンを使用して分散レジストリにも追加されますが、このトランザクションの書き込みセットはWorldStateの現在の状態には適用されないため、トランザクションに参加しているオブジェクトは変更されません。 この後、トランザクションが分散レジストリに永久に追加されるという通知と、トランザクションのステータス、つまり、トランザクションが有効であるかどうかがユーザーアプリケーションに送信されます...

図7.レジストリへのブロックの追加

注文サービス

Ordering Serviceは、対応するZooKeeperノードとOrdering Service Nodes（OSN）を備えたKafkaクラスターで構成されます。これらは、Ordering ServiceクライアントとKafkaクラスターの間にあります。 Kafka Clusterは、分散型のフォールトトレラントフロー（メッセージング）管理プラットフォームです。 Kafkaの各チャネル（トピック）は、新しいレコードの追加のみをサポートする変更不可能な一連のレコードです（既存のレコードを削除することはできません）。 トピックの構造の図を以下に示します。 ブロックチェーンプラットフォームの構築に使用されるのは、Kafkaのこのプロパティです。

kafka.apache.orgから取得
図8.注文サービスのトピック構造

便利なリンク

Youtube-Hyperledger Projectでビジネス向けのブロックチェーンを構築する
Hyperledger Fabric Docs
Hyperledger Fabric：許可されたブロックチェーン用の分散オペレーティングシステム

謝辞

私は同僚に記事を準備するのを助けてくれたことに深く感謝します。
ニコライ・マリーナ
イゴール・ハポフ
ドミトリー・ゴルバチョフ
アレクサンダー・ゼムツォフ
エカテリーナ・クルデンコワ
エカテリーナ・グセバ