Date   

Is it efficient when "Upgrade Chaincode New Docker Container will be created"?

Kimheng SOK
 

Dear all,

I would like to ask about hyperledger performance related to chaincode upgrade. 

Each time when we upgrade the new chaincode, a new docker container will be created.
Do you think this is an optimal way to go?

Will hyperledger continue to adopt this concept, or may be modified to other solutions?
If YES why and if NO what is the alternative solution in mind?

Bests,


Re: chaincode 2.0 problems

David Enyeart
 

This is not an issue with the submitting client credentials, it is an issue with the peer credentials not matching the org credentials in the channel config.

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

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

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

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

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

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

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


Dave Enyeart

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

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





Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of  CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, 

` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at 
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` 

The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, 

` Error: proposal failed with status: 500 - Failed to authorize invocation due to failed ACL check: Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]` 
I tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? 

Thank you!
BR,
Indirajith.

On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
    Jason pointed out the problem:

    > You tried to approve the same definition twice, completely unmodified. This produced an empty write-set, because nothing changed. Since there was no change to a specific collection, but because we had to pick _some_ endorsement policy to validate your tx with, you get the default for `_lifecycle`.

    opened FAB-17371 for this

    - J


On Fri, Jan 10, 2020 at 1:02 AM Jay Guo via Lists.Hyperledger.Org <guojiannan1101=gmail.com@...> wrote:
I'm using byfn w/o any modification

- J

On Thu, Jan 9, 2020 at 9:25 PM <email4tong@...> wrote:
    Jay, how does your policy look like for both org and channel? Thanks.




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

        - J

        On Thu, Jan 9, 2020 at 12:46 AM Tong Li <litong01@...> wrote:
        Thanks David and Nikhil for your response. I took David's suggestion and sent to multiple peers for commit which went through successfully. Then I tried the lifecycle chaincode approveformyorg command and lifecycle chaincode install few more times, here is what I found.

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

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

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

        Thanks so much for your response.


        Tong Li
        IBM Open Technology

        Inactive hide details for"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distrib

        From: "Nikhil Gupta" <negupta@...>
        To: "David Enyeart" <enyeart@...>
        Cc: "Tong Li" <litong01@...>, fabric@...
        Date: 01/08/2020 08:53 AM
        Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
        Sent by: fabric@...




        The approval is at the Org level. You only need to target one peer, and then the approval is distributed to other peers using gossip.

        The endorsement error also pops up if you try to commit a different chaincode definition than the one that was approved.



        -----fabric@... wrote: -----
        To: "Tong Li" <litong01@...>
        From: "David Enyeart"
        Sent by: fabric@...
        Date: 01/08/2020 12:28AM
        Cc: fabric@...
        Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

        1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem...

        2. Your LifecycleEndorsement policy is:

        LifecycleEndorsement:
        Type: ImplicitMeta
        Rule: "MAJORITY Endorsement"

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

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


        Dave Enyeart

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

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





        Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

        1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

        {
        "approvals": {
        "org0examplecom": true,
        "org1examplecom": true
        }
        }

        That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

        peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
        2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
        2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
        Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

        Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

        2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

        ---
        Organizations:
        - &examplecom
        Name: examplecom
        ID: examplecom
        MSPDir: keyfiles/ordererOrganizations/example.com/msp
        Policies:
        Readers:
        Type: Signature
        Rule: "OR('examplecom.member')"
        Writers:
        Type: Signature
        Rule: "OR('examplecom.member')"
        Admins:
        Type: Signature
        Rule: "OR('examplecom.admin')"
        - &org0examplecom
        Name: org0examplecom
        ID: org0examplecom
        MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
        Policies:
        Readers:
        Type: Signature
        Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
        Writers:
        Type: Signature
        Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
        Admins:
        Type: Signature
        Rule: "OR('org0examplecom.admin')"
        Endorsement:
        Type: Signature
        Rule: "OR('org0examplecom.peer')"

        AnchorPeers:
        - Host: peer1.org0.example.com
        Port: 7051
        - Host: peer2.org0.example.com
        Port: 7051
        - &org1examplecom
        Name: org1examplecom
        ID: org1examplecom
        MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
        Policies:
        Readers:
        Type: Signature
        Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
        Writers:
        Type: Signature
        Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
        Admins:
        Type: Signature
        Rule: "OR('org1examplecom.admin')"
        Endorsement:
        Type: Signature
        Rule: "OR('org1examplecom.peer')"

        AnchorPeers:
        - Host: peer1.org1.example.com
        Port: 7051
        - Host: peer2.org1.example.com
        Port: 7051

        Capabilities:
        Channel: &ChannelCapabilities
        V2_0: true

        Orderer: &OrdererCapabilities
        V2_0: true

        Application: &ApplicationCapabilities
        V2_0: true

        Application: &ApplicationDefaults
        Organizations:
        Policies:
        Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
        Writers:
        Type: ImplicitMeta
        Rule: "ANY Writers"
        Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"
        LifecycleEndorsement:
        Type: ImplicitMeta
        Rule: "MAJORITY Endorsement"
        Endorsement:
        Type: ImplicitMeta
        Rule: "MAJORITY Endorsement"

        Capabilities:
        <<: *ApplicationCapabilities

        Orderer: &OrdererDefaults
        OrdererType: etcdraft

        Addresses:
        - orderer1.example.com:7050
        - orderer2.example.com:7050
        - orderer3.example.com:7050

        BatchTimeout: 2s

        BatchSize:
        MaxMessageCount: 10
        AbsoluteMaxBytes: 99 MB
        PreferredMaxBytes: 512 KB

        EtcdRaft:
        Consenters:
        - Host: orderer1.example.com
        Port: 7050
        ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
        ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
        - Host: orderer2.example.com
        Port: 7050
        ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
        ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
        - Host: orderer3.example.com
        Port: 7050
        ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
        ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

        Organizations:
        Policies:
        Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
        Writers:
        Type: ImplicitMeta
        Rule: "ANY Writers"
        Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"
        BlockValidation:
        Type: ImplicitMeta
        Rule: "ANY Writers"

        Channel: &ChannelDefaults
        Policies:
        Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
        Writers:
        Type: ImplicitMeta
        Rule: "ANY Writers"
        Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"

        Capabilities:
        <<: *ChannelCapabilities

        Profiles:
        OrgChannel:
        Consortium: SampleConsortium
        <<: *ChannelDefaults
        Application:
        <<: *ApplicationDefaults
        Organizations:
        - *org0examplecom
        - *org1examplecom
        Capabilities:
        <<: *ApplicationCapabilities

        OrdererGenesis:
        <<: *ChannelDefaults
        Capabilities:
        <<: *ChannelCapabilities
        Orderer:
        <<: *OrdererDefaults
        Organizations:
        - *examplecom
        Capabilities:
        <<: *OrdererCapabilities
        Application:
        <<: *ApplicationDefaults
        Organizations:
        - <<: *examplecom
        Consortiums:
        SampleConsortium:
        Organizations:
        - *org0examplecom
        - *org1examplecom


        Tong Li
        IBM Open Technology









