Date   

Re: chaincode 2.0 problems

indirajith
 

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









Re: 7.1.3 of the Tutorial (page 188) v2.0.0 pdf

Trevor Lee Oakley <trevor@...>
 

Is there a work around for this?

--------------Original Message--------------

From: "Bret Harrison" <beharrison@...>
Sent: Monday, February 17, 2020 08:37:AM
To: fabric@...
Subject: Re: [Hyperledger Fabric] 7.1.3 of the Tutorial (page 188) v2.0.0
pdf

We have a PR in review to fix the following issue
Failed to register user "user1": TypeError: gateway.getClient is not a
function

See https://github.com/hyperledger/fabric-samples/pull/117


Re: Proposal : Hyperledger Fabric block archiving

nekia <atsushin@...>
 

Hi,

I figured out that it's quite difficult to estimate maximum size in advance to align metadata size on each orderer. So we've decided to change to handle archive data at block level, not at blockfile level. By managing archived data at block level, we can avoid the following issues:
  • The layout of blockfile with same suffix is not always identical among peers in an organization
  • Because of this variance of the layout, each peer can't get access to archived data by using original block location info recorded in block index DB
I've put together overview of the new approach in the following slide.
HLF Block Archiving - Google Slides

In the feedbacks we got in this thread, implementing separately from fabric core has been mentioned several times. We have not been able to offer this feature as a pluggable module for ledger layer of fabric so far. One of the main reasons of it is that we need to hook the local file access when reading block data from local file system.

Do you think this project can compensate or coexist the functionality offered by 'ledger checkpoint and pruning' feature which is planned to be added to v2.x?

Cheeers,
Atsushi


Re: 7.1.3 of the Tutorial (page 188) v2.0.0 pdf

Bret Harrison <beharrison@...>
 

We have a PR in review to fix the following issue
Failed to register user "user1": TypeError: gateway.getClient is not a function


Next Hyperledger Fabric Application Developer Community call - this Thursday, Feb 20th @ 4pm UTC (4pm UK) - 11am ET, 8am PT

Paul O'Mahoney <mahoney@...>
 

dear Fabric Application Developer,


the next  Fabric Application Developer community call is scheduled for this  Thursday Feb 20th @ 4pm UTC (4pm UK) - 11am ET (-5 hrs), 8am PT(-8 hrs) - see time zones.   It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Meeting+Agendas%3A+Fabric+Application+Developer+Community+Call

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts,  developing application clients, using the SDKs, tutorials/demos etc -  NodeJS/TypeScript, Java, Go etc etc) 
- helping App developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes


The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1

mahoney@...


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


#fabric #configtxgen #fabric-orderer #fabric #configtxgen #fabric-orderer

Jean-Gaël Dominé <jgdomine@...>
 

Hi,

Until now, to set up a Raft Fabric network, I had a batch in charge of registering and enrolling all the identities (admin, orderers and peers), creating the system and application channel genesis blocks.
What I'd like to do is to move the enrollment part to each component (peers and orderers) when they start up so that the batch is now only in charge of the enrolling of admins and creating the genesis blocks.
But the issue is that with Raft as the genesis block must contain each orderer TLS certificate. So the orderer can't enroll itself before startup because it will need the system channel genesis block to start and I can't create this genesis block without having the TLS certificates.

So it's a vicious circle and I don't see a nice way to fix this.

Any idea of how to do that? In your cases, how did you automate this part (generation of certificates and genesis blocks creation) in a nice way?

Thanks

JG


divya.s@...
 

I have installed hyperledger fabric 2.0.0. When I try to run the fabcar example, I am getting an error like this "Error: error getting endorser client for channel: endorser client failed to connect to peer0.org1.example.com:7051: failed to create new connection: context deadline exceeded".

When I checked in docker logs using docker logs peer0.org1.example.com, It shows warning "Retrying couchdb request in 250ms. Error:Get http://couchdb0:5984/: dial tcp 172.22.0.8:5984: connect: connection refused".

I pruned all the docker images,volumes, networks and installed again. I have tried adding dns search in .yml files. And tried checking docker network inspect. But nothing resolves. Kindly help to solve this


7.1.3 of the Tutorial (page 188) v2.0.0 pdf

Trevor Lee Oakley <trevor@...>
 

