Following is given as part of hyperldedger fabric documentation for v1.1:
Switching between organizations to sign a config transaction (or to do anything else) is not reflective of a real-world Fabric operation. A single container would never be mounted with an entire network’s crypto material. Rather, the config update would need to be securely passed out-of-band to an Org2 Admin for inspection and approval.
Say we have 4 organizations Org1,Org2,Org3 and Org4 and we are in the process of creating Org5.
Let Org1 and Org2 belong to same cli whereas Org3 be in Org3cli and Org4 be in Org4cli
Let us say all initial steps to launch org5 into network has been done.
On coming to peer channel signconfigtx I first sign from cli using peers of Org1 and Org2.But I need one more signature as majority says 3.
I go to Org3cli as sign on behalf of org3 but since peer channel signconfigtx method is local cli (Containing Org1 and Org2) doesn't come to know about it.(result is not send to the orderer).
So given in a real world scenario that a single cli isn't expected to handle all configuration,How do u handle interaction between 2 different cli ?
As you have correctly interpreted, the documentation is telling you that setting up a multi-org network using a single control point which has access to the crypto material for multiple organizations is not reflective of how things work in the real world. We do this in the samples to make it easy to bootstrap a multi-org sandbox network.
In the real world, you would need to pass the serialized configuration (update) transaction out of band to all of the organizations who need to sign it based on the channel policy. Fabric currently does not provide any tools for handling the out of band communication ... this is left up to the members of the network to decide.
There are vendors out there that are providing governance and lifecycle management tools for Fabric as part of their offerings, but there are currently no Fabric-specific tools available in open source for this.
Related
I am using Hyperledger Fabric v2.2 with multiple organizations setup. I want to join a new organization to an existing channel. The problem is in signing channel update.
Fabric docs says that there are two main implementations of signing:
“pass it along” - admin of Org1 signs channel update and sends in to Org2 admin, Org2 admin signs and sends to Org3 and so on, until enough signatures will be collected.
"The other option is to submit the update to every Admin on a channel and wait for enough signatures to come back. These signatures can then be stitched together and submitted. This makes life a bit more difficult for the Admin who created the config update (forcing them to deal with a file per signer) but is the recommended workflow for users which are developing Fabric management applications."
All samples that I found describes only the first implementation. But how to do it with the second? I found the related code in HLF Node.js SDK v1.4 but can't find the same for v2.2.
I had the same doubt, until I saw this here.
The Fabric v2.x SDKs only support transaction and query functions and event listening. Support for administrative functions for channels and nodes has been removed from the SDKs in favor of the CLI tools.
No more admin function starting from v2.x tho. Not sure if I answered your question.
In Hyperledger ledger, how could I list endorsing peers of a specific chaincode?
I have a channel with 5 peers but I need that only three of them endorse a transaction while the other two need only to access to same ledger.
You can use the discovery service to get the endorsing peer. Here you can find some information:
https://hyperledger-fabric.readthedocs.io/en/latest/discovery-overview.html
Hyperledger fabric has a CLI tool to query the discovery service:
https://hyperledger-fabric.readthedocs.io/en/latest/discovery-cli.html
For node.js applications, you can follow the tutorial here:
https://hyperledger.github.io/fabric-sdk-node/release-1.4/tutorial-discovery.html
With the latest Fabric Client SDKs (personally using GO client), you don't need to deal with endorsement policies. Client SDK already does this dirty work for you. It extracts:
Which organizations' endorsements are required for this chaincode, key (key level endorsement policy can be defined as well), etc.
Which peers currently exist in the system and what are their MSPs (from discovery service).
According to these information, client SDK builds a set of necessary peers then sends your transaction request to all. It waits response from requested endorsers. Once it collects all responses, it sends to orderer and so on.
If you have a special case which you need to manually set endorsing peers of your choice (I had one use case about private collections so I had to use this approach) check out discovery service API of your client SDK.
It is possible to configure a single organization, to act both as peer and orderer organization, at the same time?
And also, if possible, can an example be provided?
More specifically, using the first-network from fabric-samples as template, with both cryptogen and cryptotxgen cli, to generate all the certificates, and also using docker-compose to bring the network up.
I've tried it out, but had some trouble instantiating the code at the peer node.
Yes, it is possible, but not recommended. From https://hyperledger-fabric.readthedocs.io/en/release-1.4/Fabric-FAQ.html#ordering-service:
Question: Can I have an organization act both in an ordering and application role?
Answer: Although this is possible, it is a highly discouraged configuration. By default the /Channel/Orderer/BlockValidation policy allows any valid certificate of the ordering organizations to sign blocks. If an organization is acting both in an ordering and application role, then this policy should be updated to restrict block signers to the subset of certificates authorized for ordering.
I have also experienced strange behaviours getting peers from those organizations join to channels they are not allowed to (although they are not able to synchronize with the channel later).
I have done using Fabric-CA. With cryptogen you probably have to declare those organizations as if they were orderers, so that peers will also have their cryptographic material under ../ordererOrganizations/.
I am new to the area of DLTs or "blockchain" and I am trying to create an application on top of Hyperledger Fabric. Before I describe my use case, I need to mention that due to my use case's nature I need a private & permissioned "blockchain" which justifies the choice of Fabric (I am aware of other platforms e.g. Corda, private Ethereum, but Fabric seems to match my use case better).
Use Case
My use case consists of two different types of participants. A number of organizations (which upload and share information about individuals on the distributed ledger) and a client who can query information about an individual.
The client should not be able to see the transactions uploaded by the organizations and will not have write rights on the DL. He has read-only rights. Moreover, the organizations trust each other and there is also a level of trust between them and the client.
Design thoughts
Based on what I've read, I was thinking of creating a DL network that includes all of these parties and use channels which, based on the documentation, can be used to create a grouping among a number of participants (the organizations in my case) thus "hiding" the transactions from the parties which are not included in this group (the client in my case).
However, later I read about chaincode (a.k.a. smart contracts) which:
can be invoked by an application external to the blockchain when that
application needs to interact with the ledger
which confused me since if the "blockchain" can be queried from an external entity, that probably means that the client should not be included in the trusted network.
Am I headed in the wrong direction (design-wise)?
Based on your description, Hyperledger Fabric channels sound like a good solution. You should also familiarise yourself with private data collections, as this is another way of hiding some of the data from some peers. Which option is best for your scenario will depend on how your datasets are structured, and whether you also need to keep the data private from the orderer.
Clients are not part of the network. They query the blockchain by connecting to a peer and then requesting data from that peer. They can then only access the data visible to that peer (which is stored locally by that peer). So, it is not possible for a client to access more data than is available to the peer the client is connected to.
In your example, you would have a "client" organisation, with at least one peer. This peer would be part of the network, and your client application would then connect to it for access to data on the ledger (typically using the Hyperledger Fabric Node SDK).
There are two types of chaincode in Hyperledger Fabric.
User Chaincode (often just referred to as "chaincode") is used to update the ledger for a channel, and is only installed on those peers which require it (i.e. endorsing peers). Since your "client" peer would not be an endorsing peer, it would not have access to the user chaincode for the channel.
System Chaincode which all peers have access to, provides (among other things) an interface to allow queries to be run against the ledger.
what is Application's own signature in this context, and how can someone using hyperledger fabric node SDK can set the application's signature?
the application that you are talking about is simply a client app which talks to the ledger. The issue here is not the client app, the issue here is that you need a proper endorsement policy which establishes how anything goes onto the ledger.
Imagine this scenario ...
you have 2 orgs, Org1 and Org2, both owning one peer, P1 belongs to Org1, P2 belongs to Org2 and both peers joined on a channel, let's call it defaultchannel.
you deploy and instantiate your chaincode and set a basic endorsement policy which is 1-Of.
Each org has a client application, running against their own peer. When Org1 submits a transaction to the ledger, its validity is endorsed by itself, but not by the second org, because your policy requires only one to accomplish this. Basically in any network where you have more than one org, you really want a proper endorsement policy. 2-Of would work in the case of our example as any transaction would need to be validated by both orgs and that gives the ledger much better integrity.
Bottom line, your fabric network needs to be properly built and protected, especially in a production environment and this allows it to be protected by any client apps which have rights to interact with it. Your network being protected means that it doesn't matter how a client app is built and what it tries to do, it won't be able to bypass mechanisms such as the endorsement mechanisms.