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.
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 installed two peers in two different organizations Org1MSP and Org2MSP and installed chaincode on all 4 peers. I did not set signing policy explicitly as it takes "Majority" as implicit signing policy. I am able to get information from all the peers when executed query. Later I added two new peers to each organization and made both of them to join the channel and installed chaincode on both of them. I did not execute approveformyorg now as it was already done in the previous step.
I am using Hyperledger Fabric 2.2.3 version.
Later when I executed
"discover --configFile discovery-conf.yaml endorsers --channel
channelone --server peer0.org1.example.com:7051 --chaincode basic"
I am getting details of all 6 peers of both the organizations. How do I configure non endorsing peers in my set up. I want to have atleast one non endorsing peer in each organization.
Every peer that has joined a channel is a committer on that channel.
If the peer has chaincode installed, it can act as an endorser.
If clients Invoke the installed chaincode on the peer, then it will act as an endorser.
Why should one use Anchor peers when the cross org communication can be acheived by setting CORE_PEER_GOSSIP_EXTERNALENDPOINT in every peer?
Can anyone explain the correct way one should be used?
Let me clearly explains you
In the hyperledger fabric there are total Three Types of peers
Endorsing Peers
Committing Peers
Orderer Peer (Orderer is also a
Peer)
Something Hidden is:
Anchor Peers
Leader Peers
Anchor Peers are for cross-organization peer-to-peer communication, to setup Anchor Peers you need to setup Anchor Peers and use ENV
Step-By-Step
- &org1
Name: org1
ID: org1MSP
MSPDir: ./data/orgs/org1/msp
AnchorPeers:
- Host: org1-peer
- Port: 7051
# generate anchor peer transaction
configtxgen -profile OrgsChannel -outputAnchorPeersUpdate ./crypto-config/org1Anchors.tx -channelID publicchannel -asOrg org1
if [ "$?" -ne 0 ]; then
echo "Failed to generate anchor peer update for maersksea..."
exit 1org1 fi
Now you need to send a transaction inorder to setup Anchor Peers
Check this >> https://hyperledger-fabric.readthedocs.io/en/release-1.1/commands/peerchannel.html#peer-channel-update
If you want to make other peers in your organization known to other organizations, you need to set the
CORE_PEER_GOSSIP_EXTERNALENDPOINT
What They Do:
High-level, peer-to-peer communication happens through gossip protocol and Anchor Peers are the key to gossip communication.
Make sure peers in different organizations know about each other through gossip protocol.
One Can use Private Data Concept using Anchor Peers because gossip distributes the private data peer-to-peer across authorized organizations, it is required to set up anchor peers on the channel
Read below mentioned docs
- https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data/private-data.html
- https://hyperledger-fabric.readthedocs.io/en/release-1.4/glossary.html
LeaderPeers are the main entry point for orderer to ship blocks to peers
One can set up leader Peers or Peers can elect one by its own
Two Types
Static leader election
Dynamic leader election
Static leader election
Static leader election allows you to manually define one or more peers within an organization as leader peers. Please note, however, that having too many peers connect to the ordering service may result in inefficient use of bandwidth.
export CORE_PEER_GOSSIP_USELEADERELECTION=false
export CORE_PEER_GOSSIP_ORGLEADER=true
Dynamic leader election
Dynamic leader election enables organization peers to elect one peer which will connect to the ordering service and pull out new blocks. This leader is elected for an organization’s peers independently.
export CORE_PEER_GOSSIP_USELEADERELECTION=true
export CORE_PEER_GOSSIP_ORGLEADER=false
Suppose there are 2 orgs in the network A and B. Each org has 2 peers.
ORGA-peer1.orgA, peer2.orgA
ORGB-peer1.orgB, peer2.orgB
Lets say peer1 is anchor peer in both the orgs.
When org A anchor peer(peer1.orgA) communicates with orgB anchor peer(peer1.orgB), then org A anchor peer will tell the org B anchor peer about the CORE_PEER_GOSSIP_EXTERNALENDPOINT of other non anchor peer (peer2.orgA) and vice-versa.
So anchor peer shares the gossip endpoint of non anchor peers. So all the peers in the network know about all the other peers through anchor peers. And then peers can use the CORE_PEER_GOSSIP_EXTERNALENDPOINT of another peer to communicate with that peer.
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
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)