Re: chaincode 2.0 problems

indirajith
 

Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of  CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, 

` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at 
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` 

The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, 

` Error: proposal failed with status: 500 - Failed to authorize invocation due to failed ACL check: Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]` 
I tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? 

Thank you!
BR,
Indirajith.

On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
Jason pointed out the problem:

> You tried to approve the same definition twice, completely unmodified. This produced an empty write-set, because nothing changed. Since there was no change to a specific collection, but because we had to pick _some_ endorsement policy to validate your tx with, you get the default for `_lifecycle`.

opened FAB-17371 for this

- J


On Fri, Jan 10, 2020 at 1:02 AM Jay Guo via Lists.Hyperledger.Org <guojiannan1101=gmail.com@...> wrote:
I'm using byfn w/o any modification

- J

On Thu, Jan 9, 2020 at 9:25 PM <email4tong@...> wrote:
Jay, how does your policy look like for both org and channel? Thanks.




On Thursday, January 9, 2020, 4:47 AM, Jay Guo <guojiannan1101@...> wrote:

I could reproduce this by approving the same definition twice (with same seq). It seems that the first approval is validated with /Channel/Application/Org1MSP/Endorsement, although the second is validate with /Channel/Application/LifecycleEndorsement

- J

On Thu, Jan 9, 2020 at 12:46 AM Tong Li <litong01@...> wrote:

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

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

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

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

Thanks so much for your response.


Tong Li
IBM Open Technology

Inactive hide details for"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distrib

From: "Nikhil Gupta" <negupta@...>
To: "David Enyeart" <enyeart@...>
Cc: "Tong Li" <litong01@...>, fabric@...
Date: 01/08/2020 08:53 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
Sent by: fabric@...





The approval is at the Org level. You only need to target one peer, and then the approval is distributed to other peers using gossip.

The endorsement error also pops up if you try to commit a different chaincode definition than the one that was approved.



-----fabric@... wrote: -----
To: "Tong Li" <litong01@...>
From: "David Enyeart"
Sent by: fabric@...
Date: 01/08/2020 12:28AM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem...

2. Your LifecycleEndorsement policy is:

LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"

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

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


Dave Enyeart

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

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





Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

{
"approvals": {
"org0examplecom": true,
"org1examplecom": true
}
}

That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

---
Organizations:
- &examplecom
Name: examplecom
ID: examplecom
MSPDir: keyfiles/ordererOrganizations/example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('examplecom.member')"
Writers:
Type: Signature
Rule: "OR('examplecom.member')"
Admins:
Type: Signature
Rule: "OR('examplecom.admin')"
- &org0examplecom
Name: org0examplecom
ID: org0examplecom
MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
Writers:
Type: Signature
Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
Admins:
Type: Signature
Rule: "OR('org0examplecom.admin')"
Endorsement:
Type: Signature
Rule: "OR('org0examplecom.peer')"

