How does a Ledger update transaction happen in Hyperledger fabric network with private data and without private data
There is a bit difference between ledger update transaction and query transaction because single peer cannot update the ledger by own. It requires the consent of other peers in the network. As well as, when some peers have private data the transaction is happening in another different way.
Firstly I am going to describe how the transaction happens when there is not any private data.
Ledger update transaction goes through three steps. The first step is between application and set of peers. It does not involve orderers. It is all about an application is asking for different organizations’ endorsing peers to agree to the results of the proposed chaincode invocation.
In this phase, an application will generate a transaction proposal that will be sent to each of the required set of peers for endorsement. Then each of these endorsement peers will execute the chain code using the transaction proposal and generate transaction proposal response. It does not apply this update to ledger but simply signs it and send it back to the application. When an application receives a sufficient number of signed proposal responses the first step of the transaction is completed.
Different peers can return different and therefore inconsistent transaction responses to the application for the same transaction proposal. It might simply be that the result was generated at different times on different peers with ledgers at different states, in which case an application can simply request a more up-to-date proposal response. Inconsistent results are cannot be applied to ledgers. The application is free to drop any inconsistent response.
In the second step, the packaging is happening. Orderer is crucial to this process. It receives transactions containing endorsed transaction proposal responses from many applications. It orders each transaction which is relative to each other and packages set of (batches ) transactions into blocks in order to distribute back to all connected peers including original endorsing peers. These transaction blocks which is described in the previous sentence becomes blocks of the blockchain. The sequence of the transaction is not the same sequence as the order of arrival of transactions at the orderer!.
Now we are going for the third and the final step of the transaction. This step is concerned with the distribution and subsequent validation of blocks from the orderer to the peers, where they can be applied to the ledger. Deeply what is happening here is, at each peer transaction within a block is validated to ensure that it has been consistently endorsed by all relevant organizations before it is applied to the ledger. They will keep failed transactions for audit purposes but will not be applied to ledgers.
In this step, the copy of the block is sent to all the peers connected to the Orderer and all the peers will process the blocks independently but in the same way. Every peer is no need to connected to the Orderer because peers and exchanges block through the gossip protocol.
You can read more about the gossip protocol here.
According to the above information we can see that step 2 and step 3 does not need chain code. It means that chaincode only have to be available on endorsing nodes, rather than throughout the blockchain network. This is a helpful tip so that we can keep chaincode confidential to endorsing peers.
This is how ledger update transaction is happening in a simple form. If you need a more deep description about this topic you can refer Hyperledger fabric documentation.
Now I am going to tell you how does this happen when some peers have private data.
When a group of organizations needs to keep some private data from other organizations in the channel, they have an option of creating a different channel between those organizations who want to keep private data. But it needs more administrative overhead. From version 1.2 Fabric offers a concept called private data collection.
Private data collection has two elements.
- The actual private data- sent peer-to-peer via gossip protocol to only the organizations authorized to see it. This data are stored in a private database on the peer (sometimes called a “side” database, or “SideDB”). Orderer does not involve in this and the cannot see these data.
- 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.
Now I am going to tell you when to use private data and when to use a separate channel for that purpose
If you want to keep the entire transaction confidential within a set of organization use channel.
Use collection, when you need to share the transaction among a set of organizations and subset of those organizations need to have some data private in that transaction.
Now I am going to tell you how the transaction flow happens when there is some private data.
The client application submits a transaction proposal of writing a private data or reading a private data to endorsing peers within an otherized organizations of the collection. There is a field called transient in the transaction proposal. Private data or data used to generate private data are sending in this field.
Then endorsing peers simulate the transaction and they will store the private data in a transient data store which is tempory storage local to the peer. After that, they will distribute the private data based on the collection policy to authorized peers using gossip protocol.
After that process endorsing peers send proposal response back to the application with public data including the hash of private data key and value. Private data will not be sent back to the client application. If you want to know more about this endorsement you can refer here.
After the client application receives proposal responses, it will send them to the ordering peer and the ordering peer will block them and distribute to the peers as in normal transaction flow which I was explained in the above of this article. As in this process, all the peers are able to validate the transaction without knowing the actual private data.
When peers receive the block, they will use the collection policy to determine if they are authorized to access the private data. If they are authorized, they will check first their transient data store to determine if they have already received the private data at chaincode endorsement time via gossip protocol. If not they will pull the data from another peer. Then they will validate the private data against the hashes in the public block and commit the transaction and the block.
After the validation process, private data is sent to their local copy of the private state database and private write-set storage and delete the private data from the transient data store.
That is how transaction flow happens when private data is available between a set of organizations.
Now I am going to give a use case of using private data collection which was taken from Hyperledger official documentation.
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 Shipperrelationship and the Distributor and Wholesaler relationship. Because these databases are kept separate from the database that holds the channel ledger, private data is sometimes referred to as “SideDB”.
That all for this tutorial.Thank you for reading my article.Goodbye!! until we meet in another tutorial.
You can follow me to read more articles relating to blockchain and Hyperledger fabric. Thank you.
