1. チェーンコードとは何ですか?

ChainCode は、 Go、Node.js、またはJavaで書かれた、指定されたインターフェイスを実装するプログラムです。ChainCode は安全な Docker コンテナ内で実行され、エンドースメントノードから分離されており、アプリケーションによって送信されたトランザクションを通じて台帳の状態を初期化および管理します。

チェーンコードは通常、ネットワークメンバーによって合意されたビジネスロジックを処理するため、「スマートコントラクト」とみなすことができます。チェーンコードによって作成された台帳への更新は、そのチェーンコードに制限されており、他のチェーンコードから直接アクセスすることはできませんが、同じネットワーク内であれば、適切な権限が与えられていれば、チェーンコードは別のチェーンコードを呼び出してその状態にアクセスできます。

2. チェーンコードをデプロイする

ファブリックチェーンコードのライフサイクルは、チャネルでチェーンコードを使用する前に、複数の組織がチェーンコードの操作方法に同意できるようにするプロセスです。ファブリックライフサイクルを使用して、チェーンコードのデプロイと運用を操作します。

2.1 チェーンコードのインストールと定義

ファブリックチェーンコードのライフサイクルでは、名前、バージョン、チェーンコードの承認ポリシーなど、チェーンコードを定義するパラメーターに組織が同意する必要があります。チャネルメンバーは次の 4 つのステップを通じて同意しますが、チャネル上のすべての組織が各ステップを完了する必要はありません。

スマートコントラクトのパッケージ化:このステップは、1 つの組織または各組織によって完了できます。
ピアノードにチェーンコードをインストールする:チェーンコードを使用してトランザクションを承認したり、台帳をクエリしたりする各組織は、この手順を完了する必要があります。
チェーンコードの組織の承認:チェーンコードを使用する各組織は、このステップを完了する必要があります。チェーンコード定義は、チャネルでチェーンコードを起動する前に、チャネルの LifecycleEndorsement ポリシー (デフォルトは過半数) を満たすのに十分な数の組織によって承認される必要があります。
チェーンコードをチャネルに送信する:チャネル上の必要な数の組織が承認されると、トランザクションは 1 つの組織によってコミットされます。送信者はまず承認された組織の十分な数のピアから承認を収集し、次にチェーンコードを送信するトランザクションを送信します。

2.1.1 スマートコントラクトのパッケージ化

チェーンコードは、ピアノードにインストールする前に tar ファイルにパッケージ化する必要があります。チェーンコードをパッケージ化するには、ファブリックピアバイナリ、ノードファブリック SDK、またはサードパーティツール (GNU tar など) を使用できます。チェーンコードパッケージを作成するときは、簡潔で読みやすいパッケージ説明を作成するためにチェーンコードパッケージタグを指定する必要があります。

サードパーティのツールを使用してチェーンコードをパッケージ化する場合、生成されるファイルは次の形式である必要があります。Fabric ピアバイナリと Fabric SDK は、この形式でファイルを自動的に作成します。

チェーンコードは、.tar.gz ファイル拡張子で終わる tar ファイルにパッケージ化する必要があります。
tar ファイルには、メタデータファイル「metadata.json」と、チェーンコードファイルを含むもう 1 つの tar 「code.tar.gz」という 2 つのファイル (ディレクトリは含まれません) が含まれている必要があります。
「metadata.json」には、チェーンコード言語、コードパス、パッケージタグを指定するJSONが含まれています。メタデータファイルの例を以下に示します。

{"Path":"fabric-samples/asset-transfer-basic/chaincode-go","Type":"golang","Label":"basicv1"}

チェーンコードは Org1 と Org2 によってそれぞれパッケージ化されます。どちらの組織も、パッケージラベルとして MYCC_1 を使用し、名前とバージョンを使用してパッケージを識別します。組織が同じパッケージラベルを使用する必要はありません。

2.1.2 ピアノードがチェーンコードをインストールする