I am working via the fabcar examples and I have an error; I can register the admin user and I get the wallet entry. But when I try and use node registerUser.js I get an error (below) - not a function. I did not change anything and the network is running, it has the CA working. 
 
 
:~/fabric-samples/fabcar/javascript/wallet$ ll
total 12
drwxrwxr-x 2 ubuntu ubuntu 4096 Feb 17 03:40 ./
drwxrwxr-x 4 ubuntu ubuntu 4096 Feb 17 03:46 ../
-rw-rw-r-- 1 ubuntu ubuntu    0 Feb 15 08:00 .gitkeep
-rw-rw-r-- 1 ubuntu ubuntu 1121 Feb 16 12:07 admin.id
 
 
~/fabric-samples/fabcar/javascript$ node registerUser.js 
Wallet path: /home/ubuntu/fabric-samples/fabcar/javascript/wallet
Failed to register user "user1": TypeError: gateway.getClient is not a function
 
 
     const gateway = new Gateway();
        await gateway.connect(ccpPath, { wallet, identity: 'admin', discovery: { enabled: true, asLocalhost: true } });
        // Get the CA client object from the gateway for interacting with the CA.
        const client = gateway.getClient();
        const ca = client.getCertificateAuthority();
        const adminUser = await client.getUserContext('admin', false);
 
 
I get this for Gateway for a console.log -
 
Gateway {
  client: Client {
    type: 'Client',
    name: 'gateway client',
    mspid: null,
    _tls_mutual: {
      selfGenerated: true,
      clientKey: '-----BEGIN PRIVATE KEY-----\r\n' +
        'MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgZVYzMEW42hnKm2D5\r\n' +
        'LsjRAMK3iQG34lrB1oF3j6C/n06hRANCAAR6es5QJNc1WdgC9hVRyEnl/YHeYtk4\r\n' +
        'lexkh++nGRtspkmb0UIB/EY9E5LPh/SXEcbTZm6II81TZNdm3e3NASjO\r\n' +
        '-----END PRIVATE KEY-----\r\n',
      clientCert: '-----BEGIN CERTIFICATE-----\r\n' +
        'MIIBVTCB+6ADAgECAgEEMAoGCCqGSM49BAMCMBgxFjAUBgNVBAMMDWZhYnJpYy1j\r\n' +
        'b21tb24wIhgPMjAyMDAyMTcwMjMxMjhaGA8yMDIwMDIxNzIwMzQ0OFowGDEWMBQG\r\n' +
        'A1UEAwwNZmFicmljLWNvbW1vbjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABHp6\r\n' +
        'zlAk1zVZ2AL2FVHISeX9gd5i2TiV7GSH76cZG2ymSZvRQgH8Rj0Tks+H9JcRxtNm\r\n' +
        'bogjzVNk12bd7c0BKM6jMjAwMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgbAMBMG\r\n' +
        'A1UdJQQMMAoGCCsGAQUFBwMCMAoGCCqGSM49BAMCA0kAMEYCIQCQkeSzqt3LI747\r\n' +
        'NG7WWP9hNU+aVi82+XT1eyfbzjgriwIhAOnXOCVrAmQtpANJFXs/4sDbQ7ozQlBy\r\n' +
        'U4/YRulyQXUN\r\n' +
        '-----END CERTIFICATE-----\r\n'
    },
    endorsers: Map {},
    committers: Map {},
    channels: Map {},
    centralizedOptions: null
  },
  wallet: null,
  identityContext: IdentityContext {
    type: 'IdentityContext',
    client: Client {
      type: 'Client',
      name: 'gateway client',
      mspid: null,
      _tls_mutual: [Object],
      endorsers: Map {},
      committers: Map {},
      channels: Map {},
      centralizedOptions: null
    },
    user: User {
      type: 'User',
      _name: 'admin',
      _roles: null,
      _affiliation: '',
      _enrollmentSecret: '',
      _identity: [Identity],
      _signingIdentity: [SigningIdentity],
      _mspId: 'Org1MSP',
      _cryptoSuite: [CryptoSuite_ECDSA_AES]
    },
    options: {},
    name: 'admin',
    mspid: 'Org1MSP',
    transactionId: null,
    nonce: null
  },
  networks: Map {},
  options: {
    query: { timeout: 30, strategy: [Function: MSPID_SCOPE_SINGLE] },
    transaction: {
      endorseTimeout: 30,
      commitTimeout: 300,
      strategy: [Function: MSPID_SCOPE_ALLFORTX]
    },
    discovery: { enabled: true, asLocalhost: true },
    wallet: Wallet {
      providerRegistry: [IdentityProviderRegistry],
      store: [FileSystemWalletStore]
    },
    identity: 'admin'
  }
}
Failed to register user "user1": TypeError: gateway.getClient is not a function
ubuntu@ip-10-0-1-151:~/fabric-samples/fabcar/javascript$ 
 


