Date   

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


User Group Recording: Implementing Enterprise Distributed Apps with HLF

Lauren Fournier
 

A new video is available from the Hyperledger Kansas City User Group December meeting.

Video Topic: Where Hyperledger Blockchains Fit Into Enterprise Development // Accessing and Implementing Distributed Apps (DApps) with Hyperledger Fabric 

Abstract: Speaker David Pitt discusses where he feels the Hyperledger blockchain fits into modern business applications and how they can be architected. He gives an overview of Hyperledger Fabric and shows how it can be used to benefit enterprise due to its tamper-proof and distributed nature. David also introduces an open-source reference blockchain with a real healthcare use case applicable to global data sharing, Byzantine Flu.

This one-hour talk can be split into two parts - part one is the presentation and reference blockchain overview, part two has Q&A with user group attendees to ensure understanding of presented concepts.

View the video on Youtube here - https://youtu.be/iaS89MgYJIw

We hope that you find the video helpful. Posted with permission.
-- 

Lauren Fournier
Director - Operations, Recruiting & Marketing
Keyhole Software
Direct: (913) 530-4193 lfournier@... 
Connect With Keyhole: LinkedIn | GitHub | Facebook | Twitter

Mentoring, Training & Development Consulting: https://keyholesoftware.com

Software Tools & Services for Enterprise Development: https://keyholelabs.com


Documentation Workgroup: Agenda for Friday, 10 Jan. First call of 2020!

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

Happy 2020 to all!

We will restart our regular documentation workgroup call this Friday, both Western and Eastern hemispheres.  This is the first call of 2020, and a big welcome to everyone who'd like to attend.

You can read the summary minutes for our last meeting of 2019: https://wiki.hyperledger.org/display/fabric/Meetings

This call was great -- with Joe going through the proposed rework of the operations guide, and thoughts on integration of Fabric CA documentation.  You can catch up via the recording: https://wiki.hyperledger.org/display/fabric/Recordings

You'll see that there are lots of interesting items for this week: https://wiki.hyperledger.org/display/fabric/2020+01+10+DWG+Agenda
Please feel free to contribute using the wiki!

You can also help build the our next agenda: https://wiki.hyperledger.org/display/fabric/2020+01+17+DWG+Agenda

Really looking forward to more great work on Fabric documentation in 2020!

Pam, Anthony,  Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 110A: Friday 10 Jan
                    1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 110B: Friday 10 Jan
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1300 Brasil Time (BRT)
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: chaincode 2.0 problems

Jay Guo
 

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: How to achieve channels isolation on RAFT orderers?

Yacov
 

Just make a channel with only a single organization, or alternatively - create a channel with all organizations and then remove the organizations you don't want.



From:        "Aleksandr Kochetkov" <aleksandr.kochetkov@...>
To:        fabric@...
Date:        01/09/2020 05:47 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] How to achieve channels isolation on RAFT orderers?
Sent by:        fabric@...




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?

 




How to achieve channels isolation on RAFT orderers?

Aleksandr Kochetkov
 

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: chaincode 2.0 problems

email4tong@gmail.com
 

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: chaincode 2.0 problems

Jay Guo
 

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

"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

"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: chaincode 2.0 problems

Tong Li
 

Thanks David and Nikhil for your response. I took David's suggestion and sent to multiple peers for commit which went through successfully. Then I tried the lifecycle chaincode approveformyorg command and lifecycle chaincode install few more times, here is what I found.

1. Chaincode can be installed multiple times, if the chaincode package never changes, the returned package id will be the same. No errors.
2. Command chaincode lifecycle approveformyorg behaves like this (at least from what I can figure):
a.) one peer in the org can only approve the chaincode one time
b.) the other peer in the org can also approve the chaincode but the sequence number has to increase by 1, this is after chaincode has been committed.
c.) once the chaincode gets approved by a peer, that peer can not approve it the 2nd time. If you try the 2nd time, it will give you the same error like below:

2020-01-08 16:31:53.754 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [af84dab09c428471a87aad3e9f921b8f876ecdc69b6b0b05fdf42d621cd3e31a] committed with status (ENDORSEMENT_POLICY_FAILURE) at
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

The behavior at 2 is a bit different from what David suggested earlier, I wonder if I misunderstood David's point. My endorsement policy is using the Majority.

Thanks so much for your response.


Tong Li
IBM Open Technology

"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is 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

"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: chaincode 2.0 problems

Nikhil Gupta
 

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

"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: about fabric-sdk-java

yaojian@vip.taxchina.com <yaojian@...>
 

Thank you! when I use Hex.encodeHexString ,and I get result is:  �Ub�˥q��]���;�ؙ�vʖL��V,�   to
039e1ea7added4b84ad0b9c58989535c92c8e4ab3d1a4d8ed9cbc279a34ce21c