チェーンコードがインストールされているピアノードのみがトランザクションと承認トランザクションを実行できます。CLI または SDK のいずれであっても、この手順を完了するにはPeer Administratorを使用する必要があります。チェーンコードはインストール後にビルドされ、チェーンコードに問題がある場合はビルドエラーが返されます。組織はチェーンコードを 1 回パッケージ化するだけで済み、その後、インストールする必要がある組織に属するピアノードに同じチェーンコードパッケージをインストールすることをお勧めします。チャネルが各組織で同じチェーンを実行するようにしたい場合は、コードを使用すると、1 つの組織がパッケージ化作業を完了し、それをチャネルの他のメンバーに送信します。

インストールコマンドが成功すると、パッケージラベルとパッケージのハッシュ化された組み合わせであるチェーンコードパッケージ識別子が返されます。このパッケージ識別子は、ピアノードにインストールされているチェーンコードパッケージを組織承認のチェーンコード定義と関連付けるために使用されます。次のステップのために識別子を保存してください。ピア CLI を使用してピアにインストールされているパッケージをクエリすることによっても見つけることができます。パッケージ識別子。

Org1 と Org2 のピア管理者は、チャネルに参加しているピアにチェーンコードパッケージ MYCC_1 をインストールします。チェーンコードパッケージをインストールすると、チェーンコードが構築され、パッケージ識別子 MYCC_1:hash が作成されます。

2.1.3 組織がチェーンコードを承認する

チャネルメンバーがチェーンコード定義を承認する場合、承認はチェーンコードパラメータを受け入れる組織の投票によって決定されます。これらの承認された組織定義により、チャネルメンバーは、チャネルで使用される前にチェーンコードに同意することができます。チェーンコード定義には次のパラメータが含まれており、組織間で一貫している必要があります。

名前:アプリケーションがチェーンコードを呼び出すときに使用する名前。
バージョン:特定のチェーンコードパッケージに関連付けられたバージョン番号または値。チェーンコードバイナリをアップグレードする場合は、チェーンコードバージョンも変更する必要があります。バージョンには任意の文字を含めることができますが、通常は v1.v2.v3 などの形式が使用されます。ピアノードはバージョンをチェックしません。組織を支援するように設計されたインジケーターであり、チェーンコードロジックを更新するときに調整します。
シーケンス:チャネル上でチェーンコードが定義される回数。この値は、チェーンコードのアップグレードを追跡するために使用される整数です。たとえば、初めてチェーンコード定義が承認され、チャネルに送信されるときは、シーケンス番号を 1 に設定する必要があります。次回チェーンコードがアップグレードされるか、チェーンコード定義が更新されると、シーケンス番号は 2 に増加します。シーケンス番号はピアノードによって使用され、すべての組織が承認および送信されたチェーンコード定義と同期していることを確認します。
承認ポリシー:どの組織がトランザクション出力を実行および検証する必要があるか。承認ポリシーは、CLI に渡される文字列として表現することも、チャネル設定内のポリシーを参照することもできます。デフォルトでは、承認ポリシーはチャネル/アプリケーション/承認に設定されており、チャネル内のほとんどの組織がトランザクションを承認する必要があります。
コレクション構成:チェーンコードに関連付けられたプライベートデータ収集定義ファイルへのパス。プライベートデータコレクションの詳細については、「プライベートデータスキーマリファレンス」を参照してください。
ESCC/VSCC プラグイン:チェーンコードで使用されるカスタム承認または検証プラグインの名前。
初期化: Fabric ChainCode Shim API によって提供される低レベル API を使用する場合、チェーンコードには、チェーンコードを初期化するための Init 関数が含まれている必要があります。この関数はチェーンコードインターフェイスで必要ですが、アプリケーションで呼び出す必要はありません。チェーンコード定義を承認するときに、呼び出す前に Init を呼び出す必要があるかどうかを指定できます。Init が必須であると指定すると、ファブリックは、Init がチェーンコード内の他の関数よりも前にこの関数を呼び出し、一度だけ呼び出すようにします。Init 関数の実行をリクエストすると、チェーンコードの初期化時に実行されるロジックを実装できます。いくつかの初期状態を設定します。チェーンコードのバージョンをインクリメントするたびに、チェーンコードがバージョン表示をインクリメントするために必要な init を定義していると仮定して、init を呼び出してチェーンコードを初期化する必要があります。

