ブロックチェーン技術の起源と進化（パート2）：Hyperledger Fabricと分散型アライアンスデータベース

【51CTO.comオリジナル記事】序文

今日最も代表的なデータ通信技術といえば、ブロックチェーンは間違いなくその1つです。ブロックチェーンは現在最も人気のある次世代分散システムとして、さまざまな意見を集めており、コンセンサスはありません。これを次のインターネット技術革命のきっかけとなる画期的な発明と見る人もいれば、投機的なツールであり衝撃的な詐欺だと言う人もいます。本稿は、技術レベルから独立した価値判断を可能な限り停止し、視点をブロックチェーン技術そのものに移し、ブロックチェーン 1.0 から 3.0 までの技術原理と設計概念の進化を徹底的に追跡し、ブロックチェーンを覆っている謎のベールを読者に明らかにすることを目的とします。

第2章 Hyperledger Fabricと分散型アライアンスデータベース

前回の記事では、ブロックチェーン1.0をベースに設計されたビットコイン電子会計システムについて詳しく紹介しました。アクセスメカニズムと POW アルゴリズムがないため、ビットコインはネットワークのオープン性とデータセキュリティの両方を実現できます。ただし、POW アルゴリズムの計算能力のオーバーヘッドが高いため、ブロックチェーン ネットワークのデータ処理効率も大幅に制限されます。ブロックチェーン技術は、電子会計だけでなく、金融やセキュリティなど、データセキュリティに敏感な分野でも幅広く活用できます。強い技術的要求に後押しされ、企業や組織間の情報共有に特化したブロックチェーン プロジェクトが誕生しました。これは Linux Foundation 傘下の有名な Hyperledger Fabric プロジェクトです。

1. Hyperledger Fabricの技術的背景

Hyperledger Fabric は、Linux Foundation が主導する Hyperledger プロジェクトの 1 つです。 Hyperledger エコシステムには、Fabric に加えて、Burrow、Sawtooth (Ethereum 拡張プロジェクト)、Indy (デジタル ID プラットフォーム) などの専門プロジェクトも含まれています。 Hyperledger は、ビットコイン ネットワークのパブリック チェーン設計とは異なり、内部および外部のネットワーク分離とビジネス アクセスを備えたコンソーシアム チェーン アーキテクチャを採用し、ブロックチェーン 1.0 ネットワーク アーキテクチャに基づいてノードの役割の差別化をさらに形成します。この設計により、企業内での内部データ漏洩のリスクが回避され、潜在的なセキュリティ リスクも可能な限り排除されます。

Hyperledger Fabric は、ネットワーク内の任意のノード間のピアツーピア通信を可能にする Google の gRPC フレームワークに基づいて開発されています。同時に、基本的な相互作用ロジックを構成するスマート コントラクトをホストするために、Docker コンテナ テクノロジが使用されます。つまり、Hyperledger Fabric は、企業や機関向けに特別に設計された汎用ビジネス システムです。

2. Hyperledger Fabricのデータ構造

1. Hyperledger Fabricのブロックチェーン構造

図14: Hyperledger Fabricのブロックチェーン構造

Hyperledger Fabric のブロックチェーン構造は、Bitcoin のそれとほぼ同じです。各ブロックはブロック ヘッダーとブロック本体で構成され、親ブロックのハッシュ コードを通じて一意にリンクされます。ただし、Hyperledger Fabric では、読み取りと書き込みのパフォーマンスを向上させるために、ブロックチェーン 1.0 に基づく状態キャッシュ設計のレイヤーがさらに追加されています。

