Channel capabilities¶

対象読者: チャネル管理者、ノード管理者

注意: これは、新しいユーザーやアプリケーション開発者が理解する必要のない高度なFabricの概念です。ただし、チャネルやネットワークが成熟するにつれて、ケーパビリティの理解と管理が不可欠になります。さらに、アップデートケーパビリティは、ノードのアップグレードとは別のプロセスですが、関連することが多いプロセスであることを認識することも重要です。この点については、このトピックで詳しく説明します。

Fabricは通常、複数の組織が関与する分散システムであるため、異なるバージョンのFabricコードが、ネットワーク内の異なるノードおよびそのネットワーク内のチャネルに存在する可能性があります。Fabricでは、すべてのピアとオーダリングサービスが同じバージョンレベルである必要はありません。実際、異なるバージョンレベルをサポートすることで、Fabricノードのローリングアップグレードが可能になります。

重要なのは、ネットワークとチャネルが同じ方法で処理し、チャネル設定の更新やチェーンコード呼び出しなどの決定的な結果を生成することです。結果が決定的でなければ、チャネル上のあるピアがトランザクションを正当としない(無効)一方で、別のピアはトランザクションを正当とするかもしれません。

そのために、Fabricは「ケーパビリティ(capabilities)」と呼ばれるレベルを定義します。これらのケーパビリティは、各チャネルの設定で定義され、動作が一貫した結果を生成するレベルを定義することによって決定性を保証します。これらのケーパビリティには、ノードのバイナリバージョンと密接に関連したバージョンがあります。ケーパビリティにより、異なるバージョンレベルで実行されているノードは、特定のブロックの高さでのチャネル設定を前提として、互換性のある一貫した方法で動作することができます。また、特定のタスクを行うための管理領域ごとに定義されたケーパビリティが、設定ツリーの多くの部分に存在することもわかります。

これから説明するように、新しい機能を有効にするためには、チャネルを新しいケーパビリティレベルに更新する必要がある場合があります。

Node versions and capability versions¶

Hyperledger Fabricに精通している場合は、Fabricはv1.1、v1.2.1、v2.0などの一般的なバージョン管理パターンに従うことを知っていると思います。これらのバージョンは、リリースおよび関連するバイナリバージョンを指します。

ケーパビリティは、同じバージョン付け規則に従います。v1.1のケーパビリティ、v1.2のケーパビリティ、v2.0のケーパビリティなどがあります。しかし、いくつかの違いに注意することが重要です。

リリースごとに新しいケーパビリティレベルがあるとは限りません。新しいケーパビリティを確立する必要性は、ケースバイケースで判断され、主に新しい機能と古いバイナリバージョンの後方互換性に依存します。例えば、v1.4.1でRaftオーダリングサービスを追加した時も、トランザクションやオーダリングサービス機能の処理方法は変わらないので、新しいケーパビリティを確立する必要はありませんでした。一方で Private Dataはv1.2より前のピアでは処理できず、v1.2のケーパビリティレベルを確立する必要がありました。すべてのリリースにトランザクションの処理方法を変更する新機能(またはバグ修正)が含まれているわけではないため、特定のリリース(v1.4など)では新しいケーパビリティは必要ありませんが、特定のレベル(v1.2やv1.3など)でのみ新しいケーパビリティが必要なリリースもあります。ケーパビリティの「レベル」と、それらのケーパビリティが設定ツリーのどこにあるかについては後ほど説明します。
ノードは、少なくともチャネル内の特定のケーパビリティレベルでなければなりません。ピアがチャネルに参加すると、台帳内のすべてのブロックが順番に読み取られます。これは、チャネルのジェネシスブロックから始まり、トランザクションブロックおよびそれ以降のすべてのコンフィグレーションブロックにわたって続きます。ピアなどのノードが、認識できないケーパビリティの更新を含むブロックを読み取ろうとした場合(たとえば、v1.4.xピアがv2.0アプリケーションケーパビリティを含むブロックを読み取ろうとした場合)、 ピアはクラッシュします。v1.4.xピアはこの時点を過ぎてもトランザクションの検証やコミットを試行しないため、このクラッシュ動作は意図的なものです。チャネルに参加する前に、ノードが、そのノードに関連するチャネル設定で指定されたケーパビリティのFabricバージョン(バイナリ)レベル以上であることを確認してください。どのケーパビリティがどのノードに関連するかについては、後で説明します。といっても、ユーザーはノードがクラッシュすることを望んでいないため、ケーパビリティを更新する前に、すべてのノードを必要なレベル(できれば最新リリース)に更新することを強くお勧めします。これは、常に最新のバイナリおよびケーパビリティレベルにするというデフォルトのFabricの推奨事項に沿っています。