AnchorPeers:
- Host: peer1.org0.example.com
Port: 7051
- Host: peer2.org0.example.com
Port: 7051
- &org1examplecom
Name: org1examplecom
ID: org1examplecom
MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
Writers:
Type: Signature
Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
Admins:
Type: Signature
Rule: "OR('org1examplecom.admin')"
Endorsement:
Type: Signature
Rule: "OR('org1examplecom.peer')"

AnchorPeers:
- Host: peer1.org1.example.com
Port: 7051
- Host: peer2.org1.example.com
Port: 7051

Capabilities:
Channel: &ChannelCapabilities
V2_0: true

Orderer: &OrdererCapabilities
V2_0: true

Application: &ApplicationCapabilities
V2_0: true

Application: &ApplicationDefaults
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"

Capabilities:
<<: *ApplicationCapabilities

Orderer: &OrdererDefaults
OrdererType: etcdraft

Addresses:
- orderer1.example.com:7050
- orderer2.example.com:7050
- orderer3.example.com:7050

BatchTimeout: 2s

BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB

EtcdRaft:
Consenters:
- Host: orderer1.example.com
Port: 7050
ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
- Host: orderer2.example.com
Port: 7050
ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
- Host: orderer3.example.com
Port: 7050
ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"

Channel: &ChannelDefaults
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"

Capabilities:
<<: *ChannelCapabilities

Profiles:
OrgChannel:
Consortium: SampleConsortium
<<: *ChannelDefaults
Application:
<<: *ApplicationDefaults
Organizations:
- *org0examplecom
- *org1examplecom
Capabilities:
<<: *ApplicationCapabilities

OrdererGenesis:
<<: *ChannelDefaults
Capabilities:
<<: *ChannelCapabilities
Orderer:
<<: *OrdererDefaults
Organizations:
- *examplecom
Capabilities:
<<: *OrdererCapabilities
Application:
<<: *ApplicationDefaults
Organizations:
- <<: *examplecom
Consortiums:
SampleConsortium:
Organizations:
- *org0examplecom
- *org1examplecom


Tong Li
IBM Open Technology








Re: Why does the Ordering Consensus Work?

Gari Singh <garis@...>
 

Transaction consensus and validity in Fabric is not the same thing as the consensus mechanism used to build a fault tolerant ordering service.

Have a look at https://hyperledger-fabric.readthedocs.io/en/release-2.0/txflow.html which describes the entire Fabric transaction flow ... this would be considered consensus for Fabric transactions. At a high-level, it is comprised of:

- execute chaincode and collect endorsements
- submit for ordering
- ordering service orders and batches into blocks
- ordering service pushes blocks to peers on a per channel basis
- peers validate and commit transactions
- check that endorsement policy has been satisfied (which means that enough peers executed chaincode with the same results based on policy)
- check for collisions using an MVCC-like model (aka double-spend)
- if valid, update state


The ordering service itself uses a consensus algorithm itself to make sure that all ordering nodes produce batches/blocks with the same transactions in the same order.

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

-----fabric@... wrote: -----
To: <fabric@...>
From: "Trevor Lee Oakley"
Sent by: fabric@...
Date: 02/06/2020 03:30AM
Subject: [EXTERNAL] [Hyperledger Fabric] Why does the Ordering Consensus Work?


From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process?

Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow?


Trevor


Re: Why does the Ordering Consensus Work?

Brett T Logan <brett.t.logan@...>
 

The ordering services job is to assemble blocks from transactions and determine the final order of the transactions. It doesn't participate in the validation of the endorsed transactions.
 
