Date   

Motion for final comment period: Ledger-api RFC

Heather Pollard <heatherp@...>
 

Hi everyone,

I am requesting that we enter the final comment period for the Ledger-api RFC and proposing that it is merged at the end of this period, in one week. The aim of this period is for any fabric maintainers to communicate any final comments or objections to the proposed RFC.

The ledger-api was discussed on a Fabric Contributors Meeting on the 11th December and the recording is available here.

Please reach out to Matthew White (whitemat@...) or me with any queries
 
Thanks,
Heather

Software Engineer, IBM Blockchain
Autism Ambassador
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


Upcoming TSC update for Fabric

Ry Jones
 

In a little over a week, the Fabric project has the first update for 2020 due.

I will be setting up the automatic reminders, but I'm not there yet.
Ry

--
Ry Jones
Community Architect, Hyperledger


Re: Chaincode nodejs getStateByPartialCompositeKey

David Enyeart
 

Yes, see the getStateByPartialCompositeKey sample here:
https://github.com/hyperledger/fabric-samples/blob/release-1.4/chaincode/marbles02/node/marbles_chaincode.js#L243-L295


Dave Enyeart

"Kimheng SOK" ---01/13/2020 12:27:00 PM---Dear all, Is there any documentation example of how to use

From: "Kimheng SOK" <sok.kimheng@...>
To: hyperledger-fabric@...
Date: 01/13/2020 12:27 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Chaincode nodejs getStateByPartialCompositeKey
Sent by: fabric@...





Dear all,

Is there any documentation example of how to use getStateByPartialCompositeKey in nodejs chaincode to query the data from the object list and iterate through it to view all the result. 

Thank for help.

Bests,




Chaincode nodejs getStateByPartialCompositeKey

Kimheng SOK
 

Dear all,

Is there any documentation example of how to use getStateByPartialCompositeKey in nodejs chaincode to query the data from the object list and iterate through it to view all the result. 

Thank for help.

Bests,


Re: JIRA Cleanup

Matthew Sykes
 

I have finished labeling JIRA items associated with the Fabric project. If you find an item with a `stale-item` label that you believe should not be closed out next week, please remove the label and add a comment indicating why it is still relevant.

Thanks.

On Thu, Jan 9, 2020 at 7:07 PM Matthew Sykes via Lists.Hyperledger.Org <matthew.sykes=gmail.com@...> wrote:
As part of our v2 shutdown (and my own new year resolution to be better about doing my chores), we'll be doing some work to close out old JIRA work items.

Over the next few days, open items that have not had a meaningful update in more than 9 months will be tagged with a 'stale-item' label. One week after that process has completed, any open items with that label will be closed out.

If a JIRA item you are interested in gets tagged and you want to stop it from being closed, please comment on the issue with information about why it is still relevant and remove the tag. This will indicate further discussion is warranted and we will defer closing the item pending that discussion.

Since the issues are simply being closed and not deleted, if something falls through the crack, we can always reopen as necessary.

Thanks.

--
Matthew Sykes



--
Matthew Sykes
matthew.sykes@...


Re: IMP: Failed to update batch size in fabric

Anoop Vijayan <anoop@...>
 

Hi,
Without looking into the logs (i.e. I am guessing here), I think you are trying to update BatchSize?
For that you need to be a OrdererMSP (endorsed by orderer)
——————— e.g. clip ———————
CORE_PEER_LOCALMSPID="OrdererMSP"

CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/Admin@example.com/msp

ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
——————— e.g. clip ———————

To know more, you should turn on DEBUG for orderer container and restart it.

Thanks,
 - Anoop

On 11 Jan 2020, at 21.49, Suhan Sumeet <suhan.premilu@...> wrote:

Hello Team,

I have an urgent requirement to fulfill and am trying to update the batch size for my network

Am following the tutorial to "Add org3 in to network" that lists out the steps to updated a channel configuration.
While running the final step to update 
" peer channel update -f batch_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA"

it fails with below error

2020-01-11 19:41:29.563 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/BatchSize not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied


Please help me out if possible urgently since I have to deliver this in another 10-12 hours.



[i18n] Status report on translation of Fabric docs

Yang Cheng
 

Dear Hyperledger community,

We are a small group of volunteers that have been translating Fabric docs to Chinese since 2018. We’d like to share our current status and rationale behinds some decisions for your reference.

Tool selection

We initially started off using github, since it’s familiar to most of developers, and other projects like k8s have been doing the same. The workflow roughly looks like this:

