|
Re: docker-compose.yml syntax doubts
Yacov
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. Tomás De: Yacov Manevich <YACOVM@...> Enviado: sexta-feira, 7 de fevereiro de 2020 23:01 Para: Tomás Peixinho <tom.peixinho@...> Cc: hyperledger-fabric@... <hyperledger-fabric@...> Assunto: Re: [Hyperledger Fabric] docker-compose.yml syntax doubts Answers inline in blue. From: "Tomás Peixinho" <tom.peixinho@...> To: "hyperledger-fabric@..." <hyperledger-fabric@...> Date: 02/08/2020 12:35 AM Subject: [EXTERNAL] [Hyperledger Fabric] docker-compose.yml syntax doubts Sent by: fabric@... 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, https://github.com/IBM/blockchain-application-using-fabric-java-sdk, Do yourself a favor and don't use any sample or tutorial that is not hosted under the official Hyperledger organization https://github.com/hyperledger/.and 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, CORE_PEER_ADDRESS=peer0.org1.example.com:7051? 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 https://hyperledger-fabric.readthedocs.io/en/release-1.4/endorsement-policies.htmlI 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 https://hyperledger-fabric.readthedocs.io/en/release-1.4/discovery-overview.html 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. Tomás |
|
|
|
Re: docker-compose.yml syntax doubts
Tomás Peixinho
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.
"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?
"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 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 (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. Going back and changing everything to work with the byfn is not an option now.
Anyway, thanks for the patience, man.
Tomás
De: Yacov Manevich <YACOVM@...>
Enviado: sexta-feira, 7 de fevereiro de 2020 23:01 Para: Tomás Peixinho <tom.peixinho@...> Cc: hyperledger-fabric@... <hyperledger-fabric@...> Assunto: Re: [Hyperledger Fabric] docker-compose.yml syntax doubts Answers inline in blue.
From: "Tomás Peixinho" <tom.peixinho@...> To: "hyperledger-fabric@..." <hyperledger-fabric@...> Date: 02/08/2020 12:35 AM Subject: [EXTERNAL] [Hyperledger Fabric] docker-compose.yml syntax doubts Sent by: fabric@... 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, https://github.com/IBM/blockchain-application-using-fabric-java-sdk, Do yourself a favor and don't use any sample or tutorial that is not hosted under the official Hyperledger organization https://github.com/hyperledger/.and 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, CORE_PEER_ADDRESS=peer0.org1.example.com:7051? 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 https://hyperledger-fabric.readthedocs.io/en/release-1.4/endorsement-policies.html I 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 https://hyperledger-fabric.readthedocs.io/en/release-1.4/discovery-overview.html 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. Tomás |
|
|
|
Re: docker-compose.yml syntax doubts
Yacov
Answers inline in blue.
From: "Tomás Peixinho" <tom.peixinho@...> To: "hyperledger-fabric@..." <hyperledger-fabric@...> Date: 02/08/2020 12:35 AM Subject: [EXTERNAL] [Hyperledger Fabric] docker-compose.yml syntax doubts Sent by: fabric@... 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, https://github.com/IBM/blockchain-application-using-fabric-java-sdk, Do yourself a favor and don't use any sample or tutorial that is not hosted under the official Hyperledger organization https://github.com/hyperledger/.and 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, CORE_PEER_ADDRESS=peer0.org1.example.com:7051? 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 https://hyperledger-fabric.readthedocs.io/en/release-1.4/endorsement-policies.html I 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 https://hyperledger-fabric.readthedocs.io/en/release-1.4/discovery-overview.html 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. Tomás |
|
|
|
docker-compose.yml syntax doubts
Tomás Peixinho
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,
https://github.com/IBM/blockchain-application-using-fabric-java-sdk, and 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. Also, why are there two entries for the same peer? When 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, CORE_PEER_ADDRESS=peer0.org1.example.com:7051? 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.
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? And how can I define the endorsement policy? I know this has to be defined at instantiation time, but if nothing
is passed, what is the default policy that is used? Are all the peers endorsing every transaction, or are no peers doing 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? 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?
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, 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.
Tomás
|
|
|
|
Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 02/07/2020
#cal-notice
fabric@lists.hyperledger.org Calendar <noreply@...>
Hyperledger Fabric Documentation Workgroup call - Western hemisphere When: Where: Organizer: Description: |
|
|
|
Fabric-Ca User Revoke
Nicholas Leonardi
Hey guys, I've been working on a user revoke script but have come across some points after some research and testing. Here's a scenario that makes it very troublesome from the process that I understood. There are two organizations, Org1 as the main organization with permissions to submit channel configurations with a root CA. There's Org2 that uses an Intermediate CA to issue users and manage their own "staff" and who may access the network to transact with the chaincodes. However, Org2 does not have permission to submit channel configuration updates so when it is needed to revoke Org2 users certificates, it would need to request Org1 to do so through a channel update and add it to a revocation list. Is there a policy that would allow Org2 to submit channel updates that only affects it's own json configuration "channel.Org2MSP..." section of the config json but restrict it from changing any other channel configurations? I must be missing something with ACL's because this would be very impractical if there are a bunch of organizations in a network with only one org managing channel updates. Thanks in advance, Nick |
|
|
|
Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 02/07/2020
#cal-notice
fabric@lists.hyperledger.org Calendar <noreply@...>
Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere When: Where: Organizer: Description: |
|
|
|
Documentation Workgroup: Agenda for Friday, 7 Feb
Anthony O'Dowd <a_o-dowd@...>
Hello!
Please note the change in time for the Western hemisphere call this week. For this week only, it is 1 hour later than usual! The Eastern hemisphere call is at its regular time. Other than this one-off change, we will hold the documentation workgroup call this Friday, both Western and Eastern hemispheres. Thanks to everyone who attended last week's call. The summary minutes for last week's meeting: https://wiki.hyperledger.org/display/fabric/Meetings You can read all about the call at https://wiki.hyperledger.org/display/fabric/2020+01+31+DWG+Agenda It included a V2 status update from Pam and Joe, a migration walk-through from Joe, as well as a style guide review. We also covered introductory topic consolidation with Nik. Thanks for a great session last week. You can catch up via the recording: https://wiki.hyperledger.org/display/fabric/Recordings You'll see that there are lots of interesting items for this week: https://wiki.hyperledger.org/display/fabric/2020+02+07+DWG+Agenda Please feel free to contribute using the wiki. You can also help build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+02+07+DWG+Agenda Thanks! Pam, Anthony, Joe, Nik Meeting Details ------------- Please use the following link to attend the meeting: https://zoom.us/j/6223336701 The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group Meeting 114A: Friday 07 Feb 1130 India Standard Time 1400 China Standard Time 1500 Japan Standard Time 1700 Australia Eastern Time 1400 Singapore Time 1000 Gulf Standard Time 0900 Moscow Standard Time 0600 Greenwich Mean Time 0700 Central European Time Meeting 114B: Friday 07 Feb 1100 Central Daylight Time 1200 Eastern Daylight Time 0900 Pacific Daylight Time 1400 Brasil Time (BRT) 1700 Greenwich Mean Time 1800 Central European Time 1900 Moscow Standard Tim Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU |
|
|
|
Re: Why does the Ordering Consensus Work?
Nikhil Gupta
Want to jump in to clear up something Brett said. If the chaincode is non-deterministic, then the read write sets will not match and will not pass the endorsement policy, and proposals will be rejected at the last stage of the transaction flow. The endorsement itself prevents non-deterministic chaincode from leading to divergent results. Nik -----fabric@... wrote: ----- To: trevor@... From: "Gari Singh" Sent by: fabric@... Date: 02/05/2020 11:29PM Cc: <fabric@...> Subject: [EXTERNAL] Re: [Hyperledger Fabric] Why does the Ordering Consensus Work? Transaction consensus and validity in Fabric is not the same thing as the consensus mechanism used to build a fault tolerant ordering service. Have a look at https://hyperledger-fabric.readthedocs.io/en/release-2.0/txflow.html which describes the entire Fabric transaction flow ... this would be considered consensus for Fabric transactions. At a high-level, it is comprised of: - execute chaincode and collect endorsements - submit for ordering - ordering service orders and batches into blocks - ordering service pushes blocks to peers on a per channel basis - peers validate and commit transactions - check that endorsement policy has been satisfied (which means that enough peers executed chaincode with the same results based on policy) - check for collisions using an MVCC-like model (aka double-spend) - if valid, update state The ordering service itself uses a consensus algorithm itself to make sure that all ordering nodes produce batches/blocks with the same transactions in the same order. ----------------------------------------- Gari Singh Distinguished Engineer, CTO - IBM Blockchain IBM Middleware 550 King St Littleton, MA 01460 Cell: 978-846-7499 garis@... ----------------------------------------- -----fabric@... wrote: ----- To: <fabric@...> From: "Trevor Lee Oakley" Sent by: fabric@... Date: 02/06/2020 03:30AM Subject: [EXTERNAL] [Hyperledger Fabric] Why does the Ordering Consensus Work? From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process? Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow? Trevor |
|
|
|
Re: Is it efficient when "Upgrade Chaincode New Docker Container will be created"?
Brett T Logan <brett.t.logan@...>
In 2.0 Fabric we added logic to remove unreferenced chaincode containers, so once your old version is no longer used anywhere it would be cleaned up. We also introduced a new chaincode builder and launcher model in 2.0, this empowers developers and admins to run chaincode however they see fit, including totally devoid of Docker, take a look at it here: https://hyperledger-fabric.readthedocs.io/en/master/cc_launcher.html
----- Original message ----- |
|
|
|
Is it efficient when "Upgrade Chaincode New Docker Container will be created"?
Kimheng SOK
Dear all, I would like to ask about hyperledger performance related to chaincode upgrade. Each time when we upgrade the new chaincode, a new docker container will be created. Do you think this is an optimal way to go? Will hyperledger continue to adopt this concept, or may be modified to other solutions? If YES why and if NO what is the alternative solution in mind? Bests, |
|
|
|
Re: chaincode 2.0 problems
David Enyeart
This is not an issue with the submitting client credentials, it is an issue with the peer credentials not matching the org credentials in the channel config. Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, ` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, ` Error: proposal failed with status: 500 - Failed to authorize invocation due to failed ACL check: Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]` I tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? Thank you! BR, Indirajith. On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
> You tried to approve the same definition twice, completely unmodified. This produced an empty write-set, because nothing changed. Since there was no change to a specific collection, but because we had to pick _some_ endorsement policy to validate your tx with, you get the default for `_lifecycle`. opened FAB-17371 for this - J On Fri, Jan 10, 2020 at 1:02 AM Jay Guo via Lists.Hyperledger.Org <guojiannan1101=gmail.com@...> wrote:
I'm using byfn w/o any modification - J On Thu, Jan 9, 2020 at 9:25 PM <email4tong@...> wrote:
On Thursday, January 9, 2020, 4:47 AM, Jay Guo <guojiannan1101@...> wrote:
- J On Thu, Jan 9, 2020 at 12:46 AM Tong Li <litong01@...> wrote: Thanks David and Nikhil for your response. I took David's suggestion and sent to multiple peers for commit which went through successfully. Then I tried the lifecycle chaincode approveformyorg command and lifecycle chaincode install few more times, here is what I found. 1. Chaincode can be installed multiple times, if the chaincode package never changes, the returned package id will be the same. No errors. 2. Command chaincode lifecycle approveformyorg behaves like this (at least from what I can figure): a.) one peer in the org can only approve the chaincode one time b.) the other peer in the org can also approve the chaincode but the sequence number has to increase by 1, this is after chaincode has been committed. c.) once the chaincode gets approved by a peer, that peer can not approve it the 2nd time. If you try the 2nd time, it will give you the same error like below: 2020-01-08 16:31:53.754 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [af84dab09c428471a87aad3e9f921b8f876ecdc69b6b0b05fdf42d621cd3e31a] committed with status (ENDORSEMENT_POLICY_FAILURE) at Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE) The behavior at 2 is a bit different from what David suggested earlier, I wonder if I misunderstood David's point. My endorsement policy is using the Majority. Thanks so much for your response. Tong Li IBM Open Technology  "Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distribFrom: "Nikhil Gupta" <negupta@...> To: "David Enyeart" <enyeart@...> Cc: "Tong Li" <litong01@...>, fabric@... Date: 01/08/2020 08:53 AM Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems Sent by: fabric@... The approval is at the Org level. You only need to target one peer, and then the approval is distributed to other peers using gossip. The endorsement error also pops up if you try to commit a different chaincode definition than the one that was approved. -----fabric@... wrote: ----- To: "Tong Li" <litong01@...> From: "David Enyeart" Sent by: fabric@... Date: 01/08/2020 12:28AM Cc: fabric@... Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems 1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem... Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems. 1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness { "approvals": { "org0examplecom": true, "org1examplecom": true } } That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below. peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA 2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050 2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE) Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other. 2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much. --- Organizations: - &examplecom Name: examplecom ID: examplecom MSPDir: keyfiles/ordererOrganizations/example.com/msp Policies: Readers: Type: Signature Rule: "OR('examplecom.member')" Writers: Type: Signature Rule: "OR('examplecom.member')" Admins: Type: Signature Rule: "OR('examplecom.admin')" - &org0examplecom Name: org0examplecom ID: org0examplecom MSPDir: keyfiles/peerOrganizations/org0.example.com/msp Policies: Readers: Type: Signature Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')" Writers: Type: Signature Rule: "OR('org0examplecom.admin', 'org0examplecom.client')" Admins: Type: Signature Rule: "OR('org0examplecom.admin')" Endorsement: Type: Signature Rule: "OR('org0examplecom.peer')" AnchorPeers: - Host: peer1.org0.example.com Port: 7051 - Host: peer2.org0.example.com Port: 7051 - &org1examplecom Name: org1examplecom ID: org1examplecom MSPDir: keyfiles/peerOrganizations/org1.example.com/msp Policies: Readers: Type: Signature Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')" Writers: Type: Signature Rule: "OR('org1examplecom.admin', 'org1examplecom.client')" Admins: Type: Signature Rule: "OR('org1examplecom.admin')" Endorsement: Type: Signature Rule: "OR('org1examplecom.peer')" AnchorPeers: - Host: peer1.org1.example.com Port: 7051 - Host: peer2.org1.example.com Port: 7051 Capabilities: Channel: &ChannelCapabilities V2_0: true Orderer: &OrdererCapabilities V2_0: true Application: &ApplicationCapabilities V2_0: true Application: &ApplicationDefaults Organizations: Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" LifecycleEndorsement: Type: ImplicitMeta Rule: "MAJORITY Endorsement" Endorsement: Type: ImplicitMeta Rule: "MAJORITY Endorsement" Capabilities: <<: *ApplicationCapabilities Orderer: &OrdererDefaults OrdererType: etcdraft Addresses: - orderer1.example.com:7050 - orderer2.example.com:7050 - orderer3.example.com:7050 BatchTimeout: 2s BatchSize: MaxMessageCount: 10 AbsoluteMaxBytes: 99 MB PreferredMaxBytes: 512 KB EtcdRaft: Consenters: - Host: orderer1.example.com Port: 7050 ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt - Host: orderer2.example.com Port: 7050 ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt - Host: orderer3.example.com Port: 7050 ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt Organizations: Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" BlockValidation: Type: ImplicitMeta Rule: "ANY Writers" Channel: &ChannelDefaults Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" Capabilities: <<: *ChannelCapabilities Profiles: OrgChannel: Consortium: SampleConsortium <<: *ChannelDefaults Application: <<: *ApplicationDefaults Organizations: - *org0examplecom - *org1examplecom Capabilities: <<: *ApplicationCapabilities OrdererGenesis: <<: *ChannelDefaults Capabilities: <<: *ChannelCapabilities Orderer: <<: *OrdererDefaults Organizations: - *examplecom Capabilities: <<: *OrdererCapabilities Application: <<: *ApplicationDefaults Organizations: - <<: *examplecom Consortiums: SampleConsortium: Organizations: - *org0examplecom - *org1examplecom Tong Li IBM Open Technology
|
|
|
|
Re: chaincode 2.0 problems
indirajith
Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, ` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, ` Error: proposal failed with status: 500 - Failed to authorize invocation due to failed ACL check: Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]` I tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? Thank you! BR, Indirajith. On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
|
|
|
|
Re: Why does the Ordering Consensus Work?
Gari Singh <garis@...>
Transaction consensus and validity in Fabric is not the same thing as the consensus mechanism used to build a fault tolerant ordering service.
Have a look at https://hyperledger-fabric.readthedocs.io/en/release-2.0/txflow.html which describes the entire Fabric transaction flow ... this would be considered consensus for Fabric transactions. At a high-level, it is comprised of: - execute chaincode and collect endorsements - submit for ordering - ordering service orders and batches into blocks - ordering service pushes blocks to peers on a per channel basis - peers validate and commit transactions - check that endorsement policy has been satisfied (which means that enough peers executed chaincode with the same results based on policy) - check for collisions using an MVCC-like model (aka double-spend) - if valid, update state The ordering service itself uses a consensus algorithm itself to make sure that all ordering nodes produce batches/blocks with the same transactions in the same order. ----------------------------------------- Gari Singh Distinguished Engineer, CTO - IBM Blockchain IBM Middleware 550 King St Littleton, MA 01460 Cell: 978-846-7499 garis@... ----------------------------------------- -----fabric@... wrote: ----- To: <fabric@...> From: "Trevor Lee Oakley" Sent by: fabric@... Date: 02/06/2020 03:30AM Subject: [EXTERNAL] [Hyperledger Fabric] Why does the Ordering Consensus Work? From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process? Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow? Trevor |
|
|
|
Re: Why does the Ordering Consensus Work?
Brett T Logan <brett.t.logan@...>
The ordering services job is to assemble blocks from transactions and determine the final order of the transactions. It doesn't participate in the validation of the endorsed transactions.
Once the orderer disseminates the block to the peer, the peer validates the signatures, verifies that its endorsements match their expected origin, and that the state of the transaction matches the current state given the current values in the ledger (the state of a key hasn't changed since the proposal was submitted for endorsement as the result of an in-flight transaction).
Your transaction has (assuming it was valid) already passed your endorsement policy, the result of the smart contracts doesn't have to match for all proposals. This is why we write deterministic chaincode, to prevent chaincode from arriving at different results.
----- Original message ----- |
|
|
|
Why does the Ordering Consensus Work?
Trevor Lee Oakley <trevor@...>
From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process?
Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow?
Trevor
|
|
|
|
Registrar enrollment and registration
#fabric-sdk-go
Amal C Saji
Hi,
I am using the example https://github.com/chainHero/heroes-service/ with fabric-sdk-go beta version. When I try to register a new user, registrar part have same issues. I can't register a registrar. The post request return some errors "Client sent an HTTP request to an HTTPS server. : invalid character 'C' looking for beginning of value" |
|
|
|
Fabric contributor meeting - February 5th 14:00 GMT
David Enyeart
For the contributor meeting scheduled for tomorrow, we'll do a quick project update, but there are no deep dive topics scheduled yet. If you have a proposal or other topic you'd like to discuss, please let us know here or on RocketChat fabric-maintainers. |
|
|
|
Re: Error when joining the channel
Nikhil Gupta
Hi Marina, I would check the order log to see what the problems are. You can find some help with what to look for with this stack overflow post: https://stackoverflow.com/questions/57662562/when-i-try-to-create-a-channel-using-hyperledger-fabric-the-request-fails/57662645#57662645 My guess is that your org does not have permission to create a channel in the orderer system channel. or is not a member of the system channel consortium. -----fabric@... wrote: ----- To: "hyperledger-fabric@..." <hyperledger-fabric@...> From: "Marina Wanis" Sent by: fabric@... Date: 02/01/2020 04:37AM Subject: [EXTERNAL] [Hyperledger Fabric] Error when joining the channel Hi,
I used to be able to create the channel using the channel transaction and join the channel with the command : peer channel join -o localhost:7050 -b ./acmechannel.block
I got the following error:
2020-02-01 09:24:48.338 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized Error: proposal failed (err: rpc error: code = Unknown desc = access denied: channel [] creator org [Org1MSP])
I made sure that the identity of the peer is admin. I’m really not sure why I keep getting this error. Thank you, Marina
Sent from Mail for Windows 10
|
|
|
|
Re: How to set regulator or auditor in private data collection
David Enyeart
In v2.0 we are promoting this pattern of org-specific collections, where the per organization collections implicitly exist so that you don't have to define them at all. Thank you for your explanation. I now understand it clearly. But this would cost huge efforts to maintain private data collections in production environment if there are hundreds of private data collections. How about pre-define a regulator or auditor, the private data collection will include this pre-defined regulator or auditor in the collection configuration period. So we don’t need to define every private data collection to include it. It will be automatically included in every private data collection. That would be more simple and useful for massive private data collection configuration in production environment.
A regulator or auditor would be modeled as any other organization. Hi All, The fabric doc said: “Fabric v2.0 also enables new patterns for working with and sharing private data, without the requirement of creating private data collections for all combinations of channel members that may want to transact. Specifically, instead of sharing private data within a collection of multiple members, you may want to share private data across collections, where each collection may include a single organization, or perhaps a single organization along with a regulator or auditor”. I wonder how to set regulator or auditor along with a single organization when using private data in Fabric 2.0? Is there any sample to tell how to do this? |
|
|
"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distrib
"胡 银松" ---02/04/2020 01:51:43 AM--- Thank you for your explanation. I now understand it clearly. But this would cost huge efforts