Re: How does the client know which are the EPs?

Trevor Lee Oakley <trevor@...>
 

I think I have an answer - use EXTERNALENDPOINTS and the discovery service.
 
 
 

From: "Trevor Lee Oakley" <trevor@...>
Sent: 16 February 2020 22:44
To: fabric@...
Subject: [Hyperledger Fabric] How does the client know which are the EPs?
 
I understand the client sends the proposal to all endorsing peers, but how are these identified to the client?
 
I assume the client needs to query a service in the network to find out the EPs or hold a local copy of the EPs; then somehow identify how to reach them by a network identifier or address.
 
Trevor
 
 


Re: How does the client know which are the EPs?

Joe Alewine <joe.alewine@...>
 

 
Might be what you're looking for.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Trevor Lee Oakley" <trevor@...>
Sent by: fabric@...
To: <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] How does the client know which are the EPs?
Date: Sun, Feb 16, 2020 10:17 PM
 
I understand the client sends the proposal to all endorsing peers, but how are these identified to the client?
 
I assume the client needs to query a service in the network to find out the EPs or hold a local copy of the EPs; then somehow identify how to reach them by a network identifier or address.
 
Trevor
 
 
 


How does the client know which are the EPs?

Trevor Lee Oakley <trevor@...>
 

I understand the client sends the proposal to all endorsing peers, but how are these identified to the client?
 
I assume the client needs to query a service in the network to find out the EPs or hold a local copy of the EPs; then somehow identify how to reach them by a network identifier or address.
 
Trevor
 
 


Re: How to error check for wrong Admin MSP certificate on network #fabric #docker #fabric-ca

Gari Singh <garis@...>
 

BatchSize actually falls under the Orderer group and not the Application group.
Therefore, you need a majority of the orderer admins to sign the config update.
Given you state this is a simple network, I'll assume you only have a single orderer org, so you just need to sign the config update using an orderer admin identity.

-----------------------------------------
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: "Niklas Krohn"
Sent by: fabric@...
Date: 02/15/2020 09:43AM
Subject: [EXTERNAL] [Hyperledger Fabric] How to error check for wrong Admin MSP certificate on network #fabric #docker #fabric-ca

Hi all,

