Date   

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 03/13/2020 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 13 March 2020
6:00am to 7:00am
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Re: Endorsement Policy Failure

email4tong@gmail.com
 

Endorsement policy is set to default when you set up your system. All application channels inherit that policy unless you change them. Then you also have chaincode endorsement policy which gets set when you instantiate your chaincode. I think that is what you were try to use. 

The default policy for 2.0 is set to “Majority”, that means if you have 2 org network, both need to endorse, if 3 org, still 2, but for 4 org, you will need 3.

Also you can look at the configtx.yaml file which should be the place where your initial policy get set.

As I suggested , if you use minifabric, how things get set will be very clear, steps can be easily repeated and tested, there is very clear path on how to get things done, vs other tools you will have to poke here and there, the sequence is chaotic , this is the reason why people always said fabric is too complex. I feel we just do not have the right tool. Minifabric is the attempt towards that direction. Once you start using it, you will learn fabric very quickly and won’t spend a lot your time tweak here or there. 

I hope that helps.




On Thursday, March 12, 2020, 3:19 PM, Tomás Peixinho <tom.peixinho@...> wrote:

Thank you, Tong, I will definitely check this out in greater detail! As for my current problem, I really don't know what I'm supposed to see here. Can you point me to the place or file or code where the endorsement policy is being defined? I don't see any configuration files where this could be defined, or even the usual docker-compose.yaml where the peers and orgs are defined... Am I missing something?

My network works correctly and I would say that I have a base understanding of how everything works (even if very superficial). My only problem now is really just getting my endorsement policies to work.

Cheers

Tom


De: email4tong@... <email4tong@...>
Enviado: quinta-feira, 12 de março de 2020 18:43
Para: Tomás Peixinho <tom.peixinho@...>
Assunto: Re: [Hyperledger Fabric] Endorsement Policy Failure
 
Tomas, since you've had quite a lot of issues, I like to take only few minutes to look at this project, https://github.com/litong01/minifabric, this project is really to help people setting up fabric either on one machine or multiple machines, and also help with learning Fabric by making create channel, join channel, installing chaincode, invoking chaincode,etc extremely simple. You can take a quick look at these two docs to get you started. You do not really need fancy environment, all it takes is an docker environment. Give it a try, it only takes few minutes to see if it works for you or not and it will never pollute your system. 


On Thursday, March 12, 2020, 1:00:18 PM EDT, Tomás Peixinho <tom.peixinho@...> wrote:


Ok, I've switched the policy to use only peers but I still don't know what I'm missing, because I still can't get it to work. Any help at all would be greatly appreciated!

Also, do I have to recreate the crypto material everytime I alter these config files (docker-compose.yml and configtx.yaml)? I'm not sure when it is that I have to do it, but since it's a pain in the ass, I'm asking just to get some guidance.

Thanks again

Tom


De: Yacov Manevich <YACOVM@...>
Enviado: quinta-feira, 12 de março de 2020 07:52
Para: Tomás Peixinho <tom.peixinho@...>
Assunto: RE: [Hyperledger Fabric] Endorsement Policy Failure
 
yes, exactly... only peers.



From:        "Tomás Peixinho" <tom.peixinho@...>
To:        Yacov Manevich <YACOVM@...>
Date:        03/12/2020 01:28 AM
Subject:        [EXTERNAL] RE:  [Hyperledger Fabric] Endorsement Policy Failure




So I should only use "peers" in the endorsement policies? I'm not really sure I understand, but still, that doesn't solve my problem. Even if I take out the "admin" roles I was using and just try the "3-of" out of the 3 peers (one of each org, if my logic is correct), it still doesn't work. I'm clearly missing something...



De: Yacov Manevich <YACOVM@...>
Enviado:
quarta-feira, 11 de março de 2020 22:56
Para:
Tomás Peixinho <tom.peixinho@...>
Assunto:
RE: [Hyperledger Fabric] Endorsement Policy Failure
 
An admin can be used in a policy, but policies can be also used to represent policies which are not endorsement policies.

So, you can't have a peer represent an admin.

Only clients can represent admins.



From:        "Tomás Peixinho" <tom.peixinho@...>
To:        Yacov Manevich <YACOVM@...>
Date:        03/12/2020 12:50 AM
Subject:        [EXTERNAL] RE:  [Hyperledger Fabric] Endorsement Policy Failure




They can't? How so? I should preface this by saying that I really don't know what I'm doing when it comes to this.

On the https://hyperledger-fabric.readthedocs.io/en/release-2.0/policies.htmlit says that there are four MSP Role Types, one of them being "admin". What does this refer to, then? When I'm defining the user context to creat a fabric client for my application and then the channel and whatever else, I define an org admin (one per org). I thought these admins were the same and they were one of the peers of the organization... I'm really confused now, can you please explain it in more detail? I would really like to understand this.

Thanks in advance

Tom





De:
Yacov Manevich <YACOVM@...>
Enviado:
quarta-feira, 11 de março de 2020 22:33
Para:
Tomás Peixinho <tom.peixinho@...>
Cc:
fabric@... <fabric@...>; hyperledger-fabric@... <hyperledger-fabric@...>
Assunto:
Re: [Hyperledger Fabric] Endorsement Policy Failure

why are you using "admin" roles in an endorsement policy? Peers cannot be admins.



From:        "Tomás Peixinho" <tom.peixinho@...>
To:        Yacov Manevich <YACOVM@...>, "hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        03/12/2020 12:06 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] Endorsement Policy Failure
Sent by:        fabric@...




Good evening,

a while back I asked about the endorsement policies, and after I tried to mess with them a bit, I've reached a dead end. My chaincode and application are now complete, so I finally decided to change the endorsement policy (if I don't define it, the default is "Any peer", and this would be very insecure). As a simple starting point, I was trying to have at least one peer from each org to endorse the transactions (my network has 3 orgs), so I defined the policy file as follows:

# A Shotgun policy xx
identities:  # list roles to be used in the policy
  user1: {"role": {"name": "peer", "mspId": "Org1MSP"}} # role member in org with mspid Org1MSP
  user2: {"role": {"name": "peer", "mspId": "Org2MSP"}}
  user3: {"role": {"name": "peer", "mspId": "Org3MSP"}}
  admin1: {"role": {"name": "admin", "mspId": "Org1MSP"}} # admin role.
  admin2: {"role": {"name": "admin", "mspId": "Org2MSP"}}
  admin3: {"role": {"name": "admin", "mspId": "Org3MSP"}}