I found the value is :
{common.Block.header=number: 1
previous_hash: "\357\200Ub\001\230\313\245q\204\254]\016\267\372\373;\346\330\231\362\265v\312\226L\303\316V\033,\354"
data_hash: "\003\236\036\247\255\336\324\270J\320\271\305\211\211S\\\222\310\344\253=\032M\216\331\313\302y\243L\342\034"
, common.Block.data=data: "\n\354{\n\314\006\n\025\b\001\032\006\b\227\304\347\357\005\"\tmychannel\022\262\006\n\225\006\n\nOrdererMSP\022\206\006-----BEGIN CERTIFICATE-----\nMIICDTCCAbOgAwIBAgIRAPiZpAvIpl3Z4ksQU0m/5e4wCgYIKoZIzj0EAwIwaTEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xFDASBgNVBAoTC2V4YW1wbGUuY29tMRcwFQYDVQQDEw5jYS5leGFt\ncGxlLmNvbTAeFw0xOTEyMTgwNzI0MDBaFw0yOTEyMTUwNzI0MDBaMFgxCzAJBgNV\nBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNp\nc2NvMRwwGgYDVQQDExNvcmRlcmVyLmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYI\nKoZIzj0DAQcDQgAEEUuCetao6Hb/Kgk4wfgiNFlQLKO9PiFb3bpdkFqlQBrg+9De\ngFqJB2lfPZsOAoWF60+Z6CrHTGEOMuNMZxoqLKNNMEswDgYDVR0PAQH/BAQDAgeA\nMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAg7elSCdPCLWsmgqUQwCkIEk3GTnTX\nPtao/Uf3/ldbN5wwCgYIKoZIzj0EAwIDSAAwRQIhAOxwImMmboNI/UHSbv4VZZ3b\nCwhcoLwdCdPAuYvzBXMgAiAEyRTqu7I1jK09K1Z9v+3rV3C+32eQn7p+psnGMtsT\nAg==\n-----END CERTIFICATE-----\n\022\030z\031M\236\316T\362\n\220\325o&\301\354`\035\035\206\334Y\254\266m\347\022\232u\n\257d\b\002\022\252d\022\340\027\n\aOrderer\022\324\027\022\203\025\n\nOrdererOrg\022\364\024\032\311\023\n\003MSP\022\301\023\022\266\023\022\263\023\n\nOrdererMSP\022\302\006-----BEGIN CERTIFICATE-----\nMIICPDCCAeOgAwIBAgIQBbg6CzfM0vLrLgRPjJEapDAKBggqhkjOPQQDAjBpMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xFzAVBgNVBAMTDmNhLmV4YW1w\nbGUuY29tMB4XDTE5MTIxODA3MjQwMFoXDTI5MTIxNTA3MjQwMFowaTELMAkGA1UE\nBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lz\nY28xFDASBgNVBAoTC2V4YW1wbGUuY29tMRcwFQYDVQQDEw5jYS5leGFtcGxlLmNv\nbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOnYXV2XEOPks5g6aHk3b9gaGoQN\nFdN0DRl3vtEdAvMUavy7jHz5OvxaeyJMjXWc/M9PDR4UnKpJiQmKYr2oa86jbTBr\nMA4GA1UdDwEB/wQEAwIBpjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEw\nDwYDVR0TAQH/BAUwAwEB/zApBgNVHQ4EIgQg7elSCdPCLWsmgqUQwCkIEk3GTnTX\nPtao/Uf3/ldbN5wwCgYIKoZIzj0EAwIDRwAwRAIgQN51s39yD0/24ktLTpfy4R/U\ntjFDjHhpo4ZfKgFNvZ4CIE6UgOfNyBKMUc6s+WDYJTalLxwpSh8G1DL3ySB/KI1z\n-----END CERTIFICATE-----\n\"\201\006-----BEGIN CERTIFICATE-----\nMIICCjCCAbCgAwIBAgIQSIGz9ilAatFhImiBzlyNbjAKBggqhkjOPQQDAjBpMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xFzAVBgNVBAMTDmNhLmV4YW1w\nbGUuY29tMB4XDTE5MTIxODA3MjQwMFoXDTI5MTIxNTA3MjQwMFowVjELMAkGA1UE\nBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lz\nY28xGjAYBgNVBAMMEUFkbWluQGV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQgAErnDfNo4LxvpfBlZ72V1RFSlOBAJOSyvRq5XWUapkNlTZl7Uq5cLj\nL7NFVos+SWUAqkzOm/xM32zJHYAIQ8/ERKNNMEswDgYDVR0PAQH/BAQDAgeAMAwG\nA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAg7elSCdPCLWsmgqUQwCkIEk3GTnTXPtao\n/Uf3/ldbN5wwCgYIKoZIzj0EAwIDSAAwRQIhAI6uobZmYL3fhQqt6XojvSUIfbA8\nTG47KHfnNxk1mZnmAiBsA0I4i1moqMLdv61QoG8puE/Bh6/1XnAPfWuxJkS17A==\n-----END CERTIFICATE-----\nB\016\n\004SHA2\022\006SHA256J\313\006-----BEGIN CERTIFICATE-----\nMIICQjCCAemgAwIBAgIQRuuTG2aC3EQJW9uZQ/Pw6jAKBggqhkjOPQQDAjBsMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xGjAYBgNVBAMTEXRsc2NhLmV4\nYW1wbGUuY29tMB4XDTE5MTIxODA3MjQwMFoXDTI5MTIxNTA3MjQwMFowbDELMAkG\nA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFu\nY2lzY28xFDASBgNVBAoTC2V4YW1wbGUuY29tMRowGAYDVQQDExF0bHNjYS5leGFt\ncGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABKBokX5gzh5DNURi+Y+C\nUDYi/mTJFbYY5/yNC4LciwgeIfs8J7XTZX9Jaj9Rea3Uk3jEAOHTLEOLZfioazHe\nnV6jbTBrMA4GA1UdDwEB/wQEAwIBpjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB\nBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zApBgNVHQ4EIgQgMO2R5LWmjG+yXobfmcwv\n4d33sQvsCB82PYLulSNApLYwCgYIKoZIzj0EAwIDRwAwRAIgUnhDMOUtwgVZNn+j\nkWR/37144HGVoR3wggnGlI147sMCIA2ReXP5ijfGlbVM32OHUL00eRIj0MfE1kF+\nVWjcN0Yb\n-----END CERTIFICATE-----\n\032\006Admins\"3\n\aReaders\022(\022\036\b\001\022\032\022\b\022\006\b\001\022\002\b\000\032\016\022\f\n\nOrdererMSP\032\006Admins\"3\n\aWriters\022(\022\036\b\001\022\032\022\b\022\006\b\001\022\002\b\000\032\016\022\f\n\nOrdererMSP\032\006Admins\"4\n\006Admins\022*\022 \b\001\022\034\022\b\022\006\b\001\022\002\b\000\032\020\022\016\n\nOrdererMSP\020\001\032\006Admins*\006Admins\032$\n\fCapabilities\022\024\022\n\n\b\n\004V1_1\022\000\032\006Admins\032!\n\rConsensusType\022\020\022\006\n\004solo\032\006Admins\032\"\n\tBatchSize\022\025\022\v\b\n\020\200\200\3001\030\200\200 \032\006Admins\032\036\n\fBatchTimeout\022\016\022\004\n\0022s\032\006Admins\032\037\n\023ChannelRestrictions\022\b\032\006Admins\"\"\n\aWriters\022\027\022\r\b\003\022\t\n\aWriters\032\006Admins\"\"\n\006Admins\022\030\022\016\b\003\022\n\n\006Admins\020\002\032\006Admins\"*\n\017BlockValidation\022\027\022\r\b\003\022\t\n\aWriters\032\006Admins\"\"\n\aReaders\022\027\022\r\b\003\022\t\n\aReaders\032\006Admins*\006Admins\022\334I\n\vApplication\022\314I\b\001\022\256$\n\aOrg1MSP\022\242$\b\001\0326\n\vAnchorPeers\022\'\022\035\n\033\n\026peer0.org1.example.com\020\2137\032\006Admins\032\211\"\n\003MSP\022\201\"\022\366!\022\363!\n\aOrg1MSP\022\337\006-----BEGIN CERTIFICATE-----\nMIICUTCCAfigAwIBAgIRAN2pHcYcB81x7+UWVhBxq90wCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzEuZXhhbXBsZS5jb20wHhcNMTkxMjE4MDcyNDAwWhcNMjkxMjE1MDcyNDAw\nWjBzMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UE\nAxMTY2Eub3JnMS5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA\nBG88/ai6ngvYbFkQVUwb4eblrbQQ1z/s3r1QBw4kLpMg3Svigq1CZLBXX5mbseq4\nfXRUH1dhdFwjwwVRvZ11T02jbTBrMA4GA1UdDwEB/wQEAwIBpjAdBgNVHSUEFjAU\nBggrBgEFBQcDAgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zApBgNVHQ4EIgQg\nigN42EMp0Y2MvB4BYe2o0Rdvt0QVDJB1AP5RJf873SgwCgYIKoZIzj0EAwIDRwAw\nRAIhALQ4zjaJb0n2M298cl4qiCEh+YWvq4Ism3PQq/yzAkIrAh98dXuuwsPZXI7j\n/EEHGueYFy6lnqkZ0trGC7UnK9Vn\n-----END CERTIFICATE-----\n\"\252\006-----BEGIN CERTIFICATE-----\nMIICKTCCAdCgAwIBAgIQB26XMhFoCdJzFujgzXC6tTAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xOTEyMTgwNzI0MDBaFw0yOTEyMTUwNzI0MDBa\nMGwxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMQ8wDQYDVQQLEwZjbGllbnQxHzAdBgNVBAMMFkFkbWluQG9y\nZzEuZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASiLz7BaGsS\nCUKFO47LKFB+5iVQ9xkfzt7UnpYAU//Q/KgYZ5iNnsIBJIh0XI4VKoSt4CLf+UVB\nCZqLOQG4Dnono00wSzAOBgNVHQ8BAf8EBAMCB4AwDAYDVR0TAQH/BAIwADArBgNV\nHSMEJDAigCCKA3jYQynRjYy8HgFh7ajRF2+3RBUMkHUA/lEl/zvdKDAKBggqhkjO\nPQQDAgNHADBEAiBEglNixpmBGK7nKFGALhZ5E0nwQzUl0U2Kyo9s7YQAkAIgRvwJ\nMzQ2lg4mnOfXft/WARBKBHcS3i4jOmoJU0C2vXo=\n-----END CERTIFICATE-----\nB\016\n\004SHA2\022\006SHA256J\353\006-----BEGIN CERTIFICATE-----\nMIICWDCCAf6gAwIBAgIRAKAu+NZzaELW7iKf4ENosbAwCgYIKoZIzj0EAwIwdjEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHzAdBgNVBAMTFnRs\nc2NhLm9yZzEuZXhhbXBsZS5jb20wHhcNMTkxMjE4MDcyNDAwWhcNMjkxMjE1MDcy\nNDAwWjB2MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UE\nBxMNU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEfMB0G\nA1UEAxMWdGxzY2Eub3JnMS5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABANqpYxkIYADQukLCUjTkXSCFFvkNjl7MDy9Tj41S2Gr8e1aG3NIXzkR\nwtbL+nFbq7r84HCC3LCv3gF54utvvCyjbTBrMA4GA1UdDwEB/wQEAwIBpjAdBgNV\nHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zApBgNV\nHQ4EIgQgzHpV2qHN1CbJPogJE8q+aBfE+62J9p4I12CT9nv5jzcwCgYIKoZIzj0E\nAwIDSAAwRQIhANKioHOvmHtWLkE9kWyiyweks99pfkWA5yf005czwm9/AiBGFdPM\nBY0M0hvU/P/FrTzS9VWL4B3WOfLCIYua0Coayg==\n-----END CERTIFICATE-----\nZ\332\r\b\001\022\352\006\n\337\006-----BEGIN CERTIFICATE-----\nMIICUTCCAfigAwIBAgIRAN2pHcYcB81x7+UWVhBxq90wCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzEuZXhhbXBsZS5jb20wHhcNMTkxMjE4MDcyNDAwWhcNMjkxMjE1MDcyNDAw\nWjBzMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UE\nAxMTY2Eub3JnMS5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA\nBG88/ai6ngvYbFkQVUwb4eblrbQQ1z/s3r1QBw4kLpMg3Svigq1CZLBXX5mbseq4\nfXRUH1dhdFwjwwVRvZ11T02jbTBrMA4GA1UdDwEB/wQEAwIBpjAdBgNVHSUEFjAU\nBggrBgEFBQcDAgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zApBgNVHQ4EIgQg\nigN42EMp0Y2MvB4BYe2o0Rdvt0QVDJB1AP5RJf873SgwCgYIKoZIzj0EAwIDRwAw\nRAIhALQ4zjaJb0n2M298cl4qiCEh+YWvq4Ism3PQq/yzAkIrAh98dXuuwsPZXI7j\n/EEHGueYFy6lnqkZ0trGC7UnK9Vn\n-----END CERTIFICATE-----\n\022\006client\032\350\006\n\337\006-----BEGIN CERTIFICATE-----\nMIICUTCCAfigAwIBAgIRAN2pHcYcB81x7+UWVhBxq90wCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzEuZXhhbXBsZS5jb20wHhcNMTkxMjE4MDcyNDAwWhcNMjkxMjE1MDcyNDAw\nWjBzMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UE\nAxMTY2Eub3JnMS5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA\nBG88/ai6ngvYbFkQVUwb4eblrbQQ1z/s3r1QBw4kLpMg3Svigq1CZLBXX5mbseq4\nfXRUH1dhdFwjwwVRvZ11T02jbTBrMA4GA1UdDwEB/wQEAwIBpjAdBgNVHSUEFjAU\nBggrBgEFBQcDAgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zApBgNVHQ4EIgQg\nigN42EMp0Y2MvB4BYe2o0Rdvt0QVDJB1AP5RJf873SgwCgYIKoZIzj0EAwIDRwAw\nRAIhALQ4zjaJb0n2M298cl4qiCEh+YWvq4Ism3PQq/yzAkIrAh98dXuuwsPZXI7j\n/EEHGueYFy6lnqkZ0trGC7UnK9Vn\n-----END CERTIFICATE-----\n\022\004peer\032\006Admins\"E\n\aWriters\022:\0220\b\001\022,\022\f\022\n\b\001\022\002\b\000\022\002\b\001\032\r\022\v\n\aOrg1MSP\020\001\032\r\022\v\n\aOrg1MSP\020\002\032\006Admins\"1\n\006Admins\022\'\022\035\b\001\022\031\022\b\022\006\b\001\022\002\b\000\032\r\022\v\n\aOrg1MSP\020\001\032\006Admins\"X\n\aReaders\022M\022C\b\001\022?\022\020\022\016\b\001\022\002\b\000\022\002\b\001\022\002\b\002\032\r\022\v\n\aOrg1MSP\020\001\032\r\022\v\n\aOrg1MSP\020\003\032\r\022\v\n\aOrg1MSP\020\002\032\006Admins*\006Admins\022\374#\n\aOrg2MSP\022\360#\032\221\"\n\003MSP\022\211\"\022\376!\022\373!\n\aOrg2MSP\022\343\006-----BEGIN CERTIFICATE-----\nMIICUjCCAfigAwIBAgIRALxag1/Wbk0DTWaDzFbSypIwCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzIuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzIuZXhhbXBsZS5jb20wHhcNMTkxMjE4MDcyNDAwWhcNMjkxMjE1MDcyNDAw\nWjBzMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQb3JnMi5leGFtcGxlLmNvbTEcMBoGA1UE\nAxMTY2Eub3JnMi5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA\nBNV+bYW5iQG4n1N9tFbqWmB3xQqLAHo/HMoxbNmt4+423/6Um5HateXBVNulUxtC\nsS9ioHHzgps4lgKb7ZMw0kSjbTBrMA4GA1UdDwEB/wQEAwIBpjAdBgNVHSUEFjAU\nBggrBgEFBQcDAgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zApBgNVHQ4EIgQg\nv6NzWecmbIFV8dZxgkQH2jtOQCLCBszcgynY8WJ5QTIwCgYIKoZIzj0EAwIDSAAw\nRQIhALuJ/r3Car4k9c7cMDGOcqW+k/cMWoMV9MxfS3XVdevtAiAj+p344RZHUdHL\nVC2U6yz7xVI+XhwCWHYkLll6RZeuwA==\n-----END CERTIFICATE-----\n\"\252\006-----BEGIN CERTIFICATE-----\nMIICKTCCAdCgAwIBAgIQYSJSBhy0uCO9h8gA+i/6VzAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMi5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMi5leGFtcGxlLmNvbTAeFw0xOTEyMTgwNzI0MDBaFw0yOTEyMTUwNzI0MDBa\nMGwxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMQ8wDQYDVQQLEwZjbGllbnQxHzAdBgNVBAMMFkFkbWluQG9y\nZzIuZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARZsvrIeih8\nQIdJuwCIvo6kt7TuZ7ng3PCzrDpShIVOdti/zGfQxfBLNFqRAMHkCh4BElNA/Xwk\nyn6T1YmzDPiBo00wSzAOBgNVHQ8BAf8EBAMCB4AwDAYDVR0TAQH/BAIwADArBgNV\nHSMEJDAigCC/o3NZ5yZsgVXx1nGCRAfaO05AIsIGzNyDKdjxYnlBMjAKBggqhkjO\nPQQDAgNHADBEAiAfx0qWp/6TP5YlB0Adc1zXcgA9tLkCDoQmTl8PmBB9CgIgFSkh\nERlPX2/9EkAxplcAJQp/TUoXiY7jnuC8xH9rwto=\n-----END CERTIFICATE-----\nB\016\n\004SHA2\022\006SHA256J\347\006-----BEGIN CERTIFICATE-----\nMIICVjCCAf2gAwIBAgIQMwVO2y0v5amf1Yp0APrQGjAKBggqhkjOPQQDAjB2MQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMi5leGFtcGxlLmNvbTEfMB0GA1UEAxMWdGxz\nY2Eub3JnMi5leGFtcGxlLmNvbTAeFw0xOTEyMTgwNzI0MDBaFw0yOTEyMTUwNzI0\nMDBaMHYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQH\nEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBvcmcyLmV4YW1wbGUuY29tMR8wHQYD\nVQQDExZ0bHNjYS5vcmcyLmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0D\nAQcDQgAEW2QwpqIFiJLmfIj6AAkRNSQq+/QiZyK5kA/NAdsbbSvosMSVV0b6plFh\n4YryprqQ2oMT2Lh4Q9NTqWg+aIqcMaNtMGswDgYDVR0PAQH/BAQDAgGmMB0GA1Ud\nJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAPBgNVHRMBAf8EBTADAQH/MCkGA1Ud\nDgQiBCB6VtFH+QDqaY2tlPfZDcoMHSP9AaRkBK35wHJ3FMxaXjAKBggqhkjOPQQD\nAgNHADBEAiBN86C6obdIx58vycU1Wptwydvzgotd2IVJz35pMFSV4QIgQHdW03hK\n1twgUEARxfKzJQY6+aTqELAfhq028Wwpx4Y=\n-----END CERTIFICATE-----\nZ\342\r\b\001\022\356\006\n\343\006-----BEGIN CERTIFICATE-----\nMIICUjCCAfigAwIBAgIRALxag1/Wbk0DTWaDzFbSypIwCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzIuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzIuZXhhbXBsZS5jb20wHhcNMTkxMjE4MDcyNDAwWhcNMjkxMjE1MDcyNDAw\nWjBzMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQb3JnMi5leGFtcGxlLmNvbTEcMBoGA1UE\nAxMTY2Eub3JnMi5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA\nBNV+bYW5iQG4n1N9tFbqWmB3xQqLAHo/HMoxbNmt4+423/6Um5HateXBVNulUxtC\nsS9ioHHzgps4lgKb7ZMw0kSjbTBrMA4GA1UdDwEB/wQEAwIBpjAdBgNVHSUEFjAU\nBggrBgEFBQcDAgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zApBgNVHQ4EIgQg\nv6NzWecmbIFV8dZxgkQH2jtOQCLCBszcgynY8WJ5QTIwCgYIKoZIzj0EAwIDSAAw\nRQIhALuJ/r3Car4k9c7cMDGOcqW+k/cMWoMV9MxfS3XVdevtAiAj+p344RZHUdHL\nVC2U6yz7xVI+XhwCWHYkLll6RZeuwA==\n-----END CERTIFICATE-----\n\022\006client\032\354\006\n\343\006-----BEGIN CERTIFICATE-----\nMIICUjCCAfigAwIBAgIRALxag1/Wbk0DTWaDzFbSypIwCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzIuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzIuZXhhbXBsZS5jb20wHhcNMTkxMjE4MDcyNDAwWhcNMjkxMjE1MDcyNDAw\nWjBzMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQb3JnMi5leGFtcGxlLmNvbTEcMBoGA1UE\nAxMTY2Eub3JnMi5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA\nBNV+bYW5iQG4n1N9tFbqWmB3xQqLAHo/HMoxbNmt4+423/6Um5HateXBVNulUxtC\nsS9ioHHzgps4lgKb7ZMw0kSjbTBrMA4GA1UdDwEB/wQEAwIBpjAdBgNVHSUEFjAU\nBggrBgEFBQcDAgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zApBgNVHQ4EIgQg\nv6NzWecmbIFV8dZxgkQH2jtOQCLCBszcgynY8WJ5QTIwCgYIKoZIzj0EAwIDSAAw\nRQIhALuJ/r3Car4k9c7cMDGOcqW+k/cMWoMV9MxfS3XVdevtAiAj+p344RZHUdHL\nVC2U6yz7xVI+XhwCWHYkLll6RZeuwA==\n-----END CERTIFICATE-----\n\022\004peer\032\006Admins\"E\n\aWriters\022:\0220\b\001\022,\022\f\022\n\b\001\022\002\b\000\022\002\b\001\032\r\022\v\n\aOrg2MSP\020\001\032\r\022\v\n\aOrg2MSP\020\002\032\006Admins\"1\n\006Admins\022\'\022\035\b\001\022\031\022\b\022\006\b\001\022\002\b\000\032\r\022\v\n\aOrg2MSP\020\001\032\006Admins\"X\n\aReaders\022M\022C\b\001\022?\022\020\022\016\b\001\022\002\b\000\022\002\b\001\022\002\b\002\032\r\022\v\n\aOrg2MSP\020\001\032\r\022\v\n\aOrg2MSP\020\003\032\r\022\v\n\aOrg2MSP\020\002\032\006Admins*\006Admins\032$\n\fCapabilities\022\024\022\n\n\b\n\004V1_3\022\000\032\006Admins\"\"\n\006Admins\022\030\022\016\b\003\022\n\n\006Admins\020\002\032\006Admins\"\"\n\aReaders\022\027\022\r\b\003\022\t\n\aReaders\032\006Admins\"\"\n\aWriters\022\027\022\r\b\003\022\t\n\aWriters\032\006Admins*\006Admins\032$\n\fCapabilities\022\024\022\n\n\b\n\004V1_3\022\000\032\006Admins\032*\n\nConsortium\022\034\022\022\n\020SampleConsortium\032\006Admins\032&\n\020HashingAlgorithm\022\022\022\b\n\006SHA256\032\006Admins\032-\n\031BlockDataHashingStructure\022\020\022\006\b\377\377\377\377\017\032\006Admins\032I\n\020OrdererAddresses\0225\022\032\n\030orderer.example.com:7050\032\027/Channel/Orderer/Admins\"\"\n\aWriters\022\027\022\r\b\003\022\t\n\aWriters\032\006Admins\"\"\n\006Admins\022\030\022\016\b\003\022\n\n\006Admins\020\002\032\006Admins\"\"\n\aReaders\022\027\022\r\b\003\022\t\n\aReaders\032\006Admins*\006Admins\022\345\020\n\232\020\n\355\006\n\025\b\002\032\006\b\227\304\347\357\005\"\tmychannel\022\323\006\n\266\006\n\aOrg1MSP\022\252\006-----BEGIN CERTIFICATE-----\nMIICKTCCAdCgAwIBAgIQB26XMhFoCdJzFujgzXC6tTAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xOTEyMTgwNzI0MDBaFw0yOTEyMTUwNzI0MDBa\nMGwxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMQ8wDQYDVQQLEwZjbGllbnQxHzAdBgNVBAMMFkFkbWluQG9y\nZzEuZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASiLz7BaGsS\nCUKFO47LKFB+5iVQ9xkfzt7UnpYAU//Q/KgYZ5iNnsIBJIh0XI4VKoSt4CLf+UVB\nCZqLOQG4Dnono00wSzAOBgNVHQ8BAf8EBAMCB4AwDAYDVR0TAQH/BAIwADArBgNV\nHSMEJDAigCCKA3jYQynRjYy8HgFh7ajRF2+3RBUMkHUA/lEl/zvdKDAKBggqhkjO\nPQQDAgNHADBEAiBEglNixpmBGK7nKFGALhZ5E0nwQzUl0U2Kyo9s7YQAkAIgRvwJ\nMzQ2lg4mnOfXft/WARBKBHcS3i4jOmoJU0C2vXo=\n-----END CERTIFICATE-----\n\022\030ba\276\335`~\353\347\320\242\036\235\306\022\024\224\350[\032\021\356\262Y\235\022\247\t\n\202\002\n\tmychannel\022W\022U\n\vApplication\022F\b\001\022:\n\aOrg1MSP\022/\032\a\n\003MSP\022\000\"\v\n\aReaders\022\000\"\v\n\aWriters\022\000\"\n\n\006Admins\022\000*\006Admins\032\233\001\022\230\001\n\vApplication\022\210\001\b\001\022|\n\aOrg1MSP\022q\b\001\032\a\n\003MSP\022\000\0326\n\vAnchorPeers\022\'\022\035\n\033\n\026peer0.org1.example.com\020\2137\032\006Admins\"\v\n\aWriters\022\000\"\n\n\006Admins\022\000\"\v\n\aReaders\022\000*\006Admins*\006Admins\022\237\a\n\323\006\n\266\006\n\aOrg1MSP\022\252\006-----BEGIN CERTIFICATE-----\nMIICKTCCAdCgAwIBAgIQB26XMhFoCdJzFujgzXC6tTAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xOTEyMTgwNzI0MDBaFw0yOTEyMTUwNzI0MDBa\nMGwxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMQ8wDQYDVQQLEwZjbGllbnQxHzAdBgNVBAMMFkFkbWluQG9y\nZzEuZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASiLz7BaGsS\nCUKFO47LKFB+5iVQ9xkfzt7UnpYAU//Q/KgYZ5iNnsIBJIh0XI4VKoSt4CLf+UVB\nCZqLOQG4Dnono00wSzAOBgNVHQ8BAf8EBAMCB4AwDAYDVR0TAQH/BAIwADArBgNV\nHSMEJDAigCCKA3jYQynRjYy8HgFh7ajRF2+3RBUMkHUA/lEl/zvdKDAKBggqhkjO\nPQQDAgNHADBEAiBEglNixpmBGK7nKFGALhZ5E0nwQzUl0U2Kyo9s7YQAkAIgRvwJ\nMzQ2lg4mnOfXft/WARBKBHcS3i4jOmoJU0C2vXo=\n-----END CERTIFICATE-----\n\022\030\273f\272Z\024\243\257\321o\250\254\235D;\260\017\t\261@>\021\253:c\022G0E\002!\000\305\2059x\272\322\tjiF\tV\253\257\"\245\376\360\036\257W\320\350\022\366\272\365\257\231\234S\216\002  //:\300\n6M\021J\022\327\020&\361\022\256\276k=\027\250\'\214\307\244;\337\020\341\307\251\022F0D\002 |<\201C\204\372\365!R\"\212<\210\237q\a\240\362J\035\\\3068\226\021\225N \266\016d\265\002 :K\317\205\356_p1\017\353\213MF\\\363\2023PS\344\326\t\323\265z\0259\354\215\031Mw\022F0D\002 *\000V\345E\260\2711<\2213\330\354\226p\035\270h,\317\250T^L\201(5M?\345\237\332\002 NF\342\267\256lN\231u\0163vH\265\223+\'\332Z\275]\246\244\347\222\236\366 X7\2511"
, common.Block.metadata=metadata: "\022\375\006\n\262\006\n\225\006\n\nOrdererMSP\022\206\006-----BEGIN CERTIFICATE-----\nMIICDTCCAbOgAwIBAgIRAPiZpAvIpl3Z4ksQU0m/5e4wCgYIKoZIzj0EAwIwaTEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xFDASBgNVBAoTC2V4YW1wbGUuY29tMRcwFQYDVQQDEw5jYS5leGFt\ncGxlLmNvbTAeFw0xOTEyMTgwNzI0MDBaFw0yOTEyMTUwNzI0MDBaMFgxCzAJBgNV\nBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNp\nc2NvMRwwGgYDVQQDExNvcmRlcmVyLmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYI\nKoZIzj0DAQcDQgAEEUuCetao6Hb/Kgk4wfgiNFlQLKO9PiFb3bpdkFqlQBrg+9De\ngFqJB2lfPZsOAoWF60+Z6CrHTGEOMuNMZxoqLKNNMEswDgYDVR0PAQH/BAQDAgeA\nMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAg7elSCdPCLWsmgqUQwCkIEk3GTnTX\nPtao/Uf3/ldbN5wwCgYIKoZIzj0EAwIDSAAwRQIhAOxwImMmboNI/UHSbv4VZZ3b\nCwhcoLwdCdPAuYvzBXMgAiAEyRTqu7I1jK09K1Z9v+3rV3C+32eQn7p+psnGMtsT\nAg==\n-----END CERTIFICATE-----\n\022\030\004\216\017o\204~\3267\351\331\244\225\023\202\361\253\317vvzG\244\214\024\022F0D\002 w0\205\2305R;\310y\245\220\a\207\300\342!G}\346\006RH\021\031\366\223\234\326\234\276>\202\002 z,\311\254\324\276M\254$\322}\265\221DP%L\343\242\031-~P(\244\236\313:\327^\r\a"
metadata: "\n\002\b\001\022\375\006\n\262\006\n\225\006\n\nOrdererMSP\022\206\006-----BEGIN CERTIFICATE-----\nMIICDTCCAbOgAwIBAgIRAPiZpAvIpl3Z4ksQU0m/5e4wCgYIKoZIzj0EAwIwaTEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xFDASBgNVBAoTC2V4YW1wbGUuY29tMRcwFQYDVQQDEw5jYS5leGFt\ncGxlLmNvbTAeFw0xOTEyMTgwNzI0MDBaFw0yOTEyMTUwNzI0MDBaMFgxCzAJBgNV\nBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNp\nc2NvMRwwGgYDVQQDExNvcmRlcmVyLmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYI\nKoZIzj0DAQcDQgAEEUuCetao6Hb/Kgk4wfgiNFlQLKO9PiFb3bpdkFqlQBrg+9De\ngFqJB2lfPZsOAoWF60+Z6CrHTGEOMuNMZxoqLKNNMEswDgYDVR0PAQH/BAQDAgeA\nMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAg7elSCdPCLWsmgqUQwCkIEk3GTnTX\nPtao/Uf3/ldbN5wwCgYIKoZIzj0EAwIDSAAwRQIhAOxwImMmboNI/UHSbv4VZZ3b\nCwhcoLwdCdPAuYvzBXMgAiAEyRTqu7I1jK09K1Z9v+3rV3C+32eQn7p+psnGMtsT\nAg==\n-----END CERTIFICATE-----\n\022\030\263I\0223Qv\302AS\n72+\200t\306\aw6\231\322s7\243\022F0D\002 2\320\353o\314\n\345\245|\324~\353\346:R\025O\250\221\200\215\266\a\272d\362\030\326\334\240\244\025\002 Y|\315t/j\343\360lae.\272j\016\312bn\230\267z\361\224u\275B\234p\004\372T\327"
metadata: "\000"
metadata: ""
}