Once the orderer disseminates the block to the peer, the peer validates the signatures, verifies that its endorsements match their expected origin, and that the state of the transaction matches the current state given the current values in the ledger (the state of a key hasn't changed since the proposal was submitted for endorsement as the result of an in-flight transaction).
 
Your transaction has (assuming it was valid) already passed your endorsement policy, the result of the smart contracts doesn't have to match for all proposals. This is why we write deterministic chaincode, to prevent chaincode from arriving at different results.
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Trevor Lee Oakley" <trevor@...>
Sent by: fabric@...
To: <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Why does the Ordering Consensus Work?
Date: Wed, Feb 5, 2020 10:30 PM
 
 
From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process?
 
Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow?
 
 
Trevor
 
 


Why does the Ordering Consensus Work?

Trevor Lee Oakley <trevor@...>
 

 
From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process?
 
Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow?
 
 
Trevor
 


Registrar enrollment and registration #fabric-sdk-go

Amal C Saji
 

Hi,
I am using the example https://github.com/chainHero/heroes-service/  with fabric-sdk-go beta version.
When I try to register a new user, registrar part have same issues. I can't register a registrar. The post request return some errors
"Client sent an HTTP request to an HTTPS server.
: invalid character 'C' looking for beginning of value"


Fabric contributor meeting - February 5th 14:00 GMT

David Enyeart
 

For the contributor meeting scheduled for tomorrow, we'll do a quick project update, but there are no deep dive topics scheduled yet. If you have a proposal or other topic you'd like to discuss, please let us know here or on RocketChat fabric-maintainers.

As always, find agenda and call details at https://wiki.hyperledger.org/display/fabric/Contributor+Meetings.


Thanks,

Dave Enyeart


Re: Error when joining the channel

Nikhil Gupta
 

Hi Marina,

I would check the order log to see what the problems are. You can find some help with what to look for with this stack overflow post: https://stackoverflow.com/questions/57662562/when-i-try-to-create-a-channel-using-hyperledger-fabric-the-request-fails/57662645#57662645

My guess is that your org does not have permission to create a channel in the orderer system channel. or is not a member of the system channel consortium.



-----fabric@... wrote: -----
To: "hyperledger-fabric@..." <hyperledger-fabric@...>
From: "Marina Wanis"
Sent by: fabric@...
Date: 02/01/2020 04:37AM
Subject: [EXTERNAL] [Hyperledger Fabric] Error when joining the channel

Hi,

 

I used to be able to create the channel using the channel transaction and join the channel with the command :

peer channel join -o localhost:7050 -b ./acmechannel.block

 

I got the following error:

 

2020-02-01 09:24:48.338 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized

Error: proposal failed (err: rpc error: code = Unknown desc = access denied: channel [] creator org [Org1MSP])

 

I made sure that the identity of the peer is admin. I’m really not sure why I keep getting this error.

Thank you,

Marina

 

Sent from Mail for Windows 10

 



Re: How to set regulator or auditor in private data collection

David Enyeart
 

In v2.0 we are promoting this pattern of org-specific collections, where the per organization collections implicitly exist so that you don't have to define them at all.
I agree with your thought - if every one of the implicit collections should have a regulator (or another party) as well, then it should be possible to specify this once, not per collection.

We have also considered implicit collections that could represent any combination of organizations, for example where the collection name would be a hash of the concatenated MSPIDs, and could be referenced without any upfront chaincode or channel configuration. As the number of combinations would still explode for large channels, it may still be necessary for organizations to indicate in peer config which of the implicit collections they are interested in participating in, but this would still be easier to manage than in chaincode or channel config.

Anyways, there's lots of things we *could* do in this space, but let's carefully consider what we *should* do. I'd encourage you to open a Jira and explain the use case more fully. Share the Jira number here and let's see if others expand on it with further requirements or opinions.


Thanks,

Dave Enyeart

"胡 银松" ---02/04/2020 01:51:43 AM--- Thank you for your explanation. I now understand it clearly. But this would cost huge efforts

From: "胡 银松" <huyinsong@...>
To: David Enyeart <enyeart@...>
Cc: "fabric@..." <fabric@...>
Date: 02/04/2020 01:51 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] How to set regulator or auditor in private data collection
Sent by: fabric@...





Thank you for your explanation. I now understand it clearly.

But this would cost huge efforts to maintain private data collections in production environment if there are hundreds of private data collections.
How about pre-define a regulator or auditor, the private data collection will include this pre-defined regulator or auditor in the collection configuration period. So we don’t need to define every private data collection to include it. It will be automatically included in every private data collection. That would be more simple and useful for massive private data collection configuration in production environment.

      On Feb 4, 2020, at 1:54 PM, David Enyeart <enyeart@...> wrote:

      A regulator or auditor would be modeled as any other organization.

      Example: Channel includes four organizations: 'Org1', 'Org2', 'Org3', 'regulator'.

      Create Org1Collection that includes (Org1, regulator) in the private data distribution "policy" and "endorsementPolicy".
      Create Org2Collection that includes (Org2, regulator) in the private data distribution "policy" and "endorsementPolcy".
      Create Org3Collection that includes (Org3, regulator) in the private data distribution "policy" and "endorsementPolcy".

      Org1Collection would have properties as:

      "policy": "OR('Org1.peer', 'regulator.peer')"
      "endorsementPolicy": {
      "signaturePolicy": "AND('Org1.peer', 'regulator.peer')"
      },

      This implies that any private data written to Org1Collection requires endorsement from a 'Org1' peer AND a 'regulator' peer. And the private data will get distributed to any peer belonging to 'Org1' OR 'regulator'.

      See collection definition doc at https://hyperledger-fabric.readthedocs.io/en/release-2.0/private-data-arch.html#private-data-collection-definition.


      Dave Enyeart

      <graycol.gif>"胡 银松" ---02/03/2020 11:55:26 PM---Hi All, The fabric doc said: “Fabric v2.0 also enables new patterns for working with and sharing

      From:
      "胡 银松" <huyinsong@...>
      To:
      "fabric@..." <fabric@...>
      Date:
      02/03/2020 11:55 PM
      Subject:
      [EXTERNAL] [Hyperledger Fabric] How to set regulator or auditor in private data collection
      Sent by:
      fabric@...





      Hi All,
      The fabric doc said: “Fabric v2.0 also enables new patterns for working with and sharing private data, without the requirement of creating private data collections for all combinations of channel members that may want to transact. Specifically, instead of sharing private data within a collection of multiple members, you may want to share private data across collections, where each collection may include a single organization, or perhaps a single organization along with a regulator or auditor”.

      I wonder how to set regulator or auditor along with a single organization when using private data in Fabric 2.0?
      Is there any sample to tell how to do this?