policy: # the policy  .. could have been flat but show grouping.
  3-of: # signed by one of these groups  can be <n>-of  where <n> is any digit 2-of, 3-of etc..
    - 1-of:
      - signed-by: "user1" # a reference to one of the identities defined above.
      - signed-by: "admin1"
    - 1-of:
      - signed-by: "user2"
      - signed-by: "admin2"
    - 1-of:
      - signed-by: "user3"
      - signed-by: "admin3"

I used the example file that came with the java sdk (chaincodeendorsementpolicy.yaml) and updated it to do what I wanted. However, no matter what I define in this file, the policy check always fails with this message:

2020-03-11 19:22:29.527 UTC [vscc] Validate -> WARN 05a Endorsement policy failure for transaction txid=3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] validateTx -> ERRO 05b VSCCValidateTx for transaction txId = 3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] Validate -> INFO 05c [mychannel] Validated block [2] in 4ms
2020-03-11 19:22:29.527 UTC [valimpl] preprocessProtoBlock -> WARN 05d Channel [mychannel]: Block [2] Transaction index [0] TxId [3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

I thought I might have been doing something wrong with the syntax of the file, but if I change the "3-of" to "0-of", it works, so I guess that's not it. I also thought it could have been because the peers were unable to find each other, so I manually defined the anchor peers for each organization on the configtx.yaml (the port I defined for all of them was the 7051, which was the default port for the peer0-org1, not sure if this is correct or not), and I also defined the fields CORE_PEER_GOSSIP_BOOTSTRAP and CORE_PEER_GOSSIP_EXTERNALENDPOINT for each peer on the docker-compose.yml (the file which defines the network topology), but I'm also not sure of what I should define them with, so I put the "bootstrap" with the address of the anchor peer of the org, and the "external endpoint" with the same address as the peer on which I'm defining it. This final alteration was because I was getting a warning saying that since the external endpoint wasn't defined, peers were unable to see each other and I thought that might have something to do with it (if they couldn't find peers from different orgs, these weren't able to endorse the transactions and the verification would fail, just a theory).

Not sure if any of this makes sense, but since it's not working, I'm gonna go ahead and assume it doesn't. Or maybe my problem isn't even related to any of this, but in that case, I really don't know what I'm missing or doing wrong. Any help would be greatly appreciated. If I'm going about this all wrong, my purpose here was just to define my own endorsement policy, in order to make the blockchain more secure (as per Yacov's recommendation), so if someone can enlighten me on the subject, I thank you in avance.

Cheers

Tomás








Re: Endorsement Policy Failure

Tomás Peixinho
 

Thank you, Tong, I will definitely check this out in greater detail! As for my current problem, I really don't know what I'm supposed to see here. Can you point me to the place or file or code where the endorsement policy is being defined? I don't see any configuration files where this could be defined, or even the usual docker-compose.yaml where the peers and orgs are defined... Am I missing something?

My network works correctly and I would say that I have a base understanding of how everything works (even if very superficial). My only problem now is really just getting my endorsement policies to work.

Cheers

Tom


De: email4tong@... <email4tong@...>
Enviado: quinta-feira, 12 de março de 2020 18:43
Para: Tomás Peixinho <tom.peixinho@...>
Assunto: Re: [Hyperledger Fabric] Endorsement Policy Failure
 
Tomas, since you've had quite a lot of issues, I like to take only few minutes to look at this project, https://github.com/litong01/minifabric, this project is really to help people setting up fabric either on one machine or multiple machines, and also help with learning Fabric by making create channel, join channel, installing chaincode, invoking chaincode,etc extremely simple. You can take a quick look at these two docs to get you started. You do not really need fancy environment, all it takes is an docker environment. Give it a try, it only takes few minutes to see if it works for you or not and it will never pollute your system. 


On Thursday, March 12, 2020, 1:00:18 PM EDT, Tomás Peixinho <tom.peixinho@...> wrote:


Ok, I've switched the policy to use only peers but I still don't know what I'm missing, because I still can't get it to work. Any help at all would be greatly appreciated!

Also, do I have to recreate the crypto material everytime I alter these config files (docker-compose.yml and configtx.yaml)? I'm not sure when it is that I have to do it, but since it's a pain in the ass, I'm asking just to get some guidance.

Thanks again

Tom


De: Yacov Manevich <YACOVM@...>
Enviado: quinta-feira, 12 de março de 2020 07:52
Para: Tomás Peixinho <tom.peixinho@...>
Assunto: RE: [Hyperledger Fabric] Endorsement Policy Failure
 
yes, exactly... only peers.



From:        "Tomás Peixinho" <tom.peixinho@...>
To:        Yacov Manevich <YACOVM@...>
Date:        03/12/2020 01:28 AM
Subject:        [EXTERNAL] RE:  [Hyperledger Fabric] Endorsement Policy Failure




So I should only use "peers" in the endorsement policies? I'm not really sure I understand, but still, that doesn't solve my problem. Even if I take out the "admin" roles I was using and just try the "3-of" out of the 3 peers (one of each org, if my logic is correct), it still doesn't work. I'm clearly missing something...



De: Yacov Manevich <YACOVM@...>
Enviado:
quarta-feira, 11 de março de 2020 22:56
Para:
Tomás Peixinho <tom.peixinho@...>
Assunto:
RE: [Hyperledger Fabric] Endorsement Policy Failure

 
An admin can be used in a policy, but policies can be also used to represent policies which are not endorsement policies.

So, you can't have a peer represent an admin.


Only clients can represent admins.




From:        
"Tomás Peixinho" <tom.peixinho@...>
To:        
Yacov Manevich <YACOVM@...>
Date:        
03/12/2020 12:50 AM
Subject:        
[EXTERNAL] RE:  [Hyperledger Fabric] Endorsement Policy Failure




They can't? How so? I should preface this by saying that I really don't know what I'm doing when it comes to this.

On the https://hyperledger-fabric.readthedocs.io/en/release-2.0/policies.htmlit says that there are four MSP Role Types, one of them being "admin". What does this refer to, then? When I'm defining the user context to creat a fabric client for my application and then the channel and whatever else, I define an org admin (one per org). I thought these admins were the same and they were one of the peers of the organization... I'm really confused now, can you please explain it in more detail? I would really like to understand this.

Thanks in advance

Tom





De:
Yacov Manevich <YACOVM@...>
Enviado:
quarta-feira, 11 de março de 2020 22:33
Para:
Tomás Peixinho <tom.peixinho@...>
Cc:
fabric@... <fabric@...>; hyperledger-fabric@... <hyperledger-fabric@...>
Assunto:
Re: [Hyperledger Fabric] Endorsement Policy Failure

why are you using "admin" roles in an endorsement policy? Peers cannot be admins.