Hyperledger Fabric は、Bitcoin ネットワークと同様に、本質的には分散型台帳です (Hyperledger Fabric の台帳インタラクション ロジックは、ユーザーが独自のビジネスに基づいてカスタマイズでき、データ ストレージの柔軟性の点でブロックチェーン 1.0 システムよりも優れています)。基礎となる構造では、データはキーと値のペアの形式で保存されます。ブロックチェーンは、データの時間追跡可能性と改ざん防止メカニズムを実現するために、チェーン内のデータの状態を保存せず、データの変更のみを保存します。つまり、データのステータス クエリには完全なチェーン トラバーサルが必要であり、そのクエリ パフォーマンスでは一部のエンタープライズ レベルのビジネスのパフォーマンス要件を満たすことが困難です。そのため、Hyperledger Fabric では「ワールド ステート」という概念が導入されています。レコードがブロックに保存されると、対応するキーのワールド状態が同期的に更新されます。キー値を照会する必要がある場合は、チェーン全体を走査せずに、対応するワールド状態のみを照会する必要があります。

強調しておくべきことは、ワールド ステート (世界状態) はオフチェーンの追加キャッシュ メカニズムである LevelDB/CouchDB 構造内にオフチェーンで保存されるということです。世界の状態が失われても、ブロックチェーン内のデータには影響しません。

2. Hyperledger Fabricの元帳構造

ネットワーク内のソートノードが最新のブロックをパッケージ化して各アカウンティングノードに配布した後、アカウンティングノードはローカルブロックチェーンデータを更新します。その元帳ストレージ構造は次の図に示されています。

図15: Hyperledger Fabricの元帳構造

まず、各アカウンティングノードはすべての履歴ブロック情報を保存します。ブロックはファイル システムの形式で保存され、複数のブロックがファイル ブロック内のコレクションとして保存されます。ブロックチェーンは、ファイル番号、ブロック番号、オフセットを使用して、履歴ブロックをすばやくインデックスします。

ブロックチェーン データは、アカウンティング ノード内の唯一の永続データでもあり、永続的に保存され、変更することはできません。ブロックは 64 MB のサイズにハードコードされており、6 ビットのコードによって区別されます。理論上、1 つのチェーンは最大 64*1000000M のデータに対応できます。新しいブロックの書き込み要求が行われると、アカウンティングノードはまず新しいブロックをローカルブロックチェーンに追加し、次にデータを状態データベースに同期します（ワールドステートは現在のデータの最終状態、つまり元の状態+ブロックチェーン内のすべてのトランザクション操作を重ね合わせた後の最終状態です）。

ノードが起動されるたびに、まずブロックチェーン、ワールドステート、キー履歴インデックス内のデータが一貫しているかどうかが検証されます。そうでない場合は、ブロックチェーン情報を使用して状態データベースを再構築できます。もちろん、世界状態がジェネシス ブロックから再構築される場合、パフォーマンスのオーバーヘッドは非常に高くなることがよくあります。そのため、Hyperledger Fabric は、ワールド ステート内の各キーと値のペアに対する操作 (トランザクション要求) のエンコードを記録する追加の履歴状態モジュールを追加します。キーと値のペアを再構築するときは、ブロックチェーンから対応するトランザクション要求をフィルタリングし、ブロックチェーン全体を走査せずにそれを実行するだけで済みます。

3. Hyperledger Fabricの読み取り書き込みセットメカニズム

読み取り/書き込みセットは、Hyperledger Fabric がデータ更新に使用するコア テクノロジーです。承認ノードはトランザクションをシミュレートするときに、トランザクション要求を検証します。読み書きセットは、読み取りセット（コミットされたステータス値の読み取り）と書き込みセット（更新されるステータスのキーと値のペア、ステータスのキーと値のペアの削除マーク、同じキーと値のペアが複数回更新された場合は最後の更新が優先される）に分かれています。トランザクション検証を実行する場合、特定の更新操作では、読み取りセットのバージョン番号 = ワールド状態のバージョン番号の場合にのみ書き込みセットが実行されます。書き込みセット内のキーと値のペアが更新されるたびに、キーと値のペアのバージョン番号も更新されます。この設計の目的は、同じブロック内の複数のトランザクションがワールドステートに対して重複した操作を引き起こさないようにすることです (Redis の楽観的ロック メカニズムと同様)。