Admins:
1.create branches in `hyperledger-labs/fabric-docs-cn` following Fabric release tags, for example `1.4.2_zh-CN`
2.populated Github issues with untranslated docs
3.assign issues to translators upon request
4.review pull request
5.readthedocs is updated automatically upon successful merge
6.periodically pull in updates from Fabric docs in the form of new issues

Translators:
1.browse Github issues looking for unassigned issues
2.assign issue by commenting on it
3.translate and submit pull request

This workflow had served us well for a small group of contributors. Later on, translation tools, in particular Zanata and Transifex, were proposed by community members, and we decided to give them a try. However, several major drawbacks of Transifex were observed after months of trial:

1.slow access in this region, resulting in bad user experience
2.intermediate files (.po) loses annotations during conversion, resulting in bad formats
3.no commit sign-off when eventually pushed to github

Therefore, we went back to Github. However, this does not mean we rule out the option of using professional tool, which obviously has its own advantages. Our current focus is to get things done and keep handful of contributors happy. When the time comes that Github becomes bottleneck (either due to increase of volunteers, or number of languages being translated to), we are definitely open for reassessment of tooling.

Location of translated docs

It was proposed to separate docs from Fabric code repo, which can co-exist with translations, similar to k8s [1]. Although the proposal was turned down for solid reasons, and we are happily informed that readthedocs actually supports multiple Github repo setup [2]. This is so far the least invasive option to incorporate non-English docs into main site.

We do not think putting translated docs into Fabric core repo is a good idea, even with fine-grained maintainer-ship in place. The PR page would be overwhelmed by foreign characters and we are no longer able to track tasks with Github issues. Besides, it doesn’t really buy us anything beyond one less repo.

To avoid creating new repo for each language that people are interested in translation, we could also setup a repo `Fabric-i18n` containing them as separate directories, e.g. `zh`, `es`, `de`, etc.

This is how things get done today and we definitely welcome any suggestion and feedback. As the number of volunteers and languages grow, we believe a standardized process will emerge.

Thank you,
Cheng Yang

[2] here’s a demonstration website to show how to incorporate multiple github repo into one readthedocs site https://stone-fabric.readthedocs.io/zh/release-1.4_zh-cn/

--
程阳
Yang Cheng
great_cy_ang@...


[i18n][Help-wanted] Incorporate Fabric docs in zh-CN into ReadTheDocs

Yang Cheng
 

Dear Hyperledger Administrators,

As reported previously, a group of volunteers from Technical Working Group China have translated Fabric 1.4 docs into Chinese, and we would like some help to incorporate them into readthedocs. This could be done by creating a child project in readthedocs under Fabric, and point it to [1], where translated docs reside.

We've made a demo site to showcase final result at [2]. And we are happy to facilitate the process along the way.

I will send out a separate mail explaining our current process for translation, in case some of you are interested.

Cheers, 
Yang Cheng


--
程阳
Yang Cheng
great_cy_ang@...


Fw:Re:Re: re:[Hyperledger Fabric] identity authentication

qs meng <qsmeng@...>
 







-------- Forwarding messages --------
From: "meng" <qsmeng@...>
Date: 2020-01-13 11:08:34
To: "Nikhil E Gupta" <negupta@...>,robert@...,nlzanutim@...
Subject: Re:Re: re:[Hyperledger Fabric] identity authentication
Hi,
     Thank you all for your reply.
     About the CID, the certificate is initialized into an object and the information like id/mspID is obtained by CID function. The authenticity about the ID is not checked at all. CID think it is true because the endorsing peer has already checked.
    About SDK maintaining a credential wallet that holds end user's HLF credentials, I didnot find any material on it. I guess the DApp uses the credntials in the wallet to check the ID of endusers? Is the transaction proposal then signed  by the DApp and submitted to Fabric?  If so, we must trust the DApp. 
  About the restful API, an enduser must send a  proposal to a server, what is the server that handles the proposal and where the server is running? 
  Thank you.
   Best regards,
qsmeng





At 2019-12-06 00:19:27, "Nikhil E Gupta" <negupta@...> wrote:




-----fabric@... wrote: -----
To: Robert Broeckelmann <robert@...>
From: "qs meng"
Sent by: fabric@...
Date: 12/04/2019 09:21PM
Cc: Nicholas Zanutim <nlzanutim@...>, "fabric@..." <fabric@...>
Subject: [EXTERNAL] 回复:[Hyperledger Fabric] identity authentication

hello Robert,
more specificly,I want to authenticate requestor id in chaincode. this provide more freedom for enduser. 
thank you. 
regards. 
qsmeng




-------- 原始邮件 --------
发件人: Robert Broeckelmann <robert@...>
日期: 2019年12月4日周三 中午12:32
收件人: qs meng <qsmeng@...>
抄送: Nicholas Zanutim <nlzanutim@...>, fabric@...
主 题: Re: [Hyperledger Fabric] identity authentication
Hello. 