From:        
"Tomás Peixinho" <tom.peixinho@...>
To:        
Yacov Manevich <YACOVM@...>, "hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        
03/12/2020 12:06 AM
Subject:        
[EXTERNAL] [Hyperledger Fabric] Endorsement Policy Failure
Sent by:        
fabric@...




Good evening,

a while back I asked about the endorsement policies, and after I tried to mess with them a bit, I've reached a dead end. My chaincode and application are now complete, so I finally decided to change the endorsement policy (if I don't define it, the default is "Any peer", and this would be very insecure). As a simple starting point, I was trying to have at least one peer from each org to endorse the transactions (my network has 3 orgs), so I defined the policy file as follows:

# A Shotgun policy xx
identities:  # list roles to be used in the policy
  user1: {"role": {"name": "peer", "mspId": "Org1MSP"}} # role member in org with mspid Org1MSP
  user2: {"role": {"name": "peer", "mspId": "Org2MSP"}}
  user3: {"role": {"name": "peer", "mspId": "Org3MSP"}}
  admin1: {"role": {"name": "admin", "mspId": "Org1MSP"}} # admin role.
  admin2: {"role": {"name": "admin", "mspId": "Org2MSP"}}
  admin3: {"role": {"name": "admin", "mspId": "Org3MSP"}}

policy: # the policy  .. could have been flat but show grouping.
  3-of: # signed by one of these groups  can be <n>-of  where <n> is any digit 2-of, 3-of etc..
    - 1-of:
      - signed-by: "user1" # a reference to one of the identities defined above.
      - signed-by: "admin1"
    - 1-of:
      - signed-by: "user2"
      - signed-by: "admin2"
    - 1-of:
      - signed-by: "user3"
      - signed-by: "admin3"

I used the example file that came with the java sdk (chaincodeendorsementpolicy.yaml) and updated it to do what I wanted. However, no matter what I define in this file, the policy check always fails with this message:

2020-03-11 19:22:29.527 UTC [vscc] Validate -> WARN 05a Endorsement policy failure for transaction txid=3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] validateTx -> ERRO 05b VSCCValidateTx for transaction txId = 3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] Validate -> INFO 05c [mychannel] Validated block [2] in 4ms
2020-03-11 19:22:29.527 UTC [valimpl] preprocessProtoBlock -> WARN 05d Channel [mychannel]: Block [2] Transaction index [0] TxId [3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

I thought I might have been doing something wrong with the syntax of the file, but if I change the "3-of" to "0-of", it works, so I guess that's not it. I also thought it could have been because the peers were unable to find each other, so I manually defined the anchor peers for each organization on the configtx.yaml (the port I defined for all of them was the 7051, which was the default port for the peer0-org1, not sure if this is correct or not), and I also defined the fields CORE_PEER_GOSSIP_BOOTSTRAP and CORE_PEER_GOSSIP_EXTERNALENDPOINT for each peer on the docker-compose.yml (the file which defines the network topology), but I'm also not sure of what I should define them with, so I put the "bootstrap" with the address of the anchor peer of the org, and the "external endpoint" with the same address as the peer on which I'm defining it. This final alteration was because I was getting a warning saying that since the external endpoint wasn't defined, peers were unable to see each other and I thought that might have something to do with it (if they couldn't find peers from different orgs, these weren't able to endorse the transactions and the verification would fail, just a theory).

Not sure if any of this makes sense, but since it's not working, I'm gonna go ahead and assume it doesn't. Or maybe my problem isn't even related to any of this, but in that case, I really don't know what I'm missing or doing wrong. Any help would be greatly appreciated. If I'm going about this all wrong, my purpose here was just to define my own endorsement policy, in order to make the blockchain more secure (as per Yacov's recommendation), so if someone can enlighten me on the subject, I thank you in avance.

Cheers

Tomás








Documentation Workgroup: Agenda for Friday, 13 March

Anthony O'Dowd <a_o-dowd@...>
 

Hello!

We will hold the documentation workgroup call this Friday as usual -- with both an Eastern hemisphere and Western hemisphere call.

You can read all about last week's call at https://wiki.hyperledger.org/display/fabric/2020+03+06+DWG+Agenda It included a V2 status update from Pam and Joe, including all the new items in development for 2.x, with an indication of possible delivery for these items. We reviewed the Deploy chaincode tutorial with Nik, the new Fabric CA documentation with Pam, and the Commands Reference topic.

You can catch up with the recording: https://wiki.hyperledger.org/display/fabric/Recordings

You'll see that there are lots of interesting items for this week, including an update on the recent Hyperledger Global forum, from Chris. See  https://wiki.hyperledger.org/display/fabric/2020+03+13+DWG+Agenda for the full agenda.

Please feel free to contribute using the wiki, including helping to build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+03+20+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 119A: Friday 13 March
                   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 119B: Friday 13 Mar
              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 Time
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: Endorsement Policy Failure

Tomás Peixinho
 

Ok, I've switched the policy to use only peers but I still don't know what I'm missing, because I still can't get it to work. Any help at all would be greatly appreciated!

Also, do I have to recreate the crypto material everytime I alter these config files (docker-compose.yml and configtx.yaml)? I'm not sure when it is that I have to do it, but since it's a pain in the ass, I'm asking just to get some guidance.

Thanks again

Tom


De: Yacov Manevich <YACOVM@...>
Enviado: quinta-feira, 12 de março de 2020 07:52
Para: Tomás Peixinho <tom.peixinho@...>
Assunto: RE: [Hyperledger Fabric] Endorsement Policy Failure
 
yes, exactly... only peers.



From:        "Tomás Peixinho" <tom.peixinho@...>
To:        Yacov Manevich <YACOVM@...>
Date:        03/12/2020 01:28 AM
Subject:        [EXTERNAL] RE:  [Hyperledger Fabric] Endorsement Policy Failure




So I should only use "peers" in the endorsement policies? I'm not really sure I understand, but still, that doesn't solve my problem. Even if I take out the "admin" roles I was using and just try the "3-of" out of the 3 peers (one of each org, if my logic is correct), it still doesn't work. I'm clearly missing something...



De: Yacov Manevich <YACOVM@...>
Enviado:
quarta-feira, 11 de março de 2020 22:56
Para:
Tomás Peixinho <tom.peixinho@...>
Assunto:
RE: [Hyperledger Fabric] Endorsement Policy Failure

 
An admin can be used in a policy, but policies can be also used to represent policies which are not endorsement policies.

So, you can't have a peer represent an admin.


Only clients can represent admins.