Re: How to set regulator or auditor in private data collection

胡 银松
 

   Thank you for your explanation. I now understand it clearly. 
    
   But this would cost  huge efforts to maintain private data collections  in production environment if there are hundreds of private data collections.
   How about pre-define a regulator or auditor, the private data collection will include this pre-defined regulator or auditor in the collection configuration period. So we don’t need to define every private data collection to include it. It will be automatically included in every private data collection. That would be more simple and useful for massive private data collection configuration in  production environment.

On Feb 4, 2020, at 1:54 PM, David Enyeart <enyeart@...> wrote:

A regulator or auditor would be modeled as any other organization.

Example: Channel includes four organizations: 'Org1', 'Org2', 'Org3', 'regulator'.

Create Org1Collection that includes (Org1, regulator) in the private data distribution "policy" and "endorsementPolicy".
Create Org2Collection that includes (Org2, regulator) in the private data distribution "policy" and "endorsementPolcy".
Create Org3Collection that includes (Org3, regulator) in the private data distribution "policy" and "endorsementPolcy".

Org1Collection would have properties as:

"policy": "OR('Org1.peer', 'regulator.peer')"
"endorsementPolicy": {
"signaturePolicy": "AND('Org1.peer', 'regulator.peer')"
},

This implies that any private data written to Org1Collection requires endorsement from a 'Org1' peer AND a 'regulator' peer. And the private data will get distributed to any peer belonging to 'Org1' OR 'regulator'.

See collection definition doc at https://hyperledger-fabric.readthedocs.io/en/release-2.0/private-data-arch.html#private-data-collection-definition.


Dave Enyeart

<graycol.gif>"胡 银松" ---02/03/2020 11:55:26 PM---Hi All, The fabric doc said: “Fabric v2.0 also enables new patterns for working with and sharing

From: "胡 银松" <huyinsong@...>
To: "fabric@..." <fabric@...>
Date: 02/03/2020 11:55 PM
Subject: [EXTERNAL] [Hyperledger Fabric] How to set regulator or auditor in private data collection
Sent by: fabric@...





Hi All,
The fabric doc said: “Fabric v2.0 also enables new patterns for working with and sharing private data, without the requirement of creating private data collections for all combinations of channel members that may want to transact. Specifically, instead of sharing private data within a collection of multiple members, you may want to share private data across collections, where each collection may include a single organization, or perhaps a single organization along with a regulator or auditor”.

I wonder how to set regulator or auditor along with a single organization when using private data in Fabric 2.0?
Is there any sample to tell how to do this?





Re: Potential project in need of BFT orderers #consensus #fabric-orderer

Brian Behlendorf <bbehlendorf@...>
 

Excellent, thanks!  I should have piped up on this earlier when I saw the call for mass-closure of old issues.

Brian

On 2/3/20 10:18 PM, David Enyeart wrote:

To clarify, as Jason mentioned the Jira FAB-33 got caught up in a recent mass cleanup of stale issues that hadn't been touched in a long time. Any issue that was automatically closed in error can be re-opened, we simply ask that a comment be added to explain the rationale for re-opening. I've re-opened FAB-33 and commented that it is targeted for a future release.

Jason is correct that for major features, Jiras will typically be created after an RFC is merged, and they will cross reference each other. But if a Jira already exists for an item that is intended to be worked, I see no problem keeping the Jira open and tagged as Future.


Dave Enyeart

"Brian Behlendorf" ---02/03/2020 01:24:35 PM---You really should use a different status for deferred feature requests than "Closed", because "deci

From: "Brian Behlendorf" <bbehlendorf@...>
To: fabric@...
Date: 02/03/2020 01:24 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Potential project in need of BFT orderers #consensus #fabric-orderer
Sent by: fabric@...





