I was checking a use-case if it is possible to share the peers, invoke chaincode functions & perform transactions with different MSPs. This is a use-case where a shared environment will be required for some organizations that are not willing to spend on infrastructure but may want to use the blockchain network running by the network operator.
For example, a network operator with MSP org1 creates a Hyperledger Fabric network. org4 wants to join the network but without any peers. The CA container will be there for this org4. Is it possible for org4 identity to invoke transactions on org1 peers?
I tried this actually. Check the logs of the rest client below:
[Service Discovery Turned On]
2021-04-02T04:19:27.643Z - debug: [Channel]: _getServiceEndpoints - start - org4
2021-04-02T04:19:27.643Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer0.org1.com:7051 - org1
2021-04-02T04:19:27.643Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer1.org1.com:7051 - org1
2021-04-02T04:19:27.643Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer1.networkoperator.com:7051 - networkoperator
2021-04-02T04:19:27.643Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer0.networkoperator.com:7051 - networkoperator
2021-04-02T04:19:27.643Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer0.org2.com:7051 - org2
2021-04-02T04:19:27.643Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer1.org2.com:7051 - org2
2021-04-02T04:19:27.643Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer0.org3.com:7051 - org3
2021-04-02T04:19:27.643Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer1.org3.com:7051 - org3
2021-04-02T04:19:27.643Z - debug: [RoundRobinQueryHandler]: constructor: peers=[]
The above logs show that rest-client tries to match the MSP id with peers
The logs without service discovery:
[Service Discovery Turned Off]
2021-04-02T04:39:11.091Z - debug: [Channel]: _getServiceEndpoints - start - org4
2021-04-02T04:39:11.091Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer0.org1.com - org1
2021-04-02T04:39:11.091Z - debug: [Channel]: _getServiceEndpoints - Endorser mspid not matched, not added peer1.org1.com - org1
2021-04-02T04:39:11.091Z - debug: [RoundRobinQueryHandler]: constructor: peers=[]
In general, these organizations will join the shared infrastructure and when they are ready to use their own infrastructure, they will be migrated to it. In the meantime, they will be invoking chaincode functions through their identities
The fabric-sdk was trying to match the invoker's MSP ID with the available endorser's MSP ID which was failing the whole transaction because there's no peer that matches with the invoker's MSP ID. I had to disable the service discovery, add specific peers into the target peer list to make this working.
Some code:
const endorsingPeers = channel.getEndorsers('org1');
if (endorsingPeers.length > 0) transaction = transaction.setEndorsingPeers(endorsingPeers);
const response_payloads = await transaction.evaluate(JSON.stringify(args))
In such a case, org4 will only user crypto material given to it by the network operator to connect to the network and invoke chaincode. Following does not make sense to me.
Is it possible for org4 identity to invoke transactions on org1 peers?
From my understanding, as long as you have cyrpto material to connect to HLF, and you have the right connection profile in place, the HLF client that org4 runs, would end up posting transaction to all peers, check the simulation result on the HLF client side, and then send the transaction to orderer for it to be comitted onto the peers.
So, in your case we'll have a new user created for org4 to use, and then org4 would use that crypto material to invoke the chaincodes. A transaction submitted by any org will end up getting executed by all participating org's infrastructure, so someone does not want to contribute infra, they'll just use crypto material to connect to HLF network by not addition and reuse existing chaincodes put up on peers.
Related
The use case is:
I created a network with Raft Ordering service having one channel say, channel1 with three Organisations (Org1, Org2 and Org3).
Org1 and Org2 peers have joined the channel channel1.
Org3 is just present in the channel config but not joined the channel yet.
Now I added the new orderer endpoints in the system channel and channel1 config and removed the old orderer endpoints.
My new orderers are working fine, able to fetch the config for both channels.
I fetched the 0 block of channel1 from Org3 peer and issued the join command.
The command works fine, but in the peer I am getting these error:
2022-04-20 05:28:18.210 UTC 006b WARN [peer.blocksprovider] func1 -> Encountered an error reading from deliver stream: EOF channel=channel1 orderer-address=orderer.example.com:7050
2022-04-20 05:28:18.210 UTC 006c WARN [peer.blocksprovider] DeliverBlocks -> Got error while attempting to receive blocks: received bad status SERVICE_UNAVAILABLE from orderer channel=channel1 orderer-address=orderer.example.com:7050
The Org3 peer is still trying to connect with the older orderer endpoints (as they were defined in the 0 block initially).
So how to sort out this problem?
One way I can think is to use the snapshot of the Org1/Org2 peer maybe.
What are your thoughts?
Thanks
I found the solution, so if anyone in the future needs it, can use this answer to join the channel when the orderer endpoints are updated in the channel configuration.
Method 1:
In the peer configuration you can override some of the variables to override the old orderer endpoint with the new orderer endpoints.
The link to the config file and params is:
https://github.com/hyperledger/fabric/blob/main/sampleconfig/core.yaml#L382-L388
This method will allow you to join the peer using genesis block and is supported by older versions of Fabric (<=v2.2) which does not support joining by snapshot.
Method 2:
If you are on Fabric v2.2+, then you can either use the Method 1 or join the channel using a snapshot from another peer.
There is tutorial in the official docs for that, please check it:
https://hyperledger-fabric.readthedocs.io/en/release-2.3/peer_ledger_snapshot.html
Thanks,
Sahil
From HLF docs
joining by snapshot will provide a peer with the latest channel configuration, which may be important if the channel configuration has changed since the genesis block. For example, the peer may need the orderer endpoints or CA certificates from the latest channel configuration before it can successfully pull blocks from the ordering service.
Taking ledger snapshots and using them to join channels
I'm setting up a little architecture to test some things with Hyperledger Fabric.
Having 3 Orgs, 2 of which formed by just one peer each (availability not the main concern for the test), I'm getting some warning on gossip: can't establish connection with 0.0.0.0:7051, same for both single peers.
2019-10-02 15:18:49.667 UTC [gossip.discovery] func1 -> WARN 02e Could not
connect to Endpoint: 127.0.0.1:7051, InternalEndpoint: 127.0.0.1:7051,
PKI ID: <nil>, Metadata: : context deadline exceeded
I began to wonder if having just one peer for Org is at least feasable, can't find any example or any guide on how to choose env setting in docker-compose.yaml, or anything that would state that you can't have single peer Orgs.
Any hint?
Thanks
warning on gossip: can't establish connection with 0.0.0.0:7051
Its because you did not update anchor peer transaction, please do update transaction by providing the anchor.tx
check: https://hyperledger-fabric.readthedocs.io/en/release-1.1/glossary.html#anchor-peer
Anchor peers are used to establishing cross-organization communication
Command to generate anchorpeer.tx:
configtxgen -outputAnchorPeersUpdate anchor_peer_tx.pb -profile SampleSingleMSPChannelV1_1 -asOrg Org1
Output a configuration update transaction to anchor_peer_tx.pb which
sets the anchor peers for organization Org1 as defined in profile
SampleSingleMSPChannelV1_1 based on configtx.yaml.
My fabric network's consortium(in configtx.yaml) has two organizations: ORG1 and ORG2. ORG1 has 4 main peers and ORG2 has only 1 peer. ORG2 peer's only purpose is to have the copy of the ledger(for the auditing purpose).
They all joined the same channel and let's say ORG1's admin already installed/instantiated the chaincode version 0.1
Now, ORG2's admin will be also able to 'peer chaincode upgrade" to version 0.2 with the same chaincode name and when the proposal reaches one of the ORG1 peers, it will say something like :
endorsement failure during invoke. response: status:500 message:"cannot retrieve package for chaincode [chaincode name]/0.2, error open /var/hyperledger/production/chaincodes/[chaincode name]/0.2: no such file or directory"
How we completely prevent ORG2 from upgrading the chaincode version? so that only ORG1's admin can perform the administrative operations?
I have searched the ACL, but it seems the administrative operations are not controlled by ACL settings.
After the research, we figured out we can set this on the instantiate policy on chaincode package.
please see below fabric document:
https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peerchaincode.html#peer-chaincode-package
with the flag -i, you can set the instantiate policy when packing the chaincode. Then only the Org(s) allowed on the policy will be able to instantiate or upgrade the chaincode on the channel
I'm testing Hyperledger Fabric network, which is based on the BYFN example (2 Organizations, 2 Peers for each organization, Single orderer, 1 channel, 1 chaincode).
In the default example, they only instantiate chaincode on each anchor peer. What I tried to do is instantiate chaincode on a peer in addition to two anchor peers. So, the chaincode is instantiated on the anchor peer for Org1, the anchor peer for Org2, and the normal peer for Org1. But, everytime I tried, instantiating chaincode for the 3rd peer (no matter what the peer is), it fails.
For example,
* Anchor peer for Org1 (success) -> Normal peer for Org1 (success) -> Anchor peer for Org2 (failed)
* Anchor peer for Org1 (success) -> Anchor peer for Org2 (success) -> Normal peer for Org1 (failed)
Failed error message is "the chaincode is already instantiated", which actually not.
Is there any restriction of the number of chaincode distribution? My endorsement policy is "OR(Org1.member, Org2.member)".
You only instantiate chaincode once per channel not per peer. As long as peers in the channel have the chaincode installed, they will receive the instantiate transaction from the ordering service. The first time the chaincode is invoked on any peers in the channel (which have the chaincode installed), the chaincode will be launched
Am working on hyperledger fabric, i have network setup of 2 org,1 channel and 1 orderer.
I installed chaincode(Say CH1) in Org1, with endoserment policy "AND(Org1.member,Org2,member)". Now i need to install same chaincode(CH1) in Org2 to validate and endorse transaction.
Since chaincode(CH1) installed in Org2(for endorsement purpose), also permitted to execute transaction using same chaincode(CH1), which will affect state, created by Org1. How to prevent this?
You need to separate 3 concepts here:
Installing chaincode
Instantiating chaincode on a channel
Endorsing chaincode
Installing chaincode simply makes the bytes of the chaincode available on the peer on which it is installed.
Instantiating chaincode on a channel makes that chaincode available for execution on the channel.
The endorsement policy determines which peers need to successfully execute and sign a transaction (technically peers sign the endorsement response).
In your case, installing the chaincode on the peers for both Org1 and Org2 makes the chaincode bytes available to the peers.
Instantiating the chaincode on a channel will make it available for execution.
The endorsement policy you set requires that a peer from Org1 AND a peer from Org2 must execute and endorse the transaction.
Once the client has collected the endorsements, the transaction will be send to the ordering service and then delivered to all peers in the channel. When the peers in the channel receive a transaction which involves CH1, they will check to make sure that the endorsement policy has been met (in this case that a peer from both Org1 and Org2 signed the transaction) and only then can it be committed (after the other validation checks)