たとえば、ワールド ステートにキーと値のペア (A、100、V1) がある場合、同様の時間を持つ 2 つのトランザクション要求が同じブロックにパッケージ化されて実行されます。

要求 1: A の値を 100 として読み取り、50 を減算します。

要求 2: A の値を 100 として読み取った後、20 の減算演算を実行します。

リクエスト 1 が実行されると、ワールド状態は (A, 50, V2) に更新されます。この時点でリクエスト 2 が実行されると、操作は以前に読み取られたワールド状態 (A、100、V1) に従って実行されます。操作後、ワールド状態は（A、80、V2）に更新され、リクエスト1の操作は消去されます。したがって、バージョン検証の目的は、同時実行性の高い状況でのデータ損失を回避することです。

3. 実用的なビザンチンフォールトトレランス

1. PBFTの基本モデル

前回の記事では、分散システムが直面するデータ一貫性の問題であるビザンチン将軍問題について紹介しました。ブロックチェーン 1.0 のネットワーク アーキテクチャは、主に POW アルゴリズムを通じてネットワーク全体のコンセンサスを実現します。このアルゴリズムは、会計ノードに会計権と引き換えに物理的なオーバーヘッドを使用させることで不正行為を回避します。しかし、POW アルゴリズムのパズル解決設計は、膨大なリソースの浪費も引き起こし、実質的な意味を持たないデジタル パズルに大量の計算能力が浪費されます。コンソーシアム チェーンとして、Hyperledger Fabric は、企業の分散データ ストレージとデータ共有のニーズを満たすことに重点を置いています。そのため、パフォーマンスはネットワーク アーキテクチャの設計レベルで考慮する必要がある問題になっています。 Hyperledger Fabric は、ブロックチェーン 1.0 に基づくネットワーク アクセス メカニズムを導入しました。承認されたノードのみがブロックチェーン内のデータにアクセスできます。ノードの数はパブリックチェーンシステムよりもはるかに少なくなります。 POW は、アライアンス チェーン システムの設計と開発には適さなくなりました。そのため、Hyperledger Fabric では、コストが低くパフォーマンスの高いコンセンサス アルゴリズム「Practical Byzantine Fault Tolerance Algorithm (PBFT)」を採用しています。

Leslie Lambert が提案した BFT アルゴリズムは、理論上はビザンチンフォールトトレランスの実現可能性を証明するだけですが、実際の分散システム設計では、ネットワークのブロックなどの理由により、BFT アルゴリズムを適用することはほとんどできません。そこで、BFT をベースに、カストロ、ミゲル、バーバラ・リスコフの 3 人のコンピューター科学者が、実際に使用できる PBFT アルゴリズムをさらに提案しました。

PBFT アルゴリズムは、まず分散システムの 3 つの基本モデルを区別します。

強力な同期モデル: ノードによって送信されたメッセージは、一定期間内にターゲット ノードに配信できます。

強力な非同期モデルでは、どのノードから送信されたメッセージもターゲットノードに届かない可能性があります。

部分同期モデルでは、ノードによって送信されたメッセージは、最終的には可能な遅延範囲内でターゲット ノードに到達します。

強い同期モデルと強い非同期モデルによって設定される状況は極端すぎます。実際の分散システムでは、状況は弱い同期モデルに近くなります。 PBFT アルゴリズムは弱い同期モデルに基づいて設計されています。つまり、メッセージは遅延される可能性がありますが、無期限に遅延されることはありません。

分散ネットワークに F 個の障害のある/悪意のあるノードがあり、ノードの総数が N であると仮定します。弱い同期モデルでは、PBFT は次の 2 つの点を保証する必要があります。

ノードがメッセージを受信すると、最大 F 個のノードが沈黙している可能性があることを考慮すると、NF メッセージが受信されたときに検証を開始する必要があり、フォールト トレラントの判断を完了するには、少なくとも F 個を超える NF メッセージが一致している必要があります。したがって、N と F は次の条件を満たす必要があります。

N - F > F