how can I get the right value from above?


Re: about fabric-sdk-java

Jay Guo
 

I think you need to Hex.encodeHexString byte array

- J

On Wed, Jan 8, 2020 at 8:44 PM yaojian@... <yaojian@...> wrote:
hi :
 I am chinese ,my english is not good!
I use the method queryblockbynumber in fabric SDK java to get the block information
But the previoushash obtained is like this : �Ub �˥q��] ���;�ؙ�vʖL��V ,�


I don't know why? and I found that all the values in blockinfo are like this, What should I do to get the normal value?

Thanks ! please ask me quickly,Because I've learned that it can't go on! Thanks ! Thanks! Thanks!




about fabric-sdk-java

yaojian@...
 

hi :
 I am chinese ,my english is not good!
I use the method queryblockbynumber in fabric SDK java to get the block information
But the previoushash obtained is like this : �Ub�˥q��]���;�ؙ�vʖL��V,�


I don't know why? and I found that all the values in blockinfo are like this, What should I do to get the normal value?

Thanks ! please ask me quickly,Because I've learned that it can't go on! Thanks ! Thanks! Thanks!



yaojian@...


Re: Regarding system chaincodes

Jay Guo
 

On Wed, Jan 8, 2020 at 3:56 PM <amalcs2311@...> wrote:

Hi,
When the system chaincodes are invoked? Can you please share the file flow in the system chaincode invocation?


Re: Regarding Client Orderer communication

Jay Guo
 

On Wed, Jan 8, 2020 at 3:54 PM <amalcs2311@...> wrote:

Hi,
In Hyperledger Fabric after receiving endorser responses how the client send it to orderer? Please give me a detailed flow to understand how the client request is reached to orderer?

4021 - 4040 of 11518