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.
Related
i have a current channel of hyperledger fabric with chaincode that does CRUD operations my question is that is there any way to make a method in a chaincode that registers the new user when certain condition match.
You can use one of several methods to get the identity of the user:
GetCreator
GetId
GetMSPId
They are part of the Client Identity Chaincode Library, documented here: https://pkg.go.dev/github.com/hyperledger/fabric-chaincode-go/pkg/cid#section-readme
The Hyperledger Fabric docs provide some help for access control also if you're interested in that: https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html?highlight=getmspid#private-data-sharing-patterns
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.
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.
I am new to composer, and now practicing some of the tutorials and examples. But while doing this I can not understand some of the features, so here are the questions which I do not clearly understand:
Are queries restricted by .acl file (when, for example, we use them in rest server)?
Do the rules written in the .acl restrict some of the transactions which are allowed for certain participant to submit? (For example, for participantA it is not allowed to CREATE new participants, but what happens if participantA submits the transaction(which is allowed for him to submit)which creates another participant, will this transaction fail?
Could cards be created by rest api server?(I know that participants could be created using JS api, but is it possible to create and issue the identity for those participants through RestServerApi?)
What happens when PeerAdmin upgrade certain node to a new version? How do other nodes act in this case? Do they upgrade themself automaticly?(Also found that upgrade takes a lot of time(2-4 minutes) when deployed locally, whereas in browser for local connection it takes 3-4 seconds)
Does Hyperledger fabric allow some of the ledger data be stored in one private network, whereas other network connected to the private one would not store this part of ledger( or the data will be simply crypted)? The same question regarding the transactions: will the be executed on outer networks?
Yes Composer Queries (and therein, results) are subject to ACL restrictions or filters.
It will still fail due to ACL rule restriction. Once denied to create, always denied as that is the final operation (in this scenario). The actual transaction would fail.
Yes of course use POST /system/identities/issue REST endpoint (eg http://localhost:3001/api/system/identities/issue) - see an example here -> https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc
An administrator with PeerAdmin capability has responsibility to install new version on his peers (in his Org). The other Org peer Admins are responsible for theirs, that's how a blockchain consortium with different Orgs will work. They will agree the 'what' and when but will need to install the new version on own Org's peers, so the new version can be started on the same channel. Of course, there will be a difference between a Fabric infrastructure response time, and that of a web connection using local storage.
Channels in Fabric implement privacy. You can have one or more business networks on that channel (ledger), therefore transactions in that business network are private to that ledger. It is the client's responsibility to encrypt data or not. Hyperledger Composer can allow call one business network from another, on the same channel, or if permitted to do so, on different channels too - see https://hyperledger.github.io/composer/latest/tutorials/invoke-composer-network
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.