ユーザーがバイナリをアップグレードできない場合は、ケーパビリティを下位レベルに残しておく必要があります。下位レベルのバイナリとケーパビリティは、本来の目的どおりに動作します。ただし、ユーザーがケーパビリティを更新しないことを選択した場合でも、常に新しいバイナリに更新することをお勧めします。ケーパビリティ自体にもバグ修正が含まれているため、ネットワークバイナリがケーパビリティをサポートするようになったら更新することをお勧めします。

Capability configuration groupings¶

すでに説明したように、チャネル全体を網羅する単一のケーパビリティレベルはありません。むしろ、3つのケーパビリティがあり、それぞれ管理領域を表しています。

Orderer: これらのケーパビリティは、オーダリングサービス専用のタスクと処理を制御します。これらのケーパビリティには、トランザクションやピアに影響を与えるプロセスが含まれていないため、これらのケーパビリティの更新は、オーダリングサービスの管理者に委ねられています。(ピアはOrdererケーパビリティを理解する必要がないため、Ordererケーパビリティが何に更新されてもクラッシュしません)。ただし、チャネルのセクションで説明するように、これは、v1.1のオーダリングノードがv1.4.2より低いケーパビリティレベルのすべてのチャネルで機能することを意味するわけではありません。
アプリケーション(Application): これらのケーパビリティは、ピア専用のタスクと処理を制御します。オーダリングサービスの管理者は、ピア組織間のトランザクションの性質を決定する役割を持たないため、このケーパビリティレベルの変更は、ピア組織間に限定されます。たとえば、プライベートデータは、v1.2(またはそれ以降)のアプリケーション・グループ・ケーパビリティが有効になっているチャネルでのみ有効にできます。プライベートデータの場合、チャネル管理やオーダリングサービスによるトランザクションの処理方法を変更する必要がないため、これが唯一有効にしなければいけないケーパビリティとなります。
チャネル（Channel）: このグループには、ピア組織とオーダリングサービスが共同で管理するタスクが含まれます。たとえば、ピア組織によって開始されオーダリングサービスによってオーケストレーションされるチャネル設定の更新が処理されるレベルを定義するケーパビリティです。実用的なレベルでは、このグループは、チャネル内のすべてのバイナリの最小レベルを定義します。これは、オーダリングサービスとピアの両方が、ケーパビリティを処理するために、少なくともこのケーパビリティに対応するバイナリ・レベルでなければならないためです。

チャネルのOrdererケーパビリティとチャネルケーパビリティは、デフォルトではオーダリングシステムチャネルから継承されます。このチャネルの変更は、オーダリングサービス管理者だけの権限です。そのため、ピア組織は、ピアをチャネルに参加させる前に、チャネルのジェネシスブロックを検査する必要があります。チャネルケーパビリティは、(コンソーシアムのメンバーシップと同様に)オーダリングシステムチャネルのOrdererによって管理されますが、一般的に、オーダリングサービス管理者は、コンソーシアムの準備ができたときにのみチャネルケーパビリティがアップグレードされるように、コンソーシアムの管理者と調整します。

オーダリングシステムチャネルはアプリケーションケーパビリティを定義しないため、チャネルのジェネシスブロックを作成するときに、このケーパビリティをチャネルプロファイルで指定する必要があります。

アプリケーションケーパビリティを指定または変更する場合は注意が必要です。オーダリングサービスは、ケーパビリティレベルが存在することを検証しないため、そのようなケーパビリティが存在しない場合でも、たとえばv1.8アプリケーションケーパビリティを含むチャネルを作成(または変更)できます。このケーパビリティを使用してコンフィグレーションブロックを読み取ろうとすると、ピアがクラッシュし、チャネルを再び有効なケーパビリティレベルに変更できたとしても、無効なv1.8のケーパビリティを使用してブロックを通過できるピアがないため、問題にはなりません。

現在有効なOrderer、アプリケーション、およびチャネルケーパビリティの詳細については、「Capabilities」セクションにリストされているsample configtx.yaml fileを参照してください。

ケーパビリティおよびチャネル設定内でのケーパビリティの設定箇所に関する詳細については、defining capability requirementsを参照してください。