Re: docker-compose.yml syntax doubts


In green.

From:        "Tomás Peixinho" <tom.peixinho@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        "hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        02/08/2020 01:50 AM
Subject:        [EXTERNAL] RE:  [Hyperledger Fabric] docker-compose.yml syntax doubts

Thanks for the quick response, Yacov! And when I said 2.5 years, I atually meant it. That's the time I have been working on my master's thesis. Anyway...

What do you mean when you say I shouldn't use the "Any member" policy? Why is it bad? If it's the default, why should I not? Not that I want to, I would like to define my own policy, I'm just trying to understand.
Because an endorsement policy is what defines who, among the organizations in the network, is able to change data in an arbitrary way.
Consider a case where you have a smart contract that transfers money from Alice to Bob.
You'd want both Alice and Bob to consent on the money transfer, otherwise any of the parties can rob each other.
You'd also probably want another party, say - some auditor, to consent on these transactions, otherwise Alice and Bob can collude to print infinite money.
This is also why you should never use system chaincodes as smart contracts, because their endorsement policy can't be changed and it's always "any member".

"and it is the address that the peer publishes to other peers"  What do you mean by this? Published address for what? And why do they all take the same port, in this case, the 7051? That's just the default peer port, it can be changed. The address is the address that peers publish to each other in the gossip protocol. the other address they publish is the external endpoint (CORE_PEER_GOSSIP_EXTERNALENDPOINT) which is used for inter-org communication.

"An endorsing peer is a peer that has the chaincode installed."Thank you for this, I never really got this and I don't see anywhere in the docs where this explanation is. However, if this is the case but all the peers are invisible to other organization's peers, how does this work? If you're a client then when you send a transaction to a peer, as long as you know the peer, it doesn't mean anything if the other peers don't know about the peer. All peers receive blocks from the ordering service node(s) so in theory unless you use private data or service discovery, you don't need peers to know about each other.  If they can't communicate with each other, does that mean that only the peers from the same org are endorsing my transactions? When I look at the logs from all the other containers, all of them have lines that read something like:

2020-02-07 23:34:49.793 UTC [gossip.privdata] StoreBlock -> INFO 04d [mychannel] Received block [4] from buffer
2020-02-07 23:34:49.798 UTC [committer.txvalidator] Validate -> INFO 04e [mychannel] Validated block [4] in 4ms
2020-02-07 23:34:49.816 UTC [kvledger] CommitWithPvtData -> INFO 04f [mychannel] Committed block [4] with 1 transaction(s) in 18ms (state_validation=0ms block_commit=10ms state_commit=2ms)

What is this referring to if they can't see what the other peers are doing They got a block from the ordering service and validated and committed it. (this was from a log from a peer in a different org than the one that issued the transaction)?

As for the sample/tutorial that I was using, it was the one that was recommended in a lot of places, a while back, when Hyperledger started to have support for java. I'm mainly a java developer, so I thought it'd be easier to work with a java blockchain. The guy who did it worked for IBM so I thought it was trustworthy. Trustworthy or not, the developer can always abandon its repository because he/she is busy or moving to another project, and as Fabric develops these samples are not updated along with Fabric because they are not in the official Hyperledger organization. Going back and changing everything to work with the byfn is not an option now.

Anyway, thanks for the patience, man.


De: Yacov Manevich <YACOVM@...>
sexta-feira, 7 de fevereiro de 2020 23:01
Tomás Peixinho <tom.peixinho@...>
hyperledger-fabric@... <hyperledger-fabric@...>
Re: [Hyperledger Fabric] docker-compose.yml syntax doubts

Answers inline in blue.

"Tomás Peixinho" <tom.peixinho@...>
"hyperledger-fabric@..." <hyperledger-fabric@...>
02/08/2020 12:35 AM
[EXTERNAL] [Hyperledger Fabric] docker-compose.yml syntax doubts
Sent by:        

Good evening,

I am at my wits end with Hyperledger Fabric. Now that I got this out of the way, on to my question:

Apparently, to define the network topology for my blockchain, I have to modify three files, configtx.yaml, crypto-config.yaml and docker-compose.yml (I know that in the byfn examples, there are more files, like docker-compose-cli.yml, however I'm using the java sdk provided here,,
Do yourself a favor and don't use any sample or tutorial that is not hosted under the official Hyperledger organization I only have the three files that I mentioned previously).

The syntax for the first two is pretty straight-forward, I add the orgs and the peers that I need and that's that. As for the docker-compose.yml, I'm really having trouble understanding what I have to change. For each peer there are two lines on the "ports" field. For peer0-org1, for example, there's this "7051:7051" and on the second line "7053:7053". From the docker compose web page, I read that the first port is the host port and the second is the container port... I don't know what any of these are and what they are used for
The A:B notation means that traffic towards the host on port A is redirected towards the container on port B.. Also, why are there two entries for the same peer? You only need the A:7051 one. The 7053 port was deprecated a few years ago. That's why you shouldn't use samples from a non-Hyperledger repository. People leave them and never update themWhen I get the network up and running, I can see that all the other containers are connecting to these two ports, but why? Actually, I think I know why, it's because it is defined for each peer in the docker-compose, but is there any reason for this? What is the core peer that every other peer has to reference, for example, Why do all the peers need this line and have to have the defined port as the peer0-org1 port? Does this mean that all the peers in the network have to communicate with this peer? And if so, why is that? I'm really having trouble understanding this part.  The A_B_C="foo" environment variable definition, is a way to configure the core.yaml or orderer.yaml files without changing the files, but just defining environment variables instead. This CORE_PEER_ADDRESS defines peer.address in the core.yaml file and it is the address that the peer publishes to other peers

Also, and I don't even know if this has something to do with this file or not but, how can I see which peers are "endorsing peers" and which aren't?
An endorsing peer is a peer that has the chaincode installed.  And how can I define the endorsement policy? Read the documents know this has to be defined at instantiation time, but if nothing is passed, what is the default policy that is used? "Any member" (don't use it...)Are all the peers endorsing every transaction, or are no peers doing it?  "Any member" means - at least a single endorsement from any peer or client (don't use it) I know in byfn you have to change this with the cli but, again, I'm using the java sdk blockchain example and I'm not doing anything with the cli. I know I can give a file to my instantiation function, but by default it's not using anything and I wonder what's happening behind the scenes in this case.

Finally, when trying to see which peers were endorsing the transactions, I came across this warning in one of the container logs:
"2020-02-07 18:50:44.458 UTC [gossip.gossip] NewGossipService -> WARN 013 External endpoint is empty, peer will not be accessible outside of its organization".
Does this mean that the peers can't communicate with each other between organizations?
Exactly, but it also means the peer is "invisible" to peers in other organizations. What does that mean for the endorsing process? Does this have something to do with the ports that I defined in the docker-compose.yml? No. This has nothing to do with it. You can configure the SDK to use these peers as you see fit, but these peers won't be used by service discovery

I'm really struggling with this, so any help would be greatly appreciated. Also, I have been working on this for the past almost two and a half years of my life,
 Are you saying that you aged 2.5 years in one day or one week? so please don't tell me to read the tutorials on the IBM page and the readthedocs page, coz I've read that a million times already and I still don't understand most of what I'm doing

Sorry for the rant. Thank you in advance.


Join to automatically receive all group messages.