チェーンコード定義にはパッケージ識別子も含まれます。これは、チェーンコードを使用するすべての組織にとって必須のパラメータです。パッケージ ID は、すべての組織で同じである必要はありません。組織は、チェーンコードをインストールしたり、定義に識別子を含めたりしなくても、チェーンコード定義を承認できます。

チェーンコードを使用したい各チャネルメンバーは、組織のチェーンコード定義を承認する必要があります。この承認は順序付けサービスに送信され、すべてのピアに配布される必要があります。この承認は、組織管理者によって送信される必要があります。承認トランザクションが正常に送信されると、承認された定義は、組織内のすべてのピアが使用できるコレクションに保存されます。したがって、複数のピアがある場合でも、組織はチェーンコードを 1 回承認するだけで済みます。

Org1 と Org2 の組織管理者は、組織に対する MYCC のチェーンコード定義を承認します。チェーンコード定義には、チェーンコード名、バージョン、承認ポリシーなどのフィールドが含まれます。両方の組織はチェーンコードを使用してトランザクションを承認するため、両方の組織の承認定義に packageID を含める必要があります。

2.1.4 チェーンコードをチャネルに送信する

十分な数のチャネルメンバーがチェーンコード定義を承認すると、組織はその定義をチャネルに送信できます。ピア CLI を使用して定義をチャネルにコミットする前に、checkcommitreadiness コマンドを使用して、どのチャネルメンバーが定義を承認したかに基づいてチェーンコード定義の送信が成功するかどうかを確認できます。送信されたトランザクション提案は、まずチャネルのメンバーであるピアに送信され、ピアは組織によって承認されたチェーンコード定義をクエリし、組織によって承認された場合はその定義を承認します。次に、トランザクションを発注者に送信し、チェーンコード定義をチャネルに送信します。定義トランザクションを送信するには、組織の管理者として送信する必要があります。

チャネルへの送信を成功させるために定義を承認する必要がある組織の数は、Channel/Application/LifecycleEndorsement ポリシーによって制御されます。デフォルトでは、このポリシーではチャネル内の組織の大多数がトランザクションを承認する必要があり、LifecycleEndorsement ポリシーはチェーンコード承認ポリシーとは別のものです。たとえば、チェーンコード承認ポリシーで 1 つまたは 2 つの組織からの署名のみが必要な場合でも、チャネルメンバーの大多数はデフォルトポリシーに従ってチェーンコード定義を承認する必要があります。チャネル定義を送信するときは、十分な数のピア組織を対象にする必要があります。要件を満たすチャネル。LifecycleEndorsement ポリシー。

Channel/Application/LifeCycleEndoseMent ポリシーを署名ポリシーとして設定し、チェーンコード定義を承認できるチャネル上の組織のセットを明示的に指定することもできます。これにより、選択した数の組織がチェーンコード管理者として機能し、チャネルで使用されるビジネスロジックを管理するチャネルを作成できます。また、チャンネルに多数のIdemix組織があり、チェーンコードの定義を承認したり、チェーンコードを承認したりできないため、チャンネルが過半数に達することができない可能性がある場合にも、署名ポリシーを使用することができます。

Org1 または Org2 の組織管理者は、チェーンコード定義をチャネルに送信します。チャネル上の定義には packageID が含まれていません。