I had a similar situation earlier this year.

The Fabric SDKs contain support for maintaining a credential wallet that holds end user's HLF credentials.

If you have an architecture similar to:

Mobile App-> REST API->HLF Peer 

Then, the REST API layer can be used to translate from a security token embedded in API requests to credentials that the blockchain network will understand (ie, PKI an X509 private public key pairs).

See [1] for an example. 

Our requirements eventually shifted to an "application" id being recorded in the blockchain. So, we just issued a "system identity" that the REST API layer's SDK used for all peer interaction. So, that ended up being much simpler.

I honestly don't like the solution where the server-side app has to maintain a credential wallet that contains all registered users HLF credentials, but that does seem cleaner than having every mobile app instance issued a set of HLF credentials and directly communicating with the blockchain network. Note, I haven't seen anyone or anything pitching that architecture, but it would probably be the only alternative.

For authentication of end users on the mobile, app I'd recommend using OpenId Connect's Authorization Code Grant with a Public Client. Use one of the numerous IdaaS (Identity as a Service) Providers available today.  If OIDC is used in this manner, you also get an OAuth2 access token that can be cached in the mobile app (and refreshed as needed) and included with API calls (authorization header) to the REST API layer. An API Gateway can be used to handle authentication, authorization, request validation, and other typical concerns of API Security. All the major cloud hosting platforms offer an API Gateway solution that would do this out-of-the-box, the previous poster mentioned Kong, Apigee is another. There are a bunch of others. 


RCBJ

On Tue, Dec 3, 2019 at 6:24 PM qs meng <qsmeng@...> wrote:


hi Nicholas,
 the identity be authentocated by fabric. if the kong runs outside the fabric, its result of ID authenticate is not accepted by fabric.
  I want  to authenate the requestor in the fabric.
thank you.
best regards. 
qsmeng



-------- 原始邮件 --------
发件人: Nicholas Zanutim <nlzanutim@...>
日期: 2019年12月3日周二 晚上9:31
收件人: fabric@..., qs meng <qsmeng@...>
主 题: Re: [Hyperledger Fabric] identity authentication
You can use Kong Service manager with JWT or any other form of authentication to access the services that submit transactions to the Fabric network. In this case, the user certificate must be present with the services

Em terça-feira, 3 de dezembro de 2019 10:08:44 BRT, qs meng <qsmeng@...> escreveu:


Hi experts, 
      In the current fabric design, the client app is the use of Fabric. Running a client app is a heavy cost  for a mobilephone user. We design a payment system, where a user can sign a payment request with his/her private key, submit it to a client app and then to Fabric.  
A problem exists that how the identity of the user or requestor can be authenticated?  Can anyone give me some suggestions?
 Thank you.
 Best regards,
qsmeng


 



--
Robert C. Broeckelmann Jr | Managing Director |  IyaSec
m: +1 314-494-3398 (SMS or WhatsApp) | fax: +1 (866) 484-1634
email: robert@... | site: iyasec.io

mail: 19215 SE 34th St Ste 106-407 Camas WA 98607-8830





 



 


Fw: First Network on Windows

ontrares@...
 



----- Forwarded Message -----
From: Ont Rares <ontrares@...>
To: hyperledger-fabric@... <hyperledger-fabric@...>
Sent: Sunday, January 12, 2020, 05:40:45 PM GMT+2
Subject: First Network on Windows

      Hi, I encountered a problem on the samples repository.
  
      On the first-network project if I run ./byfn.sh -m generate, ./byfn.sh generate or ./byfn.sh up I always get:*

      Is there a way to just download these certificates or generate them in another way or bypass them? I must use the Windows system.


*
Generating certs and genesis block for channel 'mychannel' with CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n] y
proceeding ...
/c/Users/bc/bin/cryptogen

##########################################################
##### Generate certificates using cryptogen tool #########
##########################################################
+ cryptogen generate --config=./crypto-config.yaml
org1.example.com
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x7ee984]

goroutine 1 [running]:
github.com/hyperledger/fabric/common/tools/cryptogen/msp.GenerateVerifyingMSP(0xc00001a5c0, 0x34, 0x0, 0x0, 0xc00001ca01, 0x16, 0x0)
        /w/workspace/fabric-release-jobs-x86_64/gopath/src/github.com/hyperledger/fabric/common/tools/cryptogen/msp/generator.go:186 +0x2d4