さらに、NF メッセージには悪意のあるノードからの F 個の誤ったメッセージが含まれている可能性があります。したがって、フォールト トレランスの判断を完了するには、真のメッセージの数が少なくとも F 以上である必要があります。したがって、N と F は次の条件を満たす必要があります。

N - F - F > F

要約すれば：

したがって、悪意のあるノードや障害のあるノードの数がノードの総数の 1/3 を超えない場合、PBFT アルゴリズムはグローバルな一貫性を実現できます。

2. PBFTネットワークトポロジモデル

図16: PBFTネットワークトポロジモデル

PBFT によって実装される分散ネットワークは、次の 2 つの条件を満たす必要があります。

• 各ノードの開始状態は同じです。
• 同じ状態では、同じ操作で同じ結果が生成されます。

PBFT アルゴリズムによって実装された分散ネットワークでは、ノードのグループから 1 つのノードがプライマリ ノード (Primary) として選択され、他のノードはバックアップ ノード (Backup) として選択されます。ノードをマスターノードとして選択した状態をシステムのビューと呼びます。マスターノードに障害が発生すると、新しいマスターノードが選択されます。マスターノードが変更されると、システムビューが更新されたと見なされます。 View1ビューでは、ネットワークがメッセージmの順序nについて合意に達し、それがOrder⟨view1,m,n⟩であると仮定します。その後、ビューが更新されても、m の順序は Order⟨view2,m,n⟩ のままです。つまり、ビューの変換前後でメッセージの順序は変わりません。

3.PBFTメッセージ処理フロー

図17: PBFTメッセージ処理フロー

PBFT のメッセージ処理フローは、一般的に、要求、前処理、準備、コミット、応答の 5 つの段階に分かれています。 PBFT 情報伝送検証プロセスを説明するために、4 つのノードと 1 つのクライアントを持つ単純なネットワーク モデルを使用します。

このネットワーク モデルでは、プライマリ ノードとバックアップ 1 ノードおよびバックアップ 2 ノードは通常のノードであり、バックアップ 3 ノードは障害が発生して応答できないため、N>3F の要件を満たします。

まず、リクエスト フェーズでは、クライアントがプライマリにリクエストを送信します。メッセージの形式は次のとおりです。

ここで、o は操作要求の内容を表し、t は現在のタイムスタンプを表し、c はクライアント ノードを表します。

プライマリがメッセージを受信して​​検証すると、事前準備フェーズに入ります。プライマリはメッセージ m にシーケンス番号 n を割り当て、前処理メッセージをバックアップ 1、バックアップ 2、バックアップ 3 にブロードキャストします。メッセージの形式は次のとおりです。ここで、v は現在のシステム ビュー、n はメッセージの順序、m はメッセージの内容、d はメッセージ m のハッシュ値を表します。

Backup1 ノードと Backup2 ノードは、プライマリ ノードからメッセージを受信すると、まずシステム ビューが更新されているかどうか、メッセージ署名が正当かどうか、ランキング n が現在のビューの最高水準点と最低水準点の間にあるかどうか (n が極端な値を持たないようにするため、システムは同じビュー内の n の値の範囲を n∈(h,H) となるように制限します)、およびランキング n の他のメッセージが受信されているかどうか (異なるメッセージが同じランキングにならないようにするため) を確認します。検証後、PREPARE フェーズに入ります。ノードは準備メッセージを他のノード (プライマリ ノードを含む) に送信し、そのメッセージをローカル ログに保存します。メッセージの形式は次のとおりです。ここで、i は現在のノードを表します。

他のノードがメッセージを受信すると、次の検証を実行し、メッセージをローカル ログに保存します。

最初のステップは、メッセージ m がローカル ログに存在するかどうかを確認することです。

2 番目のステップは、ローカル ログに m の PRE-PREPARE メッセージがあるかどうかを確認することです。

3 番目のステップは、ローカル ログに m に関する少なくとも 2F PREPARE メッセージがあるかどうかを確認することです。