You really should use a different status for deferred feature requests than "Closed", because "decided not to implement this ever" is a closer inference from "Closed" than "maybe someday".  Jira is depended upon as a future-feature-request tool by lots of other projects and asking people to know it's differently treated at Fabric is another cognitive burden to new contributors.  At the very least I suggest updating FAB-33 with a link to new work.

Brian

On 2/3/20 7:44 AM, Jason Yellick wrote:
      I've seen some similar confusion to this on Rocketchat as well.

      FAB-33 was closed along with hundreds of other items in an overall cleanup of JIRA.  Its closure does not indicate any mothballing or abandonment of BFT efforts, in fact, there's been considerably more activity in the space in the recent months; particularly there are some ongoing efforts to develop a golang BFT consensus library that is compatible with Fabric.

      JIRA can be a good tool for tracking the progress of a designed, approved, and mid-implementation item, but it's the wrong place to look for future work.  Future work is to be submitted and approved as an RFC 
      https://github.com/hyperledger/fabric-rfcs/ so I would watch that space for updates.

      Thanks,
      ~Jason

       
      ----- Original message -----
      From:
      atom@...
      Sent by:
      fabric@...
      To:
      fabric@...
      Cc:
      Subject: [EXTERNAL] [Hyperledger Fabric] Potential project in need of BFT orderers #consensus #fabric-orderer
      Date: Sun, Feb 2, 2020 6:16 PM
       

      We are leading a standardization effort within SunSpec.org to utilize blockchain for securing the distributed power grid in the US.

      https://sunspec.org/sunspec-alliance-advances-security-for-distributed-energy-resource-systems/

      Fabric could be a good candidate for this effort but we need BFT in the orderer nodes.  It looks like this effort has been mothballed to an extent:

      https://jira.hyperledger.org/browse/FAB-33

      What are the options for revitalizing this effort?

      Thanks,
      Alfred
      Wivity Inc.

       

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf





-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Potential project in need of BFT orderers #consensus #fabric-orderer

David Enyeart
 

To clarify, as Jason mentioned the Jira FAB-33 got caught up in a recent mass cleanup of stale issues that hadn't been touched in a long time. Any issue that was automatically closed in error can be re-opened, we simply ask that a comment be added to explain the rationale for re-opening. I've re-opened FAB-33 and commented that it is targeted for a future release.

Jason is correct that for major features, Jiras will typically be created after an RFC is merged, and they will cross reference each other. But if a Jira already exists for an item that is intended to be worked, I see no problem keeping the Jira open and tagged as Future.


Dave Enyeart

"Brian Behlendorf" ---02/03/2020 01:24:35 PM---You really should use a different status for deferred feature requests than "Closed", because "deci

From: "Brian Behlendorf" <bbehlendorf@...>
To: fabric@...
Date: 02/03/2020 01:24 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Potential project in need of BFT orderers #consensus #fabric-orderer
Sent by: fabric@...





You really should use a different status for deferred feature requests than "Closed", because "decided not to implement this ever" is a closer inference from "Closed" than "maybe someday".  Jira is depended upon as a future-feature-request tool by lots of other projects and asking people to know it's differently treated at Fabric is another cognitive burden to new contributors.  At the very least I suggest updating FAB-33 with a link to new work.

Brian

On 2/3/20 7:44 AM, Jason Yellick wrote:
      I've seen some similar confusion to this on Rocketchat as well.

      FAB-33 was closed along with hundreds of other items in an overall cleanup of JIRA.  Its closure does not indicate any mothballing or abandonment of BFT efforts, in fact, there's been considerably more activity in the space in the recent months; particularly there are some ongoing efforts to develop a golang BFT consensus library that is compatible with Fabric.

      JIRA can be a good tool for tracking the progress of a designed, approved, and mid-implementation item, but it's the wrong place to look for future work.  Future work is to be submitted and approved as an RFC 
      https://github.com/hyperledger/fabric-rfcs/ so I would watch that space for updates.

      Thanks,
      ~Jason

       

----- Original message -----
From:
atom@...
Sent by:
fabric@...
To:
fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Potential project in need of BFT orderers #consensus #fabric-orderer
Date: Sun, Feb 2, 2020 6:16 PM
 

We are leading a standardization effort within SunSpec.org to utilize blockchain for securing the distributed power grid in the US.

https://sunspec.org/sunspec-alliance-advances-security-for-distributed-energy-resource-systems/

Fabric could be a good candidate for this effort but we need BFT in the orderer nodes.  It looks like this effort has been mothballed to an extent:

https://jira.hyperledger.org/browse/FAB-33

What are the options for revitalizing this effort?

Thanks,
Alfred
Wivity Inc.

 

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf





Re: How to set regulator or auditor in private data collection

David Enyeart
 

A regulator or auditor would be modeled as any other organization.

Example: Channel includes four organizations: 'Org1', 'Org2', 'Org3', 'regulator'.

