When command "peer channel fetch 0 mychannel.block -c mychannel --orderer orderer0.****.com:7050" is executed in a peer's cli container, does it mean fetching mychannel.block from the orderer(orderer0.****.com:7050)? If so, does it mean that mychannel.block is stored in orderer instead of peer? And where is mychannel.block stored and persisted, is it stored by orderer container?
Thank you.
Orderer never reads, processes or stores the data. Orderer within the fabric network is responsible for:
Creating the blocks in the correct sequence after the receiving transaction proposal requests from the application.
Delivering these blocks to the anchor peers that have subscribed to the Orderer.
Now, coming to the command:
peer channel fetch 0 mychannel.block -c mychannel --orderer orderer0.****.com:7050
Here, we're passing two important information:
Channel ID, using -c
Ordering Service Endpoint, --orderer
Here, you pass the ordering service endpoint because the ordering service provides an interface to the peer for interacting with the channel. This is because a peer can be connected to multiple channels and these channels might've different orderers.
Next, to the following query:
where is mychannel.block stored and persisted, is it stored by orderer container?
It is quite clear that Orderer container does not store any data. This data is stored within the peer's channel(ledger) itself. Ordering service just acts as an interface to connect to the channel and deliver mychannel.block.
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.
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
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)