Private data

What is private data?

ある組織のグループが、同じチャネル上の他の組織からデータを秘匿する必要がある場合には、データへのアクセスが必要な組織だけから構成される新しいチャネルを作成することができます。しかし、このようにケースに応じて別のチャネルを作成するのは、追加の管理オーバヘッド(チェーンコードのバージョン、ポリシー、MSPなど）となり、また、全ての参加者にトランザクションを見せつつ、データの一部の秘匿化する必要があるユースケースには対応ができなくなります。

これが、Fabricがプライベートデータコレクションを提供する理由です。プライベートデータコレクションにより、新たにチャネルを作成する必要なく、チャネル内の組織のサブセットに、プライベートデータのエンドースメント、コミット、あるいはクエリーを行わせることができるのです。

What is a private data collection?

コレクションは、次の2つの要素の組み合わせです:

  1. 実際のプライベートデータ。そのデータを見る権限のある組織にのみ、ゴシッププロトコルでのpeer-to-peer通信でデータが送信されます。このデータは、許可された組織のピア内のプライベートステートデータベースに保管され、これら許可されたピア上のチェーンコードからアクセスすることができます。オーダリングサービスはここでは関与しないので、プライベートデータを見ることはありません。ゴシッププロトコルにより、許可された組織間のpeer-to-peer通信でプライベートデータが配布されるので、組織間の通信を開始するため、チャネル内にアンカーピアを設定し、各ピアにCORE_PEER_GOSSIP_EXTERNALENDPOINTを設定する必要があることに注意してください。

  2. 当該データのハッシュ。このハッシュ値は、エンドースされ、順序付けされ、チャネル上の各ピアの台帳に書き込まれます。ハッシュはトランザクションの証拠となり、ステートの検証に使われるとともに、監査目的で利用することもできます。

次の図は、プライベートデータを持つ権限があるピアとそうでないピアの台帳の内容を示しています。

private-data.private-data

係争に巻き込まれたり、資産を第3者に譲渡したいといった場合に、コレクションのメンバーはプライベートデータを他のメンバーに共有するようにすることもできます。その場合、第三者がプライベートデータのハッシュを計算し、それがチャネル台帳のステートと一致するかを確認して、コレクションのメンバー間で共有しているステートが特定の時点で存在していたことを証明することができます。

ケースによっては、単一の組織のみからなるコレクションのセットを定義することもできます。例えば、ある組織が自身のコレクションにプライベートデータを記録しておいて、後ほどチャネル内の他のメンバーに共有、チェーンコードトランザクションから参照してもらうということもできます。この具体的な例については、下のSharing private dataのトピックをご参照ください。

When to use a collection within a channel vs. a separate channel

A use case to explain collections

チャネル上で農産物を取引する5つの組織のグループを考えてみましょう：

Distributorは取引条件をWholesalerとRetailerから秘匿するために、FarmerとShipperとの間でプライベートトランザクションを利用しようとするかもしれません（彼らが値上げをしないようにするために）。

Distributorは、Retailerよりも低価格を請求するために、Wholesalerとの別のプライベートデータの関係を持ちたい場合もあります。

Wholesalerは、RetailerおよびShipperとのプライベートデータの関係も必要とする場合があります。

これらの関係ごとに多数の小さなチャネルを定義するのではなく、複数のプライベートデータコレクション (PDC) を定義して、以下の様にプライベートデータを共有できます:

  1. PDC1: Distributor, Farmer および Shipper
  2. PDC2: Distributor および Wholesaler
  3. PDC3: Wholesaler, Retailer および Shipper

private-data.private-data

この例を使用すると、Distributorが所有するピアは、台帳内に複数のプライベートデータベースを持ちます。このデータベースには、Distributor、Farmer、Shipperの関係およびDistributorとWholesalerとの関係のプライベートデータが含まれます。

private-data.private-data

Transaction flow with private data

プライベートデータコレクションがチェーンコードから参照される時には、トランザクションの提案、エンドースメント、および台帳へのコミットという一連のトランザクションフローは、プライベートデータの機密性の保護のため通常とやや異なります。

プライベートデータを使用しないトランザクションのフローの詳細については、当ドキュメントのtransaction flowをご参照ください。

  1. クライアントアプリケーションは、コレクションのアクセス許可のある組織内のエンドーシングピアに、チェーンコードの関数(プライベートデータの読み書き)を呼び出すための提案要求を発行します。プライベートデータ、あるいはプライベートデータをチェーンコード内で生成するために使われるデータは提案のtransientフィールドにて送信されます。

  2. エンドーシングピアはトランザクションをシミュレートし、プライベートデータをtransient data store(ピアのローカルにある一時ストレージ)に保管します。エンドーシングピアは、コレクションポリシーに従ってgossipにより許可されたピアにプライベートデータを配布します。

  3. エンドーシングピアは提案応答をクライアントに返します。提案応答には、パブリックデータを含むエンドースメント時のread/writeセット、およびプライベートデータのキーと値のハッシュ値を含みます。プライベートデータはクライアントに返されません。プライベートデータを伴うエンドースメントの振る舞いのより詳しい情報についてはこちらをクリックください。

  4. クライアントアプリケーションは、トランザクション（プライベートデータのハッシュ付きの提案応答を含む）をオーダリングサービスに送信します。プライベートデータのハッシュ付きのトランザクションは、通常どおりブロックに含まれます。プライベートデータハッシュを持つブロックは、すべてのピアに配布されます。このようにして、チャネル上のすべてのピアは、実際のプライベートデータを知らなくても、一貫した方法でプライベートデータのハッシュを使用してトランザクションを検証できます。

  5. ブロックのコミット時には、許可されたピアはコレクションポリシーを使用してプライベートデータへのアクセス権限があるかどうかを判断します。もし受け取っていなければ、そのピアは最初に、チェーンコードの承認時にプライベートデータをすでに受け取っているかを判断するために、ローカルのtransient data storeを確認します。もし権限がなければ、ピアは他の許可されたピアからプライベートデータを取得しようとします。その後、ピアはパブリックブロックの中のハッシュとの比較でプライベートデータを検証し、トランザクションとブロックをコミットします。検証/コミット時には、プライベードデータは、プライベートステートデータベースのコピーとプライベートライトセットストレージに移されます。その後、プライベートデータは、transient data storeから削除されます。

Sharing private data

多くのシナリオにおいて、１つのコレクション内のプライベートデータのキー/バリューは、他のチャネルメンバー、あるいは他のプライベートコレクションと共有される必要があるかもしれません。例えば、元々のプライベートデータコレクションに含まれていない単一の、あるいは複数のチャネルメンバーとプライベートデータをやりとりする必要がある場合などです。データを受領したメンバーは通常、トランザクションの一部であるオンチェーンハッシュを使ってプライベートデータの検証をしたいものです。

プライベートデータの共有と検証を可能にするために、プライベートデータコレクションにはいくつかの特徴があります:

プライベートデータを共有し検証するこの機能は、アプリケーションと、関連するプライベートデータコレクションを設計する時に留意しておく必要があります。チャネルメンバーの様々な組み合わせの中でデータを共有する複数のプライベートデータコレクションのセットを作成することももちろん出来ますが、このアプローチは結果的に多数のコレクションを定義する必要が出てしまいます。代わりに、少数のプライベートデータコレクションを使い(例：組織ごとに1コレクション、あるいは組織のペアごとに1コレクション)、そのプライベートデータを他のチャネルメンバー、あるいは他のコレクションと必要に応じて共有する、ということも検討してください。Fabric v2.0からは、暗黙的な組織固有コレクションが全てのチェーンコードから利用可能となり、これによりチェーンコードのデプロイ時にこれら組織単位のコレクションを定義する必要さえなくなりました。

Private data sharing patterns

プライベートデータコレクションの設計においては、多数の複数組織間のコレクションを定義するというオーバーヘッドなしに、プライベートデータを共有し転送する複数のパターンが利用可能です。チェーンコードアプリケーションが利用可能ないくつかの共有パターンを挙げます:

上記のパターンに加えて、プライベートデータを使用したトランザクションは、通常のチャネルのステートデータと同様に、具体的には次のような条件に紐付けることできます：

Example scenario: Asset transfer using private data collections

上記のプライベートデータ共有パターンを組み合わせることで、強力なチェーンコードベースのアプリケーションを実現できます。例えば、組織別のプライベートデータコレクションを使用して資産移転シナリオを実装する方法を考えてみましょう:

資産を取引するトランザクションは、次のように動作します:

  1. オフチェーンにて、所有者と潜在的な買い手が、資産を特定の価格で取引する契約を結びます。

  2. 売り手は、プライベートデータの詳細をFabricネットワーク外で渡すか、買い手のノードまたは規制機関のノード上のプライベートデータを照会するための資格情報を買い手に提供することによって、所有権の証明を提供します。

  3. 買い手は、プライベートデータの詳細のハッシュがオンチェーンの公開ハッシュと一致することを確認します。

  4. 買い手はチェーンコードを呼び出して、入札の詳細を自身のプライベートデータコレクションに記録します。買い手のピアでチェーンコードが呼び出され、コレクションエンドースメントポリシーによって要求されている場合には、規制機関のピアでチェーンコードが呼び出される可能性があります。

  5. 現在の所有者(売り手)は、チェーンコードを呼び出して資産を販売および譲渡し、プライベートデータの詳細および入札情報を渡します。チェーンコードは、パブリックなキーのエンドースメントポリシー、ならびに買い手と売り手のプライベートデータコレクションのエンドースメントポリシーを満たすよう、売り手、買い手、および規制機関のピアにて起動します。

  6. チェーンコードは、送信クライアントが所有者であることを確認し、売り手のコレクションのハッシュに対してプライベートデータの詳細を確認し、買い手のコレクションのハッシュに対して入札詳細を確認します。次に、チェーンコードは、パブリックなキーに対する提案された更新を書き込み(買い手に所有権を設定し、買い手の組織および規制機関としてエンドースメントポリシーを設定)、買い手のプライベートデータコレクションにプライベートデータの詳細を書き込み、場合によっては、売り手のコレクションからプライベートデータの詳細を削除します。最終的なエンドースメントの前に、エンドーシングピアは、権限を持つ売り手と規制機関のすべてのピアにプライベートデータが確実に配布されるようにします。

  7. 売り手は、オーダリングサービスにパブリックデータおよびプライベートデータのハッシュを付加してトランザクションを送信し、そのトランザクションはブロックに含まれる形で、チャネル内の全てのピアに配布されます。

  8. 各ピアのブロック検証ロジックは、エンドースメントポリシーが満たされたこと(買い手、売り手、規制機関のすべてがエンドースしたこと)を一貫して検証し、チェーンコードで読み取られたパブリックおよびプライベートのステートが、チェーンコードの実行後に他のトランザクションによって変更されていないことを検証します。

  9. すべてのピアは、検証チェックを通過したため、トランザクションを有効なものとしてコミットします。売り手のピアおよび規制機関のピアは、エンドースメント時にプライベートデータを受信していなかった場合、他の承認されたピアからプライベートデータを取得し、そのプライベートデータを自身のプライベートデータのステートデータベースに保持します(プライベートデータがトランザクションのハッシュと一致すると仮定します)。

  10. トランザクションが完了すると、資産は譲渡され、資産に関心を持つ他のチャネルメンバーは、公開鍵の履歴を照会してその出所を把握することができます。しかし、所有者が必要に応じてそれを共有しない限り、プライベートデータの詳細にアクセスすることはできません。

基本的な資産移転シナリオは、他の考慮事項にも拡張することができます。例えば、移転のチェーンコードは、実行前に、支払対引渡の要件を満たすために支払記録が利用可能であることを検証することができたり、銀行が信用状を提出したことを検証することができます。また、取引者が直接ピアを所有する代わりに、ピアを所有している保管組織を通じてトランザクションを実行することもできます。

Purging private data

非常に機密性の高いデータの場合、個人データを共有している当事者でさえ、ブロックチェーン上にデータのハッシュを残し、個人データの不変の証拠として機能させながら、定期的にピア上のデータを「パージ」(消去)することを望むかもしれないし、行政の規制によってパージを要求されるかもしれません。

このような場合、いくつかのケースでは、プライベートデータは、ピアのブロックチェーンの外部のデータベースに複製されるようになるまでの間のみ、ピアのプライベートデータベースに存在する必要があります。データは、チェーンコードビジネスプロセス(取引の決済、契約の履行など)が完了するまで、ピア上に存在していればよい場合もあります。

これらの使用例をサポートするために、設定したブロック数にわたってプライベートデータが変更されていない場合は、プライベートデータをパージできます。パージされたプライベートデータは、チェーンコードから照会できません。また、他の要求元ピアからは使用できません。

How a private data collection is defined

コレクション定義の詳細、およびプライベートデータとコレクションに関するその他のローレベルの情報については、private data reference topicを参照してください。