ダミー向けのハイパーレジャーファブリック

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

こんにちは、親愛なる読者の皆さん、私の名前はニコライ・ネフェドフです。IBM の技術スペシャリストです。この記事では、ブロックチェーン プラットフォームである Hyperledger Fabric について紹介したいと思います。 このプラットフォームは、エンタープライズクラスのビジネス アプリケーションを構築するために設計されています。 この記事のレベルは、IT テクノロジの基本的な知識を備えた準備の整っていない読者を対象としています。

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

私の記事は 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 ファブリックの一般的なアーキテクチャ

ユーザー アプリケーション (送信クライアント) は、ユーザーがブロックチェーン ネットワークを操作するためのアプリケーションです。 作業するには、ネットワーク上のさまざまな種類のアクションを許可され、適切な権限を持っている必要があります。

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

• 承認ピアは、トランザクションの実行をシミュレートする (スマート コントラクト コードを実行する) ノードです。 スマート コントラクトの検証と実行後、ノードは実行結果を署名とともにクライアント アプリケーションに返します。
• Ordering Service は、複数のノード上の分散サービスであり、分散レジストリの新しいブロックを生成し、トランザクションを実行するためのキューを作成するために使用されます。 Ordering Service は、レジストリに新しいブロックを追加しません (この機能は、パフォーマンスを向上させるためにピアのコミットに移動されました)。
• コミットピアは、分散レジストリを含むノードであり、新しいブロック (順序付けサービスによって生成された) をレジストリに追加します。 すべてのコミットピアには、分散台帳のローカルコピーが含まれています。 コミットピアは、新しいブロックをローカルに追加する前に、ブロック内のすべてのトランザクションの有効性をチェックします。

エンドースメントポリシーは、取引の正当性を確認するためのポリシーです。 これらのポリシーは、トランザクションが有効であると認識されるためにスマート コントラクトを実行する必要があるノードの必須セットを定義します。

分散レジストリ - Lerger - は、WolrldState (State Database とも呼ばれる) と BlockChain の XNUMX つの部分で構成されます。

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

WolrldState は、すべての分散台帳オブジェクトの現在 (最先端) の値を保存する分散台帳コンポーネントです。

WorldState は、基本バージョン - LevelDB またはより複雑なバージョン - CouchDB のデータベースであり、キーと値のペアが含まれています。例: 名 - Ivan、姓 - Ivanov、システムへの登録日 - 12.12.21/17.12.1961/XNUMX 、生年月日 - XNUMX年XNUMX月XNUMX日など。 WorldState と分散レジストリは、特定のチャネルのすべての参加者間で一貫している必要があります。

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

メンバーシップ サービスは、オブジェクトが特定の組織またはチャネルに属していることをメンバーが確認するサービスです。

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

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

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

次に、私たちのプロジェクトを例として、典型的なトランザクション実行シナリオについて説明したいと思います。

内部プロジェクトの一環として、大学に入学する学生を登録および管理するように設計された Hyperledger Fabric ネットワークを作成しました。 私たちのネットワークは、大学 A と大学 B に属する XNUMX つの組織で構成されています。各組織にはクライアント アプリケーションと、独自のコミット ピアおよび承認ピアが含まれています。 また、共通サービスであるオーダーサービス、メンバーシップサービス、認証局も利用します。

1) 取引の開始

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

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

2) スマートコントラクトの実行

トランザクションを実行するリクエストを受け取ったノード (エンドーシングピア) は、クライアントの署名をチェックし、すべてが正常であれば、リクエストデータを含むオブジェクトを取得し、スマートコントラクト (チェーンコード関数) の実行のシミュレーションを実行します。このデータ。 スマート コントラクトは、トランザクションのビジネス ロジック、特定の条件と指示のセットです (この場合、これは学生の認証、新入生か、すでに登録されているか、年齢認証などです)。 スマート コントラクトを実行するには、WorldState からのデータも必要になります。 承認ピアでスマート コントラクトをシミュレートした結果、読み取りセットと書き込みセットの XNUMX つのデータ セットが取得されます。 Read Set と Write Set は、元の WorldState 値と新しい WorldState 値です。 (新しい – スマート コントラクトのシミュレーション中に得られる意味で)。

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

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

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

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

4) RW セットを順序付けピアに送信する

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

順序付けサービス – 名前に基づくと、このサービスの主な機能は、受信したトランザクションを正しい順序で配置することです。 分散レジストリの新しいブロックの形成と、新しく生成されたブロックのすべてのコミット ノードへの配信が保証されるため、分散レジストリを含むすべてのノード (コミット ピア) でのデータの一貫性が保証されます。 同時に、Ordering サービス自体はレジストリを一切変更しません。 Ordering Service はシステムの重要なコンポーネントであるため、複数のノードからなるクラスターになります。 Ordering Service はトランザクションの有効性をチェックせず、単に特定のチャネル ID を持つトランザクションを受け入れ、受信したトランザクションを特定の順序で整理し、それらから分散レジストリの新しいブロックを形成します。 7 つの順序付けサービスは、複数のチャネルに同時にサービスを提供できます。 Ordering Service には、正しい (不変の) トランザクション キューを維持する Kafka クラスターが含まれています (ポイント XNUMX を参照)。

図 5. RW セットを順序付けピアに送信する

5) 生成されたブロックをコミットピアに送信する

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

図 6. 生成されたブロックをコミットピアに送信する

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

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

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

注文サービス

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

kafka.apache.org から取得

• 図 8. 注文サービスのトピック構造*

役立つリンク

Youtube – Hyperledger プロジェクトによるビジネス向けブロックチェーンの構築
ハイパーレジャーファブリックのドキュメント
ハイパーレジャーファブリック: 許可されたブロックチェーン用の分散オペレーティングシステム

感謝

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

出所： habr.com