Re: chaincode 2.0 problems


indirajith
 

Yes, I have defined Endorsement policies for my peer orgs. But not for the orderer org.
Endorsement:
            Type: Signature
            Rule: "OR('org1MSP.peer')"
Endorsement:
            Type: Signature
            Rule: "OR('org2MSP.peer')"
These are the endorsement policies for the orgs in my configtx.yaml. Don't they get endorsed when we commit the package? The peer orgs show both peers have successfully endorsed the transaction. 

Thank you verymuch for the response.
Kind regards,
Indirajith.


On Mon, 17 Feb 2020 at 16:12, Nikhil E Gupta <negupta@...> wrote:
Hi,

Your logs say zero of the endorsement sub-policies were defined. Did you define the endorsement sub policies in configtx.yaml for your organizations?




-----fabric@... wrote: -----
To: David Enyeart <enyeart@...>
From: "indirajith"
Sent by: fabric@...
Date: 02/17/2020 09:28AM
Cc: fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

Thank you David Enyeart,

As you have suggested, the problem was with credentials and I have fixed them. Now the problem is during the commit stage. Even though both Orgs approved the CC package and they both endorse the commit, it fails with ' (ENDORSEMENT_POLICY_FAILURE) '. The reason behind this is statebased validator fails. I don't know how to meet this state-based endorsement policy. The peer logs are as follows:

PEER1_ORG2

2020-02-17 13:40:32.589 UTC [lifecycle] CheckCommitReadiness -> INFO 0c6 Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [lifecycle] CommitChaincodeDefinition -> INFO 0c7 Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [endorser] callChaincode -> INFO 0c8 finished chaincode: _lifecycle duration: 24ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.596 UTC [comm.grpc.server] 1 -> INFO 0c9 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:37306 grpc.code=OK grpc.call_duration=26.626315ms
2020-02-17 13:40:34.650 UTC [gossip.privdata] StoreBlock -> INFO 0ca [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.651 UTC [vscc] Validate -> ERRO 0cb VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.651 UTC [committer.txvalidator] validateTx -> ERRO 0cc Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.651 UTC [committer.txvalidator] Validate -> INFO 0cd [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.652 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0ce Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.652 UTC [valimpl] preprocessProtoBlock -> WARN 0cf Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.713 UTC [kvledger] CommitLegacy -> INFO 0d0 [twoorgschannel] Committed block [15] with 1 transaction(s) in 61ms (state_validation=0ms block_and_pvtdata_commit=43ms state_commit=15ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0d1 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.599Z grpc.peer_address=192.168.176.103:37308 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125516881s

PEER2_ORG1

2020-02-17 13:40:32.563 UTC [lifecycle] CheckCommitReadiness -> INFO 09d Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [lifecycle] CommitChaincodeDefinition -> INFO 09e Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [endorser] callChaincode -> INFO 09f finished chaincode: _lifecycle duration: 80ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.567 UTC [comm.grpc.server] 1 -> INFO 0a0 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:56972 grpc.code=OK grpc.call_duration=82.034915ms
2020-02-17 13:40:34.657 UTC [gossip.privdata] StoreBlock -> INFO 0a1 [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.658 UTC [vscc] Validate -> ERRO 0a2 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.659 UTC [committer.txvalidator] validateTx -> ERRO 0a3 Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.659 UTC [committer.txvalidator] Validate -> INFO 0a4 [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.659 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0a5 Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.659 UTC [valimpl] preprocessProtoBlock -> WARN 0a6 Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.720 UTC [kvledger] CommitLegacy -> INFO 0a7 [twoorgschannel] Committed block [15] with 1 transaction(s) in 60ms (state_validation=0ms block_and_pvtdata_commit=41ms state_commit=17ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0a8 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.598Z grpc.peer_address=192.168.176.103:56974 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125825689s

Approvals:
{ "approvals": { "org1MSP": true, "org2MSP": true } }

Thank you.
Indirajith


On Thu, 6 Feb 2020 at 14:27, David Enyeart <enyeart@...> wrote:

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.

You must approve on a peer of your own org, before continuing on to the commit step (only the commit step is bound by the configured lifecycle endorsement policy).

So ENDORSEMENT_POLICY_FAILURE on approve step means that the credentials that the peer signed the endorsed approve transaction with, was not issued by that org's CA, as defined in the channel config.

It happens to me when I'm switching environments around. Double check the msp credentials specified in your peer's config against the org msp specified in your channel config transaction.

The msp locations for the org and peer are specified at:

https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml#L38
and
https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/core.yaml#L302

Note, the msp paths above are relative to the local FABRIC_CFG_PATH. This can get confusing... to better understand it, you can instead use a fully qualified msp path to ensure you are pointing to the correct credentials. e.g. to re-use cryptogen credentials from first-network sample, use:

<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/msp
and
<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp


Dave Enyeart

"indirajith" ---02/06/2020 02:51:39 AM---Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful insta

From: "indirajith" <indirajithv@...>
To:
Cc: fabric <fabric@...>
Date: 02/06/2020 02:51 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
Sent by: fabric@...





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:
    Jason pointed out the problem:

    > 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:
      Jay, how does your policy look like for both org and channel? Thanks.




      On Thursday, January 9, 2020, 4:47 AM, Jay Guo <guojiannan1101@...> wrote:
          I could reproduce this by approving the same definition twice (with same seq). It seems that the first approval is validated with /Channel/Application/Org1MSP/Endorsement, although the second is validate with /Channel/Application/LifecycleEndorsement

          - 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

          Inactive hide details for"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

          From: "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...

          2. Your LifecycleEndorsement policy is:

          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          This will require the chaincode commit to be endorsed by both orgs (majority of '2' is '2'). I suspect you only sent the chaincode commit to one of the org peers. Alternatively, you could update your config to indicate that either org can endorse the commit of a new chaincode, e.g.:

          LifecycleEndorsement:
          Type: Signature
          Rule: "OR('org0examplecom.admin.peer','org1examplecom.peer')"


          Dave Enyeart

          Inactive hide details for"Tong Li" ---01/07/2020 11:19:18 PM---Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincod

          From: "Tong Li" <litong01@...>
          To: fabric@...
          Date: 01/07/2020 11:19 PM
          Subject: [EXTERNAL] [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...





          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









Join fabric@lists.hyperledger.org to automatically receive all group messages.