検証に合格すると、ノードはメッセージ m に対して PREPARED 状態に到達したとみなされます。このとき、ノードは他のノードにブロードキャストし、メッセージの形式は次のようになります。

他のノードが COMMIT メッセージを受信すると、次のチェックを実行し、メッセージをローカル ログに保存します。

最初のステップは、このノードがメッセージ m に対して PREPARED 状態に達しているかどうかを確認することです。

2 番目のステップは、ローカル ログに他のノードからの m に関する少なくとも 2F 個の COMMIT メッセージがあるかどうかを確認することです。

検証に合格すると、m の順序が世界的な合意に達したことを意味します。この時点で、ノードはメッセージ m に対して COMMITTED-LOCAL (m, v, n, i) 状態に到達したとみなされ、クライアントに直接返すことができます。メッセージの形式は次のとおりです。r と t は同じであり、時間の検証に使用されます。クライアントが F+1 の一貫性のある REPLY メッセージを受信すると、コンセンサス プロセスは終了します。

図18: ノードローカルログライブラリの状態遷移図

このプロセスをより直感的に理解するために、各ノードのローカル ログ ライブラリの状態遷移図を作成します。青色でマークされたメッセージはノード自体によって生成され、緑色でマークされたメッセージは他のノードからのメッセージです。

まず、クライアントは REQUEST メッセージを送信し、それがプライマリのログ ライブラリに保存されます。次に、プライマリはバックアップ 1、バックアップ 2、バックアップ 3 に PRE-PREPARE メッセージを送信します。バックアップ 1 とバックアップ 2 はそれぞれ PRE-PREPARE メッセージをログ ライブラリに保存します。次に、他のノードに PREPARE メッセージを送信します。

プライマリは、バックアップ 1 とバックアップ 2 から 2 つの PREPARE メッセージを受信し、ログ ライブラリに保存します。 Backup1 と Backup2 は、自身で生成された PREPARE メッセージに加えて、他のノードからの PREPARE メッセージも受信します。現時点では、3 つの通常ノードのログ ライブラリはすべて次の要件を満たしています。

• メッセージ m のログがあります。
• メッセージ m には PRE-PREPARE ログがあります。
• メッセージ m には 2F PREPARE ログがあります。

この時点で、3 つのノードすべてが m に関して PREPARED 状態に達し、他のノードに COMMIT メッセージを送信します。

図からわかるように、3 つの正常なノードは、自身が生成した 1 つの COMMIT メッセージに加えて、他のノードから 2 つの COMMIT メッセージを受信し、すべて COMMITTED 状態に達し、クライアントに REPLY メッセージを返し、コンセンサス プロセスを完了しました。

4. PBFTのガベージコレクションメカニズム

PBFT アルゴリズムでは、情報の定期的な検証のためにノードのログ ライブラリが必要です。情報量が増えると、ログライブラリ内の冗長データの量も増加します。したがって、PBFT は定期的なガベージ コレクションを通じてメモリ領域を解放します。 PBFT のガベージ コレクションは、チェックポイント メカニズムを通じて実行されます。チェックポイントは定数 K の整数倍に設定されます。現在のメッセージ ソート値 n の最高水準点と最低水準点が h と H の間にあると仮定します。ソートされたメッセージの数が H を超えると、ノードは次の形式で CHECKPOINT メッセージを送信します。

ノードは2F+1個のCHECKPOINTメッセージを受信すると、高低ウォーターマークをn∈(H,H+K)にリセットし、ソート値がH未満のメッセージログを削除してメモリスペースを解放します。

5. PBFTビュー更新メカニズム

PBFT はマスターノードを介してメッセージをソートするため、マスターノードに障害が発生するリスクがあります。これに対応して、PBFT は、マスター ノードに障害が発生した場合でもシステム全体の可用性を確保するための対応するビュー更新メカニズムを設計しました。

ノード i は、マスター ノードの応答がタイムアウトしたことを検出すると、ビュー更新プロセスに入り、次の形式で VIEWCHANGE メッセージを送信します。