From:        
"Tomás Peixinho" <tom.peixinho@...>
To:        
Yacov Manevich <YACOVM@...>
Date:        
03/12/2020 12:50 AM
Subject:        
[EXTERNAL] RE:  [Hyperledger Fabric] Endorsement Policy Failure




They can't? How so? I should preface this by saying that I really don't know what I'm doing when it comes to this.

On the https://hyperledger-fabric.readthedocs.io/en/release-2.0/policies.htmlit says that there are four MSP Role Types, one of them being "admin". What does this refer to, then? When I'm defining the user context to creat a fabric client for my application and then the channel and whatever else, I define an org admin (one per org). I thought these admins were the same and they were one of the peers of the organization... I'm really confused now, can you please explain it in more detail? I would really like to understand this.

Thanks in advance

Tom





De:
Yacov Manevich <YACOVM@...>
Enviado:
quarta-feira, 11 de março de 2020 22:33
Para:
Tomás Peixinho <tom.peixinho@...>
Cc:
fabric@... <fabric@...>; hyperledger-fabric@... <hyperledger-fabric@...>
Assunto:
Re: [Hyperledger Fabric] Endorsement Policy Failure

why are you using "admin" roles in an endorsement policy? Peers cannot be admins.




From:        
"Tomás Peixinho" <tom.peixinho@...>
To:        
Yacov Manevich <YACOVM@...>, "hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        
03/12/2020 12:06 AM
Subject:        
[EXTERNAL] [Hyperledger Fabric] Endorsement Policy Failure
Sent by:        
fabric@...




Good evening,

a while back I asked about the endorsement policies, and after I tried to mess with them a bit, I've reached a dead end. My chaincode and application are now complete, so I finally decided to change the endorsement policy (if I don't define it, the default is "Any peer", and this would be very insecure). As a simple starting point, I was trying to have at least one peer from each org to endorse the transactions (my network has 3 orgs), so I defined the policy file as follows:

# A Shotgun policy xx
identities:  # list roles to be used in the policy
  user1: {"role": {"name": "peer", "mspId": "Org1MSP"}} # role member in org with mspid Org1MSP
  user2: {"role": {"name": "peer", "mspId": "Org2MSP"}}
  user3: {"role": {"name": "peer", "mspId": "Org3MSP"}}
  admin1: {"role": {"name": "admin", "mspId": "Org1MSP"}} # admin role.
  admin2: {"role": {"name": "admin", "mspId": "Org2MSP"}}
  admin3: {"role": {"name": "admin", "mspId": "Org3MSP"}}

policy: # the policy  .. could have been flat but show grouping.
  3-of: # signed by one of these groups  can be <n>-of  where <n> is any digit 2-of, 3-of etc..
    - 1-of:
      - signed-by: "user1" # a reference to one of the identities defined above.
      - signed-by: "admin1"
    - 1-of:
      - signed-by: "user2"
      - signed-by: "admin2"
    - 1-of:
      - signed-by: "user3"
      - signed-by: "admin3"

I used the example file that came with the java sdk (chaincodeendorsementpolicy.yaml) and updated it to do what I wanted. However, no matter what I define in this file, the policy check always fails with this message:

2020-03-11 19:22:29.527 UTC [vscc] Validate -> WARN 05a Endorsement policy failure for transaction txid=3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] validateTx -> ERRO 05b VSCCValidateTx for transaction txId = 3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] Validate -> INFO 05c [mychannel] Validated block [2] in 4ms
2020-03-11 19:22:29.527 UTC [valimpl] preprocessProtoBlock -> WARN 05d Channel [mychannel]: Block [2] Transaction index [0] TxId [3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

I thought I might have been doing something wrong with the syntax of the file, but if I change the "3-of" to "0-of", it works, so I guess that's not it. I also thought it could have been because the peers were unable to find each other, so I manually defined the anchor peers for each organization on the configtx.yaml (the port I defined for all of them was the 7051, which was the default port for the peer0-org1, not sure if this is correct or not), and I also defined the fields CORE_PEER_GOSSIP_BOOTSTRAP and CORE_PEER_GOSSIP_EXTERNALENDPOINT for each peer on the docker-compose.yml (the file which defines the network topology), but I'm also not sure of what I should define them with, so I put the "bootstrap" with the address of the anchor peer of the org, and the "external endpoint" with the same address as the peer on which I'm defining it. This final alteration was because I was getting a warning saying that since the external endpoint wasn't defined, peers were unable to see each other and I thought that might have something to do with it (if they couldn't find peers from different orgs, these weren't able to endorse the transactions and the verification would fail, just a theory).

Not sure if any of this makes sense, but since it's not working, I'm gonna go ahead and assume it doesn't. Or maybe my problem isn't even related to any of this, but in that case, I really don't know what I'm missing or doing wrong. Any help would be greatly appreciated. If I'm going about this all wrong, my purpose here was just to define my own endorsement policy, in order to make the blockchain more secure (as per Yacov's recommendation), so if someone can enlighten me on the subject, I thank you in avance.

Cheers

Tomás








Re: Total storage size prediction for my application in hyperledger fabric #fabric #fabric-dstorage #fabric-questions

Yacov
 

In addition, there is a (very) long discussion about minimizing transaction size in https://jira.hyperledger.org/browse/FAB-8007



From:        "David Enyeart" <enyeart@...>
To:        ever4cys@...
Cc:        fabric@...
Date:        03/12/2020 02:46 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Total storage size prediction for my application in hyperledger fabric #fabric #fabric-dstorage #fabric-questions
Sent by:        fabric@...




There is going to be some overhead for the first endorser transaction. You would need to create many representative transactions, find the average growth, and then extrapolate. Even a small transaction will grow to about 5kb in the block due to the various certificates and metadata stored in a transaction. So the block storage will be the largest component (in /var/hyperleder/production), but there also will be some other metadata. The only metadata you can disable is the history database at core.yaml ledger.history.enableHistoryDatabase. This database holds pointers to the block structure per key, rather than the actual historical key values. If you disable it, the only impact is that you will not be able to perform GetHistoryForKey() queries.


Dave Enyeart

ever4cys---03/12/2020 06:11:14 AM---Hi group members, I am a kinda of newbie to hyperledger fabric chaincode.

From:
ever4cys@...
To:
fabric@...
Date:
03/12/2020 06:11 AM
Subject:
[EXTERNAL] [Hyperledger Fabric] Total storage size prediction for my application in hyperledger fabric #fabric #fabric-dstorage #fabric-questions
Sent by:
fabric@...




Hi group members,

I am a kinda of newbie to hyperledger fabric chaincode.
I need to know how much disk spaces should be prepared for my hyperledger fabric application.