Create Org1Collection that includes (Org1, regulator) in the private data distribution "policy" and "endorsementPolicy".
Create Org2Collection that includes (Org2, regulator) in the private data distribution "policy" and "endorsementPolcy".
Create Org3Collection that includes (Org3, regulator) in the private data distribution "policy" and "endorsementPolcy".

Org1Collection would have properties as:

"policy": "OR('Org1.peer', 'regulator.peer')"
"endorsementPolicy": {
"signaturePolicy": "AND('Org1.peer', 'regulator.peer')"
},

This implies that any private data written to Org1Collection requires endorsement from a 'Org1' peer AND a 'regulator' peer. And the private data will get distributed to any peer belonging to 'Org1' OR 'regulator'.

See collection definition doc at https://hyperledger-fabric.readthedocs.io/en/release-2.0/private-data-arch.html#private-data-collection-definition.


Dave Enyeart

"胡 银松" ---02/03/2020 11:55:26 PM---Hi All, The fabric doc said: “Fabric v2.0 also enables new patterns for working with and sharing

From: "胡 银松" <huyinsong@...>
To: "fabric@..." <fabric@...>
Date: 02/03/2020 11:55 PM
Subject: [EXTERNAL] [Hyperledger Fabric] How to set regulator or auditor in private data collection
Sent by: fabric@...





Hi All,
The fabric doc said: “Fabric v2.0 also enables new patterns for working with and sharing private data, without the requirement of creating private data collections for all combinations of channel members that may want to transact. Specifically, instead of sharing private data within a collection of multiple members, you may want to share private data across collections, where each collection may include a single organization, or perhaps a single organization along with a regulator or auditor”.

I wonder how to set regulator or auditor along with a single organization when using private data in Fabric 2.0?
Is there any sample to tell how to do this?




How to set regulator or auditor in private data collection

胡 银松
 

Hi All,
    The fabric doc said: “Fabric v2.0 also enables new patterns for working with and sharing private data, without the requirement of creating private data collections for all combinations of channel members that may want to transact. Specifically, instead of sharing private data within a collection of multiple members, you may want to share private data across collections, where each collection may include a single organization, or perhaps a single organization along with a regulator or auditor”.
    
   I wonder how to set regulator or auditor along with a single organization when using private data in Fabric 2.0?
   Is there any sample to tell how to do this?


Re: Customize chaincode docker image

Brett T Logan <brett.t.logan@...>
 

Part of the chaincode instantiation process is to compile the JAR, this isn't something you can hijack in 1.4.x without modifying the source code. Fabric v2.0 (which released last week) provides a framework for configuring and running chaincode however you want: https://hyperledger-fabric.readthedocs.io/en/master/cc_launcher.html
 
And, if you want to debug your chaincode containers you can forward their standard output to the peer container where you can grep the log for the chaincodes output. You can enable this by setting CORE_VM_DOCKER_ATTACHSTDOUT=true in your peer launch environment, but note, this is not meant for production purposes as it can leak sensitive information into the peer logs from broken or malicious code.
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: sanjaykumar3989@...
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Customize chaincode docker image
Date: Mon, Feb 3, 2020 6:47 PM
 
Hi,

Every time when i initiate the chaincode , it take time to build the jar. To skip this process for multiple times and to learn the flow of hyperledger CC flow, i am customizing the image.

Usually capturing the docker logs of the chaincode really helps in cases like this. - CC container get killed automatically. Is there is some way how i can capture the logs?
 


Re: Customize chaincode docker image

sanjaykumar3989@...
 

Hi,

Every time when i initiate the chaincode , it take time to build the jar. To skip this process for multiple times and to learn the flow of hyperledger CC flow, i am customizing the image.

Usually capturing the docker logs of the chaincode really helps in cases like this. - CC container get killed automatically. Is there is some way how i can capture the logs?


Re: Potential project in need of BFT orderers #consensus #fabric-orderer

Brian Behlendorf <bbehlendorf@...>
 

You really should use a different status for deferred feature requests than "Closed", because "decided not to implement this ever" is a closer inference from "Closed" than "maybe someday".  Jira is depended upon as a future-feature-request tool by lots of other projects and asking people to know it's differently treated at Fabric is another cognitive burden to new contributors.  At the very least I suggest updating FAB-33 with a link to new work.

Brian

On 2/3/20 7:44 AM, Jason Yellick wrote:
I've seen some similar confusion to this on Rocketchat as well.

FAB-33 was closed along with hundreds of other items in an overall cleanup of JIRA.  Its closure does not indicate any mothballing or abandonment of BFT efforts, in fact, there's been considerably more activity in the space in the recent months; particularly there are some ongoing efforts to develop a golang BFT consensus library that is compatible with Fabric.

JIRA can be a good tool for tracking the progress of a designed, approved, and mid-implementation item, but it's the wrong place to look for future work.  Future work is to be submitted and approved as an RFC https://github.com/hyperledger/fabric-rfcs/ so I would watch that space for updates.