ここで、n は最新のチェックポイントのシーケンス番号であり、C は対応する 2F+1 CHECKPOINT メッセージ セットです。 P は PREPARED 状態に達したメッセージのセットです。

Pm は、シーケンス番号が n より大きく、PREPARED 状態に到達しているメッセージ m の少なくとも 1 つの PRE-PREPARE メッセージと少なくとも 2F 個の PREPARE メッセージのセットを表します (つまり、メッセージ m が PREPARED 状態に到達できるようにするすべての前処理メッセージと準備メッセージの合計セット)。

新しいプライマリノード Primaryv+1 が 2F 個の有効な VIEWCHANGE メッセージを受信すると、次の形式で新しいビュー メッセージをブロードキャストします。

ここで、V は Primaryv+1 が受信したすべての VIEWCHANGE メッセージのセットであり、O は新しいビューで構築された PRE-PREPARE メッセージのセットです。ビューの更新プロセスはここで終了します。このメカニズムにより、ビューが更新される前と更新された後に PREPARED 状態に到達するメッセージの順序が変更されないことが効果的に保証されます。

4. Hyperledger Fabricのネットワークトポロジーとコンセンサスメカニズム

Hyperledger Fabric は、コンセンサス アルゴリズムの基盤となる実装として PBFT を使用します。分散システムの場合、データ一貫性戦略は、強力な一貫性戦略と最終的な一貫性戦略に分けられます。いわゆる強力な一貫性戦略とは、システムが極端な条件下でもデータの一貫性を実現できることを意味します。複雑なデータのやり取りが伴い、システムに多大な負担がかかります。商用グレードのデータストレージには適していません。したがって、Hyperledger Fabric は結果整合性戦略を採用しています。いわゆる最終的な一貫性とは、システムが短期間に異なるノード上の不整合なデータを許容でき、ブロックチェーン ネットワーク全体では、一定の期間内に合意に達することだけを保証する必要があることを意味します。

図19: Hyperledger Fabricネットワークトポロジ

図に示すように、Hyperledger Fabric は、独立したソートノードが異なる端末からのトランザクション要求を整理し、ブロックにカプセル化してから、ブロックチェーン ネットワーク全体に配布するマルチセンター ネットワーク アーキテクチャ モデルを採用しています。

Hyperledger Fabric ネットワークには、主に 4 種類のノードがあります。

• クライアントノード: このノードは主に、アプリケーションがブロックチェーン ネットワークにアクセスするためのエントリを提供するために使用され、システムとブロックチェーン間のデータ相互作用を担当します。
• ピア ノードには、アンカー ノード、エンドーサー ノード、コミッター ノードが含まれます。各組織には最大 1 つのアンカー ノードがあり、他の組織や注文ノードとのやり取りを担当します。組織ネットワーク内の非アンカー ノードは、外部ネットワークとの情報交換に直接参加しません。承認ノードは、ユーザーからのトランザクション要求の実行をシミュレートし、要求を検証して署名する役割を担います。アカウンティングノードは、ブロックチェーン情報の保存、ワールドステータスの更新などを担当します。これら 3 つの役割は相互に排他的ではないことを強調しておく必要があります。ピア ノードは、エンドースメント ノードやブックキーピング ノードなどの複数の役割を同時に持つことができ、すべてのピア ノードはブックキーピング ノードです。
• 注文ノードはコンセンサス メカニズムのコア ノードです。ユーザーからのトランザクション要求を分類し、ブロックにパッケージ化して、他の組織のアンカー ノードに配布する役割を担います。
• 非必須ノードである CA ノード (認証ノード) は、主に証明書の発行、ID 認証、およびユーザー認証を担当します。サードパーティの証明書認証機関を通じて実現することもできます。

Hyperledger Fabric のネットワーク トポロジーについては、Bitcoin や Ethereum などの一般的なパブリック チェーンのメッシュ トポロジーとは異なり、一定の階層関係を持つツリー トポロジーに近いものとなっています (この点、Hyperledger Fabric は分散型ネットワークではなく、マルチセンター ネットワークです)。