I evoked one simple transaction which add about 100 byte string to the ledger.
It increased the size of peer docker about 100 kbyte.
When I saw the size increment of chain file in /var/hyperledger/production/..., it had only 5.5kbyte increment.
So, I need to know which part is increased, how much it is increased, and how to minimize it to prepare my application.
I use CouchDB so that I don't need to think about world state DB size because it is separated and another issue.

1) What is the reason of the size increment in peer docker beside the chain file in /var/hyperledger/production/... ? It's almost 100kbyte but even I couldn't find the location of the increment.
2) If I have 1 Org with 2 peers and 1 orderer, should I prepare 3x disk size of the ledger size increment only? or more?
3) General block(or transaction) overhead is about 100kbyte? It just insert or update one 100byte string to the world state.
4) I'd like to minimize the size increment in the whole system. What I have to store in the ledger is the history of all calls (I mean all 100-byte data). How can I minimize it? Can I switch off some options?

Thank you very much.
cys








Re: Why shouldn't print chaincode logging to peer in production? #fabric-chaincode-evm

Aboubakar Koïta
 

Hi,

I have the same questions as Hubert, any ideas for answers?


Best regards,
Aboubakar


Re: Total storage size prediction for my application in hyperledger fabric #fabric #fabric-dstorage #fabric-questions

David Enyeart
 

There is going to be some overhead for the first endorser transaction. You would need to create many representative transactions, find the average growth, and then extrapolate. Even a small transaction will grow to about 5kb in the block due to the various certificates and metadata stored in a transaction. So the block storage will be the largest component (in /var/hyperleder/production), but there also will be some other metadata. The only metadata you can disable is the history database at core.yaml ledger.history.enableHistoryDatabase. This database holds pointers to the block structure per key, rather than the actual historical key values. If you disable it, the only impact is that you will not be able to perform GetHistoryForKey() queries.


Dave Enyeart

ever4cys---03/12/2020 06:11:14 AM---Hi group members, I am a kinda of newbie to hyperledger fabric chaincode.

From: ever4cys@...
To: fabric@...
Date: 03/12/2020 06:11 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Total storage size prediction for my application in hyperledger fabric #fabric #fabric-dstorage #fabric-questions
Sent by: fabric@...





Hi group members,

I am a kinda of newbie to hyperledger fabric chaincode.
I need to know how much disk spaces should be prepared for my hyperledger fabric application.

I evoked one simple transaction which add about 100 byte string to the ledger.
It increased the size of peer docker about 100 kbyte.
When I saw the size increment of chain file in /var/hyperledger/production/..., it had only 5.5kbyte increment.
So, I need to know which part is increased, how much it is increased, and how to minimize it to prepare my application.
I use CouchDB so that I don't need to think about world state DB size because it is separated and another issue.

1) What is the reason of the size increment in peer docker beside the chain file in /var/hyperledger/production/... ? It's almost 100kbyte but even I couldn't find the location of the increment.
2) If I have 1 Org with 2 peers and 1 orderer, should I prepare 3x disk size of the ledger size increment only? or more?
3) General block(or transaction) overhead is about 100kbyte? It just insert or update one 100byte string to the world state.
4) I'd like to minimize the size increment in the whole system. What I have to store in the ledger is the history of all calls (I mean all 100-byte data). How can I minimize it? Can I switch off some options?

Thank you very much.
cys






Total storage size prediction for my application in hyperledger fabric #fabric #fabric-dstorage #fabric-questions

ever4cys@...
 

Hi group members,

I am a kinda of newbie to hyperledger fabric chaincode.
I need to know how much disk spaces should be prepared for my hyperledger fabric application.

I evoked one simple transaction which add about 100 byte string to the ledger.
It increased the size of peer docker about 100 kbyte.
When I saw the size increment of chain file in /var/hyperledger/production/..., it had only 5.5kbyte increment.
So, I need to know which part is increased, how much it is increased, and how to minimize it to prepare my application.
I use CouchDB so that I don't need to think about world state DB size because it is separated and another issue.

1) What is the reason of the size increment in peer docker beside the chain file in /var/hyperledger/production/... ? It's almost 100kbyte but even I couldn't find the location of the increment.
2) If I have 1 Org with 2 peers and 1 orderer, should I prepare 3x disk size of the ledger size increment only? or more?
3) General block(or transaction) overhead is about 100kbyte? It just insert or update one 100byte string to the world state.
4) I'd like to minimize the size increment in the whole system. What I have to store in the ledger is the history of all calls (I mean all 100-byte data). How can I minimize it? Can I switch off some options?

Thank you very much.
cys



Re: Hyperledger install Java chaincode #fabric-chaincode

Matthew White
 

This, I believe, will be a mismatch of versions on the `build.gradle` file;  
 
Check the version of the 'shadowJar' plugin used - in some examples there was an older version of this that was for previous gradle versions... Latest version details are here >  https://github.com/johnrengelman/shadow
 
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Antoni Massó Mola" <antonimassomola@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Hyperledger install Java chaincode #fabric-chaincode
Date: Thu, Mar 12, 2020 7:50 AM
 
Hello,
 

I'm trying to install Java chaincode. I'm able to install go & javascript chaincode but Java installation:

peer chaincode install -n chaincode_exampleJava1 -v 1.2 -l java -p /opt/gopath/src/github.com/chaincode_exampleJava1/

Fails with the following error (tried with v1.4 & v2):

Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: docker build failed: docker image build failed: docker build failed: Error returned from build: 1 "+ INPUT_DIR=/chaincode/input
+ OUTPUT_DIR=/chaincode/output
++ find /chaincode/input -name .jar
++ paste -s -d : -
+ JARS=
++ find /chaincode/input -name '*.jar'
++ wc -l
+ NUM_JARS=0
+ for DIR in ${INPUT_DIR} ${INPUT_DIR}/src
+ '[' -f /chaincode/input/build.gradle -o -f /chaincode/input/build.gradle.kts ']'
+ '[' -f /chaincode/input/pom.xml ']'
+ for DIR in ${INPUT_DIR} ${INPUT_DIR}/src
+ '[' -f /chaincode/input/src/build.gradle -o -f /chaincode/input/src/build.gradle.kts ']'
+ buildGradle /chaincode/input/src /chaincode/output
+ cd /chaincode/input/src
Gradle build
+ echo 'Gradle build'
+ '[' -f ./gradlew ']'
+ gradle build shadowJar

Welcome to Gradle 5.6.2!

Here are the highlights of this release:
 - Incremental Groovy compilation
 - Groovy compile avoidance
 - Test fixtures for Java projects
 - Manage plugin versions via settings script

For more details see https://docs.gradle.org/5.6.2/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)

