What is private data?¶
In cases where a group of organizations on a channel need to keep data private from other organizations on that channel, they have the option to create a new channel comprising just the organizations who need access to the data. However, creating separate channels in each of these cases creates additional administrative overhead (maintaining chaincode versions, policies, MSPs, etc), and doesn’t allow for use cases in which you want all channel participants to see a transaction while keeping a portion of the data private.
That’s why Fabric offers the ability to create private data collections, which allow a defined subset of organizations on a channel the ability to endorse, commit, or query private data without having to create a separate channel.
Private data collections can be defined explicitly within a chaincode definition. Additionally, every chaincode has an implicit private data namespace reserved for organization-specific private data. These implicit organization-specific private data collections can be used to store an individual organization’s private data, which is useful if you would like to store private data related to a single organization, such as details about an asset owned by an organization or an organization’s approval for a step in a multi-party business process implemented in chaincode.
What is a private data collection?¶
A collection is the combination of two elements:
- The actual private data, sent peer-to-peer via gossip protocol to only the organization(s) authorized to see it. This data is stored in a private state database on the peers of authorized organizations, which can be accessed from chaincode on these authorized peers. The ordering service is not involved here and does not see the private data. Note that because gossip distributes the private data peer-to-peer across authorized organizations, it is required to set up anchor peers on the channel, and configure CORE_PEER_GOSSIP_EXTERNALENDPOINT on each peer, in order to bootstrap cross-organization communication.
- A hash of that data, which is endorsed, ordered, and written to the ledgers of every peer on the channel. The hash serves as evidence of the transaction and is used for state validation and can be used for audit purposes.
The following diagram illustrates the ledger contents of a peer authorized to have private data and one which is not.
Collection members may decide to share the private data with other parties if they get into a dispute or if they want to transfer the asset to a third party. The third party can then compute the hash of the private data and see if it matches the state on the channel ledger, proving that the state existed between the collection members at a certain point in time.
In some cases, you may decide to have a set of collections each comprised of a single organization. For example an organization may record private data in their own collection, which could later be shared with other channel members and referenced in chaincode transactions. We’ll see examples of this in the sharing private data topic below.
When to use a collection within a channel vs. a separate channel¶
- Use channels when entire transactions (and ledgers) must be kept confidential within a set of organizations that are members of the channel.
- Use collections when transactions (and ledgers) must be shared among a set of organizations, but when only a subset of those organizations should have access to some (or all) of the data within a transaction. Additionally, since private data is disseminated peer-to-peer rather than via blocks, use private data collections when transaction data must be kept confidential from ordering service nodes.
A use case to explain collections¶
Consider a group of five organizations on a channel who trade produce:
- A Farmer selling his goods abroad
- A Distributor moving goods abroad
- A Shipper moving goods between parties
- A Wholesaler purchasing goods from distributors
- A Retailer purchasing goods from shippers and wholesalers
The Distributor might want to make private transactions with the Farmer and Shipper to keep the terms of the trades confidential from the Wholesaler and the Retailer (so as not to expose the markup they’re charging).
The Distributor may also want to have a separate private data relationship with the Wholesaler because it charges them a lower price than it does the Retailer.
The Wholesaler may also want to have a private data relationship with the Retailer and the Shipper.
Rather than defining many small channels for each of these relationships, multiple private data collections (PDC) can be defined to share private data between:
- PDC1: Distributor, Farmer and Shipper
- PDC2: Distributor and Wholesaler
- PDC3: Wholesaler, Retailer and Shipper
Using this example, peers owned by the Distributor will have multiple private databases inside their ledger which includes the private data from the Distributor, Farmer and Shipper relationship and the Distributor and Wholesaler relationship.
Transaction flow with private data¶
When private data collections are referenced in chaincode, the transaction flow is slightly different in order to protect the confidentiality of the private data as transactions are proposed, endorsed, and committed to the ledger.
For details on transaction flows that don’t use private data refer to our documentation on transaction flow.
- The client application submits a proposal request to invoke a chaincode
function (reading or writing private data) to a target peer, which will manage
the transaction submission on behalf of the client. The client application can
specify which organizations
should endorse the proposal request, or it can delegate the
endorser selection logic
to the gateway service in the target peer. In the latter case, the gateway will
attempt to select a set of endorsing peers which are part of authorized organizations
of the collection(s) affected by the chaincode. The private data, or data used to
generate private data in chaincode, is sent in a
transientfield in the proposal.
- The endorsing peers simulate the transaction and store the private data in
transient data store(a temporary storage local to the peer). They distribute the private data, based on the collection policy, to authorized peers via gossip.
- The endorsing peers send the proposal response back to the target peer. The proposal response includes the endorsed read/write set, which includes public data, as well as a hash of any private data keys and values. No private data is sent back to the target peer or client. For more information on how endorsement works with private data, click here.
- The target peer verifies the proposal responses are the same before assembling the endorsements into a transaction, which is sent back to the client for signing. The target peer “broadcasts” the transaction (which includes the proposal response with the private data hashes) to the ordering service. The transactions with the private data hashes get included in blocks as normal. The block with the private data hashes is distributed to all the peers. In this way, all peers on the channel can validate transactions with the hashes of the private data in a consistent way, without knowing the actual private data.
- At block commit time, authorized peers use the collection policy to
determine if they are authorized to have access to the private data. If they do,
they will first check their local
transient data storeto determine if they have already received the private data at chaincode endorsement time. If not, they will attempt to pull the private data from another authorized peer. Then they will validate the private data against the hashes in the public block and commit the transaction and the block. Upon validation/commit, the private data is moved to their copy of the private state database and private writeset storage. The private data is then deleted from the
transient data store.
Note: The client application can collect the endorsements instead of delegating that step to the target peer. Refer to the v2.3 Peers and Applications topic for details.
Purging private data¶
For very sensitive data, even the parties sharing the private data might want — or might be required by government regulations — to periodically “purge” the data on their peers, leaving behind a hash of the data on the blockchain to serve as immutable evidence of the private data.
In some of these cases, the private data only needs to exist on the peer’s private database until it can be replicated into a database external to the peer’s blockchain. The data might also only need to exist on the peers until a chaincode business process is done with it (trade settled, contract fulfilled, etc).
To support these use cases, private data can be purged if it has not been modified for a configurable number of blocks. Purged private data cannot be queried from chaincode, and is not available to other requesting peers.