異なる組織は異なるネットワーク ドメインに属しており、各組織構造は他の組織と対話するためのインターフェイスとして 1 つのアンカー ノードのみを公開します。この設計は主に、一部の企業のデータ セキュリティに関する考慮事項に基づいています。多くの企業のコアデータをパブリックネットワークに直接公開するのは不便な場合がよくあります。内部ネットワークと外部ネットワークを分離する設計により、機密データのセキュリティを完全に確保できます。

さまざまな組織に加えて、ブロックチェーン ネットワークには注文ノードで構成されたソート ネットワークもあります。オーダーノードには、Solo と Kafka の 2 つの動作モードがあります。 Solo モードは、単一の Order ノードによるソート サービスを提供します。通常、ネットワーク テストやノード数が少ないシナリオでのみ使用されます。 Kafka モードは一般に商用アプリケーションで使用されます。 Order ノードは受信したトランザクション要求を Kafka クラスターに送信し、クラスターはそれを並べ替えてから Order ノードに返します。この設計により、注文クラスターのソートおよび配布の効率が大幅に向上します。

図20: Hyperledger Fabricのマルチチャネルソートメカニズム

エンタープライズ アプリケーションのシナリオでは、ブロックチェーン ネットワークで複数のビジネスを実行する必要がある状況が発生する可能性があるため、Hyperledger Fabric ではマルチチャネル設計を採用しています。チャネルとは、閉鎖的なビジネス グループを指します。 Hyperledger Fabric ネットワークには、異なるビジネスを扱う複数のビジネス グループが存在する場合があり、それらは論理的および物理的に互いに分離されています。ビジネスグループが複数ある場合は、複数の異なるブロックチェーンが存在することになります。各ノードは、参加しているチャネルのブロックチェーン データのみを保存するため、複数のビジネスにまたがるシナリオでのデータ漏洩のリスクが排除されます。ソートノードは、ビジネス間のチェーンレベルの分離を実現するために、さまざまなチャネルに応じてトランザクション要求をさまざまな Kafka キューに分散します。

Hyperledger Fabric ネットワークにおける完全なトランザクション プロセスは次のとおりです。

クライアントはまず、エンドースノード（エンドースメントポリシーで設定できる少なくとも 2 つ。ユーザーは使用するエンドースノードを指定できます）にトランザクション提案を送信します。トランザクション提案を受け取った後、承認ノードはチェーン コード (手動で介入できない分離された安全なコンテナー内で実行) を開始してトランザクションをシミュレートします (シミュレーションのみであり、ブロックチェーン ネットワークには更新されません)。認証検証に合格すると、エンドースメントノードはデジタル署名を追加してクライアントに返します (理論的には、複数のエンドースメントノードによって返される実行結果は一貫しているはずです)。クライアントは署名されたトランザクション要求を Order ノードに送信します。Order ノードはそれを並べ替えてブロックにパッケージ化し、各組織のアンカー ノードに配布します。アンカー ノードは、組織内のアカウンティング ノードに配布されます。アカウンティングノードが検証を完了すると、最新のブロックがローカルブロックチェーンに追加され、ワー​​ルドステートが更新されます。

5. スマートコントラクト

図21: トランザクションを開始し、スマートコントラクトを呼び出すプロセス

スマート コントラクト (チェーン コード) は、Hyperledger Fabric がアプリケーションとブロックチェーン ネットワーク間のやり取りに使用する媒体です。チェーンコードは、外部からの干渉や改ざんの影響を受けない独立した隔離された Docker コンテナにデプロイされ、gRPC を介してエンドースノードと通信します。エンドーシングノードがチェーンコードコンテナにトランザクション要求を送信すると、チェーンコードコンテナはトランザクションの実行結果をエンドーシングノードに返します。