Thanks,
~Jason
 
----- Original message -----
From: atom@...
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Potential project in need of BFT orderers #consensus #fabric-orderer
Date: Sun, Feb 2, 2020 6:16 PM
 

We are leading a standardization effort within SunSpec.org to utilize blockchain for securing the distributed power grid in the US.

https://sunspec.org/sunspec-alliance-advances-security-for-distributed-energy-resource-systems/

Fabric could be a good candidate for this effort but we need BFT in the orderer nodes.  It looks like this effort has been mothballed to an extent:

https://jira.hyperledger.org/browse/FAB-33

What are the options for revitalizing this effort?

Thanks,
Alfred
Wivity Inc.

 


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Potential project in need of BFT orderers #consensus #fabric-orderer

Jason Yellick <jyellick@...>
 

I've seen some similar confusion to this on Rocketchat as well.

FAB-33 was closed along with hundreds of other items in an overall cleanup of JIRA.  Its closure does not indicate any mothballing or abandonment of BFT efforts, in fact, there's been considerably more activity in the space in the recent months; particularly there are some ongoing efforts to develop a golang BFT consensus library that is compatible with Fabric.

JIRA can be a good tool for tracking the progress of a designed, approved, and mid-implementation item, but it's the wrong place to look for future work.  Future work is to be submitted and approved as an RFC https://github.com/hyperledger/fabric-rfcs/ so I would watch that space for updates.

Thanks,
~Jason
 

----- Original message -----
From: atom@...
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Potential project in need of BFT orderers #consensus #fabric-orderer
Date: Sun, Feb 2, 2020 6:16 PM
 

We are leading a standardization effort within SunSpec.org to utilize blockchain for securing the distributed power grid in the US.

https://sunspec.org/sunspec-alliance-advances-security-for-distributed-energy-resource-systems/

Fabric could be a good candidate for this effort but we need BFT in the orderer nodes.  It looks like this effort has been mothballed to an extent:

https://jira.hyperledger.org/browse/FAB-33

What are the options for revitalizing this effort?

Thanks,
Alfred
Wivity Inc.

 


Re: Private data : issues and problems #fabric #fabric-questions #fabric-dstorage

Yacov
 

> because the actual data is unknown to verifiers/endorsers

Well but you can have the endorsement policy be satisfied by a set of members that they are all in the collection policy.
Furthermore you can also have a custom endorsement policy for each collection.



From:        "Ivan Ch" <acizlan@...>
To:        fabric@...
Date:        02/03/2020 01:32 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Private data : issues and problems #fabric #fabric-questions #fabric-dstorage
Sent by:        fabric@...




I apologize for restarting this old topic, someone sent me a private message so I think the least I can do is to make the problem clear


On Wed, Dec 11, 2019 at 06:51 PM, Gari Singh wrote:
1) hashes on chain cannot be validated by any third party, so they can be used by adversaries to trick honest participants

How does this trick honest participants? When you deploy chaincode, you specify an endorsement policy. Transactions which dod not meet the endorsement policy will be marked as invalid. You need to take a look at the overall transaction flow in Fabric: https://hyperledger-fabric.readthedocs.io/en/release-1.4/txflow.html.
The validation rules for Fabric include:
- check to make sure the block is valid and that it was obtained from the correct orderer as specified in the channel definition
- check to make sure the submitter was allowed to actually submit the transaction (e.g. is allowed to write to the chaincode)
- check that the transaction meets the endorsement policy for the chaincode that was invoked
- perform MVCC check

In the case of private data, the steps are the same. If you are not a member of the collection, even though you do not have the actual data you still follow all of the rules above to validate the transaction (including the MVCC check). Not sure how someone can "trick" anyone if you have a strong endorsement policy (e.g. majority, etc).

This is no different than how private transactions work in Quorum, Besu or even Corda if you choose not to have the notary execute transactions.

The problem is that all the checks you mentioned above are checking something non-verifiable and therefore cannot be used to validate any business logic at all!!! because the actual data is unknown to verifiers/endorsers (who cares about endorsement policy if the endorser doesn't know whatever the heck he is endorsing. block, MVCC, and even transaction sender identity checks got nothing to do with the actual business logic).

of course if the data is in clear text than it would work, because then the endorsers would run the logic inside the chaincode to verify the business logic associated with the transactions being endorsed. Quorum has a host of problems but at least they are exploring crypto/ZKP options like the PoC they did with JPMorgan (to be fair, that was only a PoC, but at least it was a good attempt that fabric's been lacking).

the bottom line is Private data feature does not solve the data privacy problem (or any problem to be honest) but it is given a name and making people believe it does. this is unfortunate because fabric's endorsement architecture is actually a much better platform than anything ethereum to run ZKP cryptos.





3781 - 3800 of 11436