FAILURE: Build failed with an exception.

* What went wrong:
Receiver class com.github.jengelman.gradle.plugins.shadow.internal.DependencyFileCollection does not define or inherit an implementation of the resolved method 'abstract org.gradle.api.tasks.TaskDependency getBuildDependencies()' of interface org.gradle.api.Buildable.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 11s
Any help would be appreciated. Thanks.
 
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: How to increase capacity of peer node to handle many transactions simultaneously #hyperledger-fabric #fabric

keerthycbe@...
 

Thanks Prasanth. I think you have given me good directions to look into. I agree with your approaches that can definitely improve performance. 


Hyperledger install Java chaincode #fabric-chaincode

Antoni Massó Mola <antonimassomola@...>
 

Hello,

I'm trying to install Java chaincode. I'm able to install go & javascript chaincode but Java installation:

peer chaincode install -n chaincode_exampleJava1 -v 1.2 -l java -p /opt/gopath/src/github.com/chaincode_exampleJava1/

Fails with the following error (tried with v1.4 & v2):

Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: docker build failed: docker image build failed: docker build failed: Error returned from build: 1 "+ INPUT_DIR=/chaincode/input
+ OUTPUT_DIR=/chaincode/output
++ find /chaincode/input -name .jar
++ paste -s -d : -
+ JARS=
++ find /chaincode/input -name '*.jar'
++ wc -l
+ NUM_JARS=0
+ for DIR in ${INPUT_DIR} ${INPUT_DIR}/src
+ '[' -f /chaincode/input/build.gradle -o -f /chaincode/input/build.gradle.kts ']'
+ '[' -f /chaincode/input/pom.xml ']'
+ for DIR in ${INPUT_DIR} ${INPUT_DIR}/src
+ '[' -f /chaincode/input/src/build.gradle -o -f /chaincode/input/src/build.gradle.kts ']'
+ buildGradle /chaincode/input/src /chaincode/output
+ cd /chaincode/input/src
Gradle build
+ echo 'Gradle build'
+ '[' -f ./gradlew ']'
+ gradle build shadowJar

Welcome to Gradle 5.6.2!

Here are the highlights of this release:
 - Incremental Groovy compilation
 - Groovy compile avoidance
 - Test fixtures for Java projects
 - Manage plugin versions via settings script

For more details see https://docs.gradle.org/5.6.2/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)

FAILURE: Build failed with an exception.

* What went wrong:
Receiver class com.github.jengelman.gradle.plugins.shadow.internal.DependencyFileCollection does not define or inherit an implementation of the resolved method 'abstract org.gradle.api.tasks.TaskDependency getBuildDependencies()' of interface org.gradle.api.Buildable.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 11s
Any help would be appreciated. Thanks.


Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 03/13/2020 6:00am-7:00am #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When: Friday, 13 March 2020, 6:00am to 7:00am, (GMT+00:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

Description: Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Re: #hyperledger-fabric Problems after peer channel update: PANI 044 Cannot commit block to the ledger due to config currently at sequence 0, cannot validate config at sequence 2 #hyperledger-fabric

Howin Ho
 

I believe you should peer channel join before peer channel update. The reason being that after you peer channel update, the genesis block [block 0] becomes outdated.


GO SDK support for fabric 2.0

Suhan Sumeet
 

Hello Team,

Do we have GO SDK for fabric 2.0, and if not any idea by when we are going to have it for fabric 2.0

Regards,
Sunil Suseelan


#hyperledger-fabric Problems after peer channel update: PANI 044 Cannot commit block to the ledger due to config currently at sequence 0, cannot validate config at sequence 2 #hyperledger-fabric

Magno Alves Cavalcante
 

Fabric 1.4.3 version, 1 Oderer, 1 Org
Impossible to continue after join peer in channel.

1) At CLI docker prompt, execute:
peer channel create -o $ORDERERNAME -c $CHANNELNAME -f $CONFIGTXFOLDER/devchannel.tx --tls --cafile=$ORDERER_TLSCACERT

Last output log >> UTC [cli.common] readBlock -> INFO 04e Received block: 0

2) At CLI docker prompt, execute:
peer channel update -o $ORDERERNAME -c $CHANNELNAME -f $CONFIGTXFOLDER/$CHANNELNAME-OrgAnchor.tx --tls --cafile=$ORDERER_TLSCACERT

Last output log >> UTC [channelCmd] update -> INFO 04a Successfully submitted channel update

3) At CLI docker prompt, execute:
peer channel join -o $ORDERERNAME -b $CONFIGTXFOLDER/devgenesis.block --tls --cafile=$ORDERER_TLSCACERT

Last output log >> UTC [channelCmd] executeJoin -> INFO 03e Successfully submitted proposal to join channel

And after small time, PEER0 enter in PANIC mode and shutdown