スマート コントラクトは、アプリケーション システムの外部インターフェイスに似ており、トランザクションはインターフェイスへの呼び出しです。チェーンコードは、外部インターフェースに対して Init と Invoke の 2 つのメソッドのみを提供します。 Init メソッドは、ブロックチェーン ネットワークの起動時に任意のノードで 1 回だけ実行され、Invoke メソッドは、アプリケーションとブロックチェーン ネットワーク間の特定のやり取りに使用されます。

チェーン コードには、パッケージ化 (チェーン コードのコンパイル)、インストール (エンドースメント ノードへのアップロード)、インスタンス化 (Init メソッドの実行)、アップグレード (チェーン コード内の機能拡張とバグ修正)、およびインタラクション (アプリケーションの呼び出し) の 5 つのライフ サイクルがあります。

企業ユーザーは、独自のビジネス シナリオに応じてさまざまな機能を備えたスマート コントラクトを記述し、アプリケーションとブロックチェーン ネットワーク間のデータ相互作用を実現できます。

6. Hyperledger Fabricのビジネスアプリケーション

Hyperledger Fabric は、機関や企業向けに特別に設計された汎用ビジネス ソリューションです。ブロックチェーン1.0や2.0と比較すると、ユーザーの業務に合わせて柔軟にカスタマイズできます。モジュール式およびプラグイン サービス モデルにより、ユーザーのネットワーク コストも大幅に削減されます。財務や支払いなど、機密性が非常に高いビジネス シナリオに非常に適しています。 Hyperledger Fabric の下部にあるキー値ストレージ構造も非常にスケーラブルです。理論上、Hyperledger Fabric は従来のデータベースが保存できるすべてのデータを保存できます。マルチチャネル設計により、物理レベルのビジネス分離を実現し、複数のビジネスを干渉なく同じブロックチェーン ネットワークに搭載できます。機関間の業務重複によるデータ漏洩リスクを回避しながら、リソースの再利用を可能にします。

Hyperledger Fabric のもう 1 つの大きな利点は、ユーザーが独自のビジネスに基づいてスマート コントラクトを作成し、アプリケーション システムとブロックチェーン ネットワーク間のデータ相互作用モードをカスタマイズできることです。これにより、複雑なビジネス シナリオとブロックチェーン テクノロジーの統合が容易になり、「Blockchain+」をエンタープライズ レベルのアプリケーションに真に導入できるようになります。

結論

ブロックチェーン技術は登場以来、過去 10 年間で 3 回の進化を遂げており、その間に賞賛や批判を受けてきました。ブロックチェーンを取り巻く神秘的なベールを取り除き、その技術的原理を深く掘り下げることでのみ、その真の姿を見ることができます。ブロックチェーン自体は、技術としては価値がありません。ツールがどのような社会的価値を生み出すことができるかは、最終的にはそのユーザー次第です。私たちはデザイナーの並外れたアイデアに驚嘆するかもしれませんが、テクノロジー以外の謎をあまり深める必要はありません。ブロックチェーンは未来への入り口となるかもしれないが、技術的な特異点の爆発は単一の技術革新から生じるものではなく、むしろ蓄積された経験の結果としての段階的な進化の結果である。勤勉さと不屈の精神は社会の進歩の究極の原動力です。テクノロジーが急速に変化し、開発が飛躍的に進む時代にあって、私たちはこの姿勢をさらに貫くべきです。

参考文献

[1] サトシ・ナカモト：ビットコイン：ピアツーピアの電子キャッシュシステム[EB/OL]

[2] カストロ、ミゲル、バーバラ・リスコフ：実践的ビザンチンフォールトトレランス。OSDI.Vol.99.1999

[3] クォン・ジェ：Tendermint：マイニングなしのコンセンサス。ドラフトv.0.6、秋（2014年）

著者について:

王翔は2018年に安徽大学で電子情報工学の学位を取得し、現在は有名なフォーチュン500インターネット企業に勤務しています。サーバー側システムのアーキテクチャ設計、マルチアクティブ展開、パフォーマンス最適化、ビジネス開発などの作業に専念します。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]