チェーンコード定義がチャネルに送信されると、チェーンコードがインストールされているすべてのピアでチェーンコードコンテナーが開始され、チャネルメンバーがチェーンコードの使用を開始できるようになります。チェーンコードコンテナーの開始には数分かかる場合があります。チェーンコードを初期化するために Init 関数を呼び出す必要があるように定義されています。Init リクエストが関数を呼び出す場合、チェーンコードの最初の呼び出しは Init 関数の呼び出しである必要があります。関数 Init の呼び出しは、チェーンコードの承認ポリシーの対象となります。

2.2 アップグレードチェーンコード

チェーンコードのインストールと起動と同じファブリックライフサイクルプロセスを使用して、チェーンコードをアップグレードできます。チェーンコードバイナリをアップグレードするか、チェーンコードポリシーを更新するだけです。チェーンコードをアップグレードするには、次の手順に従います。

チェーンコードを再パッケージ化する:チェーンコードバイナリをアップグレードする場合にのみ、この手順を完了する必要があります。

Org1 と Org2 はチェーンコードバイナリをアップグレードし、チェーンコードを再パッケージ化します。どちらの組織も以前とは異なるパッケージングタグを使用します。
新しいチェーンコードパッケージをピアにインストールします。この手順も、チェーンコードバイナリをアップグレードする場合にのみ完了する必要があります。新しいチェーンコードパッケージをインストールすると、新しいチェーンコード定義に渡す必要があるパッケージ ID が生成されます。また、チェーンコードバイナリがアップグレードされたかどうかを追跡するためにライフサイクルプロセスで使用されるチェーンコードのバージョンを変更する必要もあります。

Org1 と Org2 は、新しいパッケージをピアにインストールします。インストールすると、新しい packageID が作成されます。
新しいチェーンコード定義を承認する:チェーンコードバイナリをアップグレードする場合は、チェーンコード定義内のチェーンコードバージョンとパッケージ ID を更新する必要があります。チェーンコードバイナリを再パッケージせずにチェーンコード承認ポリシーを更新することもできます。チャネルメンバーは新しいポリシーの定義を承認するだけで、定義内のシーケンス変数をインクリメントする必要があります。

Org1 と Org2 の組織管理者は、それぞれの組織の新しいチェーンコード定義を承認します。新しい定義は新しい packageID を参照し、チェーンコードのバージョンを変更します。これはチェーンコードの最初の更新であるため、シーケンスが 1 から 2 に増加します。
定義をチャネルに送信する:十分な数のチャネルメンバーが新しいチェーンコード定義を承認すると、組織は、別のアップグレードコマンドを使用せずに、ライフサイクルプロセスの一環として新しい定義を送信してチェーンコード定義をチャネルにアップグレードできます。

Org1 または Org2 の組織管理者は、新しいチェーンコード定義をチャネルに送信します。

チェーンコード定義をコミットすると、アップグレードされたチェーンコードバイナリ内のコードを使用して新しいチェーンコードコンテナが開始されます。チェーンコード定義でこの関数の実行をリクエストする場合は、新しい定義が正常に送信された後にこの関数を再度呼び出して、アップグレードされたチェーンコードを初期化する必要がありますチェーンコードのバージョンを変更せずにチェーンコード定義が更新された場合、チェーンコードのコンテナーは変更されず、Init 関数を呼び出す必要はありません。

新しい定義をチャネルに送信すると、各ピアは新しいチェーンコードコンテナを自動的に開始します。

ファブリックチェーンコードのライフサイクルは、チェーンコード定義内のシーケンスを使用してアップグレードを追跡します。チェーンコードをアップグレードするには、すべてのチャネルメンバーがシリアル番号をインクリメントし、新しい定義を承認する必要があります。version パラメーターはチェーンコードバイナリを追跡するために使用され、チェーンコードバイナリをアップグレードする場合にのみ変更する必要があります。

要約する

参考：ファブリックチェーンコードのライフサイクル — hyperledger-fabricdocs のメインドキュメント

Hyperledger Fabric チェーンコードのライフサイクル