Inspecting logs at PEER0, display:
===
2020-03-12 01:05:23.586 UTC [gossip.state] NewGossipStateProvider -> INFO 035 Updating metadata information, current ledger sequence is at = 0, next expected block is = 1
2020-03-12 01:05:23.588 UTC [sccapi] deploySysCC -> INFO 036 system chaincode lscc/devchannel(github.com/hyperledger/fabric/core/scc/lscc) deployed
2020-03-12 01:05:23.588 UTC [cscc] Init -> INFO 037 Init CSCC
2020-03-12 01:05:23.588 UTC [sccapi] deploySysCC -> INFO 038 system chaincode cscc/devchannel(github.com/hyperledger/fabric/core/scc/cscc) deployed
2020-03-12 01:05:23.588 UTC [qscc] Init -> INFO 039 Init QSCC
2020-03-12 01:05:23.588 UTC [sccapi] deploySysCC -> INFO 03a system chaincode qscc/devchannel(github.com/hyperledger/fabric/core/scc/qscc) deployed
2020-03-12 01:05:23.588 UTC [sccapi] deploySysCC -> INFO 03b system chaincode (+lifecycle,github.com/hyperledger/fabric/core/chaincode/lifecycle) disabled
2020-03-12 01:05:23.588 UTC [endorser] callChaincode -> INFO 03c [][a2380c69] Exit chaincode: name:"cscc" (239ms)
2020-03-12 01:05:23.588 UTC [comm.grpc.server] 1 -> INFO 03d unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=172.28.0.5:53834 grpc.code=OK grpc.call_duration=241.332991ms
2020-03-12 01:05:29.589 UTC [gossip.election] beLeader -> INFO 03e f26b9868b8d67867e01dd06c4965e5db9ed6556350f62e688c3081a456c0d3af : Becoming a leader
2020-03-12 01:05:29.589 UTC [gossip.service] func1 -> INFO 03f Elected as a leader, starting delivery service for channel devchannel
2020-03-12 01:05:29.609 UTC [gossip.privdata] StoreBlock -> INFO 040 [devchannel] Received block [1] from buffer
2020-03-12 01:05:29.610 UTC [committer.txvalidator] validateTx -> ERRO 041 config currently at sequence 0, cannot validate config at sequence 2
github.com/hyperledger/fabric/common/configtx.(*ValidatorImpl).Validate
/opt/gopath/src/github.com/hyperledger/fabric/common/configtx/validator.go:170
github.com/hyperledger/fabric/core/peer.(*chainSupport).Apply
/opt/gopath/src/github.com/hyperledger/fabric/core/peer/peer.go:141
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:425
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
error validating config which passed initial validity checks
2020-03-12 01:05:29.610 UTC [gossip.privdata] StoreBlock -> ERRO 042 Validation failed: config currently at sequence 0, cannot validate config at sequence 2
github.com/hyperledger/fabric/common/configtx.(*ValidatorImpl).Validate
/opt/gopath/src/github.com/hyperledger/fabric/common/configtx/validator.go:170
github.com/hyperledger/fabric/core/peer.(*chainSupport).Apply
/opt/gopath/src/github.com/hyperledger/fabric/core/peer/peer.go:141
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:425
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
error validating config which passed initial validity checks
2020-03-12 01:05:29.610 UTC [gossip.state] commitBlock -> ERRO 043 Got error while committing(config currently at sequence 0, cannot validate config at sequence 2
github.com/hyperledger/fabric/common/configtx.(*ValidatorImpl).Validate
/opt/gopath/src/github.com/hyperledger/fabric/common/configtx/validator.go:170
github.com/hyperledger/fabric/core/peer.(*chainSupport).Apply
/opt/gopath/src/github.com/hyperledger/fabric/core/peer/peer.go:141
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:425
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
error validating config which passed initial validity checks
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).commitBlock
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:811
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:598
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333)
2020-03-12 01:05:29.610 UTC [gossip.state] deliverPayloads -> PANI 044 Cannot commit block to the ledger due to config currently at sequence 0, cannot validate config at sequence 2
github.com/hyperledger/fabric/common/configtx.(*ValidatorImpl).Validate
/opt/gopath/src/github.com/hyperledger/fabric/common/configtx/validator.go:170
github.com/hyperledger/fabric/core/peer.(*chainSupport).Apply
/opt/gopath/src/github.com/hyperledger/fabric/core/peer/peer.go:141
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:425
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
error validating config which passed initial validity checks
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:603
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
panic: Cannot commit block to the ledger due to config currently at sequence 0, cannot validate config at sequence 2
github.com/hyperledger/fabric/common/configtx.(*ValidatorImpl).Validate
/opt/gopath/src/github.com/hyperledger/fabric/common/configtx/validator.go:170
github.com/hyperledger/fabric/core/peer.(*chainSupport).Apply
/opt/gopath/src/github.com/hyperledger/fabric/core/peer/peer.go:141
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:425
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
error validating config which passed initial validity checks
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:603
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333

goroutine 361 [running]:
github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc00215a210, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore/entry.go:229 +0x515
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).log(0xc00000e520, 0x4, 0x128f3f7, 0x2c, 0xc002cfec90, 0x1, 0x1, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:234 +0xf6
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).Panicf(0xc00000e520, 0x128f3f7, 0x2c, 0xc002cfec90, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:159 +0x79
github.com/hyperledger/fabric/common/flogging.(*FabricLogger).Panicf(0xc00000e528, 0x128f3f7, 0x2c, 0xc002cfec90, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/common/flogging/zap.go:74 +0x60
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads(0xc0025a99a0)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:603 +0x4a5
created by github.com/hyperledger/fabric/gossip/state.NewGossipStateProvider
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:284 +0x714

====
May you help ?


Re: Endorsement Policy Failure

Yacov
 

why are you using "admin" roles in an endorsement policy? Peers cannot be admins.



From:        "Tomás Peixinho" <tom.peixinho@...>
To:        Yacov Manevich <YACOVM@...>, "hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        03/12/2020 12:06 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] Endorsement Policy Failure
Sent by:        fabric@...




Good evening,

a while back I asked about the endorsement policies, and after I tried to mess with them a bit, I've reached a dead end. My chaincode and application are now complete, so I finally decided to change the endorsement policy (if I don't define it, the default is "Any peer", and this would be very insecure). As a simple starting point, I was trying to have at least one peer from each org to endorse the transactions (my network has 3 orgs), so I defined the policy file as follows:

# A Shotgun policy xx
identities:  # list roles to be used in the policy
    user1: {"role": {"name": "peer", "mspId": "Org1MSP"}} # role member in org with mspid Org1MSP
    user2: {"role": {"name": "peer", "mspId": "Org2MSP"}}
    user3: {"role": {"name": "peer", "mspId": "Org3MSP"}}
    admin1: {"role": {"name": "admin", "mspId": "Org1MSP"}} # admin role.
    admin2: {"role": {"name": "admin", "mspId": "Org2MSP"}}
    admin3: {"role": {"name": "admin", "mspId": "Org3MSP"}}

policy: # the policy  .. could have been flat but show grouping.
    3-of: # signed by one of these groups  can be <n>-of  where <n> is any digit 2-of, 3-of etc..
      - 1-of:
        - signed-by: "user1" # a reference to one of the identities defined above.
        - signed-by: "admin1"
      - 1-of:
        - signed-by: "user2"
        - signed-by: "admin2"
      - 1-of:
        - signed-by: "user3"
        - signed-by: "admin3"

I used the example file that came with the java sdk (chaincodeendorsementpolicy.yaml) and updated it to do what I wanted. However, no matter what I define in this file, the policy check always fails with this message:

2020-03-11 19:22:29.527 UTC [vscc] Validate -> WARN 05a Endorsement policy failure for transaction txid=3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] validateTx -> ERRO 05b VSCCValidateTx for transaction txId = 3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] Validate -> INFO 05c [mychannel] Validated block [2] in 4ms
2020-03-11 19:22:29.527 UTC [valimpl] preprocessProtoBlock -> WARN 05d Channel [mychannel]: Block [2] Transaction index [0] TxId [3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

I thought I might have been doing something wrong with the syntax of the file, but if I change the "3-of" to "0-of", it works, so I guess that's not it. I also thought it could have been because the peers were unable to find each other, so I manually defined the anchor peers for each organization on the configtx.yaml (the port I defined for all of them was the 7051, which was the default port for the peer0-org1, not sure if this is correct or not), and I also defined the fields CORE_PEER_GOSSIP_BOOTSTRAP and CORE_PEER_GOSSIP_EXTERNALENDPOINT for each peer on the docker-compose.yml (the file which defines the network topology), but I'm also not sure of what I should define them with, so I put the "bootstrap" with the address of the anchor peer of the org, and the "external endpoint" with the same address as the peer on which I'm defining it. This final alteration was because I was getting a warning saying that since the external endpoint wasn't defined, peers were unable to see each other and I thought that might have something to do with it (if they couldn't find peers from different orgs, these weren't able to endorse the transactions and the verification would fail, just a theory).

Not sure if any of this makes sense, but since it's not working, I'm gonna go ahead and assume it doesn't. Or maybe my problem isn't even related to any of this, but in that case, I really don't know what I'm missing or doing wrong. Any help would be greatly appreciated. If I'm going about this all wrong, my purpose here was just to define my own endorsement policy, in order to make the blockchain more secure (as per Yacov's recommendation), so if someone can enlighten me on the subject, I thank you in avance.

