I have a very case-specific query related to the implementation of private data collection and I am seeking recommendations/suggestions from the experts here. We have a product running on Hyperledger Fabric 2.3.3 and the platform can have any number of organizations. For instance, initially, there will be 4 organizations, next week 10 more organizations can join the network. The problem arises when these organizations start transactions with each other. These transactions can have a number of objects that need to be private between these organizations only.
For this, we can create private data collections with names:
collection_org1
collection_org2
collection_org3
collection_org1_org2
collection_org1_org3
collection_org1_org2_org3
collection_org2_org3
Assume if the network has 20 organizations as participants, how many private data collection combinations will be there.
This is because, at a given time, any organization can begin a transaction with another organization or a series of organizations in the network. The problem here is that we have to create a large number of private data collections using the pattern and maintain it.
Because of this problem, we removed this implementation and used the implicit private data collection for each organization. Now if there is an object that should be shared only with org1, org2 & org3, the object is pushed to collection_org1, collection_org2, collection_org3. We did this using setting memberOnlyRead: false and memberOnlyWrite: false and added the validations at the chaincode level.
This implementation solved the above problem but has created a new problem. Now, we wanted to implement key-level endorsement policy such that if org1 changes a private object that is shared among org2 & org3, the org1 has to obtain the endorsements from org2 & org3 peers. This means that the peers will read the object from their own private data collection resulting in a different read-set in endorsement proposal response which further leads to an error saying read/write sets do not match.
For example, org1 during the endorsement proposal will read object key: key1 from its own private data collection collection_org1. In a similar way, org2 will read the same key during endorsement from its own collection collection_org2, and likewise for org3. This leads to a different read-set in the endorsement proposal.
I am seeking suggestions to implement this whole functionality in a better way.
Please let me know your suggestions/recommendations.
GetPrivateDataHash() is your answer. You can use this function to verify that each of the endorsers have the same value, and ensure that your read sets are consistent.
See the secured transfer tutorial and sample for an example of using it for this purpose.
Related
I tried to find about how committing peer works in hyperledger fabric technically in producing new block but I couldn't seem to find resources that explain to me in a very detail manner(such as sign using private key, how transaction is validated technically, etc). My question is after committing peer validate the transaction which they got from ordering service node, who will create the new block exactly? If it's the committing peer, committing peer is not one node but usually it has multiple committing peer node(which represents number of company participating in the network), so how do the system decide which committing peer will produce the new block?
Any reference link about this will be highly appreciated.
Please refer to the Transaction Flow in the documentation. Furthermore, Please check out the Key Concept Section too (Both Ledger and Ordering Service for you to understand the flow and also what is inside a block).
Committing peers do not create new blocks, they execute, validate and commit the block created by orderer to their ledger. The signing is done by Endorsing Peers using private key with ECDSA-SHA256 signing. Then of course, verification uses ECDSA-SHA256 too.
Validation is basically executing the read write set and check if the output is deterministic (and thus the result should be same with all other nodes).
I am over simplifying here tho.
I want to ask about blockhain Hyperledger Fabric. Is it possible to let Peer nodes to do Orderer node's task which is packing the transaction into new block?
I kind of think the orderer node is kind of a redundant node since for example in Bitcoin network, the packing of the transactions into block and the verification of new transaction is solely done by the full node(miner node).
Can anyone give me justification why there should be orderer's node in the Hyperledger Fabric?
And if I were to build my project on Hyperledger network and forgo orderer node(which means the peer node will do both the verification of transaction and the packing of transaction) is it possible?
Please tell me your thoughts and ideas.
Thank you.
TL;DR
HLF by design is deterministic so the orderer nodes are important. Only they participate in consensus not all peers and the blocks they produce are Final (Not prone to forks).
No you cannot make a peer orderer as well. Your network configuration for HLF must have at least one orderer to work
Hyperledger Fabric (HLF) vs Bitcoin
HLF is a private permissioned blockchain where as Bitcoin is a public permissionless blockchain. You should not expect them to work similarly.
Public blockchains
In public blockchain for example bitcoin everyone is treated equal in other words no one have special privileges you may think well miner are the ones minning block but the important point is anyone can become miner its open game no restriction on who can become miner or who can run a node etc.
Private Blockchain
In private blockchain for example HLF roles are predefined at the time of setting up and starting blockchain. Each role has certain tasks and privileges and restriction. The no of organisations peers, endorser peers, orderers, channels all are predefined and some have special privileges which no other role has like orderer whose is responsible for receiving endorsed transactions from peers and put them into blocks then these blocks are distributed to all peers. These blocks are Final.
But Why?
Private Blockchains (Like HLF) full-fill special use cases for example supply chain, B2B operations In such use cases one may want to harness positives of blockchain like transparency, auditing, provenance but may also want some sort of role based access or restrictions of certain data to certain audience public blockchains like Ethereum and bitcoin does not fit here.
Now coming toward your question
Why is there an orderer node in HLF isn't it redundant ?
No it's not redundant, HLF has deterministic consensus algorithms where as Ethereum and Bitcoin have probabilistic consensus algorithms which means there can be ledger forks. In HLF there are no Ledger forks because fork occur when two equal participants have conflict at a common point. Incase of HLF the participants are not equal as peers cannot participate in consensus process the block order set by orderers is Final. And rightfully so because for the use cases it is designed for does not want forks and want to have special roles and much much more transaction throughput.
Must must Read !
https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html#what-is-ordering
No it is not possible to assign peers orderer's role you must have at least 1 orderer in your HLF network to work.
I removed anchor peer definition in configtx.yaml file and also I didn't update anchor peers on my channel for any participating orgs. Surprisingly, the network works fine and all transactions are going through.
I made changes in fabric-samples/first-network folder of fabric's official github repo. I understand that anchor peers are used for gossip communication and peer discovery, though having no anchor peer in the network made no visible difference as compared to when we define them. I was hoping to see some errors but none came. How do I gauge difference between both cases ?
You need anchor peers in order to allow cross organizations communication, that's mean to make peers from different organization domain able to get connected. Now, normally in each organization gossip elects peer to serve as a leader to pull blocks from ordering service and gossip them around. Therefore if no anchor peers is configured, most likely you won't see any difference.
Now, the question, why do you need them. Here is two reasons
You need cross organization communication during state transfer or replication of missing blocks in case for example where one org partitioned from the ordering service but can reach out to the other organization.
Second use case if more complex one. You need cross organization communication for private data, as private data distributed off chain, e.g. via gossip. You need to be able to push pieces of private data during endorsement. And pull missing private data during commit.
Hence unless you are not encounter a need of any of these two scenarios you won't feel any difference with or without anchor peers configured.
I'm working with the BYFN example using 3 organizations, 2 channels. One channel(c12) between Org1 and Org2, another channel (c23) between Org2 and Org3. The first chaincode is an example where I'm able to transfer value between "A" and "B". When I run the code over c12, I can see I'm able to transfer an amount from A to B. But when I query the same chaincode over c23, the initialization is kept. I understand why (different ledgers) and etc.
Now I would like to introduce the following requirement. I, as an organization, need to transfer this value only if I have the amount available.
The sequence would be:
1. I'm on org2, I have 100, and I wanna transfer 60 to org1. And everything works as expected.
2. I'm on org2, I have 40 and I'll try to transfer 50 to org3 (another ledger - channel). This should fail because I have only 40.
How can I achieve this?
Where will the "shared state" be stored? MSP?
The same approach would work for a complex asset?
Extra information:
- I already have read the documentation, about the assets, account model, the examples, but usually, they are focused only one channel only. Maybe I'm losing something.
- I'm not using hyperledger composer
In fabric you have a chaincode and a ledger different for each channel. so if you want to have the business logic descripted you need to use only one channel (with 3 orgs).
You can probably use private data to make the separation you are now doing with the two channels
I am facing a very strange issue with Hyperledger Fabric node.js sdk issue.
Right now, my network consists of:
a.) Single org
b.) 2 peers of that org (peer0 and peer1).
c.) 1 orderer
d.) 1 ca
When using node.js sdk, both peers joined the channel as you can see in the code snippet below:
var fabric_client = new Fabric_Client();
var channel = fabric_client.newChannel(channelName);
var peer = fabric_client.newPeer('grpc://localhost:7051');
var peer2 = fabric_client.newPeer('grpc://localhost:8051');
channel.addPeer(peer);
channel.addPeer(peer2);
var order = fabric_client.newOrderer('grpc://localhost:7050')
channel.addOrderer(order);
I am calling a chaincode function written in golang that generates a unique id, create the hash of it (SHA256) and saves in couchdb and logs that hash to container like this:
"password":"5ef32e670c38727ce5011dad62ff1a150362433789fdd878f2623a08bbdc990b"
The issue is, when node.js sdk is configured with single peer. It saves the same hash in couchdb that log shows. But when configured with 2 peers as the above sdk code snippet shows. The logged hash and couchdb hash does not match.
I think the hash changes because 2nd peer execute the same code again in which a random string is generated and hashed.
Any help/comment would be appreciated.
Thanks
A few things:
1) Not sure what your endorsement policy is, but assuming it is the default then generally speaking you only need to request endorsement from a single peer in the organization
2) Most importantly you should not use non-deterministic functions within your chaincode. If you actually had multiple organizations and the endorsement policy required signatures from multiple orgs, then your transaction would fail anyway (as peers from different orgs would generate different responses due to the non-deterministic unique id function you are using). In this case, since you only require a single endorsement, the state would likely be updated but it would use the value of the first response.