main.generatePeerOrg(0x95319f, 0xd, 0xc00001e270, 0x4, 0xc00001e290, 0x10, 0x1, 0x0,
0x9501fd, 0x2, ...)
        /w/workspace/fabric-release-jobs-x86_64/gopath/src/github.com/hyperledger/fabric/common/tools/cryptogen/main.go:537 +0x762
main.generate()
        /w/workspace/fabric-release-jobs-x86_64/gopath/src/github.com/hyperledger/fabric/common/tools/cryptogen/main.go:395 +0x2a8
main.main()
        /w/workspace/fabric-release-jobs-x86_64/gopath/src/github.com/hyperledger/fabric/common/tools/cryptogen/main.go:223 +0x2af
+ res=2
+ set +x
Failed to generate certificates...





IMP: Failed to update batch size in fabric

Suhan Sumeet
 

Hello Team,

I have an urgent requirement to fulfill and am trying to update the batch size for my network

Am following the tutorial to "Add org3 in to network" that lists out the steps to updated a channel configuration.
While running the final step to update 
" peer channel update -f batch_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA"

it fails with below error

2020-01-11 19:41:29.563 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/BatchSize not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied


Please help me out if possible urgently since I have to deliver this in another 10-12 hours.


Re: How to achieve channels isolation on RAFT orderers?

Mr.Phuwanai Thummavet
 

The easiest way to do is to use two private data collection, first is A-B collection and second is B-C collection. This way, all the three orgs can join the same channel or different channels with the private collections without concerning about the orderer nodes at all.

With the private collection, each data collection will only be disseminated p2p to only authorized orgs and the private data will not be passed through any orderer node like the way the public data transactions are performed.

On Thu, 9 Jan 2020, 22:44 Aleksandr Kochetkov, <aleksandr.kochetkov@...> wrote:

3 parties, each have a peer and orderer:

peer.a, orderer.a, peer.b, orederer.b, peer.c, orderer.c

Orderers operating in Raft mode.

2 channels exists A-B, B-C.

Goal is to isolate data flow, so organization C don’t have any access to channel A-B, same for A and channel B-C.


Is it possible to configure orderers in such manner, that orderer.c will not receive and store blocks from channel A-B, and respectively orderer.a from B-C?

 


Re: How to achieve channels isolation on RAFT orderers?

naeemo
 

You may create 3 orderer orgs, ordererOrgA, ordererOrgB, ordererOrgC.
Each of them has one orderer. This way ordererOrgC's orderer doesn't
participate in the A-B channel at all.

I may be wrong, correct me if so.


Re: How to achieve channels isolation on RAFT orderers?

ravinayag .
 

where does Orderer b / org b sit ? Can it sit On multiple syschannels? 

Thanks


On Fri, 10 Jan 2020, 23:18 Yueming Xu, <yxucolo@...> wrote:
It appears that each orderer keeps blocks of each channel, would this mean that the orderer.c will see transactions on the A-B channel, and so will orderer.a see transactions on the B-C channel?  If it does, to prevent orderer.c from reading data on the A-B channel, each org would have to run multiple orderers, and so the A-B network will include only orderers of org-A and org-B.  Or you can put sensitive data in private collections that only org-A and org-B can read.


Re: How to achieve channels isolation on RAFT orderers?

Yueming Xu
 

It appears that each orderer keeps blocks of each channel, would this mean that the orderer.c will see transactions on the A-B channel, and so will orderer.a see transactions on the B-C channel?  If it does, to prevent orderer.c from reading data on the A-B channel, each org would have to run multiple orderers, and so the A-B network will include only orderers of org-A and org-B.  Or you can put sensitive data in private collections that only org-A and org-B can read.


Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 01/10/2020 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 10 January 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


Migrating from Solo to Kafka

Suhan Sumeet
 

Hello Team,

Is it possible to replace/migrate ordering service of a established hyperledger fabric network from solo to kafka or do we have to set a complete new network with kafka.



Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 01/10/2020 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 10 January 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: chaincode 2.0 problems

Jay Guo
 

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








JIRA Cleanup

Matthew Sykes
 

As part of our v2 shutdown (and my own new year resolution to be better about doing my chores), we'll be doing some work to close out old JIRA work items.

Over the next few days, open items that have not had a meaningful update in more than 9 months will be tagged with a 'stale-item' label. One week after that process has completed, any open items with that label will be closed out.

If a JIRA item you are interested in gets tagged and you want to stop it from being closed, please comment on the issue with information about why it is still relevant and remove the tag. This will indicate further discussion is warranted and we will defer closing the item pending that discussion.

Since the issues are simply being closed and not deleted, if something falls through the crack, we can always reopen as necessary.

Thanks.

--
Matthew Sykes

4001 - 4020 of 11512