Issues With Private Data and Confidentiality in Hyperledger Fabric [Deep Dive]

In many blockchain platforms such as Ethereum and Bitcoin, data confidentiality is a kind of excluded item in their blockchain framework. In these distributed blockchain platform transactions are executed in every participant node in the network. So, every transaction in the network can be visible to all the peers. The ledger update process through all the endorsed peers and has to reach an agreement among all before it committed successfully to the ledger. So, in this scenario creating a private record and comprises within a certain group of participants in the network is a complete “No”.

Why Private Data?

In today’s enterprise business sector data confidentiality is a real biggest challenged for the companies. Many competitors in the market seek data privacy and confidentiality for their clients. But all the major blockchain platforms provide a Permissionless platform and their architecture doesn’t provide such facility to create a transaction for certain groups.

In this case, Hyperledger Fabric utilizes the opportunity of controlling as a Permissioned platform enabling structured Private Data architecture. We will see in the course of this article, how the Transaction flows with Private data architecture in Hyperledger Fabric.

Transaction flow with Private Data

In Hyperledger Fabric, there are many different approaches to create private transactions among a few organizations and discarding the visibility of the content of the transaction from other organizations.

In the first approach, there are can be separate individual channels for certain organizations only, so whichever organizations are authorized to see the private data can only join the channel. But creating a private channel creates additional administrative overhead and makes process complex to maintain the Chanicode version, policy, and other configuration details.

So, there is another structural procedure by creating Private Data Collection for certain organizations. The private data collection will be stored in a side database called SideDB. The side database is only accessible to authorized organizations. The Ordering Service does not see the private data but can only process the hash of private data to all the endorsed peers in the network for validation and ledger update process. Yes, all the remaining participants will get a copy of private data with hash encrypted.

In comparison with the Ordering Service Transaction flow, Private data transaction flow differs in some cases.

The client application sends the transaction proposal request to the only authorized endorsing peers. Then the peer invokes the request into the Chaincode.
The peers analyze the private data transaction and stores in the transient data store. Then, the private data collection distributed to other authorized peers via gossip protocol.
Now the endorsing peers return the proposal response to the client and the response contains the only hash of private data, it’s private key-value pair. The client doesn’t get the original private data in the response.
The client submits the transaction response to the Ordering Service. The hashed private data gets included in the block.
The block containing the hash of the private data is distributed to the remaining peers in the network. So the block can be validated among all the peers consistently.
The authorized peers will validate their private data with the public block containing the hash of the private data. If it matches then they move the private data into the Private State Database and Private Writeset Storage. And then the Private data is deleted from temporary local peer storage or transient data store.

Private Data Collection Policy

As we can create collections among authorized organizations, so the collections will follow policy while instantiating the Chaincode. These policies define which organization’s peers are authorized to store the private data in their private state database.

And these policies will be different from overall endorsing peer policy for a single Chaincode instantiation.

In Hyperledger Fabric Go SDK, we can create a collection config for each collection and can use it while instantiating a Chaincode

collCfg1, _ := newCollectionConfig("collectionOrg1Org2", "OR ('Org1MSP.member', 'Org2MSP.member')", peerCount, maximumPeerCount, blockToLive)
collCfg2, _ := newCollectionConfig("collectionOrg3Org4", "OR ('Org3MSP.member', 'Org4MSP.member')", peerCount, maximumPeerCount, blockToLive).

Here there are two collection configs for two sets of organization groups.

collCfg1 belongs only to Org1 & Org2

collCfg2 belongs only to Org3 & Org4

Function newCollectionConfig

func newCollectionConfig(colName, policy string, reqPeerCount, maxPeerCount int32, blockToLive uint64) (*cb.CollectionConfig, error) {
p, err := cauthdsl.FromString(policy)
if err != nil {
            fmt.Println("failed to create newCollectionConfig : "+err.Error())
            return nil, err
        }
        cpc := &amp;cb.CollectionPolicyConfig{
            Payload: &amp;cb.CollectionPolicyConfig_SignaturePolicy{
                SignaturePolicy: p,
            },
        }
        return &amp;cb.CollectionConfig{
            Payload: &amp;cb.CollectionConfig_StaticCollectionConfig{
                StaticCollectionConfig: &amp;cb.StaticCollectionConfig{
                    Name:              colName,
                    MemberOrgsPolicy:  cpc,
                    RequiredPeerCount: reqPeerCount, 
                    MaximumPeerCount:  maxPeerCount, 
                    BlockToLive:       blockToLive,
                },
            },
        }, nil
   }

Instantiation of Chaincode

While instantiating the chaincode, all the collection configs will be added into a config array.


cfg := []*cb.CollectionConfig{ collCfg1, collCfg2}
policy = "OR ('Org1MSP.member','Org2MSP.member','Org3MSP.member','Org4MSP.member')"
// here this policy is a completely separate entity, it relates to the all organization's peers following an endorsing policy to validate all the blocks in the network consistently.

ccPolicy, _ := cauthdsl.FromString(policy) // cauthdsl will convert the policy string to Policy object
resp, err := s.Resmgmt.InstantiateCC(
     s.ChannelID,
     resmgmt.InstantiateCCRequest{
        
            Name:       s.ChaincodeId,
            Path:       s.ChaincodePath,
            Version:    s.ChainCodeVersion,
            Args:       [][]byte{[]byte("init")},
            Policy:     ccPolicy,
            CollConfig: cfg,
     },resmgmt.WithRetry(retry.DefaultResMgmtOpts), resmgmt.WithTargets(orgPeers[0], orgPeers[1]))

PrivateLedger

I have developed a POC demonstrating the Private Data Collection using Fabric Go SDK. It’s more like an implementation of Fabric Go SDK libraries for Private data. Please follow below GitHub link below to check the project.

Github: https://github.com/Deeptiman/privateledger

This project requires us to be familiar with the Multi Organization setup using Fabric Go SDK. So, If you need a reference then I have published a Medium article to describe the step by step process for the Multi Organization setup. Please have a look at it.

“A Multi Organization Application in Hyperledger Fabric”

So, this is the overall description regarding the role of Hyperledger Fabric in Data Confidentiality and Privacy. I hope this article gave you some useful insight into the topic.

Please find the article useful :)

Thanks