Cheers

Tomás





Endorsement Policy Failure

Tomás Peixinho
 

Good evening,

a while back I asked about the endorsement policies, and after I tried to mess with them a bit, I've reached a dead end. My chaincode and application are now complete, so I finally decided to change the endorsement policy (if I don't define it, the default is "Any peer", and this would be very insecure). As a simple starting point, I was trying to have at least one peer from each org to endorse the transactions (my network has 3 orgs), so I defined the policy file as follows:

# A Shotgun policy xx
identities:  # list roles to be used in the policy
    user1: {"role": {"name": "peer", "mspId": "Org1MSP"}} # role member in org with mspid Org1MSP
    user2: {"role": {"name": "peer", "mspId": "Org2MSP"}}
    user3: {"role": {"name": "peer", "mspId": "Org3MSP"}}
    admin1: {"role": {"name": "admin", "mspId": "Org1MSP"}} # admin role.
    admin2: {"role": {"name": "admin", "mspId": "Org2MSP"}}
    admin3: {"role": {"name": "admin", "mspId": "Org3MSP"}}

policy: # the policy  .. could have been flat but show grouping.
    3-of: # signed by one of these groups  can be <n>-of  where <n> is any digit 2-of, 3-of etc..
      - 1-of:
        - signed-by: "user1" # a reference to one of the identities defined above.
        - signed-by: "admin1"
      - 1-of:
        - signed-by: "user2"
        - signed-by: "admin2"
      - 1-of:
        - signed-by: "user3"
        - signed-by: "admin3"

I used the example file that came with the java sdk (chaincodeendorsementpolicy.yaml) and updated it to do what I wanted. However, no matter what I define in this file, the policy check always fails with this message: 

2020-03-11 19:22:29.527 UTC [vscc] Validate -> WARN 05a Endorsement policy failure for transaction txid=3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] validateTx -> ERRO 05b VSCCValidateTx for transaction txId = 3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] Validate -> INFO 05c [mychannel] Validated block [2] in 4ms
2020-03-11 19:22:29.527 UTC [valimpl] preprocessProtoBlock -> WARN 05d Channel [mychannel]: Block [2] Transaction index [0] TxId [3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

I thought I might have been doing something wrong with the syntax of the file, but if I change the "3-of" to "0-of", it works, so I guess that's not it. I also thought it could have been because the peers were unable to find each other, so I manually defined the anchor peers for each organization on the configtx.yaml (the port I defined for all of them was the 7051, which was the default port for the peer0-org1, not sure if this is correct or not), and I also defined the fields CORE_PEER_GOSSIP_BOOTSTRAP and CORE_PEER_GOSSIP_EXTERNALENDPOINT for each peer on the docker-compose.yml (the file which defines the network topology), but I'm also not sure of what I should define them with, so I put the "bootstrap" with the address of the anchor peer of the org, and the "external endpoint" with the same address as the peer on which I'm defining it. This final alteration was because I was getting a warning saying that since the external endpoint wasn't defined, peers were unable to see each other and I thought that might have something to do with it (if they couldn't find peers from different orgs, these weren't able to endorse the transactions and the verification would fail, just a theory).

Not sure if any of this makes sense, but since it's not working, I'm gonna go ahead and assume it doesn't. Or maybe my problem isn't even related to any of this, but in that case, I really don't know what I'm missing or doing wrong. Any help would be greatly appreciated. If I'm going about this all wrong, my purpose here was just to define my own endorsement policy, in order to make the blockchain more secure (as per Yacov's recommendation), so if someone can enlighten me on the subject, I thank you in avance.

Cheers

Tomás


Re: How to increase capacity of peer node to handle many transactions simultaneously #hyperledger-fabric #fabric

Prasanth Sundaravelu
 

Hi Keerthi, 

You might want to check at the client. The reason transactions fail in your case is not because of peer's incapability. I'm assuming you have created your client based on samples provided in the tutorials.

In node.js client script samples (from tutorials), for every transaction, the following happens: 

 1. A new grpc channel gets created and opened between client and every peer, and the invocation request is sent.
2. Client receives the response of peers and creates a transaction proposal.
3. A new grpc channel gets created between client and orderer, and the proposal is sent.
4. Client recieved response(status) from orderer.
5. Grps channels get closed.

Notice here, a new grpc channel gets created for every transaction in this case, which is costly. 

Also, everytime when a communication channel is being created, client also requests for metadata of blockchain like channel, chaincodes etc. This meta data wont change on transaction basis, hence it is also unnecessarily costly.

If you reuse already created grpc channels for multiple transactions, you could achieve higher TPS.

An ideal approach would be to manage sessions for users and reuse open communication channels. After certain amount of inactivity, they can be closed.

On Thu, 12 Mar 2020, 12:28 am , <keerthycbe@...> wrote:
Hi,

Currently, our endosring peer node can't execute more than 30 transactions simultaneously. If I send a batch with 30 transactions, peer node is able to execute all transactions successfully. if the batch has more than 30 then the transaction fails. I would like to understand the design of peer node like how many transactions it can execute simultaneously and how can we improve it?

Thanks and Regards
Keerthi


How to increase capacity of peer node to handle many transactions simultaneously #hyperledger-fabric #fabric

keerthycbe@...
 

Hi,

Currently, our endosring peer node can't execute more than 30 transactions simultaneously. If I send a batch with 30 transactions, peer node is able to execute all transactions successfully. if the batch has more than 30 then the transaction fails. I would like to understand the design of peer node like how many transactions it can execute simultaneously and how can we improve it?

Thanks and Regards
Keerthi

3681 - 3700 of 11527