I have the most simple fabric-network, and wanted to make a simple channel-config update of the batchsize (https://hyperledger-fabric.readthedocs.io/en/release-1.4/config_update.html)

Everything is fine, until I want to post the modified config to the orderer/network, then I receive the following error inside CLI container, as peer0.org1 adm:



Orderer log:




So according to google-searches, I found this topic which states that there migth be two possible reasons (https://stackoverflow.com/questions/57662562/when-i-try-to-create-a-channel-using-hyperledger-fabric-the-request-fails)
- the MSP ID that was passed as a parameter with the request was not recognized by the ordering service
- If you are updating an application channel, this error could occur if your organization is not yet a member of the channel you are trying to update

The Org1 is indeed part of the channel already, as it created and joined the channel with the bootstrap:






So then I expect the issue to be a mismatch between MSP-ID somewhere. The topic of certificates are somewhat new to me, can anybody guide me in direction of error checking this myself, which files should I compare to see what MSP-file is wrong?

This is the cert-file inside the CLI container for peer0.org1 admin:



This is the Admin-file on the host machine:



CA-related info for Org1:




This is the policy settings inside the channel-config block:



Thanks for any input that can help me compare the rigth certificates, to spot the wrong one and why it is wrong.


How to error check for wrong Admin MSP certificate on network #fabric #docker #fabric-ca

Niklas Krohn
 

Hi all, 

I have the most simple fabric-network, and wanted to make a simple channel-config update of the batchsize (https://hyperledger-fabric.readthedocs.io/en/release-1.4/config_update.html)

Everything is fine, until I want to post the modified config to the orderer/network, then I receive the following error inside CLI container, as peer0.org1 adm: 



Orderer log:




So according to google-searches, I found this topic which states that there migth be two possible reasons (https://stackoverflow.com/questions/57662562/when-i-try-to-create-a-channel-using-hyperledger-fabric-the-request-fails)
the MSP ID that was passed as a parameter with the request was not recognized by the ordering service
If you are updating an application channel, this error could occur if your organization is not yet a member of the channel you are trying to update

The Org1 is indeed part of the channel already, as it created and joined the channel with the bootstrap: 






So then I expect the issue to be a mismatch between MSP-ID somewhere. The topic of certificates are somewhat new to me, can anybody guide me in direction of error checking this myself, which files should I compare to see what MSP-file is wrong?

This is the cert-file inside the CLI container for peer0.org1 admin: 



This is the Admin-file on the host machine: 



CA-related info for Org1: 




This is the policy settings inside the channel-config block: 



Thanks for any input that can help me compare the rigth certificates, to spot the wrong one and why it is wrong. 


Re: Performance Improvement: Max number of assets and max size of payload in single Transaction?

David Enyeart
 

On the other hand, large numbers of tiny transactions will not be as efficient due to the per-transaction overhead. It is quite typical to batch multiple writes into a single transaction (e.g. 100 at a time), especially upon initial ledger population. This provides a good balance between efficiency and keeping the transactions and blocks at reasonable sizes for distribution around the network. Some empirical trials will help you to find the sweet spot for your specific workload and data sizes.


Dave Enyeart

"Baohua Yang" ---02/14/2020 01:05:36 PM---Adhav The number of assets in a single transaction depends on several factors,

From: "Baohua Yang" <yangbaohua@...>
To: Adhav Pavan <adhavpavan@...>
Cc: Gari Singh <garis@...>, hyperledger-fabric <hyperledger-fabric@...>
Date: 02/14/2020 01:05 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Performance Improvement: Max number of assets and max size of payload in single Transaction?
Sent by: fabric@...





Adhav

The number of assets in a single transaction depends on several factors, e.g., the key-value size.

Putting many large data in one transaction may consume heavy CPU and memory at the peer, and hang other operations for a long time.

And large blocks are not efficient to distribute in the network.

This is a typical high-performance scenario, and assigning more hardware resource can accelerate the process.

On Fri, Feb 14, 2020 at 3:37 AM Gari Singh <garis@...> wrote:
    The maximum payload is ~100MB.  This is actually set at the transport protocol level and is not configurable.
    Given there is some additional overhead included in the Fabric protocol layer, you are looking at a max payload in terms of your keys/value of ~90MB (to be on the safe side).

    I'll assume that your chaincode is designed to insert multiple asset records for a single invoke.

    -----------------------------------------
    Gari Singh
    Distinguished Engineer, CTO - IBM Blockchain
    IBM Middleware
    550 King St
    Littleton, MA 01460
    Cell: 978-846-7499
    garis@...
    -----------------------------------------

    -----fabric@... wrote: -----
    To: hyperledger-fabric <hyperledger-fabric@...>
    From: "Adhav Pavan"
    Sent by: fabric@...
    Date: 02/14/2020 04:48AM
    Subject: [EXTERNAL] [Hyperledger Fabric] Performance Improvement: Max number of assets and max size of payload in single Transaction?

    Hello Experts,

    I have some concerns about number of assets and size of the payload in a single transaction.

    1)  How big payload in terms of size, we can add in a single transaction in Hyperledger Fabric. I have millions of assets, ingesting into Fabric network. Maximum assets(Key-Value) can be added into the single transaction are 1000(Correct if I am wrong). Can we customize this number, so that a high number of an asset can be added in a single transaction?

    2) What is an efficient way to trigger a huge number of assets into the network?

    Currently, I could add only 100 assets in a single transaction.

    I am trying to improve performance in terms of TPS and latency. I have already added necessary indexes and composite key (Couch DB)

    Thank you.
     Heartfelt Regards,

    Pavan Adhav Blockchain Developer, Infinichains phone:  8390114357 email:  pavan@... ------
    Please excuse my brevity.







--
Best wishes!

Baohua Yang





Re: Performance Improvement: Max number of assets and max size of payload in single Transaction?

Baohua Yang
 

Adhav

The number of assets in a single transaction depends on several factors, e.g., the key-value size.

Putting many large data in one transaction may consume heavy CPU and memory at the peer, and hang other operations for a long time.

And large blocks are not efficient to distribute in the network.

This is a typical high-performance scenario, and assigning more hardware resource can accelerate the process.

On Fri, Feb 14, 2020 at 3:37 AM Gari Singh <garis@...> wrote:
The maximum payload is ~100MB.  This is actually set at the transport protocol level and is not configurable.
Given there is some additional overhead included in the Fabric protocol layer, you are looking at a max payload in terms of your keys/value of ~90MB (to be on the safe side).

I'll assume that your chaincode is designed to insert multiple asset records for a single invoke.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: hyperledger-fabric <hyperledger-fabric@...>
From: "Adhav Pavan"
Sent by: fabric@...
Date: 02/14/2020 04:48AM
Subject: [EXTERNAL] [Hyperledger Fabric] Performance Improvement: Max number of assets and max size of payload in single Transaction?

Hello Experts,

I have some concerns about number of assets and size of the payload in a single transaction.

1)  How big payload in terms of size, we can add in a single transaction in Hyperledger Fabric. I have millions of assets, ingesting into Fabric network. Maximum assets(Key-Value) can be added into the single transaction are 1000(Correct if I am wrong). Can we customize this number, so that a high number of an asset can be added in a single transaction?

2) What is an efficient way to trigger a huge number of assets into the network?

