I'm wondering how is possible to send notifications from the chaincode of a fabric network.
What I would like to do is send a notification to an external legacy system every time a new transaction is successfully committed to the ledger.
To achieve this I thought about two different ways:
HTTP Request - Is possible to execute an http request directly from
the chaincode? If yes, is it possible to send an http request to the
endpoint of the legacy system to notify the transaction?
Event - I understood that there is the possibility to create
events in the chaincode. Is possible to listen these events without
using the Fabric SDK (I can't integrate the SDK in the legacy
system)?
What are your considerations about these two approaches?
Do you have any suggestion?
HTTP Request
Yes, this possible, but definitely not recommended. The chaincode is used to endorse transaction proposals, but one peer's endorsement of a transaction proposal does not necessarily mean that transaction itself will be committed. Sending the request from chaincode execution would be premature. You can read more about transaction flow here and here
Additionally, the chaincode is not necessarily (and not supposed to be) executed on only one peer. If you have the request being sent from the chaincode and you have 10 peers executing the chaincode, you're going to have 10 requests going to your legacy system.
Event
You can set custom events in the chaincode, but you won't need them as each sdk supports notification of transaction commitment. While I understand it is not reasonable to embed the sdk within your legacy service, the sdk is most likely the best place for you to listen for events.
Peer Channel Event Service
From 1.3 moving forward the peer will has a specific channel event service. I will not go into this as I have not used it yet and I'm assuming if your legacy system cannot integrate an sdk it most likely will not support making grpc calls against a peer service.
Solution
You will probably need to cobble together the HTTP Request and Event solutions. Have a separate service use the sdk to send transaction proposals and listen for notifications of transaction commitment. Once a transaction is committed, use this service to send a request to your legacy system's endpoint.
Related
I'm trying to combine the core strengths of the two Hyperledger projects, Indy / Aries and Fabric.
In the scenario we have an Indy network for SSI and a Fabric network managing a token. The Fabric token accounts should be tied to the Indy identities. Furthermore, an identity is only allowed to move tokens when it can proof to be an active member of the golf club.
This means, the Fabric endorsers need a way to see the identity's DID and to verify the golf club credential.
Question: Is there a best practice architecture to achieve that?
My current approach is to let the user send a <Proof Proposal>,<Receiver>,<Qty> message via her Aries agent to a server connected with the Fabric network. The server then sends a transaction including this data to all endorsers via the fabric-sdk. Now, the chaincode gets executed at each organisation. The chaincode tells its Aries agent to verify this Proof Proposal, which leads to a huge amount of connection invitations and proof requests against the users agent. Once the verification is successful, the chaincode continues execution and changes the state.
I see several (potential) problems:
The user must accept many connection invitations manually (if there's no hardcoded auto-accept whitelist)
Even you could avoid the connection attempts (maybe /w ephemeral challenges? Documentation for that?), there would still be massive parallel traffic, due to the presentation protocol, incoming from a decently large fabric network.
Here's a visualisation:
Am I missing something? Do you have any hints / experiences about how this can be accomplished?
Kind regards
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.
I am trying to migrate my code from Fabric SDK to Fabric Gaetway. Currently for sending the transaction , I construct TransactionProposalRequest object and send it to fabric using channel.sendTransactionProposal method.As a response, I get the Collection of TransactionProposalResponse back ,then I make a check whether 50% of them are successful ,if they are I go ahead and submit the transaction to orderer.
Now when I am migrating to high level API using fabric gateway, I see two methods "evaluateTransaction" and "submitTransaction" ,first one just sends to peers collect the endorsements without submitting it to orderer. second one would first collect the endorsements and then submit it to orderer and hence save it to ledger.
My requirement is
To be able to first check the endorsement response and if the 50% of them are success responses ,then proceed submitting it to orderer.
How can I achieve this using new API? If I call "evaluateTransaction" method first and check for responses and then call "submitTransaction" if its the way I expected, it would end up endorsing the same transaction twice as submit also collects endorsements first internally.
Any pointers on this would help.
If you use discovery then submitTransaction will only ever contact enough peers for simulation to satisfy your endorsement policy. If any peers cannot be contacted then it should try to get endorsements from other peers in the same org in order to collect enough endorsements to satisfy your endorsement policy and thus be able to submit to the orderer.
Therefore using discovery you shouldn't have to worry about checking for 50% of the responses anymore.
The transaction flow in the Fabric states that:
Client proposes a transaction
This proposal is passed to all the endorsing peers of the network
Endorsing peer simulates the chaincode, signs the proposal and sends it back to the client.
The client collects the signature and waits until the total number of signature matches the one specified in the endorsement policy
Once the client has enough signatures, it sends this request to the Orderer
Orderer creates blocks and sends it to the anchor peers who validates and commits into their ledger
If we are using the Composer REST server, how are all these steps handled? Are they abstracted out from the client? Or do we need to explicitly write logic in the TP function or client to handle the proposal responses?
My confusion comes from the fact that when we use the node SDK, we have to explicitly implement the logic for handling all this. As we do it over here.
Composer implements a Submit/Notify model and that includes the Rest Server. It will submit the proposal, collect the endorsements, send them to the orderer and wait for a block with the transaction in to be committed before informing the caller of the completion of the transaction.
As Composer has no visibility of the endorsement policy it will send proposals to all peers in the channel (that have been defined as having the endorsingPeer role in the connection profile, which if not specified defaults to true) and collect as many responses as possible before sending them to be ordered. The Peer(s) will then decide whether those endorsements satisfy the endorsement policy.
Composer also waits for all peers (that have been defined in the connection profile as having the eventSource role which defaults to true if not specified) to notify that the transaction has been committed before notifying the client
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