Currently, I could add only 100 assets in a single transaction.

I am trying to improve performance in terms of TPS and latency. I have already added necessary indexes and composite key (Couch DB)

Thank you.
 Heartfelt Regards,

Pavan Adhav Blockchain Developer, Infinichains phone:  8390114357 email:  pavan@... ------
Please excuse my brevity.








--
Best wishes!

Baohua Yang


Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 02/14/2020 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 14 February 2020
4:00pm to 5:00pm
(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: Error: failed to create deliver client

Marina Wanis <marinamaged1996@...>
 

Hi Faisal,

 

I copied the environment variable incomplete by mistake.

TLS_PARAMETERS=" --tls true --cafile $ORDERER_CA_ROOTFILE"

 

export ORDERER_CA_ROOTFILE=$PWD/crypto-config/ordererOrganizations/phone.com/orderers/orderer.phone.com/msp/tlscacerts/tlsca.phone.com-cert.pem

 

I’m still getting this error:

 

2020-02-14 19:10:28.886 +04 [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable

2020-02-14 19:10:28.888 +04 [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable

Error: failed to create deliver client: orderer client failed to connect to orderer.phone.com:7050: failed to create new connection: context deadline exceeded

 

 

Sent from Mail for Windows 10

 

From: Faisal
Sent: Friday, February 14, 2020 10:52 AM
To: fabric@...
Subject: Re: [Hyperledger Fabric] Error: failed to create deliver client

 

all the path to the file after the --cafile parameter your command should be include the tlsca.pem file 

export TLS_PARAMETERS = --tls true --cafile /PATH/tlsca.phone.com-cert.pem

 

 


Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 02/14/2020 4:00pm-5:00pm #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 14 February 2020, 4:00pm to 5:00pm, (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: Performance Improvement: Max number of assets and max size of payload in single Transaction?

Gari Singh <garis@...>
 

The maximum payload is ~100MB. This is actually set at the transport protocol level and is not configurable.
Given there is some additional overhead included in the Fabric protocol layer, you are looking at a max payload in terms of your keys/value of ~90MB (to be on the safe side).

I'll assume that your chaincode is designed to insert multiple asset records for a single invoke.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: hyperledger-fabric <hyperledger-fabric@...>
From: "Adhav Pavan"
Sent by: fabric@...
Date: 02/14/2020 04:48AM
Subject: [EXTERNAL] [Hyperledger Fabric] Performance Improvement: Max number of assets and max size of payload in single Transaction?

Hello Experts,

I have some concerns about number of assets and size of the payload in a single transaction.

1) How big payload in terms of size, we can add in a single transaction in Hyperledger Fabric. I have millions of assets, ingesting into Fabric network. Maximum assets(Key-Value) can be added into the single transaction are 1000(Correct if I am wrong). Can we customize this number, so that a high number of an asset can be added in a single transaction?

2) What is an efficient way to trigger a huge number of assets into the network?

Currently, I could add only 100 assets in a single transaction.

I am trying to improve performance in terms of TPS and latency. I have already added necessary indexes and composite key (Couch DB)

Thank you.
Heartfelt Regards,

Pavan Adhav Blockchain Developer, Infinichains phone: 8390114357 email: pavan@... ------
Please excuse my brevity.


Performance Improvement: Max number of assets and max size of payload in single Transaction?

Adhav Pavan
 

Hello Experts,

I have some concerns about number of assets and size of the payload in a single transaction.

1)  How big payload in terms of size, we can add in a single transaction in Hyperledger Fabric. I have millions of assets, ingesting into Fabric network. Maximum assets(Key-Value) can be added into the single transaction are 1000(Correct if I am wrong). Can we customize this number, so that a high number of an asset can be added in a single transaction?

2) What is an efficient way to trigger a huge number of assets into the network?

Currently, I could add only 100 assets in a single transaction.

I am trying to improve performance in terms of TPS and latency. I have already added necessary indexes and composite key (Couch DB)

Thank you.

Heartfelt Regards,

Pavan Adhav
Blockchain Developer, Infinichains
phone:  8390114357
email:  pavan@...
------
Please excuse my brevity